As many of you know, this past week Syed Balkhi attended WordCamp Raleigh 2012. During the event, one of his tweets sparked quite a debate. In this article, our founder Syed Balkhi will debate whether WordPress Custom Post Types belong in functions.php file or in plugins. Below is a tweet that started this debate:
— WordPress Beginner (@wpbeginner) November 4, 2012
After the tweet, many reputable folks in the WordPress community chimed in. You can see the full conversation here. Curtis McHale took it one step further and elaborated on the topic in his new blog post.
The conversation from twitter brought up some great points.
Summary of Arguments
Plugins argument: The user will always have the data even if they change the theme. It might not look as pretty, but it will stay there.
Functions.php Argument: Data without design would be irrelevant. It will confuse users even more.
Which side do you agree with more? Clearly both sides have their issues, but which is the lesser of two evils?
Here is why we believe that Custom Post Types should ALWAYS live in a site-specific plugin or a separate plugin altogether.
Long Live Data
Custom Post Types are data. In most cases, your data will outlive the current design. Having changed our themes a few times, we understand that statement clearly. Posts, Pages, Links, Attachments, and Revisions are all types of post types that comes built-in with WordPress. On top of that, we have post types like Books, Testimonials, Deals, etc. Now could you imagine if we change a theme and have all these vanish? Surely, we wouldn’t want that to happen.
Having developers in our team, this shouldn’t matter much. Considering all of our themes are custom designed by our team, what difference does it really make? The secret lies in two words: time and centralization. As long as we have all the necessary data, all we would have to do in the future is change the styling. We won’t have to worry about copying and pasting the functions from one file to another every single time. What if you want to replicate the functionality? Simply take the plugin and drop it in your new site. Change the styling, and you are done.
Rules and Standards
When you use the word ALWAYS like we did in our tweet, it can mean both rule and standards. Both rules and standards are made for the majority. There will always be special case scenarios where rules are bent and standards are broken, but that doesn’t mean we should get rid of standards altogether.
There are tons of generic post types that mostly requires the same set of additional meta fields. Some examples that come to mind would be: Quotes, Books, Recipe, Testimonials, Portfolio, etc.
Considering the large number of photography and portfolio themes that are available in the free and commercial market, it makes almost no sense to make the user re-enter all of their custom post type information every time they change a theme. Let’s take a look at an example case scenario:
Photographer – User setup a WordPress which has a blog functionality (default “post” CPT). He wants to add a portfolio of his work (requires a Portfolio CPT). He wants to show client testimonials (requires a Testimonial CPT). All of this information is surely going to live past a theme design. A year later, the user wants to change the look of his site and give it a refresh. Finds a new theme that has all the similar functions. The moment he switches the theme, BOOM. All the previous data that he entered has vanished. There is a menu called Portfolio, and a menu called Testimonials however none of the data is there. User’s thinks “HOLY CRAP, I lost all my content”. Creates a new support questions in the forum. Sends emails to sites like WPBeginner etc. If they receive no good response, they will have to re-enter all the data. This is a crappy user experience.
So how do we solve this issue?
We create a new standard base. Justin Tadlock already started working on this issue a while back by creating a base portfolio plugin. Is it going to be the perfect solution for everyone? NO, but it will be for the majority.
As Justin asks in his post, what standard fields should be included in the portfolio plugin (referring to post meta). This type of conversation needs to happen among developers who are creating similar functionality in their themes. Why copy and paste the same thing over and over from one theme to another when it can be done via a plugin? Once it becomes a standard, other themes authors will begin to adapt to it.
There are some robust WordPress themes which comes loaded with functionality which we believe should be plugins. Job Board themes, Issue Tracking themes, Classified Ads theme, Real Estate Themes, etc. They should all be powered by a base plugin. It is already happening with WooCommerce. WooThemes have released numerous themes that have built-in styling support for the plugin. Other theme companies have promised to release WooCommerce based eCommerce themes as well. You can switch from one theme to another and keep all your products as is. That’s almost like the theme changed but everything just fell right in place. That’s the theme changing experience we need to strive for.
Why not do the same thing with Portfolio, Testimonials, and other generic custom post types? Is it because it’s too simple vs. eCommerce is a bigger beast to conquer? Clearly, eCommerce has far too many fields compared to the other ones, so it should be much easier for these generic post types. It is just a matter of making a conscious effort toward making things better.
Take a look at ReciPress plugin. It creates a custom metabox with recipe fields and attaches it with posts. However it is possible to attach it with custom post types. Anyone using this plugin can change themes without having to go through such a hassle.
It would be nice to see themes like AgentPress be powered by a centralized base plugin. It would be great to see the transition of changing themes become easier. For example, if a user switch from one photography theme to another, it shouldn’t be chaos. Minor errors might happen, but at least in the bigger picture, things will work.
You can always give examples of super customized post types created for one-time client usage, but that is the exception not the rule.
What do you guys think about this topic? Where should the custom post types code reside? In the functions.php file or in plugins?