[wp-trac] [WordPress Trac] #54546: Fatal error receive while updating WP 5.8.2 to WP 5.9.
WordPress Trac
noreply at wordpress.org
Wed Dec 1 19:21:30 UTC 2021
#54546: Fatal error receive while updating WP 5.8.2 to WP 5.9.
-------------------------------+---------------------
Reporter: apeksha10 | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 5.9
Component: Upgrade/Install | Version: trunk
Severity: normal | Resolution:
Keywords: reporter-feedback | Focuses:
-------------------------------+---------------------
Comment (by hellofromTonya):
Running more tests with @costdev. Let me share findings so far.
== My Machine (macOS)
On my machine:
- localhost: Local
- OS: macOS
- Plugins: Core Rollback and Beta Tester - both are activated
- Browser: Edge
Upgrading from 5.8.2 to 5.9.0 Beta 1 via the Beta Tester
* No errors and nothing in the logs
* Upgrade is successful
* Requests library is updated with the newest 2.0.0 code
* But the renamed files are not renamed:
* `wp-includes/Requests/Iri.php` is not renamed to `wp-
includes/Requests/Iri.php`
* `wp-includes/Requests/Transport/cURL.php` is not renamed to `wp-
includes/Requests/Transport/Curl.php`
* Site Health's Filesystem Permissions show:
{{{
The main WordPress directory Writable
The wp-content directory Writable
The uploads directory Writable
The plugins directory Writable
The themes directory Writable
}}}
Downgrading from 5.9.0 Beta 1 to 5.8.2 via the Beta Tester:
* The ugly orange PHP error interface flashes
* Upgrade is successful
* Requests library is restored to the older version
* Filenames mentioned above remain, which matches the 5.8 version
* But `debug.log` has the following warning:
{{{
[01-Dec-2021 17:21:49 UTC] PHP Warning: rename(/var/tmp/wordpress-5.8.2
-no-content-gTRqga.tmp,wordpress-5.8.2-no-content.zip): Operation not
permitted in ../Local/test/app/public/wp-admin/includes/file.php on line
1201
[01-Dec-2021 17:21:49 UTC] PHP Stack trace:
[01-Dec-2021 17:21:49 UTC] PHP 1. {main}() ../Local/test/app/public/wp-
admin/update-core.php:0
[01-Dec-2021 17:21:49 UTC] PHP 2. do_core_upgrade()
../Local/test/app/public/wp-admin/update-core.php:1108
[01-Dec-2021 17:21:49 UTC] PHP 3. Core_Upgrader->upgrade()
../Local/test/app/public/wp-admin/update-core.php:879
[01-Dec-2021 17:21:49 UTC] PHP 4. Core_Upgrader->download_package()
../Local/test/app/public/wp-admin/includes/class-core-upgrader.php:124
[01-Dec-2021 17:21:49 UTC] PHP 5. download_url()
../Local/test/app/public/wp-admin/includes/class-wp-upgrader.php:309
[01-Dec-2021 17:21:49 UTC] PHP 6. rename() ../Local/test/app/public/wp-
admin/includes/file.php:1201
}}}
* Site Health's Filesystem Permissions show:
{{{
The main WordPress directory Writable
The wp-content directory Writable
The uploads directory Writable
The plugins directory Writable
The themes directory Writable
}}}
So the filesystem is the same as Windows, i.e. meaning the file name case
does not seem to be an issue. Files are loading properly.
== Colin's machine (Windows)
On my machine:
- localhost: Local
- OS: Windows
- Plugins: Beta Tester
- Browser: Edge
Upgrading from 5.0.14 to 5.9.0 Beta 1
* Fatal error:
{{{
PHP Fatal error: Uncaught Error: Class 'Requests_Exception' not found in
\wp-includes\Requests\Transport\cURL.php:422
Stack trace:
#0 \wp-includes\Requests\Transport\cURL.php(177):
Requests_Transport_cURL->process_response('', Array)
#1 \wp-includes\class-requests.php(379):
Requests_Transport_cURL->request('http://...', Array, NULL, Array)
#2 \wp-includes\class-http.php(370): Requests::request('http://...',
Array, NULL, 'POST', Array)
#3 \wp-includes\class-http.php(589): WP_Http->request('http://...', Array)
#4 \wp-includes\http.php(187): WP_Http->post('http://...', Array)
#5 \wp-admin\includes\update-core.php(1409): wp_remote_post('http://...',
Arra in \wp-includes\Requests\Transport\cURL.php on line 422
}}}
* Files are upgraded with the new code.
* Like my machine, the `IRI.php` and `cURL.php` files were not renamed.
Downgrading from 5.9.0 Beta 1 to 5.8.2
* Error:
{{{
Uncaught Error: Class 'WpOrg\Requests\Exception' not found in \wp-
includes\Requests\Transport\cURL.php:492
Stack trace:
#0 \wp-includes\Requests\Transport\cURL.php(218):
WpOrg\Requests\Transport\Curl->process_response('', Array)
#1 \wp-includes\Requests\Requests.php(468):
WpOrg\Requests\Transport\Curl->request('http://...', Array, '', Array)
#2 \wp-includes\class-wp-http.php(394):
WpOrg\Requests\Requests::request('http://...', Array, NULL, 'POST', Array)
#3 \wp-includes\class-wp-http.php(614): WP_Http->request('http://...',
Array)
#4 \wp-includes\http.php(179): WP_Http->post('http://...', Array)
#5 \wp-admin\includes\update-core.php(1408): w in \wp-
includes\Requests\Transport\cURL.php on line 492
}}}
* Files are upgraded with the 5.8.2 code
* File names remain (as they should)
What's interesting though is look at the code that's being executed in the
stack trace on his machine:
👉 ''**It's the "from" code not the "to" code.**''
The code in memory is the "from" code whereas the filesystem has been
upgraded with the "to" code. As the exception file is not loaded into
memory ''before'' upgrading the files on the filesystem, when the cURL
error happens, it attempts to throw an exception for a class that does not
exist.
== Q: What cURL error is happening on Windows machines?
Colin tracked it to:
{{{
cURL error 28: Operation timed out after 60006 milliseconds with 0 bytes
received
}}}
== Q: Is the "from" code running instead of the "to" code for the Upgrade
process?
WordPress 5.9 is incompatible with Gutenberg plugin less than 11.9. So if
Gutenberg plugin version 11.8 is installed, it should get deactivated
during the upgrade process to WordPress 5.9.
Steps to test:
1. Go to the [https://wordpress.org/plugins/gutenberg/advanced/ Gutenberg
plugin advanced page] and download 11.8.3.
2. Install and activate it.
3. Start with WordPress 5.7.4 (use the Core Rollback plugin)
4. Then upgrade via Beta Tester to WordPress 5.9.0 beta 1.
5. Go to Plugins and check that Gutenberg plugin was deactivated.
Test Results:
* My machine: Yes, the older Gutenberg plugin gets deactivated. That code
is in 5.9.0 not in 5.8.2 or 5.7.4.
* Colin's machine: same results
So yes, the 5.9 upgrader code is executing.
== Q: Why then is the "from" version code running instead of the "to"
version code?
Is the "from" version code being loaded into memory before the upgrade
process starts?
Looking at above at Colin's results, it seems to be the case for the HTTP
and Requests code. Since the "from" version code is running, when the cURL
timeout happens, it attempts to throw an exception that hasn't yet been
loaded into memory. But the filesystem is now different and doesn't have
that class. Fatal error.
Is this only on Windows? Or is this true for all systems?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/54546#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list