[wp-hackers] One CMS to Rule Them All (was This was painful to read...)

[Stephen Rider]

Hi all --

On Dec 2, 2009, at 5:42 PM, Jared Bangs wrote:

> On Wed, Dec 2, 2009 at 2:49 PM, Mike Schinkel
> <mikeschinkel at newclarity.net> wrote:
>> 

>> There's a belief held by many that adding features necessarily affects performance negatively. That is not by any means a rule and to make decisions based on only that assumption does a disservice to the broader community.  Having the option of custom post types and the option of URL routing should not negatively affect those sites that do not use those options if the enhancements are architected with performance in mind.
> 
> If on the other hand, you think that WordPress is (or should become)
> the ideal solution for every possible web project (a position I think
> is clearly wrong and cannot relate to), then it would make sense that
> the scope of the core WP project would need to be (or become) enormous
> in order to accommodate that.

I'll start by stating overall position, then get on to specifics

1) I heartily agree with and support the prospect of creating API functions the make it easy (simple!) for plugins to add custom post types.

2) I also strongly support abstracting out "Edit <post type x>" pages in Admin so that plugins can say "I need an edit page for Post Type X.  It needs (for example) the Main Text Box, Tags, and Excerpt.  Bang!  Done."

3) I understand the wariness of bloating the core with extraneous additions, but I do not believe that this situation needs to be such.  I believe that it could be done by creating a few robust, flexible functions, and a bit of reorganization.

Now, some specifics:

I'm not overly familiar with the Custom Post Type code (yet) so I can't make precise suggestions, BUT I would like to point out a patch that I recently created, that has been committed for WP 2.9.  This patch is in ways similar, in that I saw a need and created a patch that

1) adds flexibility to the area to which it applies

2) Consolidates code in areas where different functions has substantially identical code.

3) Reduces redundancy in multiple places where (for example) a series of parameters had to be specified twice.

	3a) Said parameters are readily modified by plugins

4) Created a new function that can be used by plugins to very easily create custom functions that were much more difficult (and again, redundant) to do before.  A few pre-existing functions are recreated as wrappers to the new "core" function.

	4a) The new "core" function is written in a way that it can automatically add hooks to any new wrapper functions that may be created by plugins

5) No bloat.  Adds a single new function; and two pre-existing functions are significantly simplified.

Here's the ticket:

<http://core.trac.wordpress.org/ticket/8964>

Specifically, get_plugin_data() and get_theme_data() used to be completely separate pieces of code, but did basically the same thing.  I abstracted out a new function, get_file_data(), and both of the original functions are basically wrappers that use the new one for their core functionality.  As a bonus, plugins can also put get_file_data() in a custom wrapper to read headers off of custom "add on" files of their own.  (Also pay attention to the $context parameter!)

So how does this apply to to custom Post Types?

We create a new function that is basically "add_post_edit_page".  Parameters are a location, the Post Type to which it applies, and an array containing a list of features that the Edit Page needs (Text Box, Categories, Tags, Excerpt, etc.).

Then we abstract the existing code so that the two standard pages, Edit Post, and Edit Page, use this new function.

Cutting a bit short -- have to go.  I'll chime in again later, but what do people think of this?

Stephen

-- 
Stephen Rider
http://striderweb.com/