We have released the second alpha of MODX Revolution 3.0.0. You can get it from our prerelease download page, or if you have a MODX Cloud account, you can create an alpha2 instance to experiment with. The core team has been focusing on making sure we preserve as much backward compatibility as possible once we get to the beta releases. We appreciate all the input, including testing, bug reports, and pull requests we have gotten during the first alpha cycle.
We look forward to seeing even more community participation as we progress to a final MODX 3 release.
Highlights
There are many great bug fixes and enhancements we incorporated since the previous alpha release. More notably, there are a few major changes that we made as a result of working to adapt extras to the new core.
Improved PSR-4 Support in xPDO
One significant change in xPDO 3 had to be incorporated to support custom namespaces in extras properly. Before alpha2, if you wanted to use PSR-4 namespaces MODX 3, you could not include the namespace prefix in the package name when using the setPackage or addPackage methods. If multiple packages in extras tried to follow similar conventions, they would end up with the same package name, effectively overwriting the existing package. By allowing the namespace prefix as a parameter to these methods, we can now calculate the path properly while allowing the entire namespace as the package name. Problem solved.
We’ll have updated documentation on this soon.
Bootstrapping Component Namespaces
Another problem extras were facing while trying to follow the conventions of the new core was adding custom autoloading logic when they don’t have an xPDO model. After some brainstorming, John Peca and Jason Coward came up with the idea of looking for a bootstrap file for each component namespace. In this way, we can register autoloading and handle other component-specific initialization needs when loading MODX. This approach will effectively replace the need for extension packages and could also reduce the need for service classes.
See the Bootstrapping Services section in the documentation covering Namespaces for more information.
Say Hello to Dependency Injection
Speaking of services, we also added a more capable dependency injection container for alpha2. For those that know what dependency injection is, we have included Pimple. This simple but effective DI container from Symfony does everything we need it to do while providing backward compatibility with accessing legacy MODX services as if they are just an array. Jason wrapped it with a simple PSR-11 implementation to meet our needs, and now we can utilize this container throughout the MODX core, as well as in custom xPDO models.
Learn more about using the Dependency Injection Container in the documentation.
Changes to the way legacy deprecated classes are loaded
The inclusion of the deprecated class aliases in the composer autoload caused several problems, so we refactored that slightly. Now it loads after the main modX class does, allowing us to make core initialization consistent across the board. Some additional legacy classes were added to the list of aliases, as well.
Removal of modAction and legacy controller support
Finally, we removed the long-deprecated modAction model along with legacy manager controller support. Dumping these paved the way to improve the loading of manager controllers overall. You can review the Custom Manager Pages documentation to learn more about these changes.
What’s Next for MODX 3.0.0
We are planning on just one additional alpha release cycle, and then the focus will be on locking down backward compatibility and features in preparation for a beta. As always, the more testing and other contributions we can get from the community during this process, the faster we can progress. MODX is a robust and flexible project, and, as they say, it takes a village.