[wp-trac] [WordPress Trac] #36292: Rewrites: Next Generation

[WordPress Trac]

#36292: Rewrites: Next Generation
-----------------------------+-----------------------------
 Reporter:  rmccue           |       Owner:  rmccue
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  Future Release
Component:  Rewrite Rules    |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+-----------------------------

Comment (by MikeSchinkel):

 I think both of the solutions suggested here might be missing something.

 If hooks are used as @giuseppe.mazzapica then unit testing will be more
 difficult if not close to impossible, and that is Part 2 of @rmccue's
 requirements ''(which I definitely agree with.)''

 OTOH, @rmccue's solution to use an object is a great first step is does
 not address other issues that the rewrite system has.  The biggest problem
 I've run into with URL routing on client projects is that WordPress's
 rewrite system is context free and what we've often needed has been
 context sensitive routes. For example, if you want to have an `/about/`
 URL and also have your categories in the root `/politics/` and `/sports/`
 you can't do it with the WordPress Rewrite system as-is. And simply
 ignoring those use-case requirements ends up giving people who are against
 WordPress more ammunition to shoot it down.

 That said, while FastRoute is excellent engineering by @nikic, he
 overlooked one of the most obvious optimizations you can do with URLs and
 that is segment chunking ''(although I won't take credit for recognizing
 it; it was Otto who gave me the idea.)''  So that instead of looking at
 URLs in groups of 10 you look at segments instead.

 What's more, you can subdivide the URLs you need to look at by grouping
 them based on the number of slash-separated segments they contain. Once we
 have conceptually divided up by number of segments, we can really optimize
 matching.

 For the root segment for most WordPress sites you will not have that many
 unique segments; throw them into an array and do an `in_array()` ''(or
 into a string using strpos`)'' to find the proper route; likely much
 faster than using groups of 10 regex.

 Further, by using URL segments you can divide and conquer. In most cases
 the total choices for matching a second segment will be a much smaller
 list to test against.

 I have actually implemented this generically for a project but -- as with
 so many things -- I did not realize that parts of the  approach I took
 were not optimal so I would need to refactor that code in order to use it.

 Fortunately with the `'do_parse_request'` hook we could do it as a Feature
 Plugin/Feature Project.

 So what do you think?   Do you think we can all collaborate on an approach
 like this?

 ----

 BTW, I have been trying to get WordPress to improve it's URL routing for 6
 years. My first ticket:

 - https://core.trac.wordpress.org/ticket/12935

 My 2nd ticket 5 years ago to at least allow for a workaround that did get
 included (after much objection from Otto, thank you Andy Skelton!):

 - https://core.trac.wordpress.org/ticket/16692

 Also 5 years ago:

 - https://core.trac.wordpress.org/ticket/18276

 And a  couple years ago I have a talk on "Hardcore" URL Routing at a
 WordCamp:

 - http://hardcorewp.com/2014/hardcore-url-routing-for-wordpress/

 Suffice to say I have spent a lot of time thinking about URL routing and
 written a lot of code to implement custom URL routes.

 I also argued on wp-hackers at length to no avail back around 6 or 7 years
 ago that we should be able to load a page w/o calling `WP_Query`, so I'm
 totally with you there.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36292#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform