[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