Plugin idea: custom post_type + editor

Jan Egbert (Member)
Posted 10 months ago | Permalink
WordPress 2.9 makes developing custom post_type plugins much easier. Still to hard for me, although I would develop this myself if I had the knowledge. My idea is an editor to create new post types and associated post editors. WordPress offers post, page and attachment as standard post types. I need more post types. Some post types I'd personally like to add for some of my websites:
- book (bibliography)
- video
- camera review
- event (event calendar)
- classified ad (I don't like the hacky classified ad themes and plugins that are currently available)
- faq
- product
- wiki
- photo
- etc.
I know some plugins are already doing this job. I even tried all of them, but after reading what Justin Tadlock wrote about this I decided to stop using them.
Existing plugins doing this job in a "wrong" way:
Anyone else interested in a plugin like this? Anyone interested in developing it?
Justin Tadlock (Key Master)
Posted 10 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
Justin Tadlock (Key Master)
Posted 10 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
Jan Egbert (Member)
Posted 10 months ago | Permalink
I noticed that the register_post_type() is actually in WP 2.9 rare, what can I do with that function?

I tried:
```
<?php
add_action( 'init', 'create_my_post_types', 0 );

function create_my_post_types() {
	register_post_type (  'event',  array ( 'exclude_from_search' => false) );
}
?>
```
That didn't do anything. No new post_type was added in my database and the magic of new write panels didn't happen. So I guess I really have to wait until WP 3.0. This sucks, because I want what I want when I want it.

I agree that a plugin should cover the combination of custom post types and custom taxonomies.

Some ideas for this plugin:
1. I like that Query Posts plugin is called Query Posts, I like how the Members plugin is called Members, so I guess the Post Types plugin could be called Post Types.
2. It could be integrated with Gravity Forms (they are adding custom taxonomies in future release, so they might as well add custom post_types)
3. The ability to add metaboxes
4. Integration with Members and Query Posts
Justin Tadlock (Key Master)
Posted 10 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
Patrick Daly (Member)
Posted 9 months ago | Permalink

there was a patch for a custom post type UI in 2.9

I can't this; do you have a link? I'd like to start experimenting.
Justin Tadlock (Key Master)
Posted 9 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
dwenaus (Member)
Posted 8 months ago | Permalink

Justin, I've been mulling over this issue for a long time now. I am planning on building a pretty robust plugin to create a program/event catalog and registration system, it will be at the core of a new project I'm starting. on the one hand I could develop two new tables called wp_programs and wp_programs_meta and just code everything myself. This has the upside of always working with future versions of wordpress and being able to code and organize things how I like. It also will make the system easier to create an API for if I ever want to in the future as most info will be in the programs table and only extra info will be in the meta table.

On the other hand, though, I realize the wisdom of building things using custom post types when it gets properly implemented. The one upside is that you get to use the many functions that already exist for managing posts and pages (ie. get_children, attachments, revisions). You get those more or less for free (if they work with custom post types) whereas if you build your own tables, you need to create your own functions for all those things.

So maybe if someone is creating a simple CMS plugin then using custom post types is best, however if someone is creating a specific plugin such as Events calendar with many features then creating separate tables is better. I would love to hear your feedback on this issue.

many thanks.
Justin Tadlock (Key Master)
Posted 8 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
dwenaus (Member)
Posted 8 months ago | Permalink

thanks for the clear response. I agree with everything you've said.

but what about thing like performance. If I use wordpress post types, then all my interesting data regarding event dates, teachers, location, times, will all be in the meta data so a complex query needs to be performed for every look up. however if i create my own programs table, I can put all that data in their and the query will be fast. Another possible benefit of using separate tables is if you want to access the db from another system. that is thinking far ahead, but it might be necessary with member or registration info.

Also, I'm not sure I understand how a plugin that uses its own table could break when new versions come out. isn't it more likely to break when pushing post types to the limit.

last question, if I wanted to start developing this plugin now, what tools would be best to use. I'm fine waiting for 2.9 to come out, but does 2.9 have the functionality I need. ie. are they just postponing the UI components or are they postponing all the structural changes as well? or should I use your Query Posts widget?

many thanks!
Justin Tadlock (Key Master)
Posted 8 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
designOdyssey (Member)
Posted 8 months ago | Permalink

First, Kudos to ThemeHybrid folks for being near the top of Google on post_type discussions. Either SEO is amazing or we're one of the few places this is continuously discussed.

I too, don't want to wait for 3.0 and want to use the functionality of custom post_types and not just custom front ends (flutter, more fields). If the backend is ready, I'm OK to build plugins for my two different post types (locations and events). However, I'm hearing that the backend really isn't ready or is buggy. Where can I find a fuller understanding of this???

I can't seem to find is a cogent explanation of what functionality exists, doesn't exist, what's backend vs. UI. For example, shouldn't it be trivial to modify Flutter or similar to use actual custom post_types if they are registered? Then couldn't you get both the UI and backend in alignment. Prelovac's Plugin Book gives a simple example of how to show different "post types" in admin, so although probably more complicated than his example, it's probably not too hard.

I want to understand more what's available, but this needle seems hidden well.

Thanks for any help.
designOdyssey (Member)
Posted 8 months ago | Permalink

I've been reading more on this and at least at this stage there are bigger issues. I frame them with 2 questions.

What can you do with custom post types that you can't do with categories/taxonomies? Currently, the answer appears to be nothing except remove the need to exclude certain categories from display (in widgets, etc.) because these categories are acting like custom post types.

What can you do with categories/taxonomies of posts that you can't do with custom post types? Currently, it looks like a great deal. Why? Because there are numerous plugins that seem to rely on the "post" post_type. For example GD Star Rating or Favorite Posts rely on "posts." Without hacking, I couldn't get them to work with recipes or events. Maybe they'll eventually allow users to select among registered post_types, but not now.

In terms of UI, it'll be great when Core gets a post_types UI that allows easy creation. Frankly though, most of us could muddle through doing it the "wrong way" with Flutter or Magic Fields. And, as of now, the UI wouldn't fix the plugin compatibility issue or other functions being "aware" of custom types. My larger concern is what we get for the "trouble" of using custom post_types?

For example, is 3.0 gonna have a separate table for different content types to decrease load from everything sitting in post and post meta? That would likely break even more plugins.

At this stage (unless I could be convinced otherwise), I'm looking for a good category/taxonomy excluder because I can't afford to hack all the plugins I need to be a post_type purist.
Justin Tadlock (Key Master)
Posted 8 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
designOdyssey (Member)
Posted 8 months ago | Permalink

I might be confused, but in this case I don't think so. I get what you're saying, but what makes a book review a different type of content than a post or a recipe or a store location?
It seems the fields of data (or images/files I guess) and not the labelling is what makes them different.

Well, for "practical" purposes, you can change the fields of the "post" post_type on a per post basis - creating any content type you want. If that's true, it seems that grouping, manipulating and displaying these "content types" is what most are after. I believe that grouping can occur right now through labelling/categorization.

As a result, I would add a nuance to your answer to my question:

What can you do with custom post types that you can't do with categories/taxonomies?

* Create content.
* Label it with taxonomies.
* Add an excerpt.
* Set a published status.
* Add custom metadata.

Of course, technically, you're right. However, I can label, excerpt, change status and add metadata to a "post" post_type and by it's categorization/labelling, separate it from other categories of posts for display, manipulation, etc. Since that is the end goal - at least in my implementation, I still don't see what additional benefit I get from custom post types that have "native" custom fields associated with them rather than those added to a "post" (except elimination of the unneeded fields associated with all "posts").

I'm not trying to be difficult. I too want to see content_type-aware plugins and native functions that make use of this positive additional layer of abstraction. When the wp_postmeta table becomes just contentmeta or multiple different tables, I can see WP's CMS street cred growing. I'm glad you're writing a post so plugin authors can "see" the future. I just can't wait for 3.0 and don't see that I'm missing out on much in functionality by not waiting.

In fact unless custom content types have a different database structure (e.g. multiple wp_content tables with only relevant fields), I don't see the practical benefit at all. Yes, adding custom "write panels" that allow new content types with associated custom fields will be nice. Sure, adding the ability to access those different content types with native functions will be helpful too. I just think you can do all this right now with the hackish solution of Flutter and the post post_type.

If I'm wrong, I'd like to know, so I can add the correct information to my planning. I'm normally a measure twice, cut once type of guy.
Justin Tadlock (Key Master)
Posted 8 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
designOdyssey (Member)
Posted 8 months ago | Permalink

Do you see a difference between posts, pages, and attachments? These are all default post types that WP offers. Or, do you see them as the same thing but just different groupings?

I see a difference. However, that difference is based on the associated fields and core functions built around those types. If I use a custom type now, it won't have that difference in functionality (unless I build it). For there to be a difference in 3.0, it seems the functionality available to custom types must be different than that available already for posts otherwise there is limited use except nomenclature. This is true in how plugins treat posts vs. custom types as well.

I'm sure they're thinking about this and maybe your post will encourage more thought. Frankly, I'm a bit stumped of what they will do in core. They could make a bunch of "generic" functions that could be applied to any custom type or they can just make this the domain of plugins/themes through some sort of API. They certainly can't anticipate all the functionality needed by every conceivable post-type so a compromise is warranted.

What I want to do is no more complicated than Tastykitchen.com that uses posts for recipes or others that use them for review sites. If I only needed one type (i.e. didn't need posts as blog entries), I wouldn't even need to create a separate category.

When all of this gets resolved, I may have to use some sql to extract my posts in the "store locations" category and "massage" the post and postmeta fields for them to fit into the "store locations" post_type. I'll think about a structure that facilitates that, but it shouldn't be two hard.
Justin Tadlock (Key Master)
Posted 8 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
Justin Tadlock (Key Master)
Posted 8 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
Justin Tadlock (Key Master)
Posted 7 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
Jan Egbert (Member)
Posted 7 months ago | Permalink

Cool :) How did you do that?

It really looks like registering custom post types + UI will be a really easy job after WordPress 3.0 release in April. Also I can't wait for the hierarchical taxonomies.
Justin Tadlock (Key Master)
Posted 7 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
Patrick Daly (Member)
Posted 7 months ago | Permalink

How are you getting your custom post types to display within global post list? I can't display my custom posts without a custom query.
Justin Tadlock (Key Master)
Posted 7 months ago | Permalink

You must be a logged-in exclusive member to view this reply.
Joel (Member)
Posted 6 months ago | Permalink
Someone (think it was Justin) mentioned comment_type earlier. Hoping this gets addressed in the not-to-distant future by the WP core devs.

Much like post_type has been around for a while, so has comment_type (even though it's not even possible to new register ones... yet). It's part of the WP database. The defaults are comment, trackback and pingback.

Adding to the idea of using comments for any type of form, exposing this functionality could allow the core WP comments system to be used for any of the following:
1. User review system.
2. Support ticket system.
3. Aggregator for data related to the "post".
4. A mini-twitter conversation focused around a targeted topic.
5. User Photo/Video sharing.
6. Submission method for running contests.
This is getting way ahead of where WP currently is, but it's interesting to think about. That said, can't wait for all that 3.0 is expected to bring and thanks to everyone for keeping this discussion going.

Reply

You must log in to post.

Plugin idea: custom post_type + editor

Reply

Topic Info

Topic Tags: