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

[Hikari]

----- Original Message ----- 
From: "Mike Schinkel" <mikeschinkel at newclarity.net>
To: <wp-hackers at lists.automattic.com>
Sent: Monday, 15 February, 2010 5:52 PM
Subject: Re: [wp-hackers] Some Thoughts/Enhancement Ideas In And Around TheCategory Side Of Things


| On Feb 15, 2010, at 2:22 PM, Mike Schinkel wrote:
| > 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.
|
| Here is a "strawman" proposal mentioned in my previous email:
|
| ...
|
| My guess is that these patterns would satisfy 99.99% of WordPress developers wanting control of URLs.  Anyone on this thread see 
how this proposal would not work for their needs?
|
| While this would actually be relatively easy to implement given a clean slate, the current system is so complex I don't have the 
knowledge nor possibly the skill to create a plugin that could do this and/or be able to write a patch to replace what exists.  This 
would need to be a project that several knowledgeable people got behind.  I really wish I could do it for WordPress, I just can't.



I believe that would make it much simpler, but wouldn't be 100% flexible yet.

My idea would be even more flexible:


1) Each resource has a static permalink, exemple:

post: /post/post_id/
tag: /tag/term_id/
custom taxonomy: /custom_tax/term_id/

This would be hardcoded into core, and couldn't be changed. So the code would be simple, clean and fast. Anybody that wanted 
permalinks to be fast and simple would be allowed to just use it.


2) Core also supports Endpoint Mask, that are those strings that go in the end of the URL, as /feed/ or /page/.

These masks point to special features/resources related to the permalink they are attached, so they are the first thing to be 
searched, always in the end of the URL, and once found are removed from next steps.

Plugins could just add new masks, without needing to worry with what's behind them.



3) A Core Plugin creates a table, that redirects alternative URLs to core ones:

/hello-world/ -> /post/20/
/cities/Salvador -> /cities/11/
/Natal/ -> /cities/50/
/news/ -> /category/2/
/Jack -> /author/3/


4) For every request, it would first run the regexes for core permalink matches. If not found, just query database for that URL. 
When found, that row will point to a parsable permalink that will point to the resource.


5) The core plugin has a simple UI that generates the permalink in a similar way permalinks are generated today, having a list of 
permastructs that it uses.

On every preview, the suggested URL is shown in a input=text, and if the user doesn't like it he can just edit the whole URL (as 
today we can with slugs) to anything he likes.


6) Then, plugins can be developed to enhance the base UI, to add new permalinks and permastructs, to automatically create 
alternative URLs,  to redirect alternatives to main ones, and so on.


With a simple, modular and scalable code, this would be much easier than today. People wouldn't need to learn the whole permalink 
functionality to add a new feature.

And anybody that doesn't like how something's done, just hook a filter to disable it and another one to do how they like. With no 
performance penalties :)



---------------------------
Hikari -  A Luz ilumina a PAZ
http://Hikari.ws
http://ConscienciaPlanetaria.com

Tenha seu próprio email meunome @ ConscienciaPlanetaria.com.br!: http://seunome.ConscienciaPlanetaria.com.br