Maybe we are doing a different upgrade process, but every time I upgrade it takes less steps than the initial install. I agree it would be nice to be able to do things from within the wordpress UI, but difficult? Not from what I have seen.
The biggest issue normally comes down to plugin conflicts, but the team seems to be working more to let plugin devs know when certain things are being deprecated.
I too, never have issues, and cant see how uploading files can be such an ordeal for people…which is all the 2.2 ->2.2.1 upgrade was: uploading some files.
I’ve used this Plugin when I was still using regular WP. It works great! Single click upgrades.
The only issue is that the webserver takes over all permissions of all your files, so you have to login as root to makes files changes via FTP.
If you have shell access, Bryan Layman’s EasyWPUpdate script makes the process outrageously easy.
Backs up files and database, grabs the latest version of WP, replaces the files, runs the upgrade steps.
As it runs under your own shell account, it doesn’t need any entertaining permissions changes…
The only thing it doesn’t do is deactivate and reactivate plugins.
The process the official WordPress documentation outlines is 13 steps long, including backups of everything (including your entire database), deinstalling plugins, etc. etc. The initial install has 2 steps. 2 < 13. When you have a large site, with lots of entries and lots of plugins, this stuff takes time.
If I could trust the plugins to do this process right, I’d install one. But since WordPress doesn’t trust the plugins enough to include it as a standard part of their package, I’m not sure why I would/should/could trust them (most plugins can’t hose your entire installation like an upgrade plugin might).
I don’t want any more features from future releases. I want rock-solid stability, security, and ease-of-upgrade functionality.
When you have a large site, with lots of entries and lots of plugins, this stuff takes time.
wordpress now has one click deactivation of all plugins — while I understand your point, thats hardly time consuming.
The plugin trust issue isnt just a matter of trusting plugins — its a matter of trusting users. Case in point: there are thousands, literally, of people running exploitable versions of wordpress, completely bug-ridden, obsolete code .. and a good deal of them do so, even after being told of the risk.
Expecting that everyone will have plugins that arent outdated, when you have a significant % of people running the whole outdated application is very risky.(And would undoubtedly make my life “here” alot less ‘fun’)
Its a user issue as well as a plugin issue.
Additionally, the 2.0-> 2.1 jump included significant changes to database schema. Plugins that use that older schema are apt to cause trouble.
Another thought:
The instructions on the codex are not required, they are recommended.
A person could just as easily NOT backup their database – but why would you risk that? A MySQL backup using cpanel is a one click and done thing. The same applies for a home backup as well.
I have backups of my site going back to wordpress 1.2.
And frankly, those users would likely have upgraded by now if there was a button on the control panel that said, “Upgrade” and it did that back from version 1.2 or so…. The fact this only started to become a consideration later on in development, long after the cat was out of the bag, so to speak, is not the users’ faults. Rather it’s the fault of a development process that never took into account the complexity of upgrades and all the plugins such a platform encouraged.
Lessons learned. But now I’m suggesting let’s learn from the lessons and start building it into the core of the program.
