I’ve been working on updating a bunch of MODX extras for MODX 3.
It’s relatively easy to get them to stop throwing deprecation notices when they run in MODX 3, but as far as I can tell, it’s impossible to prevent them from throwing deprecation notices during the install without creating a separate version for MODX 3.
If the build.transport.php file is run in MODX 2 to build the package, it’s guaranteed to produce lots of deprecation notices when installed in MODX 3. If build.transport.php is modified to prevent that, the package can’t be installed on MODX 2.
The good news is that in MODX 3, the deprecation log is separate from the regular error log, and the errors are not displayed during the install.
The Transport package classes could be altered to solve this, but it would be a fair amount of work, because the relevant code appears to be in many different places.
Another, not very attractive, option would be to unzip the transport package, make the changes, and zip it back up for the final package. so the installation would do the right things in both MODX 2 and MODX 3 and produce no errors. I think this would work, but I haven’t tried it.
If anyone has any great solutions, I’d be happy to hear them.
I hesitate to chime in since I don’t think it’s a “great” solution
In rebuilding ExtraBuilder, I was also looking for ways to build a package that was compatible both directions. I landed on a method where I build the Component and Transport package from MODX 3. I was planning on doing a tutorial video this week.
The first piece is in my Transport build script. I loop through the transport package files and copy the contents to a duplicate v2/ directory but I remove the /MODX/Revolution/ directories so everything moves up. Then I also replace all the classes and file paths in the vehicle files while copying. I then call the pack function again to create the zip file of this new “v2” version.
The second piece is a script resolver that does some replacement of namespace blocks and classes. It replaces all MODX\Revolution\... prefixes in the Processors directory. It also removes any lines wrapped in comment tags //v3 only. And finally for the Processor classes, it replaces the extends GetListProcessor with extends modObjectGetListProcessor.
For the Model directory that remains unmodified. I keep the v2 model files in a v2/model directory. The other trick is in the v2/processors/. These now act as “gateway” files that just load my Processor class files.
By including and extending, MODX 2 recognizes the class correctly. This allows me to use the same files in both.
The resulting zip file in the “v2” directory can be installed in MODX2 or MODX3. The reason it’s not “great” is that it requires a fair amount of work to refactor.
Another dependency is the Javascript ExtJS files need to be loaded with Smarty rather than as files in your assets directory. This is the only way you can control the action URLs and point it at the correct processor path for the MODX version. Example, in v2 you would have action: "GetList" and in v3 you would have action: "ExtraBuilder\\Processors\\GetList".
@bobray Let me know if there’s an Extra you want to assign my way? I’d like to try out converting another Extra to this methodology as long as the core group doesn’t think it’s too crazy!
Interesting ideas. If I’m understanding you, the package then installs properly in both MODX 2 and MODX 3.
Depending on how you count, I’ve got between 40 and 50 packages to convert. I think most of them will work in MODX 3 without a lot of effort, but with the deprecation notices. Most are built with MyComponent, so I’ve thought about doing something like what you’ve done via MC, but it would take a massive amount of testing in both MODX 2 and MODX 3 to make sure it works every time. I’m thinking about just living with the deprecation notices and kicking the can down the road until either the transport package classes are rewritten, or I no longer need to support MODX 2.
If you want something to play with, you could try the process on UpgradeMODX. It currently installs and works in both MODX 2 and MODX 3 (though it works best if you install something like Chrome’s Cache Killer – otherwise leftover cached stuff temporarily messes up the Manager).
Do you know if that is going to become a core feature? I notice in MODX 3 it now has versions listed and shows you when you need an update on Extras. But when you click on the “Update” link next to MODX it just takes you to the download page.
It seems like they’ve set it up but just need that final step of a built in upgrade process. Is that on the roadmap as far as you know or is this just a way to let site owners know that there is an update, but they still have to manually do the update?
I’m not the person to ask about that. I made it clear a long time ago that putting it in the core would be fine with me. Someone from MODX LLC contacted me and offered to work with me to make that happen. I said that was great and that I was looking forward to it. I never heard from them again. I suspect that it has to do with the philosophy of keeping the core code to a minimum and using extras to add functionality to it, which is also fine with me.
Although I installed UGM and used it successfully to upgrade to MODX 3 beta from 2.8.3, I just tested it on RC1, and the widget will not show up on the default dashboard until you add it manually. You also need to set the PL-only UGM system setting to “no” to see any MODX 3 versions.
Looks like there was some recent discussions on Slack. I’m asking for clarification just to be sure, but it looks like it’s not a feature they plan to incorporate.
I guess I should include myself in the “we” community
“They” would be “the powers that be”, the MAB? You
By the way, is there an official roadmap feature list that development is driven off of? How do we know what features are approved for a given version or targeted for that version?
Looks like we were experimenting with the new Project feature but maybe that added too much complexity? It looks like we’re just using milestones to tag to a particular release.
Maybe I just can’t find it, but it would probably be helpful for new people to see the process documented and methodology?
It was more of a fizzling out than a dissolution. Interest waned after some primary participants forced compromises to the original MAB proposals and then abandoned ship after they encountered some rough seas.
