[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:  4.6
Component:  Bootstrap/Load                 |     Version:
 Severity:  normal                         |  Resolution:
 Keywords:  dev-feedback wp-cli has-patch  |     Focuses:
-------------------------------------------+------------------

Comment (by ocean90):

 [37626]: I'm not really a fan of the naming and the location of these
 filters.

 * The ''This filter should *NOT* be used by plugins.'' warning should be
 removed. I really don't see the need for it and it gets ignored anyway. We
 shouldn't add the filter in the first place if we're worried about that
 plugins can use it
 * `bypass_advanced_cache`: I think this should be replaced with
 `enable_advanced_cache`:

 {{{
 /**
  * Filters whether to enable advanced caching.
  *
  * @since 4.6.0
  *
  * @param bool $enable Whether to enable advanced caching. Defaults to the
 value of `WP_CACHE`.
  */
 if ( apply_filters( 'enable_advanced_ caching', WP_CACHE )  ) {
         // For an advanced caching plugin to use. Uses a static drop-in
 because you would only want one.
         _backup_plugin_globals();
         WP_DEBUG ? include( WP_CONTENT_DIR . '/advanced-cache.php' ) :
 @include( WP_CONTENT_DIR . '/advanced-cache.php' );
         _restore_plugin_globals();
 }
 }}}

 Similiar filters are `enable_live_network_counts`,
 `enable_press_this_media_discovery`, `enable_post_by_email_configuration`
 or `enable_edit_any_user_configuration`.

 * `bypass_debug_mode` / `bypass_maintenance_mode`: Why are the filters
 '''inside''' of the function? If you want to ''bypass'' something
 shouldn't it be placed '''outside'''?
 * `bypass_debug_mode` is a bit misleading because you can't really disable
 the debug mode. There are a few places in core which check the value of
 `WP_DEBUG` and these checks can't be disabled with the filter. Is the
 filter needed at all? What's the issue if it can't be disabled? Shouldn't
 `WP_DEBUG` be set to false if you don't want to run something in debug
 mode?
 * `bypass_maintenance_mode`: I think we should go with the `enable_`
 naming here too:
 {{{
 /**
  * Filters whether to enable the maintenance_check.
  *
  * @since 4.6.0
  *
  * @param bool $enable Whether to the maintenance_check. Default true.
  */
 if ( apply_filters( 'enable_maintenance_check', true )  ) {
         wp_maintenance();
 }
 }}}

 [[BR]]

 Docs: Please note that each line should end with a period and the filter
 parameters should include a variable (`@param type $variable
 Description.`).

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