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:
- Need to update from flat file to class based processors?
- Need to move away from modAction?
- If you're already using modManagerController classes, you probably only have to change your build script to not create modAction + modMenu, but only a modMenu instance with the name of your controller class (e.g. "index") as action, and your namespace.
- If you're using flat file manager controllers, start with Custom Manager Pages in 2.3
- Using modRestClient? Here's a gist of using modRest instead to talk to APIs.
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 Nov 30, 2018 at 01:22 PM
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 Nov 30, 2018 at 08:04 PM
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.