Add custom_url_func to be run in template-loader.php

[mikeschinkel]

This is a follow-on from Ticket #9455 where the #9455 attempted to resolve one issue using a shortcut but the shortcut turned out to cause undesirable side effects and also did not address the fact that 404 and noncache headers had already been set.

So this ticket provides a patch that will allow for a custom_url_func to be called at the beginning of template-loader.php. The custom_url_func can be set in a 'parse_query' hook using code that looks like this for the URL "/foobar/":

   add_action('parse_query','my_parse_query');
   function my_parse_query() {
      if ($_SERVER['REQUEST_URI']=='/foobar/')
        set_custom_url_func('my_foobar_func');
   }
   function my_foobar_func() {
      echo 'Hello FooBar!  Bye.';
   }

Granted, this might not be the best way to accomplish this. For example, using a new filter might be a better way to accomplish this but I was trying not to add additional filter processing overhead assuming that might be a concern. I'm not attached to this particular solution, I just want to be able to get proper control of custom URLs that don't fit any of the existing patterns that have been baked into WordPress core and ideally I don't want it to have to be uber-complex for the plugin or theme developer either.

Custom URL Function DIFF file

Looking at the example, I'd do that with WP_Rewrite and a custom query var myself.

I think what would be better is a simpler way to manage endpoints and startpoints in the rewriting code, for many people (esp. new people to WordPress) its a real maze..

I've got this old example code (which was for 2.2 i think, and doesnt use any of the API functions) which shows something basicly similar to what mike wants: ​http://dd32.id.au/files/wordpress/test-rewrite.php which gave the url's: ​http://dd32.id.au/artist/ ​http://dd32.id.au/artist/artist-1/ etc. (Its old example code, it doesnt work anymore, It needs to be changed to insert the rewrite rules at the start rather than the end, since WP 2.5+? included some greedy matching rules)

Replying to DD32:

Looking at the example, I'd do that with WP_Rewrite and a custom query var myself.

I think what would be better is a simpler way to manage endpoints and startpoints in the rewriting code, for many people (esp. new people to WordPress) its a real maze..

I've got this old example code (which was for 2.2 i think, and doesnt use any of the API functions) which shows something basicly similar to what mike wants: ​http://dd32.id.au/files/wordpress/test-rewrite.php which gave the url's: ​http://dd32.id.au/artist/ ​http://dd32.id.au/artist/artist-1/ etc. (Its old example code, it doesnt work anymore, It needs to be changed to insert the rewrite rules at the start rather than the end, since WP 2.5+? included some greedy matching rules)

Yes, you are headed down the right path in terms of understand what I'm trying to accomplish. However, the WP_Rewrite() ends up being a black art because so few theme authors (and probably few plugin authors) really understand how to write RegEx. I can do it but I kringe every time I have to.

That said, making the WP_Rewrite() rules easier to use is really a much bigger project and not one I'd one to take on w/o having a much better understanding of what the community would accept. For example, I could envision a URL templating system that would be much easier to understand for themers, something like the following however that would potentially be very complex to implement all edge cases:

$wp_rewrite->url_templates = array(
	'/artist/{artist}/' => 'do_artist_page'
}

function do_artist_page($artist) {
	// Generate the artist page here.
}

The solution proposed in my patch was instead an "escape valve" solution; it's not architected like WP_Rewrite() but it would give themers and possibly plugin developers a way to break out and just get some work done. As is to create pages based on custom URL structures is overwhelmingly complicated when WordPress is supposed to be easy. This was a roadblock we hit again and again on my last project and one I'm hiting on my current project.

So I guess the question is, what's the downside of implementing (something like) the "escape valve" shown? It would not preclude a more fully architected solution in the future and would let me (and others) get work done, today. (BTW, another probably better option would be to add a new "custom_url" filter instead of using the "parse_query" filter and a $wp_query instance variable and set of functions. I can work that up if that would be preferred.)

So I guess the question is, what's the downside of implementing (something like) the "escape valve" shown?

Other than that from a code POV it looks plain ugly and a half-baked solution? - Honestly, Looking at it you've got absolutely no chance in hell of anything like that being committed. (from a non-commiters POV here)

Ideally, Someone who understands WP_Rewrite enough & Templates enough needs to attempt to make a simple API which does what you need, so that plugins which utilise it would be also able to work without the rewrite module (ie. ?artist=test-artist as well as /artist/test-artist/)

The problem that i keep hitting every time i try and write a piece of example code here, Is that Themers -Need- to know how to program PHP, They need to know how to program with WordPress, There shouldnt be a "But they shouldnt need to" arguement there, If they want to program, they need to learn how to.
Its incredibly hard to offer advanced-level functionality to basic-level programmers in a way that they'll understand.

add_startpoint(
   'artist/%artist_slug%/%artist_song%/',
   array(
      'vars' => array( 
          'artist_slug' => array(
              'required' => false,
              'callback' => ....
           )
           'artist_song' => array(....)
      ),
      'callback' => .....,
   )
);

thats just a simple version.. Its not exactly looking easy to understand for a new user.. Nor would it technically be easy to create a rule based off that, Look at the ammount of code which converts the Permalink Structure to rules..

Can you please define "ugly" and "half baked" in concrete and objective terms?

Point of clarity; your comments about themers needing to know PHP implied that I was advocating for no need to know PHP, which is not at all the case. Your example for an add_startpoint() is perfectly acceptable to me (beyond the fact that I don't know what a "startpoint" is and googling the term gives me no clarity.)

Instead I was saying that the need to know and understand RegEx and all it's side-effect ridden intricacies is way beyond what any themer and most plugin authors should be expected to understand. There's a reason few people really know how to work with Apache's mod_rewrite and it's because its a black art. WordPress's WP_Rewrite is similarly black-artish. Just look at ​your example for an example of the nightmare that is currently required.

I'm happy to be that "someone" but I don't want to go off and spend two days on something and have it dismissed offhand as being "half-baked and ugly." If I can get proper input I hope that I can produce a patch worthy solution. I have worked on a ​simple URL mapper in the past and could use what I learned from writing that code for this project.

That said, my preference is to get something workable that doesn't require the level of complexity that is currently in place and that doesn't require the development of a truly robust URL mapper. I'd love to hear the opinions of the committers on this, please?

The correct solution to your problem is to use new rewrite rules.

I am well aware that adding rules to WP is a black art and it is an area that needs improvement.

Before working on it we need to prototype how its going to work and ensure that the api's we added a few versions back in an attempt to make it simpler will still work.

So I'm now working on a plugin to make it easy to add rewrite rules by specifying templates.

However, I'm still running into numerous "challenges" with core. For example, if I add the following rewrite rule as the first "courses/(.*)" it gets matched but $wp_query->is_home is set to true. It seems that $wp->parse_query() doesn't know how to handle a "custom" rewrite rule.

Further, there appears to be no way to tell WordPress to not query posts. There are many use cases where I don't want to automatically run a query for posts in the database;

Can I get confirmation that these issues I mention are not intended behavior and also some indication on what would be an acceptable way to get these issues resolved?