[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 rmccue):

 Replying to [comment:6 giuseppe.mazzapica]:
 > It means you have to distinguish `index.php?somevar=somevalue` from a
 callback. There's no possible overlap, especially if you check for
 `is_callable`, because the only way a string can be callable is when it
 contains a function name, but a function name can't contain `=` which is
 required in the old format.

 Unfortunately, this isn't true. `add_rewrite_rule` accepts an array, which
 is sent to `add_query_arg` to add to `index.php`; `add_rewrite_rule( '/',
 array( 'MyClass', 'mystaticmethod' )` is currently valid and maps to
 `index.php?0=MyClass&1=mystaticmethod`. I doubt anyone is using this, but
 I'd prefer to avoid overloading the ambiguous parameter for now.

 (Also, `is_callable` can't be used for similar reasons to why we can't use
 it in `add_action`/`add_filter`, which is that it might be used before it
 can be called.)

 > Yes, but `[] !== ''`. In other words, if an array is returned (even
 empty) you can assume this is a query argument array. If anything that is
 not an array is returned (no matter what it is) you can assume you want to
 skip main query. This should be pretty straightforward to grasp for users.

 Good point, although right now the rule actually needs to return a string,
 as this is set to `$wp->matched_query`; I want to shim this in though, so
 shouldn't be an issue.

 I think explicit might still be better than implicit, but I'll investigate
 and feel it out to see what it's like to use. :)

 > Regarding the hook `wp` itself, IMO it is a query-related hook as well.
 Anything existing out there (plugins, themes) that is using the hook was
 coded with the current WP implementation in mind, where each frontend
 request trigger a query.

 The hook's description currently "Fires once the WordPress environment has
 been set up." which doesn't imply that there's a main query. However, it's
 not fired on the admin. I think we need to work out exactly what this hook
 should do and document that. It's a useful hook even for non-query pages
 as it allows frontend-only events.

 I guess a broader question there is whether the admin should continue to
 be regarded as separate, or just another part of the main WP environment.
 I suspect the former.

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