Core: Cache clean command

[luceos]

Let's re-add some cache cleaning through the artisan command.

This will prevent possible "oops" issues with users deleting the wrong folders. Folders/files to clear:

• assets/*.js
• assets/*.css
• storage/cache/* (recursive)

[tobyzerner]

:+1: An "advanced" page in admin CP with a button on it (among other things, like smtp settings) may also be worth thinking about.

[franzliedke]

I have basically implemented the console command.

Devs, please try it out (php flarum cache:clear) and make sure the cache directory is empty. I had some small permission problems, but that's because I didn't use chmod, my own fault.

@tobscure Should we consider the button in the admin panel to be part of this ticket or not? If not, it's done, I'd say. If yes, should we pull out the actual deletion logic into its own class that can be used by the console command and the respective admin controller?

[datitisev]

@franzliedke Shouldn't it remove the contents of storage/views, storage/less, storage/logs, etc??
As far as I'm aware, all in _storage/_ is cache...
Another point, it didn't remove anything in the storage/cache directory for me... although it might be because of the type file, all I did was copy files from _storage/views_ into _storage/cache_.
I don't know, just saying :smile:

[tobyzerner]

@franzliedke Looking good. But there's a little more to it than meets the eye.

Whenever we enable/disable an extension or change the theme we don't simply delete *.js and *.css files, we actually use the asset compiler classes to specifically delete the compiled assets. This is safer in case there are any userspace CSS/JS files dropped into the assets directory.

It's done by setting up per-client event listeners:
https://github.com/flarum/core/blob/master/src/Forum/ForumServiceProvider.php#L145
https://github.com/flarum/core/blob/master/src/Admin/AdminServiceProvider.php#L68

Perhaps the best thing to do here would be to make the cache:clear command fire an event (CacheWasCleared), and then add a listener to the Forum/AdminServiceProviders as above.

In addition to assets and the cache store, the command should also clear:

• The storage/formatter directory, which is used here. This should also be set up as an event listener in FormatterServiceProvider – the deletion itself should probably be added into the Formatter@flush method.
• The storage/tmp directory (actually, should we be garbage collecting this?)

Regarding the button in the admin interface, for now let's just add it to the Basics page. Then we can just make it fire the CacheWasCleared event, no?

[franzliedke]

@datitisev It's only removing directories inside the storage/cache directory, because that's what Laravel's cache driver writes in there. :)

Toby, thanks for the feedback. Will work on these things next.

[datitisev]

Oh, ok. Sorry for my misunderstanding, although I think the cache:clear command should also clear Laravel's cache, just in case :wink:

[franzliedke]

TODO: Make sure to clean the OpCache if enabled.

[luceos]

@franzliedke you already implemented this right? Why not close this one and add a follow up issue with improvements to the logic. This way we can keep issues limited in size and easier to solve.

[franzliedke]

Nah, it's not completely implemented yet.

[luceos]

So what's missing?

[tobyzerner]

@Luceos The event implementation I think (as outlined in my comment above)

[HavocKKS]

Isn't that feature already in B6 ?

[franzliedke]

@HavocKKS It's not quite done, as Toby explained above.

[franzliedke]

As noted in chat, we also need to remove the rev-manifest.json file in the assets directory.

[luceos]

The rev-manifest.json is causing so many issues it's causing a pretty high support load. We have to consider pushing onto the next release. Not deleting the rev-manifest.json will make browsers keep the old version in their cache.

[franzliedke]

Citing @tobscure from https://github.com/flarum/core/issues/881#issuecomment-348722857:

From my experience there is a bug in the asset compiler where the hash is only generated based on the modification timestamp of source files, but source strings are not taken into account.

So for example, if you alter custom LESS in the admin panel, the hash won't change and you'll need to clear your browser cache to force a reload.