Custom post types vs post formats : future-proofing – is one less “future proof” than another?

I’m faced with the following guideline for a contracting job.

Post Type vs. Post Format

Avoid custom Post Types and embrace Post Formats! Post formats are supported by WordPress core, and are already activated in the Starter
Theme. You can assign unique styles, formatting and function to post
formats. If the client switches themes in the future, WordPress will
still recognize the formats you have invoked as long as they are
activated in the function sheet of the next theme.

Post Types need to be registered in the functions file of your theme and will not be as easily transferable when the time comes for a new
theme to be activated. In most cases, the need to create a post with
multiple key values and functions can be satisfied by a dedicated post
format that makes use of custom fields, featured images, and so many
other functions already available through WordPress core.

Use your best judgement!”

While I understand the point, and that when building a website that plans on switching themes at the drop of a hat, that formats can be really useful – I’m having a hard time going through with it.

The website has pages, and an external API feed for what would probably normally be ‘posts.’ Then there are a few sections that loop through things like FAQs and food-menu items.

I currently have a custom post type for FAQ’s and Food-Menu items. The ‘posts’ are unlikely to be used, but I’m reserving them for a possible ‘blog’ or ‘news.’

What seems to be suggested, is that I just pick a format… like ‘aside’ and then use that as the FAQ’s – and then maybe – take ‘quote’ and use that for the menu items. Then – all the data would be under ‘posts’ which is suggested to be more future-friendly.

I don’t want to be a jerk and just go against the grain… but this seems much less intuitive. The client will have to go to ‘posts’ and then all the FAQs and Menu items will be all mixed up. Then if there is a News section later… they’ll be News, and FAQ, and Menu-items. The client will probably forget to check the formats and be confused – and have to call my contractor for help.

If you compare these 2 sentences (one from each case)

“If the client switches themes in the future, WordPress will
still recognize the {post}formats you have invoked as long as they are
activated in the function sheet of the next theme.”

and

Post Types need to be registered in the functions file of your theme and will not be as easily transferable when the time comes for a new
theme to be activated.

…then what is really the difference. Either way, a small block of code needs to be included – or neither of them will work.

It’s more likely that this data will be aggregated to a JS framework in the coming years than another WordPress theme ~ in which case the data is much messier in my eyes. I would Prefer the Custom Post Type when using the WP-API for say, an Ember App.

The custom-post-types as is – have no place in any ‘feed’ outside of this site. If I wanted FAQs in a feed – I may have used the post format ‘aside’ and a category.

If the site is built out with lots of Advanced Custom Fields – and is broken up into tons of partials – and built with stylus and concatenated bower components, and special functions, I don’t really see this in the world of sites that are just ‘theme – interchangeable’ anyways. Ensuring that a small block of code to register the Custom Post Type is the least of the worries. (It should be noted that in general I have not used WordPress with themes in mind – and only from scratch for very tailored sites.. I’ve never used a widget etc – so I may be ignorant of common practices)

I’m wondering if I should have just included 12 scripts in the head and written the css without a preprocessor? But that just seems rude… and wouldn’t make transferring to another theme easier…

In what cases would each respective style of splitting up site data be more future proof? Is there really any chance of Custom Post Types going away? I thought that the post formats were just a bonus for microblogging – and that most people were actually upset they made it into core.

I know this is on the edge of opinion, but it’s really not to me. I want to do what’s best – but it’s really hard for me to believe that an ungrammatical choice of a micro-bloging sub-format would be best.

The end users are often busy and they need a clear UI. Custom post types are a clear winner here. – But am I doing my client a disservice by “Using my best judgement” – and going to with Custom post types over Post formats?

Please give objective use-cases for each path.

Here are some thoughts on the subject:

Why Aren’t Post Formats In WordPress More Popular?

https://managewp.com/wordpress-post-formats-blogging

In IRC and other places I’m getting almost 100% ~ “If you are making FAQs – those are not posts, and should be Custom post types.” I’m getting “Don’t use the formats for this” ~ but not much proof that one is more future friendly than the other.

Take this pretend API URL though for example of how each would look:

http://somewebsite.com/cms/wp-json/wp/v2/faqs

vs


http://somewebsite.com/cms/wp-json/wp/v2/posts?format=aside&category=faq

My attempt to describe the 2:

• Post formats are for styling the post in certain scenarios and for
  micro-blogging when you want different post categorizations in a
  feed.

• Custom post types are for groups of data that are not posts.

BUT – is either less future proof… and if post-format is – is the post-format so much better – that I should forgo an intuitive interface for the user? – If so, I’ll do what’s right.

Post Type vs. Post Format

[1]Post formats are supported by WordPress core, [2]and are already activated in the Starter
Theme. [3]You can assign unique styles, formatting and function to post
formats. If the client switches themes in the future, WordPress will
still recognize the formats you have invoked as long as they are
activated in the function sheet of the next theme.

[4]Post Types need to be registered in the functions file of your theme and will not be as easily transferable when the time comes for a new
theme to be activated. [5]In most cases, the need to create a post with
multiple key values and functions can be satisfied by a dedicated post
format that makes use of custom fields, featured images, [1] and so many
other functions already available through WordPress core.

Use your best judgement!”

1. They are both in supported in WP core.
2. Not everyone will use the starter theme
3. Both can be styled and customized equally.
4. Both need to be registered in the functions file
5. Needs can be satisfied by post-formats, true – but no evidence to be ideal

All of these statements seem to cancel each side of the argument out.

The only caveat I could find:

From the docs: https://codex.wordpress.org/Post_Types

A word about custom post types as a plugin In order to avoid breaking
a site on theme switching, try to define custom post types as a
plugin, or, better as a Must Use Plugins. This way you won’t force
users into using a certain theme.

“Must use plugins”
https://codex.wordpress.org/Must_Use_Plugins

Felt like a ran a marathon, totally out of breath after reading your question.

As with these types of questions, there really is no wrong or right answer as most of it is based on opinions and not facts. There are few point here that we can concretely discuss

POINT 1

Post Types need to be registered in the functions file of your theme and will not be as easily transferable when the time comes for a new theme to be activated

Totally bull unfortunately. Custom post types and custom taxonomies should never be registered in a theme, it should always go into plugin. General rule of thumb, if anything gives functionality to the site and not the theme (which is the case here), it should go into a plugin. There have been a couple of posts done on this subject, make use of the site search for extra additional info. In short, custom post types and custom taxonomies should always be available even after a theme switch if it was correctly registered from a plugin

POINT 2

Avoid custom Post Types and embrace Post Formats! Post formats are supported by WordPress core, and are already activated in the Starter Theme

Both custom post types and post formats are supported by core, and in both cases they need to be registered/added before they can be used. So this point is totally overboard and should not even be deabateble. Yes, post formats are already part of the Starter Theme, but what about theme X when you switch to theme X.

POINT 3

The custom-post-types as is – have no place in any ‘feed’ outside of this site.

True and false. This is one of the reasons that I prefer custom post types, but let we not discuss opinion. By default, custom post types are excluded from the main query except on taxonomy and post type archive pages. This gives you much more control when and where and how to use custom post types. Adding custom post types to feeds, homepages, archive pages etc is as easy as adding a simple pre_get_posts action with the desired conditions, this can also be done in the same plugin as the one ussed to register your post type

Apart from that, you do have a lot of extra additional featured you can use to manipulate your post type and how it will be used in your site by just adjusting the values to the parameters in register_post_type() when you register the post type

POINT 4

I’m wondering if I should have just included 12 scripts in the head and written the css without a preprocessor?

Never ever do that. Always use the wp_register_scripts hook to add scipts and styles to the header and footer where necessary, never hardcode these directly in the head (or footer). I’m also never a big fan of manipulating impotant functionalities with client side languages and platforms. The issue is, anything that relies on client based functions can be manipulated by the end user. Cross browser compatibility is always an issue as well. Only use JS and CSS to manipulate the face value of a site (look and feel), never let it control how a site function. Use server side languages like PHP to control that.

POINT 5

Is there really any chance of Custom Post Types going away?

There is a definite 0% percent chance that custom post types and/or post formats will ever be removed from core. Just as an extra point, register_post_type() is used to register the default post types post and page and register_taxonomy() is used to register the default taxonomies category, post_tag, post_format and link_category.

It is very very rare that anything gets removed from core, depreciation happen regularly, but removal almost never. Take for instance the still wisely used parameters caller_get_posts and showposts. These should not be used anymore as of version 3.0, but people still use it. (turn debugging on and you will gt a clear notice on this). Imagine the core developers just removing this from core.

WordPress core is quite focused on backward compatibility (specially if a feature gets a huge upgrade and changes dramatically or a feature gets depreciated) which is quite a big advantage for non developers. As a developer, notices get added to depreciated functions/arguments/etc, that is why it is always advicable to enable debugging when developing.

To get back to the original point, you do not ever need to worry that custom post types or post formats will ever be removed from core

POINT 6

I thought that the post formats were just a bonus for microblogging – and that most people were actually upset they made it into core.

In short, post formats are just a bonus, a nice-to-have. This point can be debated over and over again, also the fact how useful it really is. It really comes down to peronal preference here whether it is useful to your project or not. I’m personally not a very big fan of post formats. I still prefer a custom post type or a custom taxonomy, depending on the project requirements, above post formats. One do have much more control with custom post types and custom taxonomies than with post formats.

One big issue with post formats are the fact standard is not a post format. It is simply some crappy fallback for posts that does not have a post format assigned. Altering any given loop is messy if you need to remove or only query posts without a post format.

POINT 7

Post formats are for styling the post in certain scenarios and for micro-blogging when you want different post categorizations in a feed.

Correct is most of what has been said. Post format does not necessarily needs to be resticted to micro blogging. You can use post formats or very large projects as well depending on the exact needs of the project. But again, how you use it exactly depends on your project and personal preference

Custom post types are for groups of data that are not posts.

Not true. Yes, they are groups of data in a sense as custom post types are used to do jus9t that, but it is incorrect to say that they are not posts. Pages are posts too, so are normal posts and any custom post type post. They are all treated exactly the same, the only real difference is hierarchy. Non hierarchical post type posts (like the build in post type post) cannot have child posts while hierarchical post types (like the build in post type page) can have child posts

CONCLUSION

Custom post types (and for that matter custom taxonomies) and post formats are here to stay. Whether which to use depends on the project at hand and what you are comfortable with. This requires careful planning beforehand. It is also very important to know how and where you should register/add functionlities to keep compatibility and useability when themes changes etc

What I have given is just a basic guideline and should be treated as such. I cannot go into much more detail as this will require a book. There are really a lot of info on-site and off-site that you should check out.

Good luck on your project