2

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:

http://wptavern.com/why-arent-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

  • Where does this info come from? Post Types need to be registered in the functions file of your theme and will not be as easily transferable. This statement is wrong in my opinion- post types are not a function of display and have no business in a theme. Put post type registration code in a plugin where it belongs and that issue immediately disappears. – Milo Sep 25 '15 at 23:17
  • The statement is in a set of guidelines for who I'm contracting with. I know they have good intentions. Maybe who wrote that is gone... and they just stick to it. There system is a giant multi-site - and so a plugin for each project I do may not be the right way to roll here... Any other advice? – sheriffderek Sep 26 '15 at 0:05
  • This really is opinion territory, there's no correct answer. Post types are certainly not ever going away, they're used by core. Abusing post formats for things that are not explicitly what the format itself describes is absolutely wrong. – Milo Sep 26 '15 at 0:13
  • Which to use could be opinion based, but the question "Is one less future-proof than the other?" seems objective to me. From what I gather, Post formats are for styling the post in certain scenarios and for micro-blogging when you want different post categorizations in a feed, and Custom post types are for groups of data that are not posts. I do not feel that a restaurants menu-item is an aside format of the standard post. The objective thing I guess is --- is either of these less future friendly? The subjective part is how do you perceive their uses and which would you choose. – sheriffderek Sep 26 '15 at 0:41
  • Please stop changing the goal of the question. We are going around in circles. I really do feel that you need to do much more research and then need to be very specific with what you really need when you do need to ask a question – Pieter Goosen Sep 26 '15 at 16:48
5

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

  • Thanks for taking the time. I clarified some things in my question. As in - "The custom-post-types as is - have no place..." I meant as I'm employing them and not in general etc... also #4 was really me just venting - and so I removed it. If you don't have access to add plugins, what would you suggest as a best practice? – sheriffderek Sep 26 '15 at 15:51
  • I really do not know what your issue is, if you really just need venting, please do it before asking a question. Reading from comments, we are going in circles as you keep changing the goal of the question. This is unfortunately not a discussion forum but a plain Q&A. I cannot add anything more to what I have said, there is no best practice. Please reread my answer – Pieter Goosen Sep 26 '15 at 16:43
  • Sorry if you feel that I'm not using SO properly. My issue is that I don't believe the argument for post-format over custom-post-type is valid and I'm curious if I'm missing something. I'm thankful for your input. The question as stated in the title hasn't changed. – sheriffderek Sep 26 '15 at 18:32
  • My issue is that I don't believe the argument for post-format over custom-post-type is valid Have you actually read my post?????? – Pieter Goosen Sep 26 '15 at 18:36
  • I have clearly read your post. I liked it. I'll probably mark it as the answer. I don't see what your issue is. / the argument I'm referring to is the one the whole post is about / not the one you've made. – sheriffderek Sep 26 '15 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.