Skip to:
Content

Opened 15 months ago

Closed 14 months ago

Last modified 4 weeks ago

#3184 closed defect (fixed)

Intercept API

Reported by: johnjamesjacoby Owned by:
Milestone: 2.6 Priority: normal
Severity: normal Version: 2.0
Component: General Keywords: 2nd-opinion close
Cc:

Description

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.

Change History (7)

#1 @johnjamesjacoby
15 months ago

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.

#2 @johnjamesjacoby
15 months ago

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.

#3 @johnjamesjacoby
15 months ago

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.

Last edited 15 months ago by johnjamesjacoby (previous) (diff)

#4 follow-up: @johnjamesjacoby
15 months ago

  • Keywords 2nd-opinion close added; commit removed

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

#5 in reply to: ↑ 4 ; follow-up: @netweb
15 months ago

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

#6 in reply to: ↑ 5 @johnjamesjacoby
14 months ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

#7 @johnjamesjacoby
4 weeks ago

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

Note: See TracTickets for help on using tickets.