[wp-hackers] Any way to bypass $wp->query_posts()?

[Mike Schinkel]

"SoJ Web" <sojweb at indiana.edu> wrote:
> why not just have the plugin modify the htaccess 
> file and bypass WordPress altogether? 

Because modifying .htaccess should be a last resort, IMO. There are too many problems with non-writable .htaccess files for permalinks, it would be suboptimal to choose that route for a plugin. Besides, code that modifies code is a very hard to fully validate for robustness. Better to use plain ole' PHP since PHP works so well.

> Anyone who needs this kind of control surely has 
> write permissions to the root. 

That assertion is only true if based on a narrow set of assumptions. Let me give a scenario where it would not at all be true. Assume that I create a plugin called "CustomUrls" and a themer uses it to create "The Ultimate Real Estate Broker Theme" and offers it for download. This theme might support URL paths of the following format:

  /properties/{property_slug}
  /communities/{community_slug}
  /agents/{agent_slug}

Now a real estate broker comes along and loves the theme, downloads it, and plops it on the most restrictive webhost out there.  My CustomUrls plugin fails to update .htaccess and after much failed effort on the part of the decidedly non-technical real estate broker she gives up and vows never to use WordPress again because "it is a piece of crap." (We all know better, but that doesn't change her newly formed opinion, and one she'll likely speak of to anyone who mentions the name "WordPress" to her at any point in the future.)

Actually, my CustomUrls plugin is designed specifically for themers to use (myself included), so I envision my stated scenario is far more likely than the scenario you present where the person using it would have skills needed to control permissions.

> If you don't need post content or any template logic, 
> I don't see why you'd need WordPress at all. 

The valid scenarios I envision *do* need WordPress in ~90% of cases but not for the ~10% of cases where I want to respond to custom URLs.  Currently the only options WordPress provides are "all or nothing." Why should it not not be valid to have "all" 90% of the time and "nothing" 10% of the time?

"Jennifer Hodgdon" <yahgrp at poplarware.com> wrote:
> Functions like wp_title() and other "template tag" functions 
> are meant to be used with the standard WP query mechanism 
> and/or The Loop. 

On the surface that would make sense. However, there are several reasons why I don't think we should just excuse wp_title() for it's deficiencies in this area.

1.) If wp_title() was only ever called by the end user, then yeah. Unfortunately, if is called by theming frameworks (such as Thesis, which I am using for my latest project) and it can be called by plugins. So my response for "it wasn't meant for that" is "Well then let's revise it so that it will be meant for that in the future."

2.) As I said, wp_title() is "just one of several places" where this type of logic has been embedded. Letting wp_title() off the hook doesn't resolve the issues elsewhere, and why not resolve the issues everywhere?  But rather than me just doing hand waving here, I'll list off the places where this type of logic pervades the core. This is not an exhaustive list as there may be more, but these are the primary culprits that would ideally be updated to support knowledge of custom URLs:

   -- redirect_canonical() in /wp-includes/canonical.php 
   -- redirect_guess_404_permalink() in /wp-includes/canonical.php 
   -- wp_title() in /wp-includes/general-template.php 
   -- parse_query() in /wp-includes/query.php 
   -- get_posts() in /wp-includes/query.php 
   -- wp_old_slug_redirect() in /wp-includes/query.php 

What I'd really like to see here is a method to tell all of these functions that I have a custom URL, a custom title, a custom query (or none at all), and a custom list of old slug redirects. As is those functions really don't give the hooks needed to do so.

> It is no surprise that they would not work if 
> you bypass the standard WP query mechanism and 
> create your own page. Trying to make some of 
> these functions work will not really help -- 
> they will never all work, anyway, if you are 
> not querying to find a list of posts.

Why will "they never all work?" From what I see I think it would be quite possible and reasonably easy to make them all work, it only takes a little bit to flesh out these use-cases and I'm perfectly willing to do it all assuming support from the committers. I've done most of the work already anyway.

> In my opinion, if you want to do a lot of this 
> custom URL stuff, you are much better off 
> starting with a CMS that has an "arbitrary 
> behavior for arbitrary URL" architecture built 
> into it at its core (such as Drupal), rather 
> than trying to build a whole system for 
> overriding URLs in a CMS that has an assumption 
> of "query for posts/pages" built into it at its 
> core (such as WordPress). I'm not saying it 
> cannot be done in WP, and certainly there are 
> mechanisms for the occasional one-off URL 
> override, but is it the right tool for what 
> you need to do? Just a thought...

I know your suggestions are well-meaning, you've always been respectful on the list, but since this is the 3rd time you've suggested directly to me that I use Drupal instead of WordPress let me detail to you why I don't find Drupal (or any other tool) to be the right tool for the job. My reasons are both for WordPress and against Drupal.  Be aware I used Drupal for almost 2 years and was heavily involved in the Atlanta Drupal user group during that time even giving two presentations, so me coming to WordPress is not without significant evaluation on my part.

1.) Drupal is optimized for genericity instead of usability. Presenting a non-technical user with a Drupal application results in me having to spend an inordinate amount of time supporting the end user.

2.) Drupal still doesn't have a default WYSIWYG editor and all of the one I used were very buggy.

3.) Drupal it poorly architected for scaling; to load just one web page can generate literally tens of SQL queries, sometimes hundreds. And the amount of PHP code that runs is just flabergasting.

4.) When there is a problem Drupal is very hard to debug (at least for me.) The reason is there is so much generic code in core Drupal that you spend 90% of your time just tracing through the same code trying to get to the code that actually matters.

5.) WordPress has many, many more of the types of plugins available that I'm interested in. More people write plugins for WordPress than Drupal, probably by an order of magnitude.

6.) More people are interested in hiring people to help with WordPress than to help with Drupal (at least from my experience.) Worse for me, there is a very aggressive local Drupal development company that sucks up any local contracts for Drupal development where the client is willing to pay a reasonable professional fee. And since most WordPress professionals are not PHP devs, I can augment WordPress pros much more often than I can augment Drupal pros (most Drupal  pros are PHP devs.) IOW, I can make a living with WordPress but cannot make a living with Drupal.

7.) But probably the biggest deal killer for Drupal (for me) is that it is extremely hard to create a professional looking theme and none of the designers I know can even begin to understand how to theme it. Since I am not a graphic designer and couldn't make a site *look* good if my life depended on it, I am basically hamstrung by Drupal, but if I develop on WordPress I can easily purchase a great looking theme and/or easily hire someone to create an even better looking custom theme for me.

So Jennifer I know you really think highly of Drupal and, for you Drupal might be the right tool for certain jobs but please accept and understand that for me Drupal is not an option to consider and WordPress is a much tool for my need, especially since it really is not that far off from what it could be.

"Otto" <otto at ottodestruct.com> wrote:
> The query *is* WordPress. It's the whole backbone of the 
> thing. If you're operating outside the query, then why 
> ever even bother to load WordPress at all?

As I said above, the reason is that I may need WordPress for 90% of a website's URLs, and for the other 10% I still need get_header(), get_footer(), and other parts of WordPress core. Should WordPress really be so inflexible that we have to completely bypass it ad then duplicate it's needed functionality in the case where the 10% of URLs are needed?

> For your custom-URL idea, you'd be better off adding a 
> filter onto mod_rewrite_rules, and appending your own 
> rules in front of it directly load your own PHP on that 
> URL. Then your URL never even loads WordPress. No query, 
> no nothing. It'd be easy enough to do. RewriteRule 
> YOUR_URL PATH_TO_YOUR_PHP_FILE [L] and you're done.
> Just hook a filter onto mod_rewrite_rules, stick your 
> own rules in (generated from your config, I assume), 
> make a call to save_mod_rewrite_rules(), and voila. The 
> .htaccess gets updated and you're golden.

I'm sorry but I can't take "modify .htaccess" as a serious suggestion for a plugin for reasons I spelled out above. Besides, I *do* need most of WordPress for these URLs, just not ALL of it (i.e. not the query.) Why is my saying "I only don't need the query" being interpreted as "I don't need WordPress at all?" 

I don't understand the pushback for what is a very simple issue.  Can anyone give me a scenario would the one "if" statement I proposed would actually cause harm? Westi has said "WordPress is a Platform" [1] to which I think everyone agreed. What I'm asking for is for WordPress to become a little bit better at being a platform than it currently is.

-Mike Schinkel
Custom Wordpress Plugins
http://mikeschinkel.com/custom-wordpress-plugins

[1] http://comox.textdrive.com/pipermail/wp-hackers/2009-February/024950.html