[wp-trac] [WordPress Trac] #21682: Rewrite endpoints are lost if a custom category or tag base is defined

WordPress Trac wp-trac at lists.automattic.com
Fri Aug 24 15:57:05 UTC 2012


#21682: Rewrite endpoints are lost if a custom category or tag base is defined
--------------------------+------------------------------------
 Reporter:  sanchothefat  |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  3.4.1
 Severity:  normal        |   Keywords:  dev-feedback has-patch
--------------------------+------------------------------------
 == Problem ==

 So this little bug was winding me up for a while.

 The standard approach according to the codex for adding rewrite endpoints
 is to call the `add_rewrite_endpoint()` function within the init hook. So
 far so good.

 The problem occurs whenever `WP_Rewrite::init()` is called ''after'' the
 init hook. It resets the endpoints array and so when rewrite rules are
 subsequently generated through the options-permalink.php admin page the
 rewrite rules are unknown to the system and hence don't work.

 `WP_Rewrite::init()` is called within `WP_Rewrite::set_category_base()`,
 `WP_Rewrite::set_tag_base()` and `WP_Rewrite::set_permalink_structure()`.

 In the latter it is only called if the permalink structure has changed so
 on first save of a change endpoints are lost. In the other 2 it is called
 every time if the slug doesn't match the default so rewrites are always
 lost.


 == Solutions: ==

 1. add an action hook to the start of `WP_Rewrite::rewrite_rules()` where
 endpoints should be added
 2. store the endpoints at the start of `WP_Rewrite::init()` and restore
 them at the end
 3. don't reset them at all

 I think solution 3 would make sense, the endpoints could be defaulted to
 an empty array and I can't see any reason to want to reset them anyway.

 I've attached a simple patch that works (for me at least).

 '''NB.''' this problem may also affect the `$extra_rules` and
 `$non_wp_rules` but I haven't tested that theory yet.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21682>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list