Stand With Ukraine. Stop Putin. Stop War.

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.

Houwen Frederik

Is it possible that Modx sets up a list of most populair add-ons and if they are OK voor 3.0 or not? F.e. I use a lot the add-on "Fastfield", is it OK to stay using it? If not, are there alternatives? (could also come in the list). It would make our work to update every site to 3.0 a lot easier.

Mark Hamstra

I think it makes more sense to make a list of extras that don't work, ideally compiled together with links to issues or pull requests that address specific issues that needs addressing.

Bob Ray

Any clue what extra is causing the "modRestClient::__construct is deprecated" message? That's actually what I'm getting most often.

It's frustrating to see error messages for extras that are disabled, not in user, or in some cases (Gallery) not even installed but whose namespaces are still there.

Mark Hamstra

That one is triggered from the constructor of modRestClient, which is supposed to be superseded by modRest. I think the reason you might see that one a lot is that the core still uses it as well in package management, but I haven't looked into it much yet.

Comments are closed :(

While I would prefer to keep comments open indefinitely, the amount of spam that old articles attract is becoming a strain to keep up with and I can't always answer questions about ancient blog postings. If you have valuable feedback or important questions, please feel free to get in touch.