For the same reason Categories works the same way, you might want to look at my last blog post on this issue, and how to achieve the results you need.
But it isn’t as hard as you might think, it just takes knowing how to go about it.
Yes it did work so I thank you very much for pointing me in the right direction!
I do see a custom post feature as a valuable tool for content box allowing developers to provide a multitude of plugins that would make the system much more flexible and easier for the non developer to use. I do think that it could be added to the system without much pain. Kind of see it this way:
A table would be needed to register the different types of posts, i.e., Blog (which would be standard), Photo Gallery, Listings, Listings which tie into google maps, etc. Post types could even be configured to use existing web services for things like capturing latitude and longitude for use in map rendering.
Each main post type, excluding blog, would then have entries in a field configuration table which would define the additional fields and their types (date time, text, select boxes, etc).
The app would need to be modified to allow a user to upload an install zip file (much like the module uploader), unzip it, run the configuration files to create the necessary entries, and create the widget necessary for rendering. And the blog engine would have to be modified to only include the blog post type.
When creating the posts, the editor can be modified so a post type selection is required. Selecting anything other than blog will reload the screen and display the additional fields defined for the selected post type. Another way would be to create additional menu entries for the different post types. Though I could see this method getting out of hand and difficult to manage using the current admin menu structure.
After looking at the admin screen, I’d think the best implementation would be to have a listing of the different post types, again, much like what you see when you load the module screen. The current Page and Content menus can be collapsed into one menu Post Types. The Page and Blog would be listed as the first two post types. Clicking on a post type name would render the editor for that post type with its custom fields ready for use. Based on security permissions, an experienced developer could also manage each custom post type and extend by adding their own custom fields. It doesn’t seem like you’d want the Page and Blog post types to be extended, but for example, in my layout, Pages have a subheading on every page, so being able to define a subheading field for pages and have it there ready for use would be great. I could see the same for blog posts.
I’ve been working with CF since version 2, but have never really gotten deeply into the OO way or using ORM so its taking me a bit to wrap my head around how all this works together. I would love to be at the point where I could contribute these features myself, but thats a way off. So hopefully someone else can run with it.
In a previous post, I explained this feature to Luis and he indicated he may take it on, but I don’t know for sure.
A few thoughts on this:
I’m not sure a new table is needed. In looking at a number of the WordPress type plugins that do this kind of functionality, it seems all of them simply leverage the equivalent of CB’s setting table. Since the content is truly configuration data (e.g., defining custom types/fields), using the setting table would seem to be feasible. Of course, if CB’s version were different in complexity/options, this might change…
RE: the implementation, I think I like that too. Let’s say you have different content types like “Events”, “Ads”, etc. Would be nice to manage them in isolation from other content types.
I think it would also be awesome if there were two ways to manage custom content types:
- Developer-centric. Be able to upload/drop-in what would be essentially a module that defines all the necessary details for registering the custom content type.
- Admin-editable: Provide a slick interface for creating content types, adding custom fields, etc. This way, you could pretty easily tweak a content type you downloaded from Forgebox, as currently is possible with widgets.
After thinking about it you’re probably right. Using the exising settings table is probably the way to go. And I also agree with your other points. So when is someone going to build it? 
Each content object has access to all custom fields already as a relationship
Luis Majano
CEO
Ortus Solutions, Corp
Toll Free/Fax: 1-888-557-8057
Direct: 909-248-3408
www.ortussolutions.com
Twitter: @lmajano, @ortussolutions