I have a a question; Why did you choose not to put the /assets and the /images directories into the /cache directory?
I am having some issues with internal users fiddling with the those files I had rewrote some of the base code to where the cache directory is hidden and that works as expected. Now the issue lies with the assets and the images directories so I opt to move them into the .cache directory. I managed to update the base code and the generated files are dumped into the correct directories and the links are correctly printed in the outputted html. The problem is that the browser throws a 500 for the generated assets and image files even though the printed href-link is correct and the files exist (No logs are printed out - Grav or server side)…
Printed HTML example for css:
This file exists in the ~/.cache/assets/[file-hash]
Below is what I had changed (as an example for the assets). I am not concerned a bout updates from Grav since we decided to branch off the current release for our internal site.
The primary reason is that we wanted to be able to deny direct access to the cache folder via the browser so that these files were secure. However, both assets/ and images/ are intended to be reachable via the browser because they are cached browser resources (images, css, js). We started off with just images, so it made sense to create a root level images folder. Later we added the asset manager, and as that was different from images it became it’s own folder too.
Everything a user needs to deal with or edit, goes into the user/ folder. A user should not be touching anything outside of this folder. This could be managed with permissions, but really education is probably the best approach.
Grav is very flexible though, and it is possible to change the locations of things. We have a system/defines.php file that sets the location of all the folders.
If your not concerned with updates, you can easily modify this defines file, however this approach is slowly being replaced with PHP streams. This will mean that you will be able to drop in a custom setu p.php at the root of Grav and it will configure where Grav finds everything (including images/ and assets/) folders. It works for somethings but not all currently. We hope to have this conversion process complete in the next couple of Grav updates.
Ok, to your question! Your 500 Error is probably because .htaccess is denying direct access to the cache folder, so please check the .htaccess and change up the directives as needed for your new structure.
I am aware of the defines.php file and that is where I started with the assumption that the ASSETS_DIR and IMAGES_DIR globals were being utilized in the code properly. Quickly I found they were not as you can see in my change example above. This leave maintainability very difficult but I am correcting it along the way. Thank goodness for the awesome tools out there.
As a Userability expert (Google University - LOL), I have found leaving everything out in the open can lead to undesired results (esp. if there is something you don’t want others accessing). I too believe in education as an approach but I was taught too to always consider “human factors”. The human factor in this case is curiosity. So I always use both. Please do not take what I am saying the wrong way - We just have to different design policies (UX).
As for the 500, Doh!! Sometimes I just forget the basics. I refactored the .htaccess to:
I had rewrote some of the base code to where the cache directory is hidden and that works as expected. Now the issue lies with the assets and the images directories so I opt to move them into the .cache directory. I managed to update the base code and the generated files are dumped into the correct directories and the links are correctly printed in the outputted html. The problem is that the browser throws a 500 for the generated assets and image files even though the printed href-link is correct and the files exist (No logs are printed out - Grav or server side)…