[wp-hackers] Custom Post - implementation specifics

[Stephen Rider]

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.

As I said in the initial email in this thread: "If we can't do it without significant bloat, it's not worth doing."  This is all backend stuff.

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.

>>> 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.

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.

> 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.

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.

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.

Not sure what you mean by "blocked from core".  I'm only "blocking" adding a GUI for adding arbitrary Post Types.  A plugin can do that if you like, but most users don't need this.  This is to make customization easier.

>>> I think having a list of known types for a given site stored in wp_options is really important.
>> 
>> 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.

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