Rewrite Rules Built Even When Not Needed

[sjregan]

Preface: this could just be me not understanding the best practices regarding rewrite rules.

Rewrite rules for components are built every page load, regardless of whether they are needed or not.

If rewrite rules are already saved in the wp_options table, they are used. If you use the BP hooks to add rewrite rules, they are ignored during until you programatically delete the wp_options entry, or visit the Permalinks settings page in WP Admin.

Would it not be more performant to only build the rewrite rules on plugin install, or when the 'generate_rewrite_rules' action is fired, or inside the 'rewrite_rules_array' filter?

[imath]

Hi @sjregan

I kind of disagree when you write:

Rewrite rules for components are built every page load, regardless of whether they are needed or not.

Rewrite rules for built in components are only generated when you activate the component or when you customize slugs.

If you’re talking about a custom component you can force this generation by firing bp_delete_rewrite_rules() once the plugin containing it is activated. Rewrite rules will then be generated at next front end page load.

PS: When building a custom component, specifying it has a directory will generate the root buddypress post type as explained here: ​https://github.com/buddypress/buddypress/blob/master/docs/developer/component/build-component.md#parsing-requests-about-your-custom-add-on-directory

That being said, if you have a better way to handle it, I’ll be happy to review a PR or a patch. Everything can be improved 😅

[sjregan]

@imath

Again, I might be getting confused about this. But from what I see:

In bp-core-actions.php:

add_action( 'bp_init', 'bp_add_rewrite_rules',       30 );

In bp-core-dependency.php

function bp_add_rewrite_rules() {
        do_action( 'bp_add_rewrite_rules' );
}

In class-bp-component.php

add_action( 'bp_add_rewrite_rules',      array( $this, 'add_rewrite_rules'      ), 10, 0 );

Does this not mean the add_rewrite_rules component method is called on every page execution, for every active component?

[imath]

If just like it's the case when you register a post type (see: ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/post.php#L1729), we need to set rewrite rules into the WP_Rewrite object, these are only generated and saved into the database when you refresh your permalinks, activate a component or customize BP slugs.

If you look at the WP Code Reference, this is the way to go: ​https://developer.wordpress.org/reference/functions/add_rewrite_rule/

[sjregan]

Just so I understand... what you are saying is that yes, the list of required rewrite rules is calculated and built every single request regardless of whether the resulting list is used in the current request, but you don't feel that is an issue?

[imath]

Is it an issue that each time a page load all possible registered post types are setting their rewrite rules ?

[sjregan]

Is it an issue that each time a page load all possible registered post types are setting their rewrite rules ?

I think so :)

What I am trying to understand is:

1. What is the point of WP writing the rewrite rules to the database, when the rewrite rules are calculated and stored in memory every single request regardless of whether the rewrite rules are in the already in the database at the start of the request?

2. Whether it is a good idea to spend CPU cycles calculating values that are never used during the request and thrown away at the end of the request?

3. Whether there is any interest or value in changing the way BP sets the rewrite rules to avoid unnecessary calculations, in order to keep request overheads as low as possible?

4. If I want to avoid my plugin unnecessarily slowing down page requests, is it more performant to use the same approach as BP or to instead use the generate_rewrite_rules action and/or the rewrite_rules_array filter?

[imath]

I understand your points. If we can do better I'm always interested.

I'm currently trying to be everywhere (code, documentation, support, ...) so I can't look into it myself as it's not a priority to me for now. But I'm very open to contributions, so feel free to investigate to check how much request overheads it's causing and how to save it. I'll be happy to test/review your PR or patch.

[sjregan]

My apologies if my comments came across the wrong way, I am and thousands of others are super appreciative of all your work.

I was just hoping for some clarity and confirmation that I am understanding how the current implementation works and the possible avenues for optimisation.

There’s no point me spending time on it if I’m starting from a misunderstanding :)