[wp-hackers] Controller Implementation

[Mike Schinkel]

On Jul 2, 2010, at 8:55 PM, Brian Layman wrote:
> Sure.. Maybe this will help..  If I am still not making sense, just nm it's
> been a long day. It makes sense to me at least :D

Thanks for the efforts!

>>> when a request arrives at the site, isolating a single post may not be
>>> possible
>> Note sure I follow.  Can you clarify with an example or two?
> This was a basically a reiteration of your initial statement in #12935:
> <blockquote>
>  As WordPress grows into a proper CMS with MultiSite and Custom Post Types
> and Custom Taxonomies there are frequent opportunities for URL conflict that
> didn't occur as often with just Posts and Pages. 
> Here's a simple example, let's say a company uses WordPress for their
> website and they offer development services as well as training on their
> website: 
> http://example.com/services/vmware/
> http://example.com/training/vmware/
> </blockquote>

I wish I could rewrite that original opening.  I've since learned that I was wrong about that (if you set a post type to be hierarchical then only it's path segments need to be unique.)  I'm using that to great effect on a very complicated project I'm working on as we type...  Be sure to read the later comments.

>>> 2. when permalinks are determined as a "post" is created, a
>>> unique permalink can no-longer be guaranteed.  
>> Again, not sure I follow.  And again, can you clarify with an example or
> two?
> When you are creating a new post, if there is a conflict, the permalink/slug
> is modified to prevent the conflict in the first place (by adding a -2 or
> whatever).

Yes. And that behavior has caused me more trouble that you can possibly know.  There've been many contexts where I wish WordPress would block the user and force them to correct the duplicate URL slugs instead of WordPress quietly making an (incompatible for our needs) "slug-2."  This is especially true of the regrettable decision (IMO) to allow slugs in trashed posts to blog slugs for new posts.

> If the goal is to create a system that can quickly identify the
> globally unique target for an URL, I would seem that there is a tie in to
> this functionality.

Maybe, but only by orthogonally and by happenstance.

Ideally the system would enable the dev/themer to have more control over how path segments are generated.  That would be one of my many goals in this new approach.

> It should be able to tell you if the proposed permalink
> would an existing target.

Yes, that would be good.  

OTOH while I envision some routes being very much use involved (i.e. like the creation of a route for a new blog post) and others not being user involved at all (like date archives, lists of posts for a taxonomy term, etc.)

>>> Changing permalink structures should cause a reverification of posts
>>> before it is accepted, but thinking of the workload caused by that on
>>> large sites makes me cringe.
>> I also don't follow that. What do you mean by "re-verification" and
> who/what is doing the "accepting?" 
>> Is the workload human or computer?
> I added this as I was thinking about how a blog admin could choose a new
> permalink structure and inadvertanly cause many urls to no longer be
> globally unique.

Ah.  I'm not sure how it would work for Jacob's proposal but with my proposal I don't think that would exactly be possible (unless I am missing something.)   Besides, I'm envisioning URL routes to be done by theme/plugin coders, not admins. At least not initially.

> Hope that helps...

Yep, and ditto.
-Mike