In my personal web space on SiteGround I don’t have this problem, but in my tightly controled work environment I’m running to an issue with clearing the Grav cache. The files and directories that Twig creates have permissions that make them inaccessible to me or to bin/grav clear-cache. I’ve google’d around a bit and found this great article:
It looks like he has a fix that is an extension of a function in Twig. Could Grav implement this or something like it, perhaps in the form of a plugin for those of us running into problem?
I’m open to testing out some stuff if anyone has any other ideas.
There is more than just twig files in the cache, so you probably need to fix the root issue. Check out this document on permissions in the learn section.
That’s what’s interesting and lead be to believe it’s only a twig problem. All the other files and dirs that get created in the cache do not have the permissions problem, only twig/ and it’s subs.
are you able to implement this fix on a local test setup and let me know if this even works for you? if it does I will look at adding it in the core of Grav. Should be doable.
When you say “this fix” you mean the one in the link I provided in the original post? That’s what I was trying to say, in my personal web space, I do not have this problem, I host on SiteGround. Grav is gorgeous there. I’m still trying to get Grav to run at work though. I’ve convinced them that it’s a great product, but getting it to work in our environment is a pain in the butt. I work for the Air Force, we have a very tight server and network security environment. I don’t and will not ever have access to much. I create web sites on a machine with the same file system as the web server but I can’t log into the web server directly. For example, I don’t have PHP CLI on the machine I’m trying to set Grav up on, so I have to do things manually such as clearing the cache. This may sound crazy, but our web server does not have internet access either, so even if I could log in there and run gpm functions, they wouldnt reach the repo. I can’t use gpm for updates, I’ll have to manually update and install everything There’s a firewall that blocks EVERYTHING except apache serv ing the site. So from what I see in the cache dir is that the twig generated php files deep in the twig dir are not being created with the appropriate permissions for me to delete them. It appears that they do not have group write, but they do have the appropriate group on them, owner is nobody. But I can’t chmod them If you can implement a fix, that would be awesome. If you could give me the specific language I would need, to talk to a sysadmin and not sound like I don’t know what I’m asking for, maybe I could get something on the server changed (even though this is the more unlikely possibility). I’m a designer/front-end kinda guy, linux is awesome but gets confusing very quickly.
Wow sounds like your system is very restrictive. I was really asking if you had the PHP skills to implement the fix you linked to yourself and let me know if it works. I can do a quick ‘feature-branch’ and point you to the version with the fix in it, and you can test that.
BTW, there’s a cachebuster plugin that lets you clear the cache from the browser. You should really secure this behind some .htaccess basic auth though so you don’t get people clearing the cache on you
Crud… so cachebuster is installed with the base package? Can’t grav be run without it? They will lay an egg if they find out about this. Also we don’t have .htaccess enabled on our server. When the time came, I was going to get the sysadmin to put the .htaccess content into the apache config files. Unfortunately that’s how we roll I was trying to at least get a proof of concept up and running before I started wasting their time.
I’m actually building all the test content outside of work, then I’ll tell my boss (who likes grav because he uses it for his wife’s blog) “Look see, here’s how it’s supposed to look but I need all this stuff changed on the server if you want it to work here” and then he can start the slow swim upstream to hopefully get it implemented. Yes, this is my job
But no, I read the article but I had no idea how to integrate that PHP into a test branch of grav, I see that it extends one of twig’s functions but I wouldnt know where to put it, sorry
I know it sounds like Grav might not be the right choice for my environment, and it might not b e, but it’s perfect for my content, and that’s where my job really is. If I can’t get this to work then they’re gonna make me learn Joomla
BTW, there’s no way will be able to get Joomla or WordPress working any easier if your running into these kinds of issues with Grav. Those are way more complex and fraught with similar caching, htaccess, requirements etc. Also they are much more at risk to security issues.
As for getting the other products working - Joomla is approved (WordPress is considered radioactive waste where I work), so it becomes the sys-admin’s problem, and I will just create content and have very little control over the thing. They integrate it into our access card and LDAP combo login. But for once I wanted to have control over something. I’m not a fan of Joomla, but they started this movement talking about Drupal. I was like… GOD NO PLEASE DON’T MAKE ME!
They also approve mediawiki for me this way, I just theme and transcode content, I do love MW though, Grav’s taxonomy flexibility will let me present the content in a wiki-like way, but with no outside collaboration.
Also this is going to be used on a public access site, so NOT having a login system for the foreign hackers to beat on all day is a big plus! It’s funny cause I outlined an in-house development project for our public sites, layers of php/templates/theming/plugin architecture. It was to be flat file too. I wanted this handed off to the programmers but there was no money for it. Literally the next day, I found Grav. So my hopes are huge, Grav is perfect, assuming I can get it running
HA!!! Yes, it worked! One more small step towards this actually becoming a reality in my work environment. Thank you! I really appreciate this kind of help, I hope it is something that will help others out at some point too. I can’t be the only one working for tight-ass security fascists
Update: For reasons unknown to me, other-than-twig dirs and files in the cache are not being created with 755 and 644. Problem is in the compiled/blueprints dir this time. No idea why my tests with the new branch worked up until now at work. Is it possible to expand the umask setting to everything the cms/server creates?
This is a trickier issue. It will require the ability to chmod every file after writing. I’m worried about the performance implication of this, not to mention the fundamental change to the File class. I’ll definitely have to look into this further.
OK thanks. I understand your concerns. If it was a config setting that we could set with the understanding that there is a performance hit, I think that would be acceptable. Is there some way apache can be set to umask the written files when these processes are run? If you told me the correct thing to ask for, I could ask my sysadmin. Ug, and I just had another thought, is this also going to happen in the assets/ and images/ dirs?
There’s a firewall that blocks EVERYTHING except apache serv ing the site. So from what I see in the cache dir is that the twig generated php files deep in the twig dir are not being created with the appropriate permissions for me to delete them. It appears that they do not have group write, but they do have the appropriate group on them, owner is nobody. But I can’t chmod them 
If you can implement a fix, that would be awesome. If you could give me the specific language I would need, to talk to a sysadmin and not sound like I don’t know what I’m asking for, maybe I could get something on the server changed (even though this is the more unlikely possibility). I’m a designer/front-end kinda guy, linux is awesome but gets confusing very quickly.
