It looks like you're new here. If you want to get involved, click one of these buttons!
So trying to upgrade a site from 1.2 to 1.4 -- everything is going really well except when I try to clear the page cache. When "Yes, clear cache" is clicked -- all users are logged out and I am presented with an error page stating that I do not have permission to view the page (/fuel/manage/cache) -- which is obviously because at that point I am logged out, haha.
I don't see any PHP errors and the Fuel activity log states that my user did clear the cache. I'm a bit baffled. Permissions seem to be fine...all cache folders recommended (cache, dwoo, compiled) exist. Any ideas?
Maybe try setting the session save path in the main fuel/application/config/config.php file to a writable folder above the web root to see if it has to do with where sessions are being stored.
Interesting...is that a new setting in 1.4? We don't have that variable set in our current 1.2 install.
Without me modifying anything, it seems to be set to APPPATH.'cache/' on the 1.4 install...which would make sense that clearing the cache would destroy it.
I'll give it a try today and report back.
Please ignore my last comment...apparently one of our server guys set the variable to APPPATH.'cache/' -- I'll change it and update in a bit.
Ok...changed it to /var/www/test-session (temporary test folder) and it seems to have fixed the issue. So is changing the session path to outside of the root the solution, or just a symptom to another issue I should be concerned with? Because even with that variable set to NULL (which was the default)...clearing the cache was still destroying the sessions.
There was a change to the CI Session Driver that has caused this issue (we run into it on different servers now and then too). If that value is not set, it will use the php.ini value session.save_path which needs to be a writable directory that can reliably store the session without it being deleted by some other cleanup process. Alternatively you can use the config to store it in the database instead which prevents that issue all together (See CI3 docs on how to do that):
OK cool...makes sense. I appreciate the help!