[wp-trac] [WordPress Trac] #29118: Registering rewrite rules is hard, so let's introduce remove_rewrite_rule.
WordPress Trac
noreply at wordpress.org
Tue Aug 5 15:20:29 UTC 2014
#29118: Registering rewrite rules is hard, so let's introduce remove_rewrite_rule.
---------------------------+-----------------------------
Reporter: ericlewis | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Rewrite Rules | Version:
Severity: normal | Keywords:
Focuses: |
---------------------------+-----------------------------
A plugin cannot use the current Rewrite API to register/deregister rewrite
rules on plugin activation/deactivation elegantly, without being extremely
hacky.
Current best practice is to add rewrite rules via init, and flush properly
on activation/deactivation hooks in your plugin:
{{{
#!php
function add_some_rewrite_rules() {
add_rewrite_rule( ... );
}
add_action( 'init', 'add_some_rewrite_rules' );
register_activation_hook( __FILE__, function() {
add_some_rewrite_rules();
flush_rewrite_rules();
} );
register_deactivation_hook( __FILE__, function() {
flush_rewrite_rules();
} );
}}}
However, there is a race condition on the deactivate request: init
triggers first, adding your rewrite rule, so when you flush rewrite rules
in the deactivation function, the rewrite rule persists.
You have some dirty options: checking the script being run in
add_some_rewrite_rules() to sniff for a request for the plugin being
deactivated comes to mind, I'm sure there are others.
This would be much easier if we had a remove_rewrite_rule() function we
could hit on deactivation, and probably read better.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/29118>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list