[wp-trac] [WordPress Trac] #40280: Short-circuit filters can't return common values

[WordPress Trac]

#40280: Short-circuit filters can't return common values
-------------------------+------------------------------
 Reporter:  andy         |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  4.8
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------

Comment (by johnjamesjacoby):

 Replying to [comment:12 flixos90]:

 I don't like the `WP_Short_Circuit_Result` idea, yet. It's too complicated
 to use for as simple (and relatively useless) as the class itself ends up
 actually being in helping me actually override a value.

 {{{
 // Override front page
 add_action( 'short_circuit_get_option', function( $ss, $option, $value ) {
         if ( $option === 'show_on_front' && $value !== 'page' ) {
                 $ss->short_circuit( true );
                 $ss->value( 'page' );
         }

         if ( $option === 'page_on_front' && $value !== 131 ) {
                 $ss->short_circuit( true );
                 $ss->value( 131 );
         }
         var_dump( $ss );
 }, 10, 3 );
 }}}

 With your patch applied, this results in many different nondescript
 `WP_Short_Circuit_Result` objects being created inside of `get_option()`,
 all with different internal memory pointers. Then my action needs to
 manipulate these objects indirectly, without a filter? It seems backwards,
 clunky, and less intuitive than what we have now that we don't like.

 {{{
 object(WP_Short_Circuit_Result)[504]
   private 'short_circuit' => boolean false
   private 'value' => null
 object(WP_Short_Circuit_Result)[507]
   private 'short_circuit' => boolean false
   private 'value' => null
 object(WP_Short_Circuit_Result)[511]
   private 'short_circuit' => boolean false
   private 'value' => null
 }}}

 ----

 My thinking with `WP_PRE_FILTER_VAL` is to maintain today's ease of use
 with a predefined, consistently named variable. It could be something like
 this (or a randomized value):

 {{{
         // Set pre-filter short-circuit value
         if ( ! defined( 'WP_PRE_FILTER_VAL' ) ) {
                 define( 'WP_PRE_FILTER_VAL', NONCE_SALT );
         }
 }}}

 Basically, just a naming convention for humans to agree to agree to agree
 on.

 ----

 It will be hard to conceptualize anything simpler than the current bespoke
 approach, and anything more complex hardly addresses the human problem of
 inconsistency because it introduces several other ways we can be even less
 consistent. :)

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