Bakery clear-cache doesn't clear twig cache

[lcharette]

The php bakery clear-cache command currently delete the illuminate cache instance, but not the route and Twig cache. This can cause confusion on production system.

[lcharette]

Plus, for some reason, apache might write to the cache folder with higher permission than the user executing bakery. This will make the command to throw this warning:

PHP Warning: file_put_contents(/var/www/blah/app/cache/cache_tags/userfrosting): failed to open stream: Permission denied in /var/www/blah/app/vendor/illuminate/filesystem/Filesystem.php on line 122

Should probably wrap that command in a try-catch

EDIT:
This error is now suppressed since the new display_errors_native config option. But the error is still there, no cache is cleared.

[alexweissman]

Ah yes, I have been experiencing this error myself. I know that in Linux-type systems, setfacl can be used to set default permissions for new files in a directory: https://learn.userfrosting.com/going-live/unix-primer-ubuntu#set-default-permissions

[lcharette]

The apache <-> Bakery user permission problem can also be handled by bakery asking apache to do it (using curl or similar method).

Filesystem could probably be used to manipulate that directory ?

[lcharette]

This issue is starting to annoy me. I even have an issue where if clear-cache is run by a normal Unix user on an empty cache dir, this will create the app/cache/cache_tags/ directory. Problem is, that directory will be owned by that normal Unix User and now Apache can't write to it, so cache based alerts are not showing anymore...

Anyone as an idea how we could handle clearing cache from bakery, i.e. the too issues:

• Clearing Twig and route cache
• Permission issue

[lcharette]

Ok so Laravel clear the route cache file directly : https://github.com/laravel/framework/blob/bd352a0d2ca93775fce8ef02365b03fc4fb8cbb0/src/Illuminate/Foundation/Console/RouteClearCommand.php#L51

As for the permission issue, I wonder why are they not created with 777 permission out of the box 🤔. Symfony does it, not sure about Laravel, since we're using their cache... oh wait...

[lcharette]

On the permission issue, just to keep a trace in case this show up again later :
There's nothing wrong with UF code or Laravel Filesystem. When UF custom TaggableFileStore defines the cache_tags directory, it goes though Laravel Filesystem component who does indeed create the folder using 777 permissions. However, php umask overwrite that mode and, in my case, make the folder with permission 755.There is a way to make it work by overwriting the default umask, but neither Laravel or UF has it implemented (and it should be done Laravel side).

tl;dr
In most case, it won't be an issue. It just happens apache user and unix user (the one running bakery) are not in the same group or whatever. This can be solved by using Redis or Memcache since anyway you shouldn't use the file driver in production env.

(Damn, will still have a permission issue when deleting the route cache file 🤔 )

[lcharette]

Twig and Router cache should be fixed in commit 3027b6c.

I did some more research on my permission issue. It's specific to tags apparently. I'll try to add something to throw an error if cache can't be written. So far, it produce false positive on my system (says cache is cleared when it's not).

[alexweissman]

So in the "going live" guide, I actually recommend making the webserver user, and the user account you use over SSH, part of the same group. Then you can just give the group write permissions.

[lcharette]

I found out in some test that Apache can create file with non group write permission. Umask related or something.

[alexweissman]

Hmm, ok. So is this fixed now?

[lcharette]

yes !