Plugins get deactivated over multi-site on updating everything from the hub

I just updated plugins for a bunch of sites via the Hub. Some WPMUDEV plugins like Defender and Smush deactivated automatically in all sites in my Multisite network. This is serious. Anyone who updates via the hub might find themselves unprotected by Defender. Please check into this immediately.

  • Kasia Swiderska

    Hello Tony,

    I'm sorry to hear that this happen to you. I just updated bunch of my test websites from HUB but I could not replicate this issue at all.
    I will need to know exact urls of the sites where this happen - you don't need to share those here, but if you could enable support access to those where it happen then I will know what urls pass to developers so they could check that issue.

    http://premium.wpmudev.org/manuals/wpmu-dev-dashboard-enabling-staff-login/

    kind regards,
    Kasia

  • Tony G

    For the record, I did not post this request, it was posted for me, and the translation of my report is incorrect.
    The issue is not with "Multi-Site", it's with "Multiple Sites". In the Hub I have registered several completely independent installations for which I use the Manage / Update Everything option. Some are at Core v4.7, some at 4.8, and they all have different plugins. When I do updates, sometimes they fail and I just repeat the updates until they all succeed.

    As reported to Support, I think what's happening is that the Hub is getting a few timeouts from my sites at different times and giving up. I believe the process to update a plugin involves internal deactivation, update, then reactivation. But if the timeout occurs during reactivation the plugin is left unactivated.

    OK, the problem is almost certainly with my shared host. Yeah, "shared host", but these things can take more than two or three simultaneous connections. :slight_smile: Server overload? Low memory? DoS? Too many simultaneous hits on my site? Nah, not every time I run updates from the Hub. Whatever the reason. This cannot be unique to me. I'm on DreamHost which is one of the large worldwide providers.

    Looking at the bigger picture, I'm seeing the same issue with failed managed backups via Snapshot, failed performance checks, and (probably the most telling) LOTS of reports that my sites are down and up. I think the WPMU DEV / Incsub code is just too aggressive.

    Yes, I'll check with my host and in their forums on this, but to my knowledge there is no common performance issue affecting their servers.

    The solution I recommend is for the Hub code to be enhanced with a higher number of retries. From my logs it looks like there are only two retries in the loop. Try a delay of 2 seconds and loop 5 times. This is probably a 2-line change that takes 2 minutes to implement. That's not going to affect anyone else where the connections are solid - only sites that some some reason are experiencing temporary delay.

    On the specific issue of this thread, the Hub code is just checking to see if a site plugin version matches current. I recommend that it also needs to verify before exiting the update loop that a plugin that's being updated is left in the same state in which it was found - Active or Inactive.

    Given this, I don' think access to the sites is required at this time. The only thing that would help for this (as I've requested in another thread) is for the Hub to maintain a detailed log of every event/transaction/response related to interaction with our sites. Just save the request/response pairs to a file somewhere so that when we report an issue within a day of an event that Support can look at the logs. (Not unreasonable?) And as a bonus, I'd like to see my own logs so I can triage issues before having to report them to Support. The logs will tell us everything we need to know.

    Thanks.

  • Tony G

    These threads are related and as I've documented it looks like the issue is consistent. The Hub has simple code to spawn off a lot of threads to do tasks. It has a low timeout value that doesn't give the threads enough time to finish, and there aren't enough retries. When a failure occurs, the Hub code doesn't re-activate what was de-activated for update. I've provided my analysis and suggestions and I hope this has been enough for the developers to recognize the actual and potential issues, and to try to code for handling this scenario. Thanks.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.