via https://discourse.roots.io/t/issue-with-yarn-run-start-after-yarn-build-production/10779/6?u=benword
do you have any plans to make a command for clearing all the caches? In Laravel there鈥檚 the
view:clearcommand and maybe there could be something similar for Sage to streamline situations like this.
...also maybe move blade cache into theme directory by default?
Re: Cache
Currently, if you delete/replace a Sage theme _(yes, frogs do fly)_, there isn't a mechanism to remove the uploads/cache directory.
@retlehs Would you consider a command-line interface similar to Artisan? The dependency, Illuminate\Console, is already there via Sage Installer.
Besides clearing blade caches, you could do things like create:controller or create:view.
If that's something Sage wants to do, it should build on WP-CLI, imo.
@mAAdhaTTah Building on WP-CLI would require that its plugin be installed. The Console is already here, and serves a different purpose than WP-CLI.
EDIT: Just noticed that WP-CLI has limited support for Windows environments.
Haven't been able to figure out how to get at Illuminate\Console, but I've updated my Blade generator WP-CLI plugin with some methods for clearing the cache: https://github.com/alwaysblank/blade-generate
@alwaysblank Its being used in sage-installer for configuration, theme meta, and style presets. For some reason though, it does not work on Windows machines. There is a fix for that that Taylor Otwell used in Artisan.
Wrote a very, very simple tool as part of sage-lib that deletes Blade cache files in the theme directory (but you can pass it other directories if you want): https://github.com/alwaysblank/sage-lib/tree/add-blade-cache-manipulation (It assumes you're caching your blades in the theme directory, in cache/blades.) It re-uses a bunch of code from sage-installer for the Console stuff.
Unfortunately, all it really does is look at the directory you point it to and delete all the files it finds there. What I'd prefer to do (and what blade-generate does) is look at your Blade templates, determine what each template's cached file is, and then specifically delete only those files. Unfortunately, doing that here would require (as far as I can tell) pulling in and loading all the Blade classes and stuff manually (since I don't believe you can get access to stuff executed "in WordPress" inside of a Console session, and hence can't get at App\sage() in a nice way), and right now that's beyond my skill level. I'll probably keep banging my head against it since it's an interesting problem, but if anyone has suggestions/pointers/input, let me know.
@alwaysblank this looks promising.
I also ran into the same problem accessing sage() in a nice way. Will look at it later tonight and get back to you.
@alwaysblank Regarding App\sage() , I created a bootstrap file that just creates an instance of the Sage container, then passes that to a new Application.
// Require Composer autoloads
if (file_exists(__DIR__.'/../vendor/autoload.php')) {
require __DIR__.'/../vendor/autoload.php';
} else {
require __DIR__.'/../../../autoload.php';
}
// Get an instance of Sage Container. Script execution aborts if not Sage9 environment
$sage = \Roots\Sage\Container::getInstance();
$sage->isWordPress();
// Create app, bind Sage, and run it.
$app = new \App\Application( );
$app->setSage($sage);
$app->run();
For the application class, a property for the Sage container and a method to set it:
class Application extends BaseApplication
{
use Illuminate\Contracts\Container\Container;
...
/**
* Instance of Sage container.
*
* @param Illuminate\Contracts\Container\Container $sage
*/
protected $sage;
...
/**
* Set the Sage container.
*
* @param Illuminate\Contracts\Container\Container $sage
* @return void
*/
public function setSage(Container $sage = null)
{
$this->sage = $sage;
}
Now you should have access to Sage at any time.
I also have been playing around with Laravel Zero which is probably more for advanced use. It does add more dependencies for Config, Events, Cache, and other niceties.
This is for a wordpress site but i just run this command to clean it up once in a while rm -rf ../../uploads/cache && rm -rf ../../cache && composer dump-autoload
@cwahlfeldt A majority of the Sage developers seem to be using Macs, I am in the other 2 or 3 percent. ;)
The equivalent to your command in Windows would be
deltree /Y ../../uploads/cache && deltree /Y ../../cache && composer dump-autoload
Apparently a too large cache folder slowed the site even on a fast production server to a crawl.
Most helpful comment
@mAAdhaTTah Building on WP-CLI would require that its plugin be installed. The Console is already here, and serves a different purpose than WP-CLI.
EDIT: Just noticed that WP-CLI has limited support for Windows environments.