-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Comments
Re: Cache @retlehs Would you consider a command-line interface similar to Artisan? The dependency, Besides clearing blade caches, you could do things like |
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 |
@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 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 |
@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 // 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 |
@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 |
Apparently a too large cache folder slowed the site even on a fast production server to a crawl. |
via https://discourse.roots.io/t/issue-with-yarn-run-start-after-yarn-build-production/10779/6?u=benword
...also maybe move blade cache into theme directory by default?
The text was updated successfully, but these errors were encountered: