[wp-trac] [WordPress Trac] #61489: 6.1.7 and 6.2.6 Updates Cause Critical Error

[WordPress Trac]

#61489: 6.1.7 and 6.2.6 Updates Cause Critical Error
-------------------------------+------------------------------
 Reporter:  mping001           |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Upgrade/Install    |     Version:  6.1
 Severity:  critical           |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------

Comment (by dd32):

 Replying to [comment:35 greenlightsolutions]:
 > For one site that was affected by this problem, I looked in a backup of
 an old version of the site.
 > In that version (v6.2.3), there was a definition of the function
 _wp_footnotes_kses_init() in the file wp-includes/blocks.php.

 The function has only existed in WordPress 6.3+, introduced to the branch
 in [56848].


 Replying to [comment:36 tomsommer]:
 > It looks like some kind of patching-software might have modified the
 core files, and now that blocks.php has been reverted due to an update
 this breaks that modification and thus the site.

 This is my best guess as well. Possibly a host-level security patcher.
 However, that doesn't make much sense to me..

 The reason it doesn't make much sense,
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-core-upgrader.php?marks=92-97#L85 is that in the event that a core
 file is modified, WordPress doesn't use the "partial" zip files] and
 instead uses the full release ZIP for that version. That would overwrite
 any modified files.

 My best guess is that the patching software has run immediately following
 the upgrade. That would explain it I guess.

 I'd be curious on the timing of the upgrade + fatals experienced, was it
 the same second, or a few minutes following, etc.

 Having reviewed the logs for post-update notifications from core
 ''([https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-core-upgrader.php?marks=230-259#L226 WordPress sends some
 statistical data], and by knowing the URL of an affected site I can infer
 which logs are from which site, as the user-agent forms part of a unique
 key hash)'', the sites mostly used partial zips to upgrade, and appears to
 have run successfully. It appears that at least one probably used a full
 ZIP (not a partial) as it took 10x longer to upgrade than the rest, but
 also didn't report any issues.

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