[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 jorbin):

 Replying to [comment:19 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

 They are loaded before plugins are loaded, so we could change it to they
 can not be used by plugins.  Do you have an alternative suggestion for
 enabling the ability to skip these parts of the bootstrap process?   The
 alternative suggestion was a `WP_CLI` constant but we decided a filter
 looked better than sprinkling a constant that seems like it would be more
 likely to be abused.

 > * `bypass_advanced_cache`: I think this should be replaced with
 `enable_advanced_cache`:

 I chose `bypass` instead of `enable` as I felt that that action that a
 user of the filter is to bypass something rather than to unenable.  I
 don't feel super strong about this though so if you do, I'm open to
 changing it.


 > * `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'''?

 I wanted to avoid littering wp-settings with wrapping if statements around
 each of the functions.

 > * `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?

 As noted in the link, it's to allow `--debug` to be used to set debug
 display settings.  Perhaps a better name and documentation would
 demonstrate that better.  Ideas?

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

 Is the $variable really needed when there is no variable used?

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