One of the things I hope to bring to both the ThemeForest as well as the entire WordPress community is a set of standard content type plugins to allow theme developers to build from.

When I say “content types”, I’m referring to plugins that handle custom post types, taxonomies, and post meta. Each plugin would be different depending on the scenario. For example, I’m currently building a base portfolio plugin, which will include both a post type and taxonomy for handling portfolios. Theme developers will be able to support this plugin just like BuddyPress, bbPress, WooCommerce, and so on.

With that in mind, here’s some questions for you all:

What post types are you seeing used often?

What taxonomies should go with those post types?

What post meta or other fields should go with the post types?

Right now, I’m just rounding up ideas so that I can see which direction to go next. I welcome any and all feedback on what should be included within the plugins.

Note: Let’s please not turn this into a discussion on what belongs in a theme vs. a plugin. We already have a thread for that.

greenshady said
Why would you not include meta fields? I’m thinking “date” and “URL” are definitely fields that are needed for portfolios. I honestly haven’t done too much work in this space though.

Often used post types can be ‘standartized’, but the fields which go with those types – not.
You cannot cover all the fields that MIGHT be needed for a custom theme. What then? Should I hack plugins source code trying to extend it? Or should I use another plugin to add some custom meta boxes? Maybe I should code them myself? And what about removal of those fields? Again, that would create even bigger mess.

greenshady said
Why would you not include meta fields? I’m thinking “date” and “URL” are definitely fields that are needed for portfolios. I honestly haven’t done too much work in this space though.

Often used post types can be ‘standartized’, but the fields which go with those types – not.
You cannot cover all the fields that MIGHT be needed for a custom theme. What then? Should I hack plugins source code trying to extend it? Or should I use another plugin to add some custom meta boxes? Maybe I should code them myself? And what about removal of those fields? Again, that would create even bigger mess.

I guess the “standard” plugin should be extensible. A base meta field set can and should exist as @greenshady said an URL and date are more or less common.

Then if an author needs to add custom fields he can do that via the action system?

BTW as I am only starting with theme development (although I am a “seasoned” developer) so I guess am some sort of a “clean slate” and I was totally excited with the mentioned CPT thread and I totally welcome and support this movement!

@greenshady if you post the github link once you setup this plugin I would be more then glad to help if I can!

greenshady said
Why would you not include meta fields? I’m thinking “date” and “URL” are definitely fields that are needed for portfolios. I honestly haven’t done too much work in this space though.

Often used post types can be ‘standartized’, but the fields which go with those types – not. You cannot cover all the fields that MIGHT be needed for a custom theme. What then? ...

True there is a wide array of custom fields that could be used with a portfolio CPT so why not include a large set of them, then provide an easy way for the theme to enable or disable the use of certain fields as needed? That way maybe 90% of portfolio themes will find the fields they need. The other 10% could then propose/contribute additional custom fields as needed. Yeah?

True there is a wide array of custom fields that could be used with a portfolio CPT so why not include a large set of them, then provide an easy way for the theme to enable or disable the use of certain fields as needed? That way maybe 90% of portfolio themes will find the fields they need. The other 10% could then propose/contribute additional custom fields as needed. Yeah?

That’d be pretty simple to do with the “post-type-supports” functionality or even tying into the “theme-supports” functionality. It’d just depends on the fields. We just need the ideas for the moment; I’ll be able to handle the implementation in an easy-to-modify way.