[wp-hackers] Custom Post - implementation specifics

[Mike Schinkel]

Kudos.  I have no suggestions at this point. I think you are headed in the right direction.

-Mike

On Dec 3, 2009, at 11:56 AM, Stephen Rider wrote:

> Okay, I'm splitting this to a new thread for a reason.  Clearly there are people who would like to see a better API for custom Post Types.  I would like to discuss in this thread *specifics* of how that would be best implemented.
> 
> PLEASE let's avoid discussion of IF we should do it.  There are already two other threads for that discussion (most recently "One CMS to Rule Them All").  This is for people who DO like the idea to discuss *specifics* of how it might/should be implemented.
> 
> Note: If this is done correctly, a default install of WordPress should be NO DIFFERENT than it is now.  We're simply adding flexibility for plugins to be able to modify things easily and consistently.
> 
> Specifically, what functions need to be created?  What should we not overlook?  What obstacles or dangers should we avoid?
> 
> Below is my previous post regarding the topic. ***Please read it before replying to this thread.***  There's a bit more new at the bottom as well.
> 
> It gets the ball rolling with  an overall conceptual overview of how such a thing should be implemented.  Specifically, I think a HUGE amount of flexibility can be added to WordPress **without adding a lot of bloat**.
> 
> That last bit is important, as I think bloat is one of the main reasons a lot of people *don't* want to add this API.  If we can't do it without significant bloat, it's not worth doing.
> 
> 
>> 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.
> 
> I'm thinking that the add_post_edit_page should have the following parameters:
> 
> * Post Type
> * Location in the Menu
> * array listing "Page Pieces" (meta boxes) -- e.g. text box, categories, etc.
> * $context -- which is basically the name that will be inserted into the standard hook that allows plugins to insert or remove "page pieces"
> 
> This will most likely be a wrapper of some sort around the existing "add menu item" function
> 
> There will be two hooks standard to all Edit-X pages:
> * One to allow plugins to modify pieces on ALL Edit pages
> * One to allow plugins to modify pieces on any Edit page that was given a $context
> 
> Again: If this is done correctly, a default install of WordPress should be NO DIFFERENT than it is now.
> 
> Ideas and suggestion?
> 
> Stephen
> 
> -- 
> Stephen Rider
> http://striderweb.com/
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers