WordPress 4.2 Radically Improves The Plugin Install and Update Process

One of the features I’m looking forward to in WordPress 4.2 is the improved plugin install and update process. Gary Pendergast and a team of volunteers have spent the last six months collaborating on shiny updates.

When you update or install a plugin in WordPress 4.1, you’re taken to a screen that shows its progress. When it’s done, you can either activate it or navigate back to the plugins screen.

Old Plugin Update Routine
Old Plugin Update Routine

Here’s what it looks like when you update a plugin in WordPress 4.2.

New Plugin Update Routine
New Plugin Update Routine

Last but not least, here’s what it looks like when you install plugins in WordPress 4.2. It’s important to note that when a plugin is installed, it’s automatically activated.

New Plugin Install Routine
New Plugin Install Routine

At the March 11th developer chat, the team decided to scale back shiny updates to focus on plugins for 4.2. Fancy updates for themes will be added in a future release and will continue to use the classic update/install routine. You can follow the progress by watching tickets 31529 and 31530.

During testing, I was able to install 10 plugins in under a minute. Removing friction from the update and install process not only saves mouse clicks, but it’s a great user experience. In fact, the process is so quick, it might make sense to add a visual indicator that tells the user a plugin is installed. For instance, when a plugin is installed, a notification model window would pop up and fade away.

If you’d like to try shiny updates for yourself, install WordPress 4.2 beta 2 on a test site. If you encounter any bugs with shiny updates or a different part of WordPress, post them to the Alpha/Beta area in the support forums.

55 Comments


  1. This is fantastic! Way better UX. I never understood why plugins aren’t automatically activated after install – finally fixed :)

    Report


  2. Some Web developers like to leave certain plugins deactivated in the dev environment that are not needed until the site is pushed live. Will there be any settings to override auto-activate?

    Report


    1. Yeah. The auto activation makes me nervous too. Things like maintenance mode plugins can do all sorts of things right on activation. I wish there was a way to opt out on a per plugin basis in the UI.

      Report


      1. I don’t always activate plugins. I install and leave until they are needed.
        Be interesting to see how the auto activate goes.

        Report


      2. Because I might want to install several that look as though they perform a similar function, and then test them one by one. That’s a much more efficient process than being forced to test each one as I install it.

        I also sometimes go hunting plugins to “play with” later when I have the time. But if I have to keep deactivating them, that’s not going to happen.

        Auto-activation is simply a ridiculous idea. It might even force many of us to go back to installing plugins via FTP!

        Report


    1. Why not just tell users to backup their sites before installing any plugins?

      the simple act of installing a plugin will “do stuff” in your WordPress database. The control and protection you lose is not worth the simplicity you gain.

      The same thing happens when you manually click activate, so what’s the big deal?

      Report


      1. ultimately? NOT a big deal. But if you absentmindedly click “install”, you still have the ability to pause and correct yourself (like it is now). There’s no reason to take that away; my real point was and is that this feature needs to have an on/off toggle, preferably defaulted to off.

        Report


    2. Guys, I don’t get it. Why should I want to install a new plugin, without the actual intent of activating it – what am I missing?

      Report


      1. While the overall sentiment here is clearly on the same side I’m coming from, your point is well-taken. BUT: “that’s mine, how dare you!!!!” left OUT of the discussion, the point still needs to be that plug-in activation makes change to your WP install, and you may not be able to unmake all of them.

        So it’s about control for a REASON; the “right way” to handle plaugins is carefully. You take a backup of the database before you activate. Then you test. Then you get a handle on what’s changed. Then you either move forward with the plugin or rip it out by its roots.

        Report


  3. I, too, have some plugins for used for maintenance and other occasional activities. I definitely would not want them activated when updated. They should remain in their prior state.

    What about support for updating a plugin from a .zip file? This ability is missing and makes it unnecessarily time consuming to upgrade plugins purchased from other sources or when you need to roll back to an older version (due to a new version breaking something).

    Report


      1. Thank you for the clarification. That’s better, but I still would not want it to auto-activate on a new plugin install. It’s not uncommon for me to install several plugins that perform a similar function, and then activate each one individually as I try it. I would think this is a common usage scenario. So, I hope there it a setting to turn off the auto-activate.

        Regarding update from a.zip – I can’t imagine why that is considered low priority!

        Report


  4. Not super relevant to the post per se, but how did you make those lovely moving gifs Jeff?

    Report


    1. I’m going to write about it tomorrow. Also, I’m glad the media library supports animated gifs now.

      Report


  5. For me I think auto activate will be up there with the removal of the dashboard column choice of WordPress 3.8 as two steps forward one step back.

    In WordPress 3.8 they introduced responsive dashboard widgets which was great, but they removed the option to choose how many columns to show.

    To get this feature back you had to add some custom code to your theme or install a new plugin, the best I have found for this is https://wordpress.org/plugins/restore-columns/

    The new 4.2 plugin install and update features are great but why not just show a “Activate” button after the install?

    I’m sure their are plugin developers working on this as we speak but it means installing another plugin to get this functionality back.

    Isn’t it ironic….don’t you think?

    Report


  6. User experience: I really wish links such as “Visit Site” from WP Admin open in a new tab, instead of overriding the current tab.

    Report


  7. I wish to be able to control auto update off/on especially for site maintenance plugins and for testing alternate plugins for best fit to my site.

    Report


  8. why not two button like “install now” and “install now and activate”? There is enough space for a second one…

    Report


    1. I agree or even once it is installed it changes to an active button.

      Report


    2. I agree or even once it is installed it changed to and activate button.

      Report


    1. Yes, how about Multisite? It better not do a “Network Activate”. In multisite you hardly ever want to network activate, you want to only activate on specific sites.

      Report


      1. I’ve installed plugins in 4.2 beta and it does NOT network activate. You still have to network activate it or activate per site.

        The UI improvement is huge and this really is a step forward.

        Report


      2. When I tested it I got the shiny workflow but it did not activate the new plugin on the network or any site.

        I liked the new UI, very smooth.

        Report


  9. The solution to the automatic activation issue people are complaining about is simple. Add a hook that allows you to disable auto activation. If you have done this then installing would not auto activate. If you have not then it will behave as intended.

    People need to remember that Developers != Average Users and Average Users > Developers. WordPress needs to take these steps to make WordPress more friendly and improve the overall UX for AVERAGE USERS. Developers will need to learn to deal with that fact.

    So instead of complaining about features like this, suggest alternative solutions that will address this concern. I’ve already done so above. Problem solved.

    Report


    1. I said the same, Carl, but not “a hook to DISable” … there should be a hook to ENable.

      Report


      1. You can add the hook, the average user can’t. It makes sense that the hook would be to activate your desired behavior, not some blogger with no coding expertise.

        Report


      2. Josh, let’s be specific, by all means. Yes, the hook is addable. And of course the average user cannot. But isn’t that the point? The average user is looking to the WordPress mother ship to take care of them and doing this “the right way” is important.

        My guess (and most people in this thread seem to be on this side) is that the average user isn’t exactly clamoring for this change, so while the ability to turn it on IS a good thing, having it on by default (or on, period), Just … is … not.

        Report


      3. The average WordPress user expects the plugin to be installed and activated.

        Requiring them to click to install a plugin and then click to activate the plugin adds an unnecessary step to the process in order to cater to developers and power users who don’t want the plugin activated immediately simply doesn’t make sense from a user experience standpoint.

        WordPress should be streamlining things and making things easier for the average user. That’s more than just making existing behavior look pretty without actually changing the existing behavior. You need to actually make it easier. Not just look nicer.

        The vast majority of users are clicking to install the plugin and then immediately clicking again to activate the plugin. Why not make that process more streamlined?

        Just like core background automatic updates the behavior should be streamlined for the average user and then a hook can be used to modify that behavior for developers and power users.

        The whole point of this change is to make WordPress a better experience for the average user. Hiding this functionality behind a hook defeats the purpose because the very type of user this functionality is geared towards is the type of user that you don’t really want fiddling with hooks.

        Report


      4. Didn’t want you to think I’d ignored you; I think we’ll have to “agree to disagree” !

        Report


    2. Carl keeps saying things about what the average user wants. @Carl Hancock, if you have access to some research to back up these assertions, please let the rest of us in on it.

      For the record, I am not a developer. I don’t code. I still don’t want auto-activation. I am clearly not the only person of that view with this (non-)skillset.

      Report


  10. I agree, will be interesting to see how this plays out.

    My thoughts, I like this idea, especially for that large percentage of average users.

    I have several thoughts on this after reading the comments, but figure if I list them, well, it will just circle back to all who are for it and all who are against it. Everyone is standing their ground with their own reasons, and that’s good.

    I think I will do my own post on this next week.

    Report


  11. I think I’m darned close to the famed “Average User.” I can’t add a hook and I don’t want to learn for this bad idea. I’ll find it a major inconvenience to lose control of plugin activation. That’s MY decision! Reg. Thumbs comes to mind as a plugin I use somewhat often and do not want activated until a time I choose.

    It seems inconsistent to force this change on us by saying “father knows best” for the average user but then not updating the theme install yet so it works the same. That kind of mismatch confuses the beginning user. I admit to missing the good old days when updates where delayed until they were done.

    Rather than taking control away from intermediate and above users to “fix” something that wasn’t broken anyway, please, please listen to what beginning and intermediate users want fixed. We want a decent front end editing system, a decent Post Editor, real image handling.

    Report


  12. Perhaps this is just the way WordPress is going? We will now be needing plugins (or hooks) to disable functionality instead of adding a simple checkbox to the general settings that says “I don’t want that”.

    WP 4.2 already has two of these things. There is this (the auto activate of new plugins) and please don’t forget the emojis that add 2-3 scripts as well as a call to s0.wp.com which is blocked for more than 20% of the world’s population.

    I think a fork of WP is around the corner if things “progress” the way they are doing now…

    Report


    1. Piet,

      I think you could be right.

      Looking at the themes I use, I see that I am already removing a ton of stuff from the WP head and the Customizer, removing the WP version from scripts, CSS and RSS and the admin footer, removing injected CSS from the comments and gallery, and, of course, removing Howdy. And, on install, I had to remove Hello Dolly!

      Report


  13. What research do I have to back up the assertion that WordPress needs to make things easier and more straightforward for the average user? My research comes from personal experience supporting and developing one of the most successful commercial WordPress plugins in the marketplace (Gravity Forms).

    Report


    1. So Gravity forms users are “average users”? Good to know. Thanks for the definition. At least I know I’m not average.

      Report


      1. Every second form on WP is almost with Gravity, so yes, Gravity user is average user ;)
        Anyway Carl has good points, that majority of users can not use hooks or put code here and there, even its hard to find right plugin for task.
        So if WordPress somehow decided to be used on more than 25% of web, it has to be focused on masses – on average users.
        Sure it can costs some performance, some functionality, maybe some cutting edge technology …

        Add many options for masses is not good solution, it will brings pain. It has to be decided for them without them :D
        I m not sure if focus on quantity (% of websites builded with WP) is right way, anyway WP did it already several years with success and beat all other platforms.

        Also keep in mind, that WP or Automatic or whoever somewhere there collect tons of data, so they have idea how WP is used by majority of users.

        Anyway I hope emoji junk in core WP is just April fool ;)

        Report


      2. And yet now it’s clear that auto-activation of plugins wouldn’t enhance the experience for the average user at all, so it’s been punted. QED.

        Report


  14. Ok, so doe anyone have that Snippet of Code for this Disable/Enable Hook handy yet ? I want to install it on ALL of my client sites as I do NOT want an Auto Activate at ALL.

    Report


      1. Hahaha I was actually wondering if you were going to write another article on this when I made the comment since so many were talking about it. I must have checked just before the article was published. :)

        Report


  15. @Jeff Chandler – you know that all us shaved apes have an innate propensity to forget awesomeness in general so personally I would reiterate WP awesomeness as a standard. ie what was awesome 5 seconds ago is now just the new bar. :) And yeah I don’t do that on my site, but WP Tavern is a standard in itself so it is not my place. :)

    Report


  16. It is always a bad idea in the development cycle of a software product to change basic default behaviour to the opposite of what has been established over years. You can of course allow things in a certain version that were not allowed yet in the previous ones, but only after an opt-in for this behaviour change. So add a new check box “Automatically activate newly installed plugins” in the basic WP settings which is off by default and do not change the behaviour of installing plugins to something else people might now expect. And maybe add a hook that allows to opt-in by calling it. Or add a define(‘WP_ACTIVATENEWLYINSTALLEDPLUGINS’, true); for the wp-config.php. Or, like already proposed, add an “Install and avtivate” button on the plugin install page. But again, leave the default behaviour as it is now.

    Report


  17. Can anybody have idea how to catch errors while updating plugins or themes programmatically using the class class-wp-upgrader?

    Report

Comments are closed.