Stand With Ukraine. Stop Putin. Stop War.

When did you last check the size of your modx_session database table? Was it huge, like gigabytes huge? If so, you're not alone. 

To understand the problem, you need a little bit of background.

How do sessions work in PHP?

Typically, the standard PHP session handler will create a session when requested, and store it as a simple file somewhere on the system. The path it writes session to is configured with the session.save_path configuration in the php.ini, and can point anywhere. When that option is empty, it writes to the temp directory on the server. 

Creating and loading sessions is simple enough, but the next thing the session handler does is clean up sessions. This is called garbage control, or gc. This removes sessions beyond their expiration time, to make sure it doesn't keep growing indefinitely and takes up your vital disk space. 

Garbage control doesn't have to run on every request. If your session/cookie life time is configured to a week and you're not too picky about the exact timing they are removed, then sessions only really need to be checked once a day. Cleaning up sessions can take a little time and resources, so PHP is by default configured to only do that once every 100 requests.  

How do sessions work in MODX?

MODX registers a custom session handler that takes care of storing, retrieving, and cleaning up sessions. It writes this to one of its own database tables (modx_session), rather than files. This allows MODX a little more control over the flow of sessions. 

It is also possible to instruct MODX to use standard PHP sessions, and there's also an extra available to write sessions to Redis. But the vast majority of sites will simply be using the default, writing to the database.

So, why does MODX not clean up its session table?

MODX awaits the signal from PHP that it's time to clean up sessions. This relies on 2 configuration options in PHP:

  • session.gc_probability
  • session.gc_divisor

You can find the official documentation for those options here.

Usually the probability is set to 1, and divisor to a value like 100 or 1000. That means that in approximately 1/100 requests, the garbage control will run. 

When MODX does not seem to be cleaning up its table, it's usually because of an attempt to improve the performance of the garbage collection, by bypassing PHP and off-loading it to a cron job that runs outside of the request/response cycle. 

Those environments assume PHP writes its sessions to a standard location in the filesystem, and clean up that directory based on the timestamp on the file. The session.gc_probability option is then set to 0, to tell PHP to never run its own session garbage collection.

That works great - if your sessions are written to the standard location. Which MODX doesn't. 

How common is this?

Based on data from SiteDash, which checks the size and status of your session table automatically, it's pretty common indeed. Out of a sample of 1727 sites, 27% seem to be affected by this.

How can I fix this?

Re-enable session.gc_probability. Set it to 1, and make sure session.gc_divisor is also set properly for your traffic.

Depending on your host and if you have access to a server control panel, you may be able of changing it yourself. In other cases, contact your host and ask them how it should be changed. 

I'm writing this post on the brand new MODX 2.7, released earlier this week. Among new features like a trash manager, form customisation for create and update in the same set, purging old packages and lots more, there's one more change you're likely to start experiencing soon: deprecated features.

Shortly after updating to 2.7, your MODX error log will start showing new messages saying various things are deprecated. Some examples of what you might encounter include:

  • modAction support is deprecated since version 2.3.0. Support for modAction has been replaced with routing based on a namespace and action name. Please update the extra with the namespace <namespace> to the routing based system.
  • Flat file processor support is deprecated since version 2.7.0.
  • Flat file processor support, used for action mgr/resources/getlist with path path/to/action.php, is deprecated since version 2.7.0.
  • modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
  • Old modTemplateVar getRender inputmethod

While those logs typically go into the MODX error log, it's also possible to see them when installing packages (especially the modAction and modRestClient messages).

What does it mean?

Basically, a feature is used which is on the shortlist to be removed from MODX in a future release. In many cases, that future release may be MODX 3.0, but that's not necessarily set in stone for everything.

The primary goal is to inform you, as someone responsible for a site, what might break in the future. You don't have to freak out right away, but it is useful to take a good look at your log after using your site and manager, to see what's at risk. Perhaps there are third party extras that will need to be updated, or you could also have custom systems running that need some tweaks.

It's better to find out now, so you can plan ahead, then when 3.0 comes out and your site does break.

How do I know what needs fixing?

Hopefully, the messages contain enough detail that it's clear where the problem is. That's not always the case, unfortunately, such as with the flat file processor message (which should be clearer in 2.7.1) and the rather vague "Old modTemplateVar getRender inputmethod" that ended up being a false positive in most cases.

My expectation is the you'll see the "modAction support since version 2.3.0 is deprecated" and "Flat file processor support is deprecated since version 2.7.0" messages the most.

In the modAction message, you'll see the namespace mentioned which should correspond with one of your extras or custom components.

Once 2.7.1 comes out, the "Flat file processor support" (which means a processor doesn't use the modProcessor class) should become rarer as it wont get triggered on every manager request anymore, and will also include the actual processor file that was called. That should pinpoint exactly what extra (or core feature, that's not ruled out!) is at fault and needs some work.

I'm a developer, how do I fix my extra?

Here are some resources to get started:

I'll also be working on my extras (both free and premium ones) to replace deprecated features as much as possible. A few of my extras still use modAction and modRestClient is also in use in various places. If I find the time I'll try to write more about dealing with specific deprecated features.

My log is now huge! How do I possible parse through all of this?

Now that you've asked... give SiteDash a try! Connect your site, and use its error log analyser to quickly summarise large error logs. It will group messages together for you, and try to explain what it finds.

(As of this week, it can also remotely upgrade sites for you, so if you're not on 2.7 yet, that's cool to try!)

Is it possible to disable the deprecated notices?

Yes, there's a new setting called log_deprecated that you can change. When disabled, you'll no longer get any deprecated notices in your logs. I would however recommend leaving it on at least for a little while to see what features your site uses that need to be updated. Report those logs to the developers of extras you use to make sure they're aware of what needs to be addressed. That gives both you and them the time to fix them well ahead of MODX 3.

Is the proper term "deprecation" or "depreciation"?

Deprecation, or deprecated.

If something it depreciated (with the extra i), it means the monetary value of a thing has decreased over time (like a car), but to deprecate something means to discourage its use as it will become obsolete.