The plugins paragraph here states this:
Functionality not related to the customisation of visual aspects of a theme must be added via plugins as much as possible. For example: Allowed in theme: Theme options frameworks Page builders Must be in plugin: Custom Post Types Shortcodes Themes may not create custom database tables. If a custom database table is absolutely necessary for some certain functionality, it should be implemented in the plugin that provides the functionality. Ideally, using WordPress’ built-in data structure would be preferable.
Let’s say i have a “recipies” template ( single-recipies.php ) in the theme for the “recipies” custom post type, do i have to create a plugin that registers custom post type, related taxonomies and custom fields?
I would like clarification on this as well, thanks!
Yes, you should put custom post types in a plugin, makes it easier to maintain.
Yep. That is exactly what you should do. All things functional in plugins, all visuals, including frontend, in theme.
As I understand, the purpose of placing portfolio CPTs to a plugin is that the buyer will be able to use the existing portfolio when he/she switches themes without having to re-create it’s portfolio. In order to achieve that an author must create the plugin to work with default WP themes as well (this makes sense to me). I get this, buyers will be more open on the idea of switching themes, therefore they will buy more.
However, the theme that I’m currently working at has a portfolio with some special features (full width/heigh, animations that depend on that…), switching to another theme will most certainly crash the the portfolio.
The second concern is: in order my portfolio plugin to work properly with other themes, it will have to register/load the same fonts as the theme does .
My real question is: If we move portfolio (CPT) to a plugin, is this plugin required to work well with other themes? I believe the answer would be “yes” since I can’t make any sense of it otherwise.