Flagging system needed to help flush rewrite rules on post type registration from a plugin

[kevindees]

When activating or deactivating a plugin with post types or taxonomies the timing of flushing rewrite rules is very cumbersome. There are also inconsistencies on how flushing rewrite rules "should" be handled when activating vs deactivating.

Further, some plugins remove the rewrite rules added for a post type by other plugins.

I think it is worth considering the implementation of a unified API for flushing rewrite rules to help plugin developers flush permalinks registering with post types and taxonomies.

I believe a good starting point would be to add a flagging system to the database. The flagging system would allow authors to check for the flag and execute code when the flag is available. This seems to be a common practice already.

Example implementation:

<?php
// Plugin Name: My Plugin

add_action( 'init', function() {
    register_post_type('book', ['public' => true]);
});

function my_plugin_activate() {
    update_site_state_changed( 'flush_rewrite_rules' );
}

function my_plugin_deactivate() {
    update_site_state_changed( 'flush_rewrite_rules' );
}

register_activation_hook(__FILE__, 'my_plugin_activate');
register_deactivation_hook(__FILE__, 'my_plugin_deactivate');

The applied patch is for proof of concept. Not intended to be final.

[kevindees]

working implementation

[kevindees]

revised working implementation

[wpscholar]

Can you provide a usage example given the patch you uploaded?

[kevindees]

Replying to wpscholar:

Can you provide a usage example given the patch you uploaded?

How most plugins do it now (if they do not require users to flush the permalinks manually).

<?php
// Plugin Name: My Plugin

function my_plugin_post_types() {
    register_post_type('book', ['public' => true]);
}

add_action( 'init', 'my_plugin_post_types');

function my_plugin_activate() {
    // oddly register "your" post types and
    // only "your" post types causing
    // bugs for others to deal with
    my_plugin_post_types();
    flush_rewrite_rules();
}

function my_plugin_deactivate() {
    // if post type is changes you
    // need to remember to update
    // the id here as well
    unregister_post_type('book'); 
    flush_rewrite_rules();
}

register_activation_hook(__FILE__, 'my_plugin_activate');
register_deactivation_hook(__FILE__, 'my_plugin_deactivate');

Proposed solution: add a wp_options entry called _site_state_changed that can be checked for after the init action is called admin_init is also another option if init is too aggressive. Store an array of native wp or your plugin function names in the _site_state_changed entry.

If _site_state_changed is not empty call the functions added to the entry on the init action.

Doing this simplifies and fixes the bugs introduced by the current method devs take. Note, the proposed method is already being used by others via custom workarounds so this would remove the need for numerous implementations by those same people.

<?php
// Plugin Name: My Plugin

add_action( 'init', function() {
    register_post_type('book', ['public' => true]);
});

function my_plugin_activate() {
    update_site_state_changed( 'flush_rewrite_rules' );
}

function my_plugin_deactivate() {
    update_site_state_changed( 'flush_rewrite_rules' );
}

register_activation_hook(__FILE__, 'my_plugin_activate');
register_deactivation_hook(__FILE__, 'my_plugin_deactivate');

[SergeyBiryukov]

Related: #47686