• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.

Online update encountered an error

Status
Not open for further replies.
K

kmaite

Chevereto Member
Website URL
<private>

Chevereto version
3.10.4

Description of the issue
Really a headache, each update will worry about the error, and now really have a problem, I was from 3.10.1 click online update to 3.10.4 when the error occurred.

"G\: Sessions are not working on this server due to missing write permission on session save path (php.ini session.save_path)."
 
System is telling you that sessions are not properly implemented, that php doesn't have permission on that folder.

I assume that you add some dirty hack to get to work. Problem is that the system overwrites all those files on each update, you should fix your server.
 
tQVuK.png

I edited php.ini, and then what should i do to do it normally? Now is still the tip.
 
Seriously, I did not see the need to open the project in the php.ini file at https://chevereto.com/docs/. The question now is, need to be reinstalled? I really do not want to re-install, every time I need to re-install to modify many places.
 
You have to realize that sessions are not working properly. When you notice that you will understand that the problem isn't the script but how your server is working with sessions.

Sessions are just files that PHP uses to store some data, php needs to be able to read and write those files within your session save path. If the system tells you permissions are wrong then plain and simple: php is unable to work with sessions in the way it should be.

The system detects permissions and then it detects if the $_SESSION variable gets stored properly or not. The system only detects what php internals throw, so you can't dig any further.

Worst scenario will be a false positive, like everything configured properly and it just don't work. I will take a peek soon as I can
 
I can confirm that the issue is that PHP can't access to the default session path. While this should get fixed on your server, it seems that you have been struggled to get sessions to work and I have seen the same incident plenty times affecting other customers. I'm adding a permanent workaround for this kind of cases.

To avoid future issues, I've placed the app/settings.php file on top of G loader so you can use the settings file to inject any kind of patches or fixes (sessions, ini settings, anything) and from now you can use the following to force a different session path:

upload_2017-10-7_12-54-35.png

Cheers,
Rodolfo.
 
Rodolfo said:
I can confirm that the issue is that PHP can't access to the default session path. While this should get fixed on your server, it seems that you have been struggled to get sessions to work and I have seen the same incident plenty times affecting other customers. I'm adding a permanent workaround for this kind of cases.

To avoid future issues, I've placed the app/settings.php file on top of G loader so you can use the settings file to inject any kind of patches or fixes (sessions, ini settings, anything) and from now you can use the following to force a different session path:

View attachment 1493

Cheers,
Rodolfo.
Click to expand...

Thank you for your help, the problem has been solved, but I think I've got: update the phobia.
😕
 
Don't worry, the change will be permanent. The session hack has been added on app/settings.php and that file doesn't get replaced by the update process.
 
Status
Not open for further replies.
Back
Top