[wp-hackers] Custom Post - implementation specifics

[Mike Schinkel]

On Dec 6, 2009, at 12:12 AM, Stephen Rider wrote:
> On Dec 5, 2009, at 9:38 PM, Mike Schinkel wrote:
> I think we are in full agreement except on weather there should or should not be any admin UI for custom posts built into the core.
> 
> Sounds about right.  I want to make it easy for plugins to do this stuff, but it is still IMO strictly plugin territory to actually use it.  If we're going to add Core GUI to set up custom post types, we would need GUI for adding (and defining -- specifically!) the add and edit pages, and their locations, etc. etc.
> 
> If *after* we do this you want to try and get a GUI added, go for it; but honestly (and no offense intended) I don't think you'll get much traction with that.

At this point, yes, let's get the functions working.  After that I think the need for an admin UI addition to the core will become a need that will be obvious to many.  Let's wait and see?
> 
>>>> What's more, minimally I think it would be really a good idea in 2.9 to have an "Post Types" link under the Settings menu that lets user add new post types with nothing more (to start) then just a way to add new types names and see a list of those names.
>>> 
>>> I disagree.  In a default install there is no need, and what you describe is too little use without more custom code via a plugin anyway.
>> 
>> Why is there no need?  If I can add a new content type (i.e. an "event" for example) in the UA then I can add-hoc use custom fields for start and end times and I can write custom loops in the theme to pull a list of events.  It's one tiny bit of additional functionality that would enable a huge amount of value. Requiring a plugin to expose such a core feature seems backward.
> 
> At any rate you'll have to have a custom Theme, and any theme using the custom post types could have the necessary code in functions.php.  I can't see any way (without MASSIVE changes to WP) to use custom post types without *some* sort of custom coding.  So... plugin.

FWIW it's a *lot* easier for a designer who is new to PHP to learn how to add the following to a theme file file single.php than it is to wrap their head around how hooks work and how to define functions, etc.

<?php print get_post_custom_values('event_start_time'); ?>

So.... not plugin.  :)

> Again, we can agree to disagree on this one.  Let's get the API and then later you can have a go at adding extra GUI for it.

Yep, we are one\ the same page here.

>> Besides if that feature is blocked from the core then every plugin is going to (have to) implement the exact same "core" functionality only will all implement it differently.
> 
> Are you talking about a plugin that allows the user to create arbitrary new post types?  I admin I wasn't thinking in that direction -- I was assuming that a site would have a specific need and a plugin/theme would be written to address that particular need.  Again, remember that whatever custom post types are introduced, the theme must be made to accommodate.

I can readily envision that many end users could see the need to add custom post types for given things that are specific to their own use cases. For example, an anime fan may want to catalog a list of all the anime conferences[1].  A mommy blogger might want to add a custom post type for her field trips[2].   An insurance industry blogger may want to create a list of local agents and also the interviews that he has had with each of them[3].  A social media marketing person may want to create a list of local events[4].

[1] http://fandomu.com/
[2] http://www.fieldtripswithsue.com/
[3] http://www.atlantainsurancelive.com/
[4] http://groups.yahoo.com/group/ATLeventsandscoop/

Those are just four examples of people I know who could use what I'm talking about yet none of them are programmers. And those use cases are pretty unique to the individuals.  I see them going without the ability to classify the things that are important to them long before they ever write a plugin.

There are many uses cases for custom post types, probably as many as their are blogs out there.  Yes there will be some common use cases that have people building plugins for them but there will be a much greater number of long tail use cases for custom post types that are exactly specific to the end user.  

It's just like Microsoft Access (or MySQL.)  How useful would it be if the database vendors predefine all table types you could use?  If they had there would almost certainly be no WordPress because the innovation would have been limited to the team defining the "approved" table types.  If there is no admin is made available in the UI to simply add new post types then all that creativity will stay locked in that genie's bottle.  Are the benefits to blocking all that really that great?  

> If that's *not* what your talking about, then I'm a bit confused.  The main thing I'm trying to do is implement a "Create Edit Page" system that will be a standard method of making Edit Pages for custom Post Types.  Thus any plugin that uses that system will result in Edit pages that are essentially similar.

And for the record I applaud that.

> That is, I'm precisely trying to *avoid* "every plugin is going to (have to) implement the exact same 'core' functionality", by creating a simple, standard method for doing just that.

Yes, agreed. OTOH every plugin that needs to let people add new post types of their own choosing will proliferate the ways to do that. 

For example I can envision a plugin that let's people define how custom fields will be displayed and then will display them at the end of the_content() making it possible to display custom fields for a custom post type without having to modify a theme. If there is no way to add custom post types that plugin would have to add that functionality

Then I could see another plugin that would let a user define what custom fields a custom type would have by default (oops, there already is such a plugin: Flutter.)  That plugin would also need to let users add custom post types. 

And so on.  

Since it will be a fundamental need shared by several plugins *and* since end users could really use the functionality there will ideally be a standard way to add a new custom post type. That standard way can do nothing more than add a string to a list i.e. adding "product" to the "custom_post_types" key in the wp_options table (or create a custom taxonomy and use the taxonomy system?) and *optionally* add a management menu in the admin for that type. 


> Not sure what you mean by "blocked from core".  I'm only "blocking" adding a GUI for adding arbitrary Post Types.  

When I say "blocking" it's shorthand for "advocating against."

> A plugin can do that if you like, but most users don't need this.  This is to make customization easier.


How do you know most user's don't need it?  I believe that 90% of greater of WordPress users need it but most simply are technical enough to know what to ask for.  People didn't ask for gasoline to power their cars in the days where everyone rode in horse and buggy.  Once people realize that custom post types are possible in WordPress I expect a huge groundswell of demand.

But we don't need to debate it;  what you are proposing needs to come first, and then if I'm right the demand will materialize after people like Justin Tadlock start writing articles about what is possible.

>>> How is it stored now?  2.9 allows you to register Post Types now, doesn't it?  Where is it stored?
>> 
>> Only in memory.  Post types are not (currently) serialized to disk in 2.9.
> 
> Question: so long as the array can be referenced, what does it matter if it's in memory or on disk? It's still information that can be used by other code.

Good point in most cases. But you can't do a SQL JOIN with data only in PHP so not workable in all cases.  I guess it comes down to the question of whether the MySQL database should have the knowledge independent of running code, or if that information should be in the database.  Personally I think it should in the database because I think it will be needed there.

Also, if stored in the database then the register could be done on activation and not on every page load hence improving performance slightly.

Lastly, if it is only stored in code then plugins that want to give an end user the ability to add a custom post type will end up persisting those custom post types in different ways. Again, it will could get ugly.

-Mike