WordPress 3.3 could be the “U” update, for improving the uploader and updates

28 Comments

Matt Mullenweg answered a number of questions during a town hall session at WordCamp Montreal on Sunday (which Joachim Kudish liveblogged brilliantly). The conversation during the session quickly turned to the future of WordPress, specifically what’s on deck for version 3.3 of WordPress. Plans for WordPress 3.3 haven’t come together fully yet, but Mullenweg did say the next version could be the “U” version, focusing on improving the uploader and updates.

It’s not clear just what an update to the uploader would look like yet, though the media system has been on the “maybe” list for improvement the last couple of version releases.

Regarding updates, the goal seems to be to move WordPress toward the Chrome implementation for updates. Google’s Chrome browser updates seamlessly on its own, in the background. Mullenweg would like to see WordPress and plugin updates work the same way.

Automatic updates were first introduced to WordPress in version 2.5, “Brecker”, thought then only for plugins. Version 2.7 “Coltrane” went a step further and brought automatic updates to the WordPress core files themselves. The most recent version release, WordPress 3.2 “Gershwin”, implemented an enhancement that will allow future updates to WordPress to modify only affected files rather than downloading all of the WordPress files and overwriting everything.

The upcoming 3.3 could see an even bigger update to automatic updates, allowing WordPress to update without a prompt or button press, entirely in the background.

Would you be excited for a “U” update focused on the uploader and updates, as described above? What effect do you think seamless background updates will have on the WordPress community, particularly how users view new version releases?

28 thoughts on “WordPress 3.3 could be the “U” update, for improving the uploader and updates

  1. That’s a tough problem to solve. There are plenty of situations where it is not ideal to auto-update where you can potentially break a site if WordPress (or a plugin) decides to update itself. I’m sure WordPress would offer some level of control over which plugins are allowed to update on their own, but for me, it would need to be implemented in a very flexible way to be helpful.

  2. Updater improvements are OK, as long as it can be turned off. Most websites will break if WP upgrades on its own without making sure that all plugins will be fine. As for the uploader, this must be done carefully, since other plugins depend on the current uploader functionality. I don’t see what is wrong with current uploader and what improvements are planned, hopefully we will get info on that soon.

    • This was my concern as well. You don’t want your site to be up and running one minute, then after an auto-update, you’re left with a broken site that visitors are seeing.

  3. uhh… I fear the “automatic” things, I still appreciate the control on everything, might be that it will bring a “automatic updates disable option”…

    thanks for the article! :)

    D.

  4. If updates became automated, I’d have to guess that what appears to be the WP philosophy would still hold true. On by default, off by developer. As in, WP seems to be preconfigured as much as possible to be at its simplest and most hands off, so I’d guess that’s how the auto update thing might look. Wit the ability to be switched off buried in there somewhere. As for the uploader business, it’d be great to get some more hooks in there to work with. (Unless that has happened recently, I haven’t messed with trying to manhandle the uploader in a while)

  5. I suspect they will proceed with caution with making updates automatic. However, there are always improvements that can be made with the update system.

    The biggest thing, imho, is the uploaded. I’ve seen talk in #wpdev and trac about looking at alternative (eg non flash based) solutions for an uploader. In my mind the issue will be how to implement a new method without breaking everything that uses what’s currently in place.

  6. A surprising number of the core developers run trunk on live sites. Ma.tt is running on trunk and it updates itself every day. Auto-updating has worked for these people for quite a long time. So the automatic update as a feature is a natural progression.

    If your sites break on upgrades, then you’re using shady themes and/or plugins, or weird and wacky configurations. I think WP would be best served by encouraging theme and plugin authors to create forward compatible code, and I can think of no better way than to start enforcing some standards and guidelines on how to do such a thing.

    While it’s true that WP sometimes breaks compatibility, this is generally *way* in advance and there’s nobody to blame but the plugin and theme devs for not getting their updates out in a reasonable time frame. The recent 3.2 release showed just which devs are slacking, frankly, as they had 4 months to get it done.

    • I agree completely. The difference is all of us who run trunk on production sites know what we are doing. By that I mean we are selective in the themes and more importantly plugins we run.

      I’ve gotten into the habit, if I don’t recognize the plugin author or it is not used by a sizable amount of users, I take the time to go through the code and see if it is A) written up to par with the latest standards and B) not doing anything shady to my site.

      However, we are the overwhelming minority. Most people just do a quick search for a plugin, install, and activate without even thinking twice. Unfortunately, this often bites them in the ass down the road.

      The plugin repo is filled with plugins that are fantastic and really are code poetry. It is also filled with plugins that are crap – code that is out of date or written by people who have no idea what they are doing.

      From my experiences with clients, every time and upgrade comes out and something breaks it is due to a plugin. At the same time, these clients fail to ever look at the plugin rating, support forum, or “supports up to” flag.

    • I am not sure that Ma.tt auto-updates every day. WordPress 3.2.1 was released yesterday, Ma.tt is still running 3.2.

  7. I honestly don’t care if we ever get auto-updates. It’s not a feature I’ll be using. Well, I said the same thing about the one-click upgrades too, but I can’t imagine auto-updates being a good thing unless we start clearing out the plugin repository. If anything, I’d like to see it in plugin form before rolling it into core.

    Right now, I’d rather see the focus shift to post statuses, comment types, post-to-post relationships, and/or term meta. Let’s continue making WordPress easier to extend.

    • Exactly, there are so many more things that are more important than to have auto update that most users will look for a way to disable. Updating core with minor revisions is one thing, but auto updating full new major version no one will use (well, maybe 1% of users will). So, focusing development on a feature that will end up disabled is not a good use of time.

      Justin mentioned post to post relationships, comment types and few other things. I would add better interface for managing posts and taxonomies. Make update faster and that’s it, lets make other things better first.

  8. I would love to have auto-updating as an option, especially for the minor point releases (looking at you 3.2.1).

    Also would be really excited about media uploader improvements. It shouldn’t take 3+ clicks to get an image into a post. How about a drag and drop method?

  9. I don’t personally know anyone unhappy with the process to update WordPress as it is now. Additionally, forcing auto update would make some of my IT friends very nervous as well. I would, however, love to see better media capabilities and post to post relationships.

  10. Nacin mentioned on November that they intend to put the media uploader inline and avoid the popup altogether
    http://twitter.com/#!/nacin/status/29433434675
    This would surely allow for better and faster image insertion, something like the Faster Image Insert plugin does. It would surely be better of course, since WordPress core team can completely revamp the media uploader from the ground up.
    It’s worth mentioning the image insertion method of the Blogsy app for iPad, where you have a sidebar from which you can select your images, even from different sources like Flickr, Picasa, system, etc. A media sidebar right next to the rich text editor would be a winner.

    • Agreed. This WILL break sites for many people. Although I understand Otto’s point of view above, people running trunk are the minority. The responsibility of updating should stay with the site owner…in my humble opinion.

  11. It’s great that differential point releases have been introduced with WP 3.2 and it would be exciting to see more development there.

    Hopefully at some point, critical security updates can be applied fully automated, without any interaction by the site’s owner. This would basically mean having two “update channels”, one for important hotfixes and another one for the rest.

  12. The idea of auto-updates is interesting, but one that I would immediately turn off if given the choice. I think there are other areas of WordPress that could be improved upon before this one is tackled.

    I’ve been anxiously waiting to see or hear what the team would do with a much needed overhaul of the media library. It would be a big step towards an even more powerful CMS if I had the ability to create a folder-like structure in the library to group PDFs, images or other file type. Would make it much easier to manage in the long run for sites that have over a thousand media items.

    Another thing that I think would be another step toward an even better CMS is an improvement to the internal page linking. The new tool for linking to existing pages within the site is great, but I’d like to see it take another step forward by linking to a page’s ID instead of the permalink, and have the permalink get rewritten from the front end to maintain SEO friendly pages. That way, if a user starts altering the overall page structure on a site, the internal links that are already in place will not break unless that page itself is deleted.

  13. Unattended automatic updates (at least for security fixes) will be a great improvement and are absolutely needed to avoid security problems with many sites run by the average user which is not checking his wordpress site for updates every day. Also too much human work force is lost with millions of people clicking on an “automatic upgrade” link – all these hours could be spent more useful! Implementation of this feature, however, should be really something wp devs should think more than twice about. Some ideas:
    A) ROLLBACK must be possible, in case things break.
    B) checksums should be used to have control about the files, that are updated – if $file has been modified, leave it alone, bt send mail about problems.
    C) there are already a few really brilliant update workflows in use – take a look at these and do not reinvent the wheel. Apt-get comes to mind – this could lead to some great ideas about how the source code (and plugins) repositories could be integrated into the process in a meaningful way.
    D) GIT – what else are updates than a pull of a remote branch? Using git as a backend for updates could be a very good way to built a rock solid update infrastructure – this would be also very easy for developers to work with custom code and to integrate into their workflows – having one stable upgrade branch would be very easy to handle even for the most adventures wp hackers.

    Worst case would be to see some wp specific code hackery that ignores the open source wisdom that already has been collected with software deployment – please build upon what already is known to work well and do not release some kind of half-baked feature into the world that might bring more problems than solutions…thanks!

  14. Automatic updates can be a good thing, especially, when considering security patches. In addition to WordPress I run a some MindTouch wiki web sites that use a svn script for handling updates. If there is a problem, which does happen with development versions, I can simply roll back to the previous version that was working.

    I would like to see multiple options, like you do with espresso machines: fully automatic, semi-automatic and manual. Fully automatic silent updates for core, themes, and plugins and if there is a fatal error it either rolls back to the previous version or removes the offending plugin. It would also notify the site admin.

    Semi-automatic would let you choose when to update.

    Manual would be similar to what you currently have now.

    To the average lay person who is getting use to Chrome, Mac OS X and Windows updates I think it would be a popular feature and reduce security holes as well as promote better coding practices among theme designers and plugin developers.

  15. I have small CORE modifications in WP I manually update on each new version. Having it update ‘seamlessly’ and by itself in the background would be the worst idea ever. Any kind of automatic updates is for amateurs, for those who should just host on wordpress.com.

    One has to test plugins, themes and such before moving forwards. You don’t just update and then fix what breaks. Instead of updates, WP should fix the slashing madness in the core. The double addslashes in metas and such.

    PS: First mu-plugin that kicks in my WP installation is an update killer.

    • If you have a modification in core then it is not WordPress anymore and you might do with that code whatever you want, except roaring on features that are built into wordpress core, as you have your own codebase then, so why worry about new features in WP? Or maybe you just learned, why it is a stupid idea to change core files of any software if it is not absolutely neccessary…

      The professional way to do such things is to use the wordpress api and build a plugin. If you need something that is really not possible to do without modfication of core files (what?) then of course you will be able to handle multiple branches yourself and do not need unattended upgrades – the view of a developer should not affect features important for all users – a good developer always thinks about his users first, you can not become a good developer without real dedication, sacrifice and modesty.

  16. Auto update is good feature for those who are using “Default Theme”.
    But by default this option should be off.

    “Certified Plugins” concept could be introduced i.e. The plugins which are thoroughly tested and certified as 100% to work. but if the bites of any plugin file don’t match then that plugin should not be automatically updated.

    Just my 2 cents

  17. wow. I’m glad my live blogging generated so much interest :)

    just to clarify, Matt didn’t say that the auto updates would be for 3.3 but rather it’s on his 1 to 3 years radar. Upload/media would be more for the immediate future however.

  18. The whole WP update ‘cycle’ is starting to become a pain for designers who manage more than a handful of websites – for one reason : plugins. Basic, no frills sites with a few plugins can usually be updated without much drama but those with a dozen or so I have decided to leave as-is.
    I implement various security measures / plugins etc to protect the sites as far as possible but leave any major updates until the client is ready for a complete site redesign…

Leave a Reply

Please note that WPCandy is a moderated community.

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>