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

[WordPress Trac]

#36292: Rewrites: Next Generation
-----------------------------+----------------------------
 Reporter:  rmccue           |      Owner:
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Future Release
Component:  Rewrite Rules    |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+----------------------------
 Let's start improving rewrites. The current rewrite system is outdated and
 clunky for modern development, and was one of the most complained about
 pieces of WordPress when I
 [https://twitter.com/rmccue/status/710460165879898114 enquired on
 Twitter]. Here's what I'd like to change.

 == Part 1: Separate rules from WP Query ==

 This has two parts. Firstly, we need to ensure any rule can be mapped to
 any set of arbitrary query parameters. Right now, this is quite hard to do
 for the more complex query parameters, such as [https://roots.io/routing-
 wp-requests/ date query]. Doing this will eliminate the need for
 temporary/intermediate query vars; these are typically used temporarily
 during the rewrite process, then changed into actual query vars in
 `pre_get_posts`.

 The second part of this is breaking the interdependency between rewrites
 and the main query. Currently, it's not possible to have a page that
 doesn't generate a main query. #10886 has attempted to tackle this in the
 past, however has run up against problems. This is important for things
 like user profile pages, and can immediately be used in core for the REST
 API. The current solution for these is to hook in at `parse_request`, but
 this causes some hooks not to be run, and changes the overall flow of a
 WordPress request.

 Part 1 will introduce a Rewrite Rule Interface that will allow better
 customisability of rules as well.

 == Part 2: Ensure the rewrite process is DRY and testable ==

 This part will decouple the rewrite process from the global state to
 ensure testability. @ericlewis has made a fantastic start on this in
 #18877, which works well with some of the refactoring from part 1.

 In separating from the global state, we may be able to reuse
 `WP_REST_Request` as a more generic `WP_HTTP_Request` (it was designed for
 this from the start).

 This should also start cleaning up the `WP` and `WP_Rewrite` classes as
 concerns get a cleaner separation. Currently the boundary between the two
 is pretty unclear.

 == Part 3: Rework flushing ==

 The `rewrite_rules` option and the flushing process are one of the
 toughest bits of the rewrite process. The fact with these is that they're
 a caching process that significantly predates transients and object
 caching. The reason flushing exists is to avoid regenerating expensive
 rules (like one-rule-per-tag) on every request, but we can create a better
 system using the newer tools available in core. An opt-in system for
 rewrite caching could potentially work well once we have a solid Rewrite
 Rule Interface that allows us to identify and group rules. (For example, a
 `WP_Rewrite_CachedRuleInterface`.)

 #29118 digs into some past work on this front; automatically flushing
 rewrites is already possible.

 == Other Changes ==

 Note that these parts are in a rough order, and get more vague as they go
 on. We need to incorporate feedback after changes are made, and these
 changes might need to be reworked or rethought with previous feedback in
 mind. There are also other changes we may want to make based on feedback
 from the community.

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