[wp-trac] [WordPress Trac] #61391: Maintenance Error on Login After Setting Up WordPress 6.6 Beta 1 on Localhost

[WordPress Trac]

#61391: Maintenance Error on Login After Setting Up WordPress 6.6 Beta 1 on
Localhost
-------------------------------+-----------------------------
 Reporter:  nithi22            |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  6.6
Component:  Upgrade/Install    |     Version:  trunk
 Severity:  critical           |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by costdev):

 @rajinsharwar I believe this occurred on MacOS based on the directory path
 included in [https://core.trac.wordpress.org/ticket/61391#comment:4 this
 comment].

 While the line mentioned in that log is an `fwrite()` call, it seems that
 might just be the point at which the 30 seconds timeout occurred.

 Given that the logs show that the `Automatic updates complete.` line
 [https://github.com/wordpress/wordpress-
 develop/blob/edad3c57c67b5c0541d9b4e36bb2f6c370f57870/src/wp-
 admin/includes/class-wp-automatic-updater.php#L704 located here] was hit,
 and no plugin or theme updates were detailed in-between `starting...` and
 `complete`, it seems that this error is not related to the Rollback Auto-
 Update feature introduced during the 6.6 release cycle.

 In the code after this, there are HTTP requests sent in these locations:
 - `wp_version_check()` - Lines [https://github.com/wordpress/wordpress-
 develop/blob/fd6c5606b1c572442f0eb15bafee0852cbbb7035/src/wp-
 includes/update.php#L202 202] and [https://github.com/wordpress/wordpress-
 develop/blob/fd6c5606b1c572442f0eb15bafee0852cbbb7035/src/wp-
 includes/update.php#L213 213]
 - `wp_update_themes()` - Lines [https://github.com/wordpress/wordpress-
 develop/blob/bb52ff8ae1f842de9e30e9ab157e3ff69f626538/src/wp-
 includes/update.php#L721 721] and [https://github.com/wordpress/wordpress-
 develop/blob/bb52ff8ae1f842de9e30e9ab157e3ff69f626538/src/wp-
 includes/update.php#L732 732]
 - `wp_update_plugins()` - Lines [https://github.com/wordpress/wordpress-
 develop/blob/bb52ff8ae1f842de9e30e9ab157e3ff69f626538/src/wp-
 includes/update.php#L440 440] and [https://github.com/wordpress/wordpress-
 develop/blob/bb52ff8ae1f842de9e30e9ab157e3ff69f626538/src/wp-
 includes/update.php#L451 451]
 - `download_url()` - Lines [https://github.com/wordpress/wordpress-
 develop/blob/bb52ff8ae1f842de9e30e9ab157e3ff69f626538/src/wp-
 admin/includes/file.php#L1172 1172] and [https://github.com/costdev
 /wordpress-develop/blob/bb52ff8ae1f842de9e30e9ab157e3ff69f626538/src/wp-
 admin/includes/file.php#L1296 1296]

 Depending on the environment, it may be that the execution of the
 automatic updates checks, including these HTTP requests and possibly
 others that I missed in my quick search, may run a little slower than
 other environments, and has exceeded the PHP default
 [https://www.php.net/manual/en/info.configuration.php#ini.max-execution-
 time maximum_execution_time] of 30 seconds.

 -----

 @nithi22 Before starting the installation process, can you try this?
 1. Add `set_time_limit( 300 );` to `wp-admin/includes/class-wp-automatic-
 updater.php` on line 651 (just above the `$is_debug = WP_DEBUG &&
 WP_DEBUG_LOG;`) line
 2. Add the debugging lines from
 [https://core.trac.wordpress.org/ticket/61391#comment:2 this comment].
 3. Start the installation process.

 Let us know whether this resolves the issue, and if not, please paste the
 (anonymized) contents of `wp-content/debug.log` as you did before. Thanks!
 🙂

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