Plugin idea: custom post_type + editor

Jan Egbert (Member)
Posted 4 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 4 months ago | Permalink

Well, there was a patch for a custom post type UI in 2.9, but it's not going to be committed to the next release. It would work just like custom taxonomies in 2.8 — register the post type and it automatically appears.

I think we'll likely see this in 3.0, so I'm not sure if there should be a plugin just yet. It's something I've been debating over.

To me, this plugin shouldn't just be about post types. It should be about content management. There should be a simple UI for creating both custom post types and taxonomies. They're both so intricately linked together that a plugin like this should definitely handle both.

A custom post type and taxonomy plugin is something I'd consider creating. While I can make no guarantees that I'll do it, I'm open to suggestions on how everything should work.
Justin Tadlock (Key Master)
Posted 4 months ago | Permalink

Existing plugins doing this job in a "wrong" way:

I should probably clarify a bit. What is meant here is that these plugins don't do things the WordPress way, which I think is a bad decision, especially for future compatibility.

Custom post types (i.e., content types) should use the wp_posts table for adding new "posts" (event, movie, book, whatever). The groundwork for this has been in WP for a long time. In fact, WP has several different default post types: post, page, attachment, revision.

While the plugins mentioned may be great tools, I can't stand behind something that doesn't use the available WP functionality.
Jan Egbert (Member)
Posted 4 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 4 months ago | Permalink

I don't think register_post_type() is going to do much other than registering it with WordPress. It wouldn't create a new DB table anyway. Once you wrote a new "post", that entry would be given the post_type of whatever you registered. But, without the UI, it's pretty much useless for most users.

The big thing happening in 2.9 is that the groundwork is being put down for custom post types. Most of the groundwork has been there, but there's been some "bugs" that needed to be cleared up.

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.

I like the simplicity of it. ;) I'm more of a fan of "Content Manager" though. To me, it'd be something that controlled post types, taxonomies, meta boxes, and maybe even forms (see below).

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)

I'm not sure how GF saves its forms, but I think an argument could be made that forms should have their own post type. Then, each entry into the form would use the already built-in comments system to be saved in the database. Using shortcodes, one could theoretically create any type of form imaginable.

Plus, using a custom post type would open forms up for easy integration with custom meta boxes and taxonomies.

3. The ability to add metaboxes

Definitely.

4. Integration with Members and Query Posts

Query Posts will be getting integration soon. I'm waiting to see if they still implement capability_type with the register_post_type() for Members before adding anything new. But, Members will always be integrated as it is now.
Patrick Daly (Member)
Posted 3 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 3 months ago | Permalink

See this ticket:
http://core.trac.wordpress.org/ticket/9674

It looks like the UI is getting pushed back to early 3.0.
dwenaus (Member)
Posted 3 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 3 months ago | Permalink

Whether it's a simple post type setup or a complex setup, I'd use post types as they're done in WordPress. If you're creating new tables and writing all your own functions, you have to:

* Make sure it works within the WP environment completely with each update. Using WP's post types will be completely forward compatible, especially once WP 3.0 hits and the rest of the post type stuff is added.

* Introduce users to a new system of doing things.

* Get theme and plugin devs behind you, which is doubtful and will leave your plugin's functionality solely within the hands of your plugin. Using WP's methods, you'll allow other devs to use your stuff without ever having to look at your plugin.

I think that last point is the most important. For example, my Query Posts widget will check available post types in WordPress and allow users to display those "posts" based on those post types. This is mostly in line with being able to use WP's functions.

Also, the Hybrid theme (not current version) will allow custom post templates for each post type like what you can currently do with page templates.
dwenaus (Member)
Posted 3 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 3 months ago | Permalink

Matt and the other core devs don't seem to think performance will be an issue, so I'm going to trust their judgment a bit here.

Also, I'm not sure I understand how a plugin that uses its own table could break when new versions come out.

Most plugins that I've ever seen break with WP updates are not using the proper WP functions. Nevertheless, I didn't say it'd break. I simply said you'd need to make sure it works.

isn't it more likely to break when pushing post types to the limit.

Have you ever pushed posts ("post" post type) to the limit before?

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?

Structurally, post types have been a part of WordPress for a long time. For example, we already have several post types: posts, pages, attachments, and revisions. WP 2.9 is mostly about making many of the functions work correctly with custom types. WP 3.0 will add the UI.

I'd start with 2.9.
designOdyssey (Member)
Posted 2 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 2 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 2 months ago | Permalink
I think you're confusing two different concepts. One is a type of content. The other is how you label or "categorize" that content.

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.
What can you do with categories/taxonomies of posts that you can't do with custom post types?
- Create a term description.
- Label something across multiple post types.
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."

A huge part of WP 2.9 is making it possible for plugins to be post-type aware. I've got a post coming up on my blog that I hope catches the attention of some of those plugin authors that need to know this.

WP 2.9 has been a lot about adding a solid foundation for new post types. Easily using them will be more of a 3.0 feature.

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?

As far as I know, nothing is changing here. Everything will be saved in wp_posts and wp_postmeta just like we've always had with custom post types.
designOdyssey (Member)
Posted 2 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 2 months ago | Permalink

If you're looking for a way to group something, then a taxonomy is probably what you want to use.

Let me propose some questions: 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 understand where you're coming from though. I'm stuck in a similar situation on two of my sites where I'm having to use the "post" post type when I should be using a custom post type. The platform just isn't ready and won't be until 3.0.
designOdyssey (Member)
Posted 2 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 2 months ago | Permalink

When custom post types are fully supported in 3.0, I imagine they'll behave like posts by default. There'll be some generic functions for handling certain things. But, functionality is something best left to plugin developers (such as the differences between posts, pages, and attachments).

For the most part, I think people will use post types for the nomenclature but not truly experiment with them, which goes back to your original point of not having a difference between a category and a post type.

Personally, I have a few things I'd love to do with custom post types that's outside the default "post" functionality.
Justin Tadlock (Key Master)
Posted 2 months ago | Permalink

Something I wanted to point out about this:

Because there are numerous plugins that seem to rely on the "post" post_type.

WordPress, prior to 2.9, had a lot of things set in stone concerning post types. That's why most plugins don't offer configuration based on custom post types — it simply wasn't possible without WP screwing it up.
Justin Tadlock (Key Master)
Posted 1 month ago | Permalink

A little something I've been playing around with for my blog home page:
http://justintadlock.com/blog/wp-content/uploads/2010/01/future-jt-home.png
Jan Egbert (Member)
Posted 1 month 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 1 month ago | Permalink

It should be extremely simple. If you're running WP trunk right now, it's easy to create custom post types. There's some things that still need to be fleshed out, but most of the functionality is already in there.

Of course, I'll probably be writing a tutorial (or several) covering how to make use of them.
Patrick Daly (Member)
Posted 1 month 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 1 month ago | Permalink

Might as well make this the first tutorial:
http://justintadlock.com/archives/2010/02/02/showing-custom-post-types-on-your-home-blog-page

No custom query required. Check out the tutorial.
Joel (Member)
Posted 1 week 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: