Goal of standard content types

[grappler]

I have read the Reasons for a standard but I still see a few issues.

@reidpeifer brought up some interesting points in his https://github.com/justintadlock/content-type-standards/issues/4#issuecomment-50567713

Here are some points that I feel need to addressed.

1. What happens when two plugins with the same cpt are activated at the same time?
2. Some plugins may have the same cpt but are for different purposes. e.g WooCommerce and EDD. Do we define a standard for every meta data that is needed?
3. How does this affect the freedom to implement things differently? There was a discussion about location data. One plugin might think a location cpt is better, where another might say a taxonomy is better and the third a custom meta data.
4. How much demand is there to be able to switch plugins? We see in some fields (e.g Multilingual plugins) they have already created import/export plugins. Normally people test the plugins before entering all of their data.
5. How does this help theme authors? As a theme developer I normally just style the markup of the plugin to match the theme. Every plugin will have a different markup. It is not feasible to create your own template and pull the standard data as like in point nr. 2 WooCommerce and EDD for two different purposes.

[slimndap]

Regarding 4: Another benefit of portability is that you can seperate importer plugins from the main plugin. For example: you can import events from a ticketing system and have them show up in any of the event plugins that use the standardized post types. I guess the same goes for webshops and their backoffice.

[grappler]

@slimndap That is an interesting point. What I meant by importer plugins was something like this https://wordpress.org/plugins/wpml-to-polylang/

[justintadlock]

What happens when two plugins with the same cpt are activated at the same time?

I can't imagine that would happen often. I don't know what would actually happen because I've never tried it.

Some plugins may have the same cpt but are for different purposes. e.g WooCommerce and EDD. Do we define a standard for every meta data that is needed?

I think it's good to lay down some common stuff right now that folks can agree on rather than covering every possible detail.

How does this affect the freedom to implement things differently? There was a discussion about location data. One plugin might think a location cpt is better, where another might say a taxonomy is better and the third a custom meta data.

Locations can be any of those things in certain contexts. Most users aren't going to be installing multiple plugins like this with multiple ways of handling locations. I think it's more important to consider real-world usage.

How much demand is there to be able to switch plugins? We see in some fields (e.g Multilingual plugins) they have already created import/export plugins. Normally people test the plugins before entering all of their data.

Not sure about the demand to switch plugins, but we all know that some plugins die out for various reasons. Import/Export plugins are good and will probably be built as needed by people.

You'd be surprised how few people really test plugins before entering their data. I've seen many users over the last few years coming from other WP theme companies with basically a year's or more work wasted because they got stuck into a system that's too specific to a certain theme (whether built into a theme or a plugin that's tied directly to the theme).

How does this help theme authors? As a theme developer I normally just style the markup of the plugin to match the theme.

Ultimately, the big help for theme authors is to push them to get away from this idea of building in-house plugins and/or packaging their CPTs into their themes while moving to one of the available plugins out there. The more theme authors start supporting third-party plugins, the closer we come to weeding out some of the plugins that aren't going to compete and having one or two major plugins in a certain space that are well supported (e.g., WooCommerce, bbPress, BuddyPress).

[thatryan]

What about dependencies, will that be left up to the theme/plugin author?

Example, the slider post type. This will obviously require a script to be of any use, and there any any number of ones that could be employed. One of the most popular among devs being flexslider and another I recently found is unslider.

Would it be beneficial to endorse scripts that may be helpful or best choices?

On that note as well, if one of the goals here is to create a jumping off point, perhaps CPTs that require extras could have a submodule link to the git repo for the script or what not?

[justintadlock]

I think we're getting way too far ahead of ourselves right now. This project should be implementation-agnostic. The goal of this project is mainly about setting some naming standards. Anything beyond that is probably outside the scope of the project.

[chryton]

@justintadlock I agree. @thatryan I think the entire goal of this is to be as implementation agnostic as possible. We are talking about setting standards for the data we store and can retrieve. I think how you would manipulate the data is secondary past how items should stored/returned (like the discussion in #3).

Portability, modularity, and customizability are the name of the game here.

[michaeldcain]

How does this help theme authors? As a theme developer I normally just style the markup of the plugin to match the theme.

@grappler, markup isn't a requirement of a CPT plugin (especially the more simple ones like portfolios and testimonials). Most, if not all, of the display of the data should be handled by themes using the template hierarchy and/or custom queries and custom page templates. Standardizing the post type will give theme developers a finite number of items to query against. For instance, instead of having to chose to create a page template in my theme that queries specifically for jetpack-portfolio or random-plugin-project, I can query the standardized portfolio_project and let the user decide which portfolio plugin to use.

[grappler]

@michaeldcain I am not sure that theme would be then allowed in the WordPress.org Theme Repository as the page template would not work without the installation of a portfolio plugin. The place where it could be useful is for cpt templates like archive-jetpack-portfolio.php. The problem I see is that every portfolio plugin will have different meta data and thus you will need to provide support for each plugin.

Somehow I cannot see it working but I might be just missing something.

[michaeldcain]

The problem I see is that every portfolio plugin will have different meta data and thus you will need to provide support for each plugin.

Meta data standardization is being discussed for each custom post type.

I am not sure that theme would be then allowed in the WordPress.org Theme Repository as the page template would not work without the installation of a portfolio plugin.

I might not have been clear, but I was talking about custom page templates, not page.php. Plenty of themes are approved in the repo with support for plugins like WooCommerce. They don't require the plugins to be used as themes, just are made better with their inclusion.

[justintadlock]

I am not sure that theme would be then allowed in the WordPress.org Theme Repository as the page template would not work without the installation of a portfolio plugin.

It would absolutely be allowed on WordPress.org. As a TRT admin, I can tell you that for sure.

The place where it could be useful is for cpt templates like archive-jetpack-portfolio.php. The problem I see is that every portfolio plugin will have different meta data and thus you will need to provide support for each plugin.

The purpose of this project is to standardize things like metadata.

Edit: Themes don't necessarily have to support multiple plugins either. That's a rather lofty goal that I'd love to see happen if possible, but it's not something I'd try to force on theme authors. I believe that as we settle into some standards, a few plugins that compete in the same space will eventually become dominant, making it easier for theme authors to adapt their themes to specific plugins.

[grappler]

It would absolutely be allowed on WordPress.org. As a TRT admin, I can tell you that for sure. So I can make a page template that only works when a certain plugin is installed.

Why do we need multiple portfolio plugins if both use the same cpt and metadata? What happens when as a plugin developer one wants to add a new metadata, would it need to be added to the list of standard metadata?

[michaeldcain]

Why do we need multiple portfolio plugins if both use the same cpt and metadata?

It's not that we're supporting having multiple plugins with the same CPT and metadata active at the same time, it's creating a theme that out of the box can support the user's choice of plugin.

[michaeldcain]

What happens when as a plugin developer one wants to add a new metadata, would it need to be added to the list of standard metadata?

As part of the standardization discussions, we're defining 'basic' vs 'edge case' metadata examples. Standardization can never account for all of the different use cases, just the most common.

[justintadlock]

So I can make a page template that only works when a certain plugin is installed.

This isn't really the place for discussing TRT stuff, but I don't see why not. Ideally, a theme would filter the theme_page_templates hook to remove that template if the plugin isn't active.

Why do we need multiple portfolio plugins if both use the same cpt and metadata?

Post types are really not about registration. That's all this project deals with. It's nice to have shared data.

However, the really cool stuff comes with implementation. If you give that some thought, you'll understand exactly why competing plugins is a really good thing.

What happens when as a plugin developer one wants to add a new metadata, would it need to be added to the list of standard metadata?

A plugin author can propose new metadata for the standard. We, as a community, can decide if it should become a part of the standard.

It's going to be next to impossible to standardize every use case in existence. We know this up front, so we're going to attempt to standardize what we can.

[grappler]

However, the really cool stuff comes with implementation.

I look forward to see how your and Devin's plugin will compare once they have been standardized.

@justintadlock & @michaeldcain Thank you for explaining the points to me. :smile:

[michaeldcain]

np. I'm glad that we're defining the purpose for others that might have questions.