Revolution: Feature Request: Improved Upgrade Process

[pyrographics]

Am I the only one who feels like the Revolution upgrade process is getting too cumbersome compared to other CMS? One has to FTP the files to the server using a sync which may or may not work correctly due to time offsets or file size. We run both to ensure all files are transferred and then we manually move the version file inside core/docs because it is, more often than not, skipped during sync. If we make any changes to core location or harden folder names we have to manually change these before FTP. If the core is moved and we do not run the installer immediately upon transferring files, the manager displays a 500 error. Many end-users, unless they are developers, are completely incapable of handling this on their own. I, for one, like to see an automatic or one-button package upgrade in the manager like other CMS or MODX Cloud uses.

[jonleverrier]

Do you mean, for example, something like Bobs UpgradeMODX extra?
https://github.com/BobRay/UpgradeMODX

[pyrographics]

Yeah, like that but I'd even go so far and auto-install minor upgrades. I didn't know about his package. As important as version upgrading and security is and given how extra developers move on and abandon development (not saying Bob would), I'd still prefer a better upgrade process in the core.

[mrhaw]

It would be cool to have an extra installer page during setup, where extras like this would be suggested. My 2 cents.

[muzzwood]

I use UpgradeMODX all the time. I would actually love to see that kind of functionality moved into the core as well.

[sottwell]

It's a bit problematic, as there are some server configurations where it simple doesn't work. So having it in the core could lead to a lot of issues that MODX just can't solve.

[OptimusCrime]

The process of upgrading MODX will _always_ require you to overwrite old files with new files, and running the setup.

This could in theory be automated, as UpgradeMODX is proof of. However, the process of upgrading _may_ also fail, and it may fail in a way that is completely repairable. There are already many issues with server setup, incorrect configuration and very, very unique and nearly impossible-to-replicate reasons for something failing. Imagine the repercussions this would have if MODX had a upgrade functionality built into the core, and it failed. It would be catastrophically and would be very negative for MODX as a platform.

I think using a custom component built by an author that is not officially associated with MODX is a good middle ground. You may use it on your own risk, and it is built dynamically enough to work for most common setups (even harden ones).

I think it is fair to assume your issues with FTP uploading is a problem with your server or provider, and has nothing to do with MODX itself. I have no problem uploading the files in a typical MODX installation to our server, and unless we have a complete connection failure, it never fails to upload a single file. Additionally, any sane FTP software, like FileZilla, show how many files failed to upload, and allow you to resume upload if you paused it (or you lost your internet for a while). This makes interacting with the server a non-issue for us. Rerunning the setup takes less then a minute from start to finish, and we usually have no problems with this neither.

Our process looks like this:

• Log into the FTP server and find out what our harden setup have named their core, connectors and manager directories.
• Rename our local directories to correspond to these.
• Select all directories, queue for upload, answer yes to any overwrite question.
• Do something else for a while until the upload is finished.
• Run the setup.
• Ensure that the setup directory is deleted.
• Ensure that the site works, both frontend and manager interface.
• Done.

Additionally, I would add that there is no reason to assume that a non-developer, like your customer, should ever be able to upgrade MODX on their own. Perhaps you have some rare cases where this okey, but I would assume this concerns very few. What would for example happen if the upgrade for some reason failed?

[pyrographics]

Regarding a package installer at install, that would be a great option. Finding extras is easy, finding quality extras that are essential, not so much. We nearly always use the same extras in our sites so we don't go looking for new ones unless I hear about them somewhere else like here.

Wordpress manages to handle automatic or one-button upgrades internally without catastrophe. As long as the upgrade doesn't touch the assets, core/components, and config folders and backs up the database in the upgrade process any errors would be easily recovered from. I've butchered some sites pretty badly but as long as I had a backup of those folders and the database I could recover from it.

[SnowCreative]

At the very least, why not have the setup process for upgrades essentially be a one-button operation? 95% of the time I just have to keep clicking "continue" on each screen until it's done. Why not have it be just one screen, and interrupt the process only if there is an error or question about something? You could put the checkbox for "remove setup folder" at the beginning of the process instead of at the end, so people could check or uncheck that, then click the setup button and that's it. Obviously, you'd need a different setup for new installs versus upgrades.

[guyinpv]

I agree it needs to be core. MODX should stop worrying about whether random edge case end users might have special environments that might cause issues that might create a catastrophe. That ain't your problem!
Any good host has daily backups and can recover with two clicks. And any good site owner will have another layer of backups on top. Who doesn't backup a site before upgrading? Why is MODX so scared that somewhere someone might mess up their site with an upgrade?

If a site admin does something funky with their configuration, it's on them that they are breaking self-update ability.

Lastly, the primary upgrade process is replacing files and running the upgrade script. This process has no fail safes whether done automatically by the core, or manually over FTP. Once all those files get overwritten, it's game on, no turning back. FTP failing will cause just as much a problem as self-updating failing to replace files.
But I would argue that if upgrading were built into the core, it would actually be MORE robust. Because the core upgrade script could do lots of things like read all the important configs first, clear cache, log out users, put site in maintenance mode, check file permissions, verify upgrade files checksums, and even create a recovery/backup before replacing files. It can even double check and verify all files were replaced successfully.
I would argue, a built-in upgrade script could do it far better than an end user who is much more likely to botch things, forget a step, or whatever.

I don't understand why MODX is so squeamish about it, as if no other self-hosted software can self update and it's a generally-avoided thing. But the reverse is actually true, self-updating is the rule, not the exception. Avoiding doing it because of being afraid 1 out of 500 people has a weird environment and the upgrade would fail, is not an acceptable excuse. For the most part, the upgrading code can TEST the environment first, for file/folder names, write permissions, free drive space, ability to use curl or wget and test checksums. And all you have to do is pop up a warning that the user should backup their site first.

[sottwell]

https://docs.modx.com/community/contribute/becoming-a-contributor

[OptimusCrime]

Who doesn't backup a site before upgrading?

That is a scary assumption to take. Imagine the backlash if a upgrade process crashes the site in an unrecoverable manner and the user assumed that the process would work without issues (and who would not assume that? After all, it's a part of the official code base).

But like @sottwell said; if you (or anyone else) feel that this is something that should be in the core, feel free to give it a go. I would be more than happy to look at any incoming pull request that attempts to do this. MODX is open source, and any contribution is either done by people that have nothing to do with the LLC (like me and @sottwell), or people in the LLC that work on MODX on their spare time. No one is getting paid to work on the product.

Instead of waiting for someone else to do something, now is a perfect chance to do it yourself.

[muzzwood]

As a way of mitigating potential hazards during the upgrade process, it might be wise to include some site checking steps such as does MODX have write access and which MySQL modes are active.

Although now I think about it, there are already some checks that are run during the install process... still upgrades do occasionally fail. Perhaps the first step might be to collate a list of common causes for such failures.