I don’t think we have specifically discussed what should be the responsibility of themes vs plugins before, but I think it’d be an interesting and helpful discussion to have. So, splitting that part out from another thread:
Generally makes sense to me.
What about a theme that supports a portfolio custom post type and provides special templates for it? Shouldn’t the theme just go ahead and register this post type?
at this point… I’ve been following WordPress guidelines that has register_post_type as a plugin territory… and I always have a template file like single-portoflio.php or archive–portoflio.php that implements the post type…The problem is that the plugin would be a recommenation… without it… the templates won’t do anything.
If CP allows register_post_type as part of the theme… is totally up to u guys… i guess. i mean it would be a lot easier than havign to install a plugin whatsoever. but that’s just me.
Many themes come with a utility plugin these days. Extending core features like custom post types should be left inside that utility plugin (and have an option to disable it). And disabling utility plugin should not break the theme.
The one sidenote I have, as I was writing this, if themes do inclue utility plugins there must be some coordination between theme review team and plugin review team. So the utility plugin doesn’t violate any theme guidelines.
Right, but installing a theme that requires a plugin to configure the theme is a bit of a sub-optimal experience, no? Also more work for the review teams to coordinate, as you say.
It would be different if there is a full contact form solution that is designed to be integrated with a particular theme, I would definitely put that in a separate plugin that the theme can recommend to install. But if it is just a couple of post types with special templates, then I wouldn’t see a problem with including their registration in the theme. There wouldn’t even need to be a user-facing option for that, just a filter that could be overridden in a child theme or a site-specific plugin.
I’m not an expert on themes and I don’t know enough about this topic to have a strong opinion. I mostly just wanted to start the discussion, and maybe that can help us build the guidelines for this kind of issue.
This becomes a problem if you’re changing themes, and now all your CPTs are gone. I’ve had to deal with this issue many times, re-registering CPTs using the same slugs to get access to the existing content in the database. Non-technical users would think it’s all gone. I’ve had clients panic because they thought all their “books” were gone when they switched to a new theme.
If it’s in a plugin, there is a chance to keep it while changing themes. Although, most of these utility plugins have a lot of features tied to the theme.
Maybe, in an ideal world, CPTs would be kept in a separate plugin. Just the registration code, so they’re never going away unless that plugin is disabled.
WordPress theme (and plugin) developers have too much freedom to do whatever they want, without stricter requirements. There are many ways to skin a cat in WordPress. That’s a problem we inherited, but I wish we would be more strict about it.
Think admin notices abuse, menu items abuse, etc.
Yes, this is a good point.
Also definitely things we need to address.
yeah! i forgot about that… themes switch would be problem. mainly not just CPT but most people build plugins to avoid theme switch and still have their plugin useable after theme switched.
I’m sure that we could find something that can be used in theme lol!
No! I have personally had to fix a client site that had been hacked, and was using a theme that registered a custom post type. It is very stressful and you have to basically take the site down, because you don’t know if the hack is in the theme or the data or the plugins. I couldn’t just switch themes, because then all the data isn’t displayed.
Also, if the CPT needs special handling, the plugin should be doing that (and work with any theme). Also, the template hierarchy works on the slug, which could be in any language. Also, the same slug could be registered by two different plugins (unlikely), and the theme should simply display whatever was retrieved.
If a big plugin like Woo makes a custom post type, they should also provide all that is needed to display it correctly, whether that is a template that is filtered in, or a shortcode, or filtering the_content. The theme shouldn’t be involved, since it can be switched (even programmatically) at any time.
The best practice is of course to let theme handle looks and plugins the structure
However, there’s tons of themes registering post types, fields, taxonomies and what not, be it because they are a “portfolio” theme or because they use cpt hiddenly somehow for whatever
We can’t forbid that.
We can suggest best approaches, and that clearly would be the plugin responsibility in case for cpt, as example.
It’s just not reality, reality is that even if there are best practices, sometimes they are not followed.
I mean, after all we maintain a cms that registers at least 3 post types. Strictly speaking that should be a plugin. There are plugins adding templating features - without cpt - and strictly speaking that should be theme territory.
And what about a search? It’s Not templating, it’s a functionality- so should it be a plugin? But then the plugin delivers perhaps some layout features for search results… and again that should be theme territory
The lines aren’t as clear as one would think. Imo a suggestion is enough, but we shouldn’t force people to do what “is considered best practice”
Not as long it doesn’t literally affect security- which a cpt in a theme certainly doesn’t (neither a templating system in a plugin)
Letting people do whatever they want is the best thing to do, to open doors instead of closing them. As long as it doesn’t affect security.
I can’t think of a way that PHP code in a theme can have a worse impact in terms of security than in a plugin. So I would not limit anything in that sense.
If CP wants to really force themes for display and plugins for logic: make themes be based on twig templates. It’s what craftCMS does.
But I would not do that.
As long as it doesn’t affect security or encourage people to write broken code or otherwise make things difficult for their users. When we design APIs, platforms and other things (tools) for other people to use, we intentionally limit the options available in a way that encourages people to use the tools as designed. (More advanced features are usually still available, but hidden behind a more advanced interface, like what hooks and filters are at the level of specific WP/CP code.)
I hadn’t considered what happens when switching themes with custom post types. (Switching themes is usually kind of a nightmare anyway but that is another topic…)
Given that, I do think registering post types in a theme should be discouraged. Given how common this is, we shouldn’t prohibit it outright, but we should probably think about requesting changes to themes that do way too many things in the theme code.
This sounds like a good way to go.
“Hey, thanks for submitting your theme. It looks great. But could you please try to adapt it and move x and y parts into a plugin, that way we keep ClassicPress secure and in line with good practices…”
The draft guidelines currently say this:
Is this opening the door to bundling plugins into a theme? I think bundling is a very bad idea.