[wp-hackers] Controller Implementation
mikeschinkel at newclarity.net
Sat Jul 3 01:13:00 UTC 2010
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
>> Note sure I follow. Can you clarify with an example or two?
> This was a basically a reiteration of your initial statement in #12935:
> 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
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
> 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
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.
More information about the wp-hackers