[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