[wp-hackers] Some Thoughts/Enhancement Ideas In And Around The Category Side Of Things

[Mike Schinkel]

On Feb 14, 2010, at 8:52 PM, mark waterous wrote:
> My point was simple: Your visitors should have NO need to be trying to find
> pages on your site by altering the URL they are currently visiting. By
> 'your', just to be clear on this, I mean anybody who runs a web site, not
> just you and Mike. If a visitor has to alter the URL in any way to find a
> page, then your site has failed in providing an adequate navigation
> structure to begin with, and no amount of user friendly control over the URL
> is going to save your visitors from leaving.

For a site to require a frequent user to click multiple links and load multiple pages each time for a user just to get to where they needed to go, especially on a slow connection, is your ideology trumping user's needs and usability.

By your same logic a computer operating system vendor would be a failure if their GUI didn't meet everyone's needs and they also provided a command line, right?

> As many people have pointed out, if this is that important to you, create
> some rewrite rules or a plugin to provide the functionality you require. The
> reason it is discussed for this long is not because the larger majority of
> WordPress users out there want it, it is because a small crowd of dissidents
> won't stop arguing the same points OVER and over and OVER again.

It's hard to maintain an argue without others debating the contrary. If you want the discussion to die, quit debating it.

On Feb 14, 2010, at 8:51 PM, Hikari wrote:
> Because of the complexity of the core code, it's hard to expand permalink features, it's as if we had to fix something that 
> shouldn't need a fix.
> 
> We can remove cat base, but only if we have few cats and pages. It's not expandable.
> 
>  ...
> 
> We need a simpler and dry base to work upon. With this complex permalink code, if something is against what we want we hardly can 
> change it.

+1

> | After thinking about this a bit, I'd like the through out the following
> | trawman: why don't we consider deprecating wp_terms and using
> | p_posts with a post type of "taxonomy_term" instead?  That would
> | ddress numerous concerns; streamline URL routing for taxonomy as
> | well as give taxonomy terms descriptions and meta data.  Hmmm?
> 
> Do you mean, do this change to to make URL parsing easier?

Yes, but also to add all the features of posts to a taxonomy term, i.e. most importantly a description but also categories, tags, URL routing, and more.  It is basically what Matt suggested to me that they want to do to replace Links so it seems to make sense for Taxonomy too.


On Feb 14, 2010, at 10:34 PM, mark waterous wrote:
> I think that's what everybody is missing. You can. Just because WordPress
> doesn't dumb it down and make it a one-click-fix doesn't mean you can't.

Yes you can, but as is there is no guarantee of compatibility with core.  URLs by definition must be unique and thus URL routing for standard patterns needs to be in the core to maximize plugin compatibility.  Having in core makes a plugin developer code to the core instead of ignore (or not be aware of) another plugin.

> Custom taxonomies should work like namespaces. If you have three taxonomies,
> such as 'Post', 'Category', and 'Links', these are by definition three
> separate entities. Under any of these you should be able to repeatedly use a
> single slug (since each should act as its own namespace), such as
> 'custom-entry'.
> 
> Now you have three urls;
> 
> http://yoursite.com/post/custom-entry
> http://yoursite.com/category/custom-entry
> http://yoursite.com/link/custom-entry

Now I agree with that (which violates a current core architecture principle in WordPress, i.e. that slugs are globally unique. That needs to change IMO.)

> These are easily readable, no they're not 10 characters long, but who cares.
> They also readily define what you're looking at. The first is a post, the
> second is a category, the third is a link.

Agreed.

> Now we remove these. Your url is http://yoursite.com/custom-entry which
> makes a couple people happier.

That's apples and oranges.  It's really more like this, using your example above but making them plural:

http://yoursite.com/posts/
http://yoursite.com/links/

And this:

http://yoursite.com/custom-category1/
http://yoursite.com/custom-category2/
http://yoursite.com/custom-category3/
...
http://yoursite.com/custom-categoryN/

> How does WordPress tell whether you were
> looking for the post custom-entry, or the category, or the link, or any
> number of possible custom taxonomies? I guess what we should be really
> arguing here is the fact that WordPress doesn't have psychic abilities in
> the core.

You admit defeat far too easily. If you acknowledge the emergent patterns this is an relatively easy problem to solve albeit maybe not 100% backward compatibly. 

Let me preface with this: I doubt anyone is reasonably asking for 100% flexibility with URLs. Instead I think what most people want is to support the finite range of URL patterns typically in use today.  

The first problem is the assumptions that WordPress makes about URLs. It makes some harmful limiting assumptions such that post slugs must be unique even if composed URLs are unique, i.e. this can't work in wordpress:

http://yoursite.com/my-slug				<-- page with slug "my-slug"
http://yoursite.com/2010/02/15/my-slug		<-- post with slug "my-slug"
http://yoursite.com/custom-types/my-slug	<-- custom post type with slug "my-slug" where "custom-types/%custom-type%" is a URL pattern

The other assumption WordPress makes is that URLs have no known patterns and that any URL can be matched with a RegEx.  That's true, but it does not allow optimization based on known-patterns. 

Here is one thing we know about URL paths: they come in path segments separated by slashes ("/").  This is a 100% always true pattern given that the set of segments can be zero or one in which case there are no slashes.  First thing we can do is go slice up the path and look at each segment on it's own (and I think we can even do that part backward compatibly because the matching RegExes can be sliced up too.)

Once you focus on URL path segments instead of full paths the scope of possible options diminishes significantly it practice. Except for the case of someone putting every path in the root you find that the number of valid path segments in the root is typically small. Then at each new segment the number of URLs with only one additional segment is also typically relatively small.  What's more as you drill down those path segments you can recognize a much smaller finite set of items to potentially load.  For examples, using reasonably standard assumptions for configuration:

http://example.com/yyyy/mm/dd/slug/	<-- Must be a post
http://example.com/customs/slug/		<-- Must be a custom post type of "custom"
http://example.com/tags/slug/			<-- Must be a taxonomy term in the taxonomy of "post_tag"

When you look at it from the perspective of URL path segments and emergent patterns then the problem suddenly gets much smaller. So I'll make a strawman proposal in my next email.


> WordPress shouldn't have to build control panels for every possible
> scenario, it's just not probable or intelligent, not when you can accomplish
> this on your own.

Agreed, but this isn't "every possible scenario", URL routing is foundational and by looking at path segments and emergent patterns then it becomes clear that this isn't every possible scenario, just the 20% that is needed by 80% of developers doing more than just building blogs.

This issue is going to come to a head even if you don't want it to because custom post types thankfully opens the pandora's box. Better to fix all of URL routing than just make patches for custom post types.

> The documentation on how to do it can be found here:
> http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html (that url broken down
> is documentation -> v1.3 -> modules -> mod_rewrite, but I suppose they could
> lose the unnecessary /docs/ :D ), or here:
> http://redmine.lighttpd.net/wiki/lighttpd/docs:modrewrite, or here:
> http://wiki.nginx.org/NginxHttpRewriteModule 

Using Apache routing is not a viable solution for many because WordPress outputs URLs that Apache can't control and it's too much of a black art for too many people.

-Mike