[wp-trac] [WordPress Trac] #62029: Do not bloat Debug Log with Scraping home page… when auto upgrade is OK
WordPress Trac
noreply at wordpress.org
Sun Sep 29 11:48:38 UTC 2024
#62029: Do not bloat Debug Log with Scraping home page… when auto upgrade is OK
-----------------------------+---------------------
Reporter: georgwordpress | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 6.7
Component: Upgrade/Install | Version:
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
-----------------------------+---------------------
Comment (by georgwordpress):
**Summup:**
The detection of errors when auto-updating of plugins is based on the
analysis of a loopback request to the homepage.
This loopback request is carried out with special parameters so that when
the homepage is requested, WordPress not only generates the normal HTML
text, but also appends the following Ascii text to the end of the body:
{{{
###### wp_scraping_result_start:e10adc3949ba59abbe56e057f20f883e ######
true ###### wp_scraping_result_end:e10adc3949ba59abbe56e057f20f883e ######
}}}
(see wp-includes/load.php)
You will find the scraping result in the middle of two needles:
- 'true' if no error occurred
- a JSON object with the result of the error_get_last() function
The result of the loopback request is then checked by the
has_fatal_error() function.
(see wp-admin/includes/class-wp-automatic-updater.php)
The function currently only checks one special case:
is_wp_error( $response ) then 'true' is returned.
If not, the following code for logging relies on the needle
'wp_scraping_result_start' being present in the response.
The absence of this needle therefore results in the entire html body of
the loopback request being written to the log.
The complete absence of this needle is not further documented in the log.
Further on the return code from has_fatal_error() then only depends on
whether the key 'type' is present in the scraping result. If the scraping
result is completely missing, this key is of course not present and
has_fatal_error() therefore returns false.
While testing, @stoyangeorgiev and I discovered that there may be some WP
setups possible where the loopback request does not contain a scraping
result:
1.) redirects to other servers or redirects with removal of query
parameters
ToDo:
1.1) has_fatal_error() must recognize if scraping needle is missing and
document it in the log
1.2) the WP Health Check could be optimized:
In order to detect errors when auto-updating plugins, not only a loopback
request must work in general, but the loopback with the special scraping
parameters must contain a scraping result as a response in the body.
If not, the auto-update function cannot detect errors.
Additionally, @stoyangeorgiev identified another possible bug during
testing:
2.) "when you update two plugins that have fatal errors"
As result the log is also cluttered up because of point 1.1, but much more
important it is an indication that error detection when updating multiple
plugins can still lead to problems.
There is already a special note about this in the source code of the
function update():
{{{
/*
* Avoids a race condition when there are 2 sequential plugins that have
* fatal errors. It seems a slight delay is required for the loopback to
* use the updated plugin code in the request. This can cause the second
* plugin's fatal error checking to be inaccurate, and may also affect
* subsequent plugin checks.
*/
sleep(2);
}}}
Sounds like there is some room for improvement.
** How to proceed?**
On point 1.1) The present PR fixes the bug that causes the log to clutter
up.
On point 1.2) I can open a new ticket: Enhancement of Health Check
Regarding point 2.) problems when updating several plugins, I would open a
new ticket for further investigations.
@stoyangeorgiev what do you think?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/62029#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list