• Resolved richards1052

    (@richards1052)


    Two plugins which are marked for auto update (using the native plugin auto updater) disappeared from my plugin directory after recent updates to the plugins were introduced. This is the 2nd time one of the plugins disappeared. The plugins were Mailpoet and Yoast SEO.

    Anyone know if auto update can have problems updating these 2 plugins? And how to prevent this from happening short of disabling auto update?

    • This topic was modified 3 years, 5 months ago by richards1052.
Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Contributor Jen H. (a11n)

    (@jenhooks)

    Hey @richards1052,

    I can’t really speculate what’s going on here. Have you consulted with your host on this yet? That’s the recommendation I’d made — or, you might consider asking on the general WordPress.org forums.

    Good luck!

    Thread Starter richards1052

    (@richards1052)

    Can you review this msg fr my web host. He asks whether the native auto updater has any connection to Jetpack. There clearly is a conflict or error generated by the native auto updater that causes the plugin updates to not only fail, but disappear the entire plugin from the directory.

    Here’s the msg:

    about the error lines, there are thousands of these lines at 16:05

    [17-Nov-2020 16:05:10 UTC] PHP Warning: chmod(): No such file or directory in XX/public_h
    tml/wp-admin/includes/class-wp-filesystem-direct.php on line 173

    I think “chmod()” is called on the update process, but the files vanished between the time they were listed and the time some actions were made on them

    right after there’s also:

    [17-Nov-2020 16:05:20 UTC] PHP Fatal error: Uncaught Error: Class ‘MailPoetVendor\Doctrine\DBAL\Types\BooleanType’ not found in XX/public_html/wp-content/plugins/mailpoet/vendor-prefixed/doctrine/dbal/lib/Doctrine/DBAL/Types/Type.php:2

    So some files were really missing during the upgrade

    The bug is probably related to the WP updater rather than those plugins: i looked at the SQL backup from the 17 morning, and i saw the auto_updater call was scheduled for 16:04:52

    First time we’ve seen this issue so far.. And i’m not seeing any bug report on the WP trac about it.

    I’d report it to them but we have too little information to share

    I have a question: are auto updates still enabled in jetpack settings (i think it’s from wp.com which i cannot see)?
    Because i see a query from jetpack server during the auto-upgrade from WP. So there are chances they both tried to upgrade:

    [17/Nov/2020:16:04:57 +0000] “POST /wp-cron.php?doing_wp_cron=1605629097.3026950359344482421875

    WP cron starts the auto update

    [17/Nov/2020:16:05:07 +0000] “GET /2013/10/15/iran-hacks-azerbaijans-israeli-made-drone-fleet/?relatedposts=1&highlight=drones HTTP/1.1” 503

    Google visits a page but gets a 503 code because the upgrade is still running

    [17/Nov/2020:16:05:00 +0000] “POST /xmlrpc.php?for=jetpack&[…]

    Jetpack makes a very long call, which finishes after the google visit (logged after but started 16:05:00), and took 11s to process, there are chances it also tried to upgrade. But that’s just a possibility.

    I have really no idea how both of them work together and if they share the same update data. It’s possible that jetpack takes over and that it’s an issue with it.

    Plugin Contributor Dan (a11n)

    (@drawmyface)

    The details of Jetpack’s compatibility with core auto-updates can be found here:
    https://github.com/Automattic/jetpack/pull/16741

    Essentially, Jetpack now uses the core update function, so there should be no conflict, and there is no longer a separate auto-update setting in Jetpack.

    I’m going to ask our developers if they have any thoughts on what might cause this. I’ll get back to you when we have an update.

    Plugin Contributor Dan (a11n)

    (@drawmyface)

    Hi again

    I confirmed with our developers that if you’re using WP5.5+ then WordPress is responsible for autoupdates, and Jetpack is not involved in that.

    The significant part is here:

    So some files were really missing during the upgrade

    This indicates that some files were missing from the plugin update (which can happen with larger plugins containing a lot of files) so the update failed and the plugin was deactivated. Then if you tried to reinstall the plugins you would also get an error because the plugin folder already exists (just without all the files).

    Regarding the Jetpack query your host mentioned, that looks like Jetpack was trying to fetch related posts from WordPress.com (which it does every 12 hours when the related posts cache expires). It’s not related to the plugin update though, just coincidental timing.

    So in summary, it seems the plugins failed to update because the updater encountered an error when copying files, and some of the files were not copied. This is more likely to happen with large plugins like Mailpoet and Yoast SEO, which have a lot of files to copy.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Potential auto update conflict’ is closed to new replies.