Cancel

Jeff Chandler

Enhanced Plugin Installs Axed From WordPress 4.2

A few days ago, we highlighted how WordPress 4.2 radically improves the installation and update process for plugins. Several readers commented on the article expressing that automatically activating plugins after installation is a bad idea. A decision was made during the March 25th, WordPress core developer chat to remove enhanced plugin installs from WordPress 4.2 and punt it to a future release. However, enhanced plugin updates will remain in WordPress 4.2.

New Plugin Update Routine
New Plugin Update Routine

It’s uncommon for functionality to be removed from WordPress this late in the development cycle. Drew Jaynes, who is leading the 4.2 release cycle, explains that the feature just isn’t ready.

Prudence demands that we decide whether to do things now vs do things right. In this case, we want to make sure we handle the user experience of activating plugins after installation the right way for most use cases. So we still have ‘Shiny Updates’, but we’re going to have to fall back and regroup on ‘Shiny Installs’.

On the Make WordPress core blog, Aaron Jorbin outlined three issues caused by auto activating plugins.

  1. Plugins that require after activation steps (such as connecting to Jetpack or Google Analytics, updating permalinks for BuddyPress, etc) aren’t obvious. We need a way for plugins to provide a notice upon activation that shows what to do next.
  2. Since the menu isn’t updated, users still need to do a page refresh in order for the changes to actually go in effect and for them to use the features of many plugins.
  3. There are plugins such as maintenance mode ones that users will not want to be activated right away.

The idea of installing plugins inline is sound, but until the user experience issues are addressed, the plugin install process will remain the same.

Category:
Tags: , ,

SHARE THIS:

LIKE THIS

25

25 responses to “Enhanced Plugin Installs Axed From WordPress 4.2”

  2. That’s great. Good call to hold it a bit until it’s ready. The easiest solution I can think of is a two step process. Like.. You click the “Install” button, the button change to show a loading effect, then the plugin gets installed and the button becomes an “Activate” button. That should have be like this from the beginning.

    Create forum topic from comment
    Reply

    • That has issues, mainly the fact that by making installs asynchronous, activation would need to be blocked until after all the installs take place. Also, what does the post activation page look like? If you are on the recommended tab, should that be cached with your recommended plugins when you install? Should you see a notice of “recently installed but not yet activated plugins”.

      This was absolutely considered, but the can of UX worms here is much much larger and it’s also not what the majority of end users need.

      Create forum topic from comment
      Reply

      • The fact that the majority of users don’t care is not an excuse to do something more lazy, where there’s a way to please everyone, making the installation easy and fast, but still giving the user the option of activate or not. That’s why I think my proposal is a good middle ground.

        Auto-activation also implies that developers needs to keep in mind what is happening after installation, and they should change their plugins accordingly (if necessary). Even if there’s an opt-out option, devs should still make changes to accommodate to this. Even if a small percentage of plugins require modifications, I think this is unnecessary.

        Again, if there’s a middle ground that can make everyone happy, there’s no reason to not go that way. Especially if a bit more work on the core can avoid a lot of work of hundreds of developers.

        I’m also responding here to your last post, that I just read.

        Create forum topic from comment
        Reply

  11. Thanks very much for this. I have a question about auto-updates, though. Won’t the same issue with the menu not updating occur with auto-updates since the screen won’t reload? That wouldn’t be an issue most of the time, but some plugin updates add new sub-menu links, such as the very latest WordPress SEO by Yoast update, which removed several sub-menu items and amalgamated them into two new sub-menu items. So wouldn’t these changes to the menu still need a page reload after an auto-update? If so, is that something that is being addressed in time for the April release? Thanks very much for the info :)

    Create forum topic from comment
    Reply

      • @ Julie – the animated gif is just showing how the new Shiny Updates feature works. It requires that you to actually click something (the update now link) in order for the plugin update to happen. All WP auto-updating stuff happens in the background and does not require any clicks by you. So those things are actually 2 totally different things. As far as I know automatic background stuff and Shiny Updates are 2 entirely different animals.

        Create forum topic from comment
        Reply

        • Hi Ed, thanks for taking the time to reply. Yes, I understand the difference between auto-updates and Shiny Updates, which is why I came back to clarify my meaning. I guess I didn’t do a good job at it!

          My question is about how Shiny Updates behave. When you click the button, the screen doesn’t reload. So, in the event that a plugin update adds a new menu item (as described in my original comment), the user would still have to refresh the screen for the changes to take effect. That seems to me to be a glitch in the expected user experience, and am wondering if it will be (or already has been) addressed in time for the April release. Thanks again, and cheers!

          Create forum topic from comment
          Reply

          • ah ok got it. I am a decent coder and know my way around WP pretty well, but that is the extent of my credentials. So I am going to state what I know from that/my perspective. I believe the Shiny Updates feature is done with AJAX and what is really cool thing about doing anything that uses js/AJAX is that you can do things in real “real-time” vs doing something with only php code, which executes/processes in real-time, but you are always seeing the past and not now/the current moment. Example: a php function is processed and you see a displayed message. In that moment you see “now”, but in reality the function was already processed so technically you are seeing the past – yeah wrap ur head around that one. :) I am not a js or AJAX expert, but what I do know is that AJAX works very similarly to Visual Basic (VB) code that is used in most Microsoft applications so you can actually access things in real-time from the client/your browser as they are happening in real-time.

            So to answer your question to the best of my knowledge I would say that since AJAX (assuming that is AJAX is used for Shiny Updates) is being used then browser refreshing is not going to be any sort of factor because of how AJAX works in real-time. So if the Shiny Updates code was doing what it does by using just php code then a browser refresh would be a factor in this equation. Hope that all made sense. :)

            Create forum topic from comment
            Reply

  12. WP automatic updates (wp version updates/upgrades) happen in the background so they would not be affected in any way. I have never tried to do/setup automatic plugin and theme updates so not sure if they are done in the background as well. I assume they are.

    Create forum topic from comment
    Reply

  13. LOL uh yeah – Configuring Automatic Background Updates kind of says it all. ;)
    https://codex.wordpress.org/Configuring_Automatic_Background_Updates

    By default, automatic background updates only happen for plugins and themes in special cases, as determined by the WordPress.org API response, which is controlled by the WordPress security team for patching critical vulnerabilities. To enable or disable updates in all cases, you can leverage the auto_update_$type filter, where $type would be replaced with “plugin” or “theme”.

    Create forum topic from comment
    Reply

  15. *cough* MAINTENANCE PLUGINS *COUGH*

    I am completely against the WordPress servers/people/mascot/etc…turning things on or off without asking me, or updating things without asking me. things can go the funky way (bad funky not good funky).

    I have a snow plugin on my site. I don’t want it active during spring/summer/fall. So this automatic active thing is not something I would like.

    On another site I have a Santa is coming plugin, I de-activate it on Dec 25 at 2am. Don’t activate it again until Dec 1. (it has a countdown as well). My snow plugin again (see line above) I put a Santa “flake” so it snows Santas for most of December.

    Create forum topic from comment
    Reply

  16. Weighing in – I am not wanting WordPress to do plugin or even core updates in the background without having my request. If some really want this, have it be to be switched on actively, not the default. It is a big lack of control over the blend of plugins I’ve selected for a site.

    Create forum topic from comment
    Reply

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading