WordPress.org
Get WordPress

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #53705, comment 7


Ignore:
Timestamp:
07/22/2021 11:02:03 PM (5 years ago)
Author:
bpayton
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #53705, comment 7

    initial v1  
    2020
    2121Then, to test:
    22 1. Start with a clean, default WordPress installation and access to WP-CLI
    23 2. Run the above script to install/downgrade plugin versions
    24 3. Make sure the plugins above are deactivated
    25 4. Open `/wp-admin/plugins.php` in your a modern web browser (I used latest Firefox)
    26 5. Open the browser dev tools Network tab so the browser starts collecting network requests
    27 6. Run this in the dev tools console to make sure plugin update links are found:
     221. Start with a clean, default WordPress 5.8 installation and access to WP-CLI
     232. Apply [https://core.trac.wordpress.org/attachment/ticket/53705/wp-upgrader-error-logging.diff the patch] to add WP_Upgrader error logging
     243. Run the above script to install/downgrade outdated plugin versions
     254. Make sure those plugins are deactivated
     265. Open `/wp-admin/plugins.php` in your a modern web browser (I used latest Firefox)
     276. Open the browser dev tools Network tab so the browser starts collecting network requests
     287. Run this in the dev tools console to make sure plugin update links are found:
    2829{{{#!js
    2930$$('.inactive + .plugin-update-tr .update-link')
    3031}}}
    31 7. If there are links found, run this in the dev tools console to request updates for the inactive plugins all at once:
     328. If there are links found, run this in the dev tools console to request updates for the inactive plugins all at once:
    3233{{{#!js
    3334$$('.inactive + .plugin-update-tr .update-link')
    … …  
    4041} )
    4142}}}
    42 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.
    43 7. Run `wp plugin list` to see if any of the plugins are still on old versions
    44 8. Check if any of the plugins disappeared after the upgrade attempt. This was not uncommon in my testing.
    45 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.
     439. Examine the PHP error logs for failures
     4410. 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.
     4511. Run `wp plugin list` to see if any of the plugins are still on old versions
     4612. Check if any of the plugins disappeared after the upgrade attempt. This was not uncommon in my testing.
     47
    4648
    4749Repeat to see different outcomes. In my experience, something usually fails, but sometimes everything works OK.
    4850
    49 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()`.
     51If your testing goes like mine, you will see a mixture of failed upgrades, disappearing plugins, and maybe new plugin versions that are missing files.
    5052
    51 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.
     53I'm sorry these are so long. Testing this is kind of a pain. But I think these instructions should work with a default WordPress 5.8 installation.
    5254
    5355If you're able to try this, I would love to hear how it went for you. Thanks!