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

 Replying to [comment:11 johnjamesjacoby]:
 > I'm not convinced it will be possible to change existing filters with
 the hooks API as it is today.

 I agree. Whatever we come up with here will likely be impossible to be
 applied in any backward-compatible way, so it should become the new
 canonical way of short-circuiting, while leaving the existing filters
 untouched.

 > If we agree to leave existing filters as-is and invent something new,
 then... how about a constant to solidify the value of the default variable
 in all of our minds, like `WP_PRE_FILTER_VAL` or something?

 A constant doesn't solve the problem in my opinion. What value would we
 give to that constant? In any case, it could still be a value that could
 conflict with something that we'd actually wanna return.

 A more verbose solution like that in [attachment:40280.2.diff] ensures
 that we can return anything we like for the return value of a filter
 operation, since that value no longer dictates whether to short circuit or
 not. Although it's different from how it has been done, it's still very
 easy to use.

 https://core.trac.wordpress.org/ticket/40280#comment:6 shows how to use it
 when running the hook:
 * These hooks should ''always'' be actions, never filters. Since the
 `WP_Short_Circuit_Result` object instance is passed to it, it can simply
 modified, it doesn't need to be returned. If the short-circuit hook exists
 to short-circuit a function that requires a return value, just set that
 value via `$short_circuit_result->value( $my_new_value )`. The benefit of
 this is that it is ensured that we work with that one object instance.
 Developers adding hooks can simply use the passed-in object and do not
 need to worry about instantiating it on their own or about what to return.
 * We should also think about how to consistently name those hooks in the
 future. While several of those filters currently use `pre_` in their name,
 there are also other hooks with that prefix, that ''do not'' short-
 circuit. I think using a more verbose term, like actually `short_circuit_`
 makes more sense.

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