[wp-trac] [WordPress Trac] #53705: Plugin upgrade deletes files from other in-progress upgrades

[WordPress Trac]

#53705: Plugin upgrade deletes files from other in-progress upgrades
-----------------------------+---------------------
 Reporter:  bpayton          |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  5.9
Component:  Upgrade/Install  |     Version:  5.8
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+---------------------

Comment (by bpayton):

 Here's how I am reproducing this issue with core WordPress. Thanks to
 @aristath for pointing out that updating inactive plugins doesn't enable
 maintenance mode, which might otherwise block concurrent update attempts.

 First, create a script to force install out-of-date plugin versions:
 {{{#!bash
 #!/usr/bin/env bash

 function wp_install() {
         wp --skip-plugins plugin install --force --version="$2" "$1"
 }

 wp_install 'amp' '2.1.2'
 wp_install 'coblocks' '2.14.0'
 wp_install 'layout-grid' '1.6'
 wp_install 'page-optimize' '0.5.0'
 wp_install 'wordpress-seo' '16.6'

 # See that we have outdated plugins
 wp plugin list
 }}}

 Then, to test:
 1. Start with a clean, default WordPress installation and access to WP-CLI
 2. Run the above script to install/downgrade plugin versions
 3. Make sure the plugins above are deactivated
 4. Open `/wp-admin/plugins.php` in your a modern web browser (I used
 latest Firefox)
 5. Open the browser dev tools Network tab so the browser starts collecting
 network requests
 6. Run this in the dev tools console to make sure plugin update links are
 found:
 {{{#!js
 $$('.inactive + .plugin-update-tr .update-link')
 }}}
 7. If there are links found, run this in the dev tools console to request
 updates for the inactive plugins all at once:
 {{{#!js
 $$('.inactive + .plugin-update-tr .update-link')
   .map( a => a.href )
   .forEach( updateUrl => {
     fetch( updateUrl )
       .then( r => r.text() )
       .then( ( ...args ) => console.log( `${updateUrl} resolved`) )
       .catch( e => console.error( e ) )
 } )
 }}}
 7. When each request completes, a message should printed to the console.
 Once all the requests are done, you can examine each request's output for
 failures in the dev tools Network tab.
 7. Run `wp plugin list` to see if any of the plugins are still on old
 versions
 8. Check if any of the plugins disappeared after the upgrade attempt. This
 was not uncommon in my testing.
 8. Examine the PHP error logs for failures. Without instrumenting
 WP_Upgrader with error_log() statements, there won't be much in the logs,
 but there may be generic warnings about failed FS-related operations.

 Repeat to see different outcomes. In my experience, something usually
 fails, but sometimes everything works OK.

 If your testing goes like mine, you will see a mixture of failed upgrades,
 disappearing plugins, and maybe new plugin versions that are missing
 files. To really see this in the logs, you unfortunately have to add error
 logging to the installation steps and error conditions under
 `WP_Upgrader::run()`.

 I'm sorry these are so long. Testing this is kind of a pain. But I think
 these instructions should work with a default WordPress installation.

 If you're able to try this, I would love to hear how it went for you.
 Thanks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53705#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform