Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add command to clear Blade cache #1987

Closed
1 task done
retlehs opened this issue Oct 31, 2017 · 12 comments
Closed
1 task done

Add command to clear Blade cache #1987

retlehs opened this issue Oct 31, 2017 · 12 comments
Labels

Comments

@retlehs
Copy link
Sponsor Member

retlehs commented Oct 31, 2017

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’s the view:clear command and maybe there could be something similar for Sage to streamline situations like this.

...also maybe move blade cache into theme directory by default?

@webstractions
Copy link

webstractions commented Nov 1, 2017

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.

@mAAdhaTTah
Copy link

If that's something Sage wants to do, it should build on WP-CLI, imo.

@webstractions
Copy link

webstractions commented Nov 2, 2017

@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.

@alwaysblank
Copy link
Member

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

@webstractions
Copy link

@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.

@alwaysblank
Copy link
Member

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.

@webstractions
Copy link

@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.

@webstractions
Copy link

@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.

@webstractions
Copy link

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.

@cwahlfeldt
Copy link

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

@webstractions
Copy link

@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

@strarsis
Copy link
Contributor

Apparently a too large cache folder slowed the site even on a fast production server to a crawl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants