[wp-trac] [WordPress Trac] #34936: Reconcile wp-settings-cli.php with wp-settings.php

[WordPress Trac]

#34936: Reconcile wp-settings-cli.php with wp-settings.php
---------------------------------+-----------------------------
 Reporter:  danielbachhuber      |       Owner:
     Type:  enhancement          |      Status:  new
 Priority:  normal               |   Milestone:  Future Release
Component:  Bootstrap/Load       |     Version:
 Severity:  normal               |  Resolution:
 Keywords:  dev-feedback wp-cli  |     Focuses:
---------------------------------+-----------------------------

Comment (by danielbachhuber):

 Replying to [comment:2 jorbin]:
 > Could you override the `$upgrading` global and always force it to be
 more than 10 minutes old?  This will cause `wp_maintenance()` to always
 return even if `. maintenance` exists?

 Where would WP-CLI do this, though? Here's the relevant code in
 `wp_maintenance()`:

 {{{
 global $upgrading;

 include( ABSPATH . '.maintenance' );
 // If the $upgrading timestamp is older than 10 minutes, don't die.
 if ( ( time() - $upgrading ) >= 600 )
         return;
 }}}

 There's no way to stomp the `$upgrading` global after `.maintenance` has
 been included.

 > What is the rationional for skipping `wp_debug_mode()` in wp-cli? If it
 is to turn display errors off, could a constant be added to
 https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/load.php#L304 ?

 We originally removed `wp_debug_mode()` so we could conditionally enable
 `WP_DEBUG` at runtime with a `--debug` flag:

 * https://github.com/wp-cli/wp-
 cli/commit/372c8f15f40664f41e5e6870c5cb6f4b71c78a24
 * https://github.com/wp-cli/wp-cli/issues/177

 > Can you point out the wp-cli tickets that explain the historical issues
 to better understand this?

 Sure:

 * https://github.com/wp-cli/wp-cli/pull/164
 * #22683
 * https://github.com/wp-cli/wp-
 cli/commit/8f3b6601377f4e7230a1275833ada39bfa182c50

 > the `active_plugins` option could be filtered for plugins.
 >
 > For themes, I assume you mean skipping the active theme? What do you
 replace it with?   Are the `stylesheet_directory` and `template_directory`
 not sufficiant?

 It could be worth trying the filtering approach. It looks like WordPress
 is smart enough not to stomp `$wp_filter` if it's already defined before
 `wp-includes/plugin.php`, so WP-CLI could inject its callbacks on the
 global.

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