Intercept API

[johnjamesjacoby]

There are some specific places in bbPress where the ability to short circuit specific function calls has been implemented over the years. These are usually queries, counts, or freshness; places where the functionality isn't desirable or doesn't scale to millions of topics.

Namely, their return values range from strings to null, and there is no real pattern to them. There is also a ​WordPress Core issue that talks about this.

Let's introduce our own intercept handlers to simplify these unique areas of bbPress a bit, and come up with a common language for future implementations.

[johnjamesjacoby]

In 6751:

Intercept: first pass intercept API.

This change introduces 3 new functions for generating a default intercept value and comparing against it in specific places. If the return value differs from the default intercept value, we know that function call was intercepted by a filter, and that value will become the new return value without executing the remaining part of the function.

See #3184.

[johnjamesjacoby]

In 6752:

Intercept: invert comparison in bbp_is_intercepted().

I was testing it to make sure it worked correctly, and forgot to switch it back before r6751.

See #3184.

[johnjamesjacoby]

2 filters were removed in this ticket.

• bbp_pre_format_activity_action_new_post
• bbp_pre_add_stick_topics

They will now be turned into:

• pre_bbp_format_activity_action_new_post
• pre_bbp_add_sticky_topics

These were new in 2.6, and stick should have been sticky, so was wrong anyways.

I'm not anticipating any problems with these renames, as nothing on the web or in the plugin repo were using them.

[johnjamesjacoby]

Paging @jmdodd and @netweb for a sanity check on this before closing.

[netweb]

Replying to johnjamesjacoby:

Paging @jmdodd and @netweb for a sanity check on this before closing.

Looks good to me 👍🏼

Groking back compat took a bit, for example, the user templates changes in [6751], the existing filter names will remain for those functions and any new addition would use pre_bbp_function_name.

As such if someone were to use pre_bbp_get_favorites_permalink this wouldn't work as they'd need to continue using bbp_pre_get_favorites_permalink

[johnjamesjacoby]

Replying to netweb:

Groking back compat took a bit, for example, the user templates changes in [6751], the existing filter names will remain for those functions and any new addition would use pre_bbp_function_name.

As such if someone were to use pre_bbp_get_favorites_permalink this wouldn't work as they'd need to continue using bbp_pre_get_favorites_permalink

Yeah; @jmdodd had the same response initially also. It's more clever than I normally like, but it's the cleanest way I could think to maintain backwards compatibility without including an additional third function parameter (or something worse.)

Thanks for looking. Closing this as fixed for 2.6.

[johnjamesjacoby]

Assigning all closed & unassigned tickets in the 2.6 milestone to myself.