Is anyone still watching this thread? A little late to the discussion, but I’ve read every post here and wanted to let this simmer before deciding what my opinions are.

Intro

Most of you don’t know me, so an introduction of sorts: I come at this w/ a 20+ yr programming background (30+ if you count those years I coded as a hobby, unprofessionally). I’ve seen, used and created all sorts of systems along the way, both good and bad. I’m relatively new to the TF scene, so I come with an outsider’s perspective. I’ve done several client sites in WP (starting about 3 yrs ago), and although I’m not necessarily familiar with the standards and practices of the WP community at large, I am intimately familiar with most, but admittedly not all, of the WP core.

Review

So, as I understand it, the discussion is basically about whether certain functionality should be done in themes or plugins in an effort to maintain data portability when switching from theme to theme. And we’re using 2 scenarios to discuss this: shortcodes and Custom Post Types (CPTs).

So, first, shortcodes…

The problem here is that themes typically define their own shortcodes and when someone switches themes, they run the risk of losing the way those shortcodes are displayed if the new theme doesn’t support the same shortcodes.

Some suggest the solution be that we have a standard plugin to handle shortcodes for all themes. Others say that solution isn’t practical because such a plugin would have to rely on guaranteed styles and frameworks to be in the theme which is an impossibility.

I would argue that WP doesn’t need a standard plugin to handle shortcodes. What WP needs is a standard list of shortcodes that all themes support. (And yes, ONE column shortcode, not dozens.)

The plugin that Justin did is a great attempt at a solution, but I would argue that shortcodes shouldn’t have to have implementation data in them (e.g. grid size). You diminish the strength and power of a shortcode by requiring that the user know something about the implementation of the theme.

I think the energy and effort should be in coming up with a standard list of shortcodes and attributes for them that we can all use in our themes. All of this, though, with the understanding that there may be some things in some themes that require a special-case shortcode or attribute that may not be part of the standard. And that’s okay.

Themes shouldn’t necessarily be bound by this list, but it would be best practice to support the standard list of shortcodes. And if one shortcode doesn’t make sense for your theme, the theme should still provide a way so it fails gracefully without spilling shortcode data all over the place.

Maybe ThemeForest could even provide a nice little icon for themes that support the standard shortcode list. They could add it to their review process by adding a simple plugin that checks for support of all the standard shortcodes.

On to CPTs…

Again, the major concern here seems to be about users losing data. If a theme uses a CPT and then the user switches themes, they may lose access to those posts entered under the CPT . Again, it seems to be about about data portability. Let me know if I’m missing something important.

Some say that adding functionality isn’t something that should be done in a theme. I would like to point out that using CPTs isn’t adding functionality. It’s just changing the UI. All the functionality is already there in the core. The only thing that separates a CPT post from a “normal” post is one field in the DB.

Also, CPTs don’t disappear when you switch themes, they just aren’t flagged as posts. So, change that DB field back to “post” and you instantly have access to all of your previous CPT content under the Posts section. Problem solved.

The simplest solution would be for a theme that uses CPTs to provide a utility under the “Tools” section to revert CPTs back to normal posts. Or, we create a standard plugin to manage CPTs, if someone hasn’t already created one.

Let’s not get too overzealous

By saying that themes shouldn’t use CPTs, it feels like clipping WordPress at the knees. That functionality is there for a reason. It’s so theme authors can use it. If a problem arises by us using CPTs, then let’s work toward a solution rather than saying don’t use the feature.

As to ThemeForest’s Street Cred

The thing I like about ThemeForest is that, as I see it, they don’t necessarily sell WordPress themes, they sell sites that happen to use WordPress as a backend. That’s a huge distinction, and I think it’s totally valid. As a TF customer, I’m not interested in buying a WordPress theme. I’m interested in buying a site.

Sure, there’s some horrible code in some of the themes on TF and it would be nice if every theme conformed to more of the WP standards, but overall, Themeforest is pushing the WordPress envelope. They are responding to the desires of the marketplace, and as we all (should) know, the customer is always right.

I understand the desire to code for standards, but sometimes standards can hold you back and get in the way of progress and innovation. Like the 37 Signals’ philosophy: design for what exists now, not for what might exist in the future.

I just hope TF puts in some real, deep thought before they go changing their review process. My concern is that there seem to be factions of people who want to be very authoritarian about how WP is used and not used. And I think that’s a detriment to the overall community and to the future of WP. You have to allow for growth, and sometimes the cutting edge cuts.

dyspersion said
I would argue that WP doesn’t need a standard plugin to handle shortcodes. What WP needs is a standard list of shortcodes that all themes support.

I couldn’t disagree more. Shortcodes are a great example of why they should be put in plugins and not in themes. There are shortcode plugins in the WordPress directory that ship with default styles set up. Some of the smarter, IMO , plugins even allow you to supply your own stylesheet in place of the plugin-supplied css file in the event you’d like to have complete control over how the shortcodes are styled. IMO that’s the superior approach. Themes can offer a custom, integrated look, but if/when the user changes themes, if built-in support is not included in the new theme, the plugin would revert to its base CSS . That way the shortcodes still work and the user doesn’t have posts and pages litered with broken shortcodes.

dyspersion said
I would like to point out that using CPTs isn’t adding functionality.

Tell that to e-commerce plugins.

dyspersion said
they just aren’t flagged as posts. So, change that DB field back to “post” and you instantly have access to all of your previous CPT content under the Posts section. Problem solved.

The problem isn’t solved by that method though… it’s actually made more complicated because now you have “staff” or “FAQs” or “products” mixed in with “posts”. And if there’s custom meta data or taxonomies with those items, now that’s all mixed in as well.

dyspersion said
By saying that themes shouldn’t use CPTs, it feels like clipping WordPress at the knees. That functionality is there for a reason.

WordPress is powerful and extensible enough that a plugin could be written to behave like a theme and vice versa. Just because a theme author can add CPTs doesn’t mean they should.

Content is content and style is style. The parts of WordPress supplying the content should largely be kept separate from the parts of WordPress supplying the style. You’d be hard-pressed to find even an edge case in which a compelling argument could be made to support a theme author supplying a CPT , especially one which is visible from the front end of the site.

Thanks for your thoughtful reply! With enough thought and “hashing it out”, I think we can all come up with a decent solution!

arconix said
...Some of the smarter, IMO , plugins even allow you to supply your own stylesheet in place of the plugin-supplied css file in the event you’d like to have complete control over how the shortcodes are styled.

Better, better, but still doesn’t handle the code differences necessary for themes using different css/html frameworks. The only way you can get that is at the theme-level, so shortcodes have be in the theme. I don’t see any way around that.

Let me at ‘em, let me at ‘em! E-Commerce plugins most likely add tables to the DB. That’s adding functionality and new content types. CPTs don’t and just reuse the existing post features.

arconix said
...because now you have “staff” or “FAQs” or “products” mixed in with “posts”.

Well, most themes are “solving” this problem now by having everything be under posts anyway, so that’s no different. Just offer an option to make CPTs a certain category when you move them. Same thing.

arconix said
And if there’s custom meta data or taxonomies with those items, now that’s all mixed in as well.

I don’t see a problem there. What’s the downside?

arconix said
Content is content and style is style. The parts of WordPress supplying the content should largely be kept separate from the parts of WordPress supplying the style.

Yes, I agree. And CPTs are just a tweak of the UI, which is just changing how the content is styled. Perfectly okay in a theme, IMHO .

arconix said
You’d be hard-pressed to find even an edge case in which a compelling argument could be made to support a theme author supplying a CPT , especially one which is visible from the front end of the site.

I honestly don’t see why there’s such resistance. It’s not adding functionality. There are no new tables in the DB or anything like that. You’re just tweaking how posts are shown to the user which everyone already does with meta boxes, etc.

I would like to point out that using CPTs isn’t adding functionality. It’s just changing the UI. All the functionality is already there in the core. The only thing that separates a CPT post from a “normal” post is one field in the DB.

When it comes to registration, that is true. However, custom post types aren’t really about registration; they’re about implementation. CPTs typically rely heavily on custom functionality. That one field in the database is largely irrelevant.

If you’re just registering a “type” and not doing anything else, you might as well not be registering it all. Just use posts. If you’re doing it for the UI, that’s not what custom post types were meant for.

greenshady said
When it comes to registration, that is true. However, custom post types aren’t really about registration; they’re about implementation.

I’m not sure I follow you here. Custom Post Types are by definition posts that are of a custom type. I don’t see them as being meant to represent something overly complex. They’re still posts and act like, and are represented in the DB as posts, because they are, in fact, posts. The implementation is largely already defined by how the core handles posts.

If you’re implementing a completely new type of content that’s not a post, then I wouldn’t expect that you’d use CPTs.

greenshady said
CPTs typically rely heavily on custom functionality. That one field in the database is largely irrelevant.

Not sure I follow you. Give me some examples so I can see the distinction to which you’re referring.

greenshady said
If you’re just registering a “type” and not doing anything else, you might as well not be registering it all. Just use posts.

Then why is the option there to do that? If I just wanted posts, I’d just use posts. But, my users benefit from having their content represented in different sections in the admin. Enter CPTs.

greenshady said
If you’re doing it for the UI, that’s not what custom post types were meant for.

What were they meant for? What am I missing?

Thanks for providing some perspective and helping me get my head around this!
Scott

It’d probably help if you thought of CPTs as “custom objects” rather than having anything to do with posts. I think this is where a lot of people get hung up on the idea of CPTs.

Also, when we’re referring to CPTs, we’re not usually just talking about the “posts” themselves. We’re talking about an entire system. Generally, CPTs are part of a system built onto WordPress.

The implementation is largely already defined by how the core handles posts.

WordPress has some standard fields that are available for use, of course. And, you can certainly do things that way if you want.

But, the implementation is defined by the “system” that the developer is building. WordPress just gives you the ability to register a CPT and use a few of its built-in features.

The reason CPTs are in the “wp_posts” table at all is for standardization. It’s easier for WordPress to have some built-in support for such things rather than plugin developers building their own tables. This also allows plugin (and theme) developers to use the built-in APIs for getting data.

If you’re implementing a completely new type of content that’s not a post, then I wouldn’t expect that you’d use CPTs.

That’s precisely what the CPT system was created for. I’m sure I could pull up a few of the original dev conversations if I dug around for them.

Not sure I follow you. Give me some examples so I can see the distinction to which you’re referring.

WordPress’ built-in nav menu system. It’s built with a unique post type, taxonomy, and metadata. It would not work without custom implementation with tons of custom functionality.

dyspersion said
They are responding to the desires of the marketplace, and as we all (should) know, the customer is always right.

I actually do not agree with this. The customer is right, yes, but what they want has been dramatically shaped by what we think they want. Customers have gotten used to the idea of having tons of short codes and theme options, so that’s what they think they want. Most of them rarely, if ever, actually utilize all of these features.

Mike McAlister wrote a really good editorial on the subject. As developers and designers releasing products into the market, we need to do a better job of producing themes and plugins that help educate customers to what really is good, as compared to what seems good.

scenario: An author adds some custom post types/shortcodes to a plugin with default styling that should work on all the themes + custom css code for integration with his own themes.

Le nice buyer gets the theme, configures it but decides to use another free theme developed by a bad coder. If some of the functionality won’t work correctly because that theme was poorly coded, who’s gonna offer support to the user? If he will ask the developer of the theme, he can easily say “I don’t offer support for anything else than what you get by default”, while the developer is not responsible at all for solving the issues of other themes.

Theme users run into that problem every day with poorly-coded themes. The shortcode/CPT thing is really irrelevant with that. The truth is that the theme user is just out of luck, but that’s the chance you take when you use open-source software.

If I were the plugin developer, I’d offer support to the user (and, yes, I do this). Of course, my entire business is built around support. I also like to keep my customers around by offering them a great service, even when they switch themes.

Post Reply

<strong></strong> to make things bold
<em></em> to emphasize
<ul><li> or <ol><li> to make lists
<h3> or <h4> to make headings
<pre></pre> for code blocks
<code></code> for a few words of code
<a></a> for links
<img> to paste in an image (it'll need to be hosted somewhere else though)
<blockquote></blockquote> to quote somebody