“And no self-respecting theme-designer wants to be associated with plugins…” Since I’m both a plugin and theme developer, I get to flip that around from time to time.
Thanks for the shout-out though. I’m watching through the video right now. Great stuff.
Not at all. Your theme should work without any plugins.
Why would I, as a developer, use shortcodes or plugins from another developer or some 3rd party plugins, in order to make them compatible with all the themes?
Because you care about the people using your products.
If you’re really worried about someone else’s code, write your own plugin(s). This isn’t about 3rd-party vs. in-house code. It’s about good vs. bad development practice.
There is no point in doing that and that would cause lots of questions like “What? Why do I need all this kind of plugins to use your theme?” or bug reports related to the shortcodes and functionality you didn’t write.
Nevermind that the larger WP developer community has been handling this well for years.
That’s never going to work, it’s like having all the features a BMW car has, in a Renault car, just because they’re both cars. That’s never going to happen.
I’m not even sure how to respond to that. That is not even close to accurate analogy of the topic at hand.
Sad part is that so many authors included them in the theme, that buyers here are actually expecting the theme shortcodes and CPTs to work as soon as the theme is installed. “It works in the demo, why the hell is my site broken when I install your theme?!” doesn’t look too good for sales… so authors keep including them.
This isn’t a user problem though. It’s a developer one. More specifically, it’s a TF developer problem. You rarely see this type of issue in the larger WP theme developer community, and the few lingering issues are being worked out by the development community.
Too many developers here on TF are thinking about the bottom line rather than what’s best for their users. When you add functionality that literally holds the key to a user’s content within a theme, you’re locking them into using your theme and your theme only, at least until the user hires another developer to fix your crap.
Not only is this bad development practice, it’s an unethical business tactic.
Shortcodes in themes sold here are tightly bound with the theme itself. Having them in a separate plugin to be used with another theme is never going work.
This is exactly why there’s such a problem on TF with these things. Rather than saying you can’t do something, you should be asking, “What solutions can we come up with?” and working to fix the problem.
A developer’s job is to come up with solutions for problems.
Quick example: how a tab (or column) shortcode using twitter bootstrap is supposed to work in a theme not using it ?
Any 13-year-old WP developer with Bootstrap knowledge could write this plugin in about two hours. Any more examples?
And who’s going to handle support for such situations ?
Be more specific. Each scenario has a different solution.
Is it bad practice to package a plugin with a theme?
TF seems to have a lot more “noob” WP users, so it might not be a bad idea to package it with (definitely not in) the theme. In general, I’d say to just write a note in the documentation to install the plugin if the user wants the functionality.
Keep in mind that a theme should never rely on that plugin functionality either. The theme should stand on its own, whether the plugin is installed or not.
I mean, do reviewers care about this problem and see it as a good thing or will they see it as a negative that the user has to install a plugin?
No idea. But, if I were a reviewer, I’d reject any theme immediately that registered a CPT or a shortcode for use in post content.
Also, if an author is packaging shortcodes and custom post types, all JS and CSS would also need to be included with the plugin right?
It would depend on the specific scenario. A good rule of thumb: Plugins add functionality and themes present content. Keep that in mind and you should be okay.
It seems like this could get a lot deeper than just shortcodes and CPTs.
Yes, there’s a lot more than just shortcodes and CPTs. These are just the obvious examples. There are some things that are even pretty borderline theme/plugin, but these two are clearly plugin territory.
Are any authors packaging shortcodes and CPTs in plugins now?
I have one of the oldest and longest-running WordPress theme/plugin clubs still around. If I need to add something like a shortcode or CPT , it goes into a plugin. Not once in several years have I had a user who couldn’t figure it out.
Not to knock Thematic (it’s an awesome theme), but I wouldn’t consider it a framework. Carrington Core, WP Framework, and Hybrid Core are actual frameworks that allow you to build themes (not child themes).
What you’re describing is taking someone else’s theme and modifying it, not building from a framework. You might as well have asked if it was okay to take the TwentyTen theme and modify it for sale. I’m not sure about the answer to that though.
It would depend on the actual case. Nothing specific was asked.
In general, I’d argue for getting behind and supporting specific plugins. The two major reasons for this are standardization and portability. Some examples: WooCommerce, bbPress, BuddyPress, etc. If the wheel’s already been invented, use it.
I’ll be more than happy to build or contribute to some open-source plugins to handle various use cases in this area if a plugin doesn’t already exist.
Any theme author who is adding these things to their themes is flat out doing it wrong. They belong in a plugin. You can package that plugin with the theme or release it separately, such as on WordPress.org.
Aesthetically, it looks pretty good. So, surely it wasn’t something there. Also, the “flip” functionality is cool.
Of course, you have a ton of things that simply shouldn’t be in a theme (post types, shortcodes, etc.), but that seems to be praised rather than discouraged here on TF.
So, I’m guessing the rejection had something to do with the code itself. I’d need to see the code in order to tell you more about that.