When WordPress 2.3 was released into the wild, one of the new features was an update notification which told you when there was a new version of WordPress or a plugin available for download. This was possible thanks to the API service called api.wordpress.org. Earlier this year, I had the privilege of attending WordCamp Dallas where WordPress 2.5 was unveiled to the world. I’ll personally never forget that day, but when Matt showcased the automatic plugin upgrader, it confirmed my suspicions back when 2.3 was released as to where at least some aspects of WordPress were headed.
During some downtime at the event, I pulled Matt aside and asked if him if the team was going to end up heavily using the API to not only upgrade plugins, but upgrade the core and also install themes. I don’t remember exactly what he said, but never the less, that is indeed where WordPress is heading. Thanks to this API, the future of WordPress from an end users point of view looks great.
WordPress 2.5 introduced automatic plugin upgrades. A time saving feature that the masses have loved. WordPress 2.7 is poised to really take advantage of the plugin API that the WordPress team has built thus far, allowing for the browsing and installation of plugins right from your administration panel. Another feature which may or may not be finalized in time for 2.7 is the core upgrade functionality. Again, thanks to the API for WordPress.org, upgrading WordPress could be as simple as a click of a button. The next item to incorporate into WordPress is the theme repository.
Although no definitive proof showcases the theme repository being integrated into the WordPress back end, I feel that it is only natural to incorporate it much like the plugin repository. What I say here is speculative, but based on the discussions that I have read, the plan is to allow users to browse around the theme repository and if they come across a theme they like, you’ll be able to click an install button which will unpack the theme automatically leaving only the step of activating the theme. I’ve mentioned this idea to others and they bring up the subject of theme upgrades. Because themes can be edited with the addition or subtraction of functions, I don’t believe upgrading themes will be as user friendly as upgrading plugins. However, unless a theme author completely revamps a theme, I don’t see the need to have an upgrade theme feature added to WordPress. Instead, the theme author should update the theme, change the version number and then, the theme repository API should notify the end user within the WordPress administration panel that a new version of their theme is available. A link within the message would direct the user to that themes entry within the repository from which they could read the change log. It would then be up to the end user on whether they want to apply the updates or not.
Based on my experience in dealing with WordPress end users, the three most difficult tasks when operating a WordPress powered site is upgrading WordPress, browsing and then installing themes, and last but not least, installing or upgrading plugins. Thanks to the hard work of the WordPress developers and associated volunteers, the API has provided us with the opportunity to use a piece of software where the three most difficult tasks to perform when using WordPress are practically automated. At the click of a button, you’ll be able to install a plugin, upgrade a plugin, upgrade to a new version of WordPress or install a theme. I may be wrong, but WordPress may be the first publishing system to provide this type of functionality to its user base.
I’ve had this feeling for quite a long time that WordPress was eventually going to provide these features as a means of making it as easy as possible to keep everything up to date. I suppose I may have a WordPress instinct built into me? At any rate, this is the road that the development team has decided to travel and I am happy to be part of the ride.
Are you looking forward to these three mundane tasks (possibly) being turned into simple mouse clicks?
If you think about child themes, I think it will be possible to upgrade also the theme: you upgrade the theme core files, and the child theme remains there, using the new version of the core one. ^__^
I didn’t think of child themes when writing the post but you make a good point. Maybe upgrading themes will only be possible through this avenue. Otherwise, people are left upgrading their themes on their own.
I agree with your points Jeff, but there are dangers here as well.
There is a risk that making things so easy removes the element of caveat emptor that exists with free software.
If something is added or upgraded and everything turns brown, what happens if the user doesn’t understand how to delete a plugin, or theme, how to FTP, etc…?
Are you saying that because things would be so easy that even those with no technical expertise would be able to use WordPress but when things go sour, they wouldn’t know what to do? Perhaps this event would encourage them to learn. I mean, do we only want geeks or technically savvy people using this piece of software?
It isn’t really about what we want it is about what is appropriate. If someone isn’t technically savvy (which is still some way from being entirely competent) then perhaps they shouldn’t be hosting their own website using software that requires they are?
In most cases, and I am one, it encourages people to learn, but the less involved things become the less people will need to learn. Then when it does go wrong there is a mountain of learning to climb.
I don’t know… being a power-user myself, I don’t tend to like or trust automatic update features much. I avoid them when I can, and use the solely as a notification system when I can’t. Last I checked (which has admittedly been a while), the automatic plugin update feature required forking over an FTP username and password. Being more security paranoid than most, I would never give out such a password to a third-party site. It wouldn’t help me anyway as I’m so security paranoid that I would never run FTP. (I access my site’s console via public-key authenticated SSH.)
Maybe this will be a boon to less tech-savvy users and, if so, I hope it helps spread WordPress even further. But as for me, I’ll probably pass. If it still relies on FTP, it would be useless for me. And if it doesn’t, I’d still prefer trusting the old unzip-the-tarball method that lets me backup everything manually first.
I just received an email the other day highlighting the fact that I think secure FTP has been added to the core upgrade feature for WordPress 2.7. I am trying to find the link to the post but have been unsuccessful.
By “secure
Let’s try this again (stupid comment form submitting when I’m not done typing)…
By “secure FTP”, do you mean FTP/SSL, FTP tunneled through SSH, or the SFTP subsystem of SSH? They’re three different things with three very different implementations. Supporting all those combinations will be quite a headache. Either way, you’d still have to bother with handing over passwords (or in my case, private keys). From a security standpoint, I’m not comfortable with that.
I also agree with other commenters that dealing with customized plugins and themes will be difficult. I’d go so far as to say automatic upgrading is only going to be really useful for folks who use purely stock add-ons, and for those folks I say more power to them. But I was recently forced to upgrade my online storefront’s software, and its automated, DIFF-powered patching system couldn’t make heads or tails of my customizations. I ended up using diff pretty extensively but still had to go about patching each individual modified file manually. I know that might seem like an apples-and-oranges comparison, but I think it’s closer to apples-and-pears. I know I’ll be sticking to manually patching for now; I’ve got enough mods in my blog now that upgrading is too delicate a task to let the software do it form me. :\
The SSH2/SFTP users the libssh2 and OpenSSL protocols from the PHP group. Now when I finished the class a few days ago I didn’t add an option for using authincated keys, Only sending your plain text password could be used in the current revision. (It’s still awaiting commit into the trunk). Never the less, our testing indicates it works just as fine and just as secure. It never leaves the WordPress directory.
Even in the current version of the functionally it does start in the root folder of “/” and works it way forward. We fixed this potential flaw at the same time. So it starts in the folder that it wants to create and goes backwards until it hits wp-content.
Adding an option to use authenticated keys would not be much of a problem as I would have to have two lines for where you have your keys stored.
I wrote the class because I also don’t use FTP on my server. It’s totally disabled and only use SSH2 for transfer. But I like to make clear that you still don’t have to use this new functionally even though it’s provided. Just personal preference.
Hope this clears something up. Jeff, my article is here.
Sounds interesting, Shane. I’m probably still way too paranoid to use it myself 😉 but it’s good to see that it’s being worked on as an option. (Why any host continues to support FTP–and in many cases, only FTP–amazes me, especially those who claim SSH is “insecure”. I understand their reasoning (not giving out shell access) but find it laughable.) I especially like to hear that public-key authentication is in the works.
I feel badly for those folks who need the automation to do things as simple as updating and installing, but isn’t that why WordPress.com exists? So that less tech-savvy users can take advantage of WordPress without having to know how to do those things?
For myself, I doubt I’ll use the automation for updating WP, and I know I won’t use it for installing themes or plugins unless it’s on my test box.
I see your point regarding WordPress.com, but must the technical bar be raised so high as to force people to use WordPress.com? I am a technically savvy user and I really enjoy the time saving benefits of clicking a link to automatically upgrade a plugin. Also, the automation is not fully automated. You must first click a link or initiate the process which means, you can continue to go down the manual route if that is what you feel more comfortable doing.
I can see choosing to use automatic updates sometimes if you know what you’re doing. I just wonder if those who really need to use automatic updates are technically adept enough, or even aware enough, to dig themselves out if they get into trouble.
I’m picturing the support forums six months of now, filled with pleas for help from people who don’t know to backup first and test before they leap.
In trying to be inclusive of those with limited skills, might this be something that backfires, and turns into something that turns those same users off?
Should it also be mentioned that this won’t work on some systems, because of the lack of proper hosting support. For the majority of people, they won’t need to handle anything and upgrading WordPress, Plugins and soon Themes will be at the click of a button.
However, there are still faults that need to be worked out. Matt has discussed DIFF support for themes that will allow users who made changes to keep those changes when upgrading. Diff support already exists for posts, it wouldn’t be difficult to enable something that SVN handles currently.
Eventually, my fear is that with making core changes to WordPress files, that those will be overwritten as well. If the WordPress Core upgrade fails, you are SOL and will require that you download manually the latest and reupload to get your files back. This may be a mute point, since no one should be making core changes anyway.
When I wrote the article, I thought about the fact that not everyone would be able to enjoy this type of functionality in WordPress. But I didn’t mention it in the article as I couldn’t figure out a way to bring it in without making it sound like the majority rules, minority rights type of deal.
As for your point regarding core file updates being overwritten, that is a risk that that particular person has decided to take upon themselves.
Have you tried using the core upgrade and then forcing an error to occur? Would you really be SOL? Hopefully, these types of errors wouldn’t happen very often as it would defeat the purpose of core upgrades.
That is understandable. There is nothing Automattic or the community can do for those in the minority, so it would make sense to exclude the information to prevent making it seem like a bigger deal than it actually is. Honestly, anyone who can upgrade their plugins won’t have any issue with installing or doing the core upgrade.
As for whether the error during core upgrade will affect anything, I have had it fail. The way I fixed it was to delete the .maintenance file, then enter the upgrade process manually. There are multiple steps where failure can be had. If failure is had during the moving of the files, then yeah, you’ll be SOL. If it fails during the automatic upgrade process, then you can fix it yourself with a little FTP help.
Given that WP will change the backend every few months, with frequent major releases that will make various plugins and themes defunct, this should be titled “the road to automated breakage.”
If WP could save major backend changes for the dot-0 version changes, and make the dot-number version changes EVOlutionary instead of REVolutionary, it might just work …
Meanwhile, I’m enjoying John Blackbourn’s “disable WP core update” and “disable plugin update” plugins. They’re godsends. They put the upgrade cycle back into the user’s hands, where it belongs.
There is no guarantee that the back end will be changed every few months. Sure, 2.7 will feature some major changes while 2.5 was released earlier this year, but that doesn’t mean they will make changes every version.
As for the two plugins you use, I believe those plugins were created because the author did not feel comfortable with his installation of WordPress phoning home to the WordPress API service. So, he disabled the data from being sent to the service.
By no means is the core of WordPress or plugins fully automated. You, as an end user have to click on a link in order to initiate the process. Therefor, the upgrades have always been and continue to be in the end users hands.
Custom installed WordPress powered sites should not necessarily be regulated to only the tech savvy blog and CMS owners. There are those that, for example, can accomplish the basics involving the care and maintenance of a WP powered site but simply don’t have the head for the “heavy lifting” so to speak. I know of someone personally who is fluent in writing HTML but simply can’t wrap her head around anything remotely technical in nature. Despite all this, she has a rather popular blog that, for the most part, she takes care of on her own.
Be that as it may, WordPress.org already made the choice a fair amount of time ago to pursue the goal of making a WordPress powered site user friendly to non-tech bloggers while still keeping it a fine choice for developers as well. For folks like myself who tend to be tech-mongers, we can simply continue our practice of “hands-on” upgrading and code patching and/or anything else that makes us satisified while those who can’t wrap their heads around such things (the same way I can’t draw a straight line with a ruler under threat of death) can use the built-in automation.
As Andrew pointed out previously, anyone who uses WordPress to power a website should at least know the basics meaning using an FTP client to service their install, backing up of data, manual upgrading and the like so that they’re able to recover from a botched automated upgrade and as Jacob stated, not all hosts will be compatible.
Although updating with a mere click of the mouse is super convenient, there could be issues with certain plugins, themes, customizations not working any longer. There should also be a method of dismissing the update notification in the WP backend so that the updates that we do not want to perform do not constantly notify us that they are available.
Other than that… the ease of being able to upgrade wordpress through a mere click is great for most. I personally have implemented the plugin that upgrades wordpress. I find it to be convenient and easy to use.
I have mixed feelings about it. The lazy butt part of me says it would be downright nice. But the power user part of me, likes to do it myself. The biggest question is, which part is greater?
😉
-Pat
Wow, the automatic upgrade is something nice to have for newbies but the element of trouble can really make the newbie see red.
Would a user be able to uninstall the plugin or revert back to the previous version of wordpress? It is easy to upgrade but to revert back is another story. Maybe when upgrading wordpress or plugins, maybe a backup could be made of the directory and the user could revert back to previous version.
I have only one issue to raise: translations.
I am a native Hebrew speaking person (which is a Righ-To-Left language). and if I open up a blog in Hebrew, I have to use another installation of WP (on wph.co.il) than that we have on wordpress.org.
Until wordpress.org won’t have a Hebrew version of it’s core installation (or allow me the default location from which to upgrade my WP), I will have to keep on upgrading wordpress manually.
Me, and all the other RTL language speaking people in the world.
p.s: allow me to emphasize that I LOVE WordPress!
Tal.
I have just to agree with you.
+1
I wish there’d be a central ftp setting to configure, complete with path and everything. As is I can’t use the plugin update feature simply because I have non-default paths when I log on to ftp.
Unless I missed something. But overall I’d say it’s a step in the right direction.
In principle automatic updates are a good idea, but there are problems.
Security has already been mentioned and that would be one of my concerns also, but for a different reason.
As a plugin developer I have access to WordPress Plugin SVN for my plugin. If my password was compromised in some way, a malicious attacker could use these details to modify the repository of my plugin and add malicious code. They could then increment the version number and potentially cause over 12,000 users to get malicious code on their blogs. Obviously I use secure passwords and take great care with security at my end but can you be sure every plugin developer does the same? The more plugins you have and decide to auto-update for, the more you amplify this risk.
Personally I like to inspect the code of every plugin I install so I know what it does. In a slow update cycle the community does this for us; If malicious code was added and updates were manual you could be sure that some techie would spot it before too many people had installed it and raise the alarm thus mitigating the threat. Auto update completely destroys this potentially beneficial delay – particularly for the very well used plugins.
As I understand it, theme code is being inspected by volunteers before it goes live so perhaps this wouldn’t be an issue for themes.
The other issue is file changes. When you make updating a black box you remove the obviousness of the actual file changes that are going on under the hood, or in this case, file over-writing.
I am thinking of course about users who have made changes to plugins or themes to suit their own ends, or more likely, non-technical users who have had WP setup and themes/plugins installed/modified to suit by a technical friend and then left to their own devices.
For these users clicking upgrade on a plugin (or a theme in the future) can (and most probably will if modifications have been made) break their site.
I have never used a theme out of the box. On many occasions I pick one that is 80% there and change it to suit. If I did this for a client’s website and they later clicked update their theme would break. This is a serious problem.
I modify plugins less often but the same risks exist there, indeed because plugins do have the auto-upgrade feature already, the risk is greater here and now for these.
Jacob mentions diff and I think this could well be a good solution. It works well with other open source projects when upgrades are required that are likely to affect user modifications and I think if WordPress is going to push the automation thing forward a method for retaining modifications easily must be implemented.
I was just watching Matt’s State of the Word from Wordcamp and he mentions Subversion style DIFF (like the Post Revisions) for Theme updates.
And if you’re really worried about theme updates, use a WordPress Child Theme for your modifications. Create an Open-source framework for all your client projects and make the custom bits happen in a Child Theme.
To me, if everything becomes fully automatic and I don´t have anything to say about things then I don´t really want to see that happen.
Why you ask? Cause I want to be able to decide what version of a plugin that I want to use. Or what version of a theme that I want to use since I know from experience that some themes when they are upgraded to a new version they look like shit or that thing you really enjoyed get´s taken away.
So sure, it´s a nice feature not having to do anything and still be on the latest update.
But wasn´t that a hole in the security when it first got announced that it had this feature in wordpress?
What says it´ll be any different now?
Just some thoughts. I enjoy using wordpress 2.6 so at this moment I don´t have any reason at all to update. Not if the automatic is a “must have”.
As i see it, the three things mentioned as most difficult tasks are in my opinion things that everyone should be able to do if they install it on their own server.
I certainly won’t be using these automated update features, because i would like to be in control of what happens and i simply don’t trust these kind of automated functions. If someone doesn’t know how to do these three tasks, then they should learn it first. Having an own server or hosting comes with responsibilities, meaning you have to know what you’re doing.
For me this is just another thing why i’m seriously considering to leave WordPress and switch to something else.
Perhaps I should of named the post, Semi Automation. It is not as if WordPress will be forcing things down your throat. The link will be displayed and it is your choice whether to click on the link or not to initiate the upgrade. You don’t have to use them if you don’t want to. And that is the way it should be.
I really like the auto update options. It allows me to update some of the smaller plugins whilst away from my home PC where I do all my coding.
It’s not if I don’t know how (I still update my phpBB forums via the [find] [replace] [insert] method), just that it’s a lot quicker and more convenient, and it’s not if I am forced to do it the automatic way.
I will stick to manual upgrades, for many of the reasons mentioned, and also this: when I manually upgrade, I run into things that help me learn. I develop questions and then must answer them.
It’s a nice option. But I expect that, even with the best intentions, security may be compromised, and because I’m not too php savvy, I lack some understanding of details of whatever y’all are talking about, I must tread carefully.
A number of blogs depend on me depending on you. I’ll play it safe.
“Are you looking forward to these three mundane tasks (possibly) being turned into simple mouse clicks?”
—
Does a bear….well, you get the idea. I managed to get over my mortal terror of upgrading manually and broke free from Fantastico, but it would be great to have this be a simple click for users. It’s scary, when you’re not sure, so making it an easy step is a way to get more people interested, that’s for sure
Thanks!
This is the flow chart of how this system works:
Everything first runs in /wp-content/upgrade/core/wordpress, /wp-content/upgrade/plguins/
1) Downloads the zip and extracts it into a class.
2) Files are checked to make sure the are valid. It will also create the directory under the above directory it works out of.
3) After all files have been validated we run a script to copy those files we just created to the root folder. Now with the core upgrade it will delete files that are now invalid based on a tree we set in the core-upgrade include that was just created. We do this so so you don’t have the extra files on your server.
4) After everything is verified, we delete the wp-content/upgrade/core directory.
I like to be clear that upgrades of both plugins and core have to be clicked to start. I’ll add a “Ignore Update” option in the plugins menu that will remove the “nag” until the version changes again. I could do the same for the core, but we like people to know there is a new version out in-case of a security update, but ignore at your own peril. I am sure a plugin author could even write an complete auto upgrade option that would do it once it detects a new core/plugin update. I am not sure that there ever will ever be a theme update option. To many customizations to deal with.
I don’t know what you mean about a wordpress api anyway, for all wordpress does now is inform you of new upgrades, you still have to download them yourself, even the ones that are right in the repository, so I don’t even have a clue of what your talking about, plugins and themes are still a pain in the rump to install, as they always have been.
another pet peeve I have, is in regards to widgets. I don’t use the widget system, because 90% of the plugins I use don’t support widgets, and not all of my sidebar items are plugins either, some of them are custom codes that i put right into the sidebar.php, so I don’t use the widget system, nor have I ever cared for it. The thing is though, more plugin authors are using widgets, forcing most of us to switch eventually. while I don’t have a problem with the widget system itself, I don’t use it on purpose because not all plugins use the widget system yet, so most of us have no choice but to not use it.
well I guess what I mean is, not plugin authors write their code to use widgets, while other plugin authors ONLY support widgets (they no longer support sidebar.php insertion) so its kinda frustrating.
Honestly I have no interest in the theme feature. My themes are heavily hacked versions of their original selves, but I guess for the few people who don’t modify their theme, it’d be nice.
I would like to see the core upgrade though assuming it works perfectly. Uploading all of those tiny files via FTP takes forever and I’m not good enough with Linux to do it via SVN.
You said:
While these are indeed challenging to some folks, I think the most critical and “newb” difficult process is getting a valid backup of the content and application settings. If anything needs automation its WordPress Backups. These should be well fleshed out and rolled into the core. I’m really surprised that no one has mentioned them yet!
I know there are a few plugins that do this, but they don’t seem to be as reliable as a backup feature should be. This is the one big area that keeps me from going full bore on WP. As it is, I manage 22 sites on WordPress already, and I hate doing manual backups with phpMyAdmin. Its ripe for automation.
Cheers,
CS
Cubesteak, I wrote about my experience of trying to implement automated backups and the solution I arrived at not to long ago. It might be of some interest to you.
Thanks! I’ll check it out…
I agree with some of the posts above – upgrading plugins is less risky if something goes wrong, it would be rare for it to screw everything up and only the plugin itself is shot. If something goes wrong while automatically upgrading the core, then it may leave less capable users in quite a situation.
Of course, if it all works fine for every single setup out there, then it would be a fantastic feature to have – security loop holes would be closed considerably quicker.
Gary,
You know, you’re right and I never noticed this myself until you mentioned it. I guess it’s because (for me anyway) the WP DB Backups plugin has been around for so long now that I never considered it. That plus I find it easy to do BU’s from phpMyAdmin. But now that I think about all the work I’ve done with non-tech type WordPress site owners it occurs to me that there’s most likely a large chunk of these somewhat non-technical WP folks out there that don’t even think about backing up their DB before an upgrade unless they’ve actually stumbled upon the back up plugin I mentioned above or something like the WordPress Automatic Upgrades plugin.
Considering the amount of times I’ve heard an experienced, tech-minded, WordPress blogger tell newbies and/or non-tech minded bloggers that setting up cron jobs is easy (not for them it isn’t) and can’t understand why they just don’t get it, I have to agree with you. This should probably be added to the core as well.
Correction: My previous comment was directed to Cubesteak, not Gary (sorry about that Gary). Too early in the morning for a disabled idiot like me. 😛
Hi guys,
I was talking a lot about WordPress security and development yestrday, might be interesting to read and join in discussion http://www.prelovac.com/vladim.....-wordpress