[wp-trac] [WordPress Trac] #16687: %postname% permalinks should not trigger verbose rewrite rules

WordPress Trac wp-trac at lists.automattic.com
Wed Apr 20 00:17:51 UTC 2011


#16687: %postname% permalinks should not trigger verbose rewrite rules
-----------------------------+------------------
 Reporter:  nacin            |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  3.2
Component:  Rewrite Rules    |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+------------------

Comment (by duck_):

 Attaching a new PoC plugin (non-verbose-page-rules.002.php) to fix the
 problems Mark referred to. The problem was with sub-pages being blocked by
 the post attachment rule:

 {{{
 [^/]+/([^/]+)/?$ => index.php?attachment=$matches[1]
 // ... and similar for trackbacks, feeds, comment pages
 }}}

 I worked around this by removing these attachment rules and dealing with
 them as part of the page catch-all. If there is a / then it's either a
 page or an attachment, it's the latter if matched by any of the attachment
 rewrite rules that were previously unset (transformed into non-regex form,
 this is were it gets a bit uglier/hackish![1]) *and* the attachment piece
 -- `([^/]+)` -- is actually an attachment... otherwise it's a page. On the
 other hand we have a post or a page which can be dealt with as before.

 I also added a check to only change the rules specifically for the
 /%postname%/ structure as it will just break other verbose structures.

 I also tried a variation for the non-/ post or page branch to get the ID
 in advance and reduce the number of queries for top level pages by one
 compared to trunk. For a full table of query counts in some quick testing
 see http://pastie.org/1813700.

 Performance tests I made before I added the OR branches to deal with post
 attachment trackbacks, feeds and comment pages showed that with the plugin
 response time remained the same as the number of pages grew (0.17s at both
 59 pages and 1297 pages). Without the plugin it was a different story.
 0.18s response time at 59 pages and 0.37s at 1297 pages. The figures I'm
 quoting are from tests with one concurrent user over 30 seconds requesting
 the comment feed of a post attachment (e.g. http://wp.dev/post-with-
 attachment/attachment-slug/feed/rss/) so very low on the rewrite stack.
 With the plugin enabled the /%postname%/ permalink structure has the least
 number of rewrite rules by default.

 Also run this against the WordPress tests for WP_Query and WP_Rewrite with
 no failures.

 ![1] I thought I had managed a relatively neat solution before realising
 that I had forgotten the trackback, feeds and comment page rules for post
 attachments which turns the condition into a bit of a monster!

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/16687#comment:16>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list