modifiedcontent

Thanks @Krlosand @ErikMH! I'm almost certainly going with a Vultr Cloud Compute instance. Any arguments against Vultr? Anyone had bad experiences with them? Are there Vultr alternatives that are similar but better? Or strong arguments to use a fully managed VPS instead? What Linux version would you recommend? Debian or AlmaLinux or Alpine Linux or Ubuntu or ... etc. ? Does it make any difference? Does Processwire work better with one or the other?

Excellent. Thanks, @ErikMH. I actually have tried Vultr for a small temp side project years ago, after positive impressions in research. They did not come up in my search for VPS hosts. I'll look into them again. Hostinger, A2 Hosting, SiteGround, Dreamhost, InMotion, IONOS, etc. often come up as Bluehost VPS alternatives. Are they? Any good? Which to avoid? Anyone have experience with OVHcloud? Other options under the radar?

I have had my websites etc. on Bluehost for over a decade, but they're now extorting me out of too much money from migration from CentOS - they should have fixed that a year ago as part of the service imho... - and trying to force me on bigger plans I don't need. What are the best, most reliable value-for-money VPS hosting providers for a bunch of Processwire websites and email etc. for 2025? What are your experiences with the current hosting landscape? Any recommendations much appreciated.

@theoretic, hopefully you had solved this by now, but had you made any changes via EasyApache and could this play a role in your case?

Thanks @kaz. I thought this module was gone and was replaced by the templates/fields export features, but see it was updated December 2021, relatively recently. ?

@BrendonKoz, when I started this thread I was not sure if PHP had anything to do with it, but looking into it further it became clear that it had. So I started another thread - sorry... - where I found the solution: PHP upgrade via EasyApache doesn't include the Apache mod_suexec module by default. Without that module 'the system executes PHP applications as the nobody system user' instead of your myusername. 'If you install the suEXEC module, the system executes PHP applications as the user that owns the VirtualHost that served the request.' I guess these modules were introduced somewhere between recent PHP versions? Enabling the mod_suexec module, included in EasyApache4, should fix most problems. There is also another Apache module mod_suphp that may be required to fix issues with some scripts.

Apologies for my rude response, @gebeer. No problem. Hope this week is better for you. My session stuff is still not fixed after solving the user/permission issues. This thread cleared up most of my PW session questions, so it must be something dumb in my script/templates.

Edit: Solution is at the end of this comment, after a few educational dead ends. ? @gebeerI use EasyApache4; just standardized automated upgrade/changes on a VPS with a few PW websites that have been running fine for years. I have not improvised anything, not made any manual configuration changes. Of course there is a misconfiguration somewhere. I'm trying to find out where and created this thread to find out if anyone had seen something similar after PHP config changes. Here's one via a Google search - also uses CentOS, but with Apache vs Nginx issue, so problably not relevant. Thanks for the file permissions link. I'll see if I can fix my problem with that, but they're not clearcut instructions what ownership and permissions each folder/file should have. I see my Apache now runs as 'nobody'; I think it used to be/should be 'myusername'? My PW sites were installed as 'myusername' and all folders/files are owned by that 'myusername'. Edit: EasyApache apparently "updates" user settings or PHP handlers (?) and you have to turn that off? Here is a possible way to make Apache run as 'username' instead of 'nobody', I think, from 2012, so not risking that one... WHM has Apache mod_userdir Tweak where only 'DefaultHost (nobody)' has 'Exclude Protection' selected and all my other hosts/website have 'myusername'. No clue what to do with that info. Can I change DefaultHost to 'myusername' anywhere? There's this file on my CentOS server: # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! # DO NOT EDIT. AUTOMATICALLY GENERATED. USE INCLUDE FILES IF YOU NEED TO MAKE A CHANGE # !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! # # Direct modifications to the Apache configuration file WILL be lost upon subsequent # regeneration of this configuration file, or an Apache update. # # To have your modifications retained, you should create/edit administrator-specific # include files: # # /etc/apache2/conf.d/includes/pre_main_global.conf # /etc/apache2/conf.d/includes/pre_virtualhost_global.conf # /etc/apache2/conf.d/includes/post_virtualhost_global.conf ... # These are hard-coded values that are required by cPanel & WHM PidFile /run/apache2/httpd.pid User nobody Group nobody ... Tried changing 'nobody' to 'myusername' in pre_main_global.conf, empty file with only this: User myusername Group myusername And then run these two commands from root in SSH to rebuild httpd.conf and restart Apache: /usr/local/cpanel/scripts/rebuildhttpdconf /usr/local/cpanel/scripts/restartsrv_httpd One site that was giving me nasty 500 server errors is suddenly back, but that could also be because I changed permissions on all folders to 777 - bad for security... <?php echo exec('whoami'); ?> is still giving me 'nobody' as Apache user. Apache mod_userdir Tweak in WHM still has 'DefaultHost (nobody)'. Another clue here: 'If you install the suEXEC module, the system executes PHP applications as the user that owns the VirtualHost that served the request. If you uninstall the suEXEC module, the system executes PHP applications as the nobody system user.' mod_suexec is an Apache Module that can be enabled in EasyApache4. Enabling that seems to fix most issues I had. <?php echo exec('whoami'); ?> now give the correct 'myusername'. Edit: There is also another Apache Module mod_suphp that may be required to fix issues with some scripts.

Bullshit. I don't know if this is 1 problem; there may be several completely unrelated things going on and I am trying to untangle them. I create threads when I try to solve distinct issues and mostly to keep track of my own findings. I had already acknowledged that my problem may be caused by something dumb in my script, but that is not what this thread is about. This thread was about the proper PW way of doing PHP sessions, if there are any differences with regular PHP sessions to watch out for, how and where in PW sessions are stored, etc. @bernhard@BitPoet@Jan Romero had already answered most questions. The fact that my /site/assets/sessions/ folder is empty and sessions process suddenly had gone missing seems to point to other issues as far as I understand now, so I started another thread about that - or is /site/assets/sessions/ supposed to be empty?

After upgrading to PHP 8 I now get errors like this in one of my sites: Unable to load Modules Unable to create directory /home/myusername/public_html/mywebsite/site/assets/cache/FileCompiler/site/modules/JquerySelectize/ ...and trying to clear caches: Fatal Error: Uncaught Error: Class "CacheControlTools" not found in site/modules/ProcessCacheControl/ProcessCacheControl.module:284 Other sites were mostly fine now, including Cache Control, but earlier I've had several other issues with suddenly unreachable folders here and here and here after making PHP and Apache changes via EasyApache. Are these known issues? Does anyone recognize them? How can I fix them? I've tried triple-checking/resetting folder ownership/permissions, but can't find a definitive guide what those settings should be and am probably only making things worse.

Is there a way to do a clean reinstall and keep your current content; database and templates configuration? It is probably not as simple as simply backing up the /site folder and the database and uploading/importing those after a fresh reinstall or is it? Process Sessions module is missing from my current installation. I have no idea how that happened. It may or may not have something to do with wrong ownership/permissions on folders, that may or may not have been caused by PHP and Apache config changes. If there is another way to fix that, let me know as well, but I'm curious to find out if a full clean install is possible.

Trying to install the Session Handler Database module, I get this error that probably explains my problem ? : Your PHP has a configuration error with regard to sessions. It is configured to never clean up old session files. Please correct this by adding the following to your /site/config.php file: ini_set('session.gc_probability', 1); Unfortunately just adding that to config does not fix my current session script, although the error message on the module is gone. Where are 'old session files' supposed to be stored? I still see nothing in my /site/assets/sessions/ folder. What are the correct ownership and permission settings for that folder? I have installed the Session Handler Database module, but see no change. Am I supposed to adapt my session script to it? Under Access in the admin area I now see this: SESSIONS The process module assigned to this page does not appear to be installed. and: Sessions This page has no process assigned. How did that happen? How can I fix it?

I now get this error: 'destinationPath is not writable - Images' I haven't changed anything on this site; I have only done some EasyApache stuff on the VPS server, upgrading to PHP8 and back to 7.4 etc. Why do I get these errrors? What are the correct permissions for the for /site/assets etc.? What are the correct ownership settings for /site/assets etc.? Edit: Doing this "fixed" the problem, but now I get "Fatal Error: Uncaught Error: Class 'SimplePie\SimplePie' not found in site/templates/simplepie/library/SimplePie" - I absolutely have SimplePie in that folder, so probably another permission and/or ownership error. What should the correct setting be and how are they getting messed up?

Thanks @Jan Romero and @BitPoet My /site/assets/sessions/ folder is empty, except for a .htaccess file. Should there be something there? Do I still have write problems on those folders? I had already triple-checked permission/ownership - what are the correct settings? Sessions worked fine when I hardcoded the session variable in the script, so probably not related either way. I'll try other things tonight or next weekend and report back... Yes, probably... ? Edit: I'm still stuck with this. The session variable value event_number is set correctly on homepage, but then reverts to a previous value on the next page. I don't see where it could be overwritten in between - echoing the variable at the end of page 1, top of page 2. Where are PW php sessions stored? On the client machine? In "memory" somewhere? Cookie? Should I see files in the /site/assets/sessions/ folder? Could register_globals interfere with how sessions are stored?It does work when I hard-code the event_number value, so session is stored somewhere? I'll look into the “Session Handler Database” module that @Jan Romero mentioned next...

Thanks @BitPoet. My sites are on a VPS, not shared or "cloud" instances. What are the correct folder permissions? Is that listed anywhere? I had double-checked folder permissions/ownership and disabled FileCompiler on every template to fix these problems, which did the trick. I'll re-enable them and see if it has any impact on my current PHP session problem. With 'Use Compiled File' set to Auto on every template and namespace removed from all template files, everything looks normal, but session still doesn't work - one session ID across pages, but the variable doesn't stay updated. When I just manually change the event number in the homepage script, PHP session works fine and that variable does get carried over to the next page: $session->set( 'event_number', 23 ); This also works: $n = 15; $session->set( 'event_number', $n ); But this fails: ... script that produces a valid $n ... $session->set( 'event_number', $n ); The $n variable does hold a correct number as far as I can tell. So the problem probably has nothing to do with PHP session or PW, just something dumb in my script. Does anyone recognize this type of error? What else could I try to troubleshoot?