Modx 3.0.5 warning: Checking if sessions garbage collector are properly configured

[terrybarth]

I’ve just upgraded a site to 3.0. Installation went smoothly. Now I’m upgradeing to 3.0.5 and the pre-installation checks show this warning.

Checking if sessions garbage collector are properly configured:Warning

OK! The current configuration “session.gc_probability” is set to 1 and “session.gc_divisor” is set to 1000.
By default, MODX stores sessions in the database, so misconfiguration of these options can cause the session table to grow in size.

I’m not sure what to do with this? Is this saying it IS misconfigured?

I understand there was an issue related to this in 3.0.0. I assume this upgrade has the fix, but will it configure it correctly or do I have to do something?

I don’t know if I should proceed with the upgrade.

Thanks.

[halftrainedharry]

@terrybarth

I don’t know if I should proceed with the upgrade.

Just proceed with the upgrade.
What you are seeing is the ‘success’ message. The code seems to output a ‘warning’ regardless of whether the check passes or fails. Not sure if this is intentional or a bug.

[terrybarth]

Excellent.

Thank you!

[terrybarth]

I spoke to soon.

I proceed with the install after the pre-checks and immediately got this.

Warning: Attempt to read property “config” on null in /home/xxxx/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php on line 304

Fatal error: Uncaught TypeError: array_merge(): Argument #2 must be of type array, null given in /home/xxxx/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php:304 Stack trace: #0 /home/xxxx/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php(304): array_merge() #1 /home/xxxx/public_html/setup/includes/modinstall.class.php(467): xPDO\xPDO->__construct() #2 /home/xxxx/public_html/setup/includes/modinstall.class.php(172): modInstall->_connect() #3 /home/xxxx/public_html/setup/includes/runner/modinstallrunnerweb.class.php(38): modInstall->getConnection() #4 /home/xxxx/public_html/setup/includes/runner/modinstallrunner.class.php(49): modInstallRunnerWeb->execute() #5 /home/xxxx/public_html/setup/controllers/install.php(34): modInstallRunner->run() #6 /home/xxxx/public_html/setup/includes/request/modinstallrequest.class.php(81): include(‘/home/udf5xpn9o…’) #7 /home/xxxx/public_html/setup/index.php(30): modInstallRequest->handle() #8 {main} thrown in /home/xxxx/public_html/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php on line 304

I then tried to go back with the browser back button and got this.

Parse error: syntax error, unexpected token “{” in /home/xxxx/public_html/core/config/config.inc.php on line 13

Now I’m see 500 error on both the front-end and back-end.

I checked the config.inc.php file and found all the config values are missing.

<?php /** * MODX Configuration file */ $database_type = '{database_type}'; $database_server = '{database_server}'; $database_user = '{database_user}'; $database_password = '{database_password}'; $database_connection_charset = '{database_connection_charset}'; $dbase = '{dbase}'; $table_prefix = '{table_prefix}'; $database_dsn = '{database_dsn}'; $config_options = {config_options}; $driver_options = {driver_options};

Now what?

[terrybarth]

Still stuck on this. I upgraded 2.8.6 to 3.0.0 no issues. Then to 3.0.5 and I get all these errors (see previous post). Basically all the config parameters in the config.inc.php, db name, user, path etc, urls are all replaced with placeholders and the upgrade crashes.

I restored the config file and attempted another upgrade to 3.0.5 with the same results.

Next I restored the config file and then the site came back up although with several elements not working, slideshow, images, etc. In the manager, the home page is missing several of the assigned TV–even though the TVs are assigned to the template they are just not visible on the TV tab.

Finally, I noticed that the manager, just below the logo, reports the version is 3.0.5 but the upgrade modx widget and update status shows 3.0.0. I assume this is due to the failed 3.0.5 upgrade.

I’m thinking reinstalling 3.0.0 over the top of this might get me back to a working site.

But I still have no idea what happened here.

[halftrainedharry]

@terrybarth

I’m thinking reinstalling 3.0.0 over the top of this might get me back to a working site.

I wouldn’t try to install 3.0.0 after installing 3.0.5.
It’s probably better to try to install version 3.0.5 again.
Or start with a backup of 2.8.6 and install 3.0.5. (There is no need to install 3.0.0 first.)

---

I haven’t heard of any problems with installing MODX 3.0.5 before. Also, these installation problems have nothing to do with the session garbage collector warning.

[terrybarth]

I’ve already tried reinstalling 3.0.5 after restoring the config file. Same result.

The manager isn’t clear what version it is. Since the install failed, I guess I thought it would still be at 3.0.0?

I could go back to 2.8.6 and upgrade directly to 3.0.5 but I though it was standard practice to go to 3.0 version first.

If this doesn’t work, I’ll start a new thread.

[halftrainedharry]

@terrybarth

I though it was standard practice to go to 3.0 version first.

Which 3.0.X version from 2.8.3/2.8.4?

Directly to 3.0.3 is fine, just make sure to note the upgrading to 3.0 documentation and understand it is a major upgrade. 3.0 has breaking changes, and not everything is compatible. Some general advice: Do not upgrade to 3.0 directly on production. Upgrade on a staging or development environment. Check the compatibility of extras you’re using. Upgrade to the latest version offered to you on 2.x before upgrading, and then check again after upgrading to 3.0 to see if there are specific 3.0-c…

[terrybarth]

Mark

Yes, we are working on a staging server. We’ve already replaced and/or removed those extras that are not compatible.

Our upgrade to 3.0.0 was successful. Our problem happened when we went from 3.0.0 to 3.0.5.

What I can’t understand is how the config file could be completely overwritten on this upgrade. Especially when the first 3.0 upgrade had no problem.

[markh]

@terrybarth

What I can’t understand is how the config file could be completely overwritten on this upgrade. Especially when the first 3.0 upgrade had no problem.

This has been a long-standing bug that is incredibly hard to debug and fix once and for all, but is not 3.0.5 related. If you look for it, you’ll find references of this issue dating back to like 2.5.x if not older.

(The problem is also not that the config file gets replaced, that’s always the case, the problem is that it loses the values somewhere along the way and corrupts it.)

What seems to help when when setup causes the config file to go corrupt is:

1. Wipe your cookies and sessions for the domain you’re installing on.
2. Wipe core/cache/setup if it exists
3. Restore the config file from backup
4. Run the setup again

When running setup, avoid going back steps, and complete it in one go. From what I’ve gathered about this, something about going back a setup step or waiting a long time to continue it, seems to be related to how the data gets corrupted.

No idea why though. I’ve tried to find a fix for it before but it’s just a super weird issue.

[terrybarth]

Mark

Thanks for that background info. I will try again with these steps and report back.

Worse case is I just start again at 2.8.6.

Thank you!

[terrybarth]

Mark

That did it! We are good to go! You just saved me a bunch of work.

Thank you.

[snowcreative]

@terrybarth

Worse case is I just start again at 2.8.6.

I had a similar problem when upgrading to 3.0.0 first. That’s totally unnecessary now. Just upgrade directly to 3.0.5.