I’m shocked at some of the comments here.
If you listen to Justin’s thinking it makes perfect sense. I think authors just don’t want to get out of their routine.
As someone earlier said about buyers not being able to install plugins, not true. Any buyer I have had has never had any problems installing plugins. anyway, buyers should have a certain level of responsibility when installing a theme.
A shortcode plugin really is the best option here, am I in the minority that I only see this? 
EireStudio saidAs someone earlier said about buyers not being able to install plugins, not true. Any buyer I have had has never had any problems installing plugins. anyway, buyers should have a certain level of responsibility when installing a theme.
Just check the number of topics for “missing stylesheet” and you’ll see how many people out there are having trouble installing just the theme. Not talking about additional plugins, tweaking them, etc.
Not at all. Your theme should work without any plugins.
Then the buyer will say he didn’t get what he bought and that he wants the demo look. Most of them are looking for just a simple .xml file to import and get the demo layout.
When I’m developing themes, it is NOT my responsability to adapt the previous layout in order to work with my theme. Even if it would become a standard on themeforest, it will still be useless. There are hundreds of wordpress theme clubs, many of them are EXTREMELEY BAD coded, how would you handle with the custom options that previous theme has? What if it has custom shortcodes? What if it uses custom post types? What if it’s totally unrelated with your theme?
FinalDestiny saidIt is an extremely BAD development practice to make your themes depend on 3rd party plugins.
Totally agree. So make your own 
One for all your themes. Update it, improve it, maintain it.
A theme shouldn’t depend on shortcodes. If the buyer wants columns, they install the plugin. If they want google maps, pricing tables, buttons, alerts, toggles, accordions, etc - they install just one plugin (your plugin, for example).
But if they don’t, regular page/post layouts should still work.
I can see why this practice is happening here, but Justin said it right: the WP theme community outside TF is doing OK with this approach. It’s better for end users, unless all we care about is making a quick buck.
It is absolutly NO bad practice to separate the functionality into plugins. There are so many user-friendly solutions.
Problem: Need to ship your theme with plugins and you’re afraid that your client is to stupid to know how that works?
Solution: Include the Plugin Activation Script mentioned above and you’re good to go.
Problem: You don’t see a way how to include your shortcode plugin which relies on styles given from your theme? And it doesn’t make sense since as soon as the client switches the theme your plugin would become useless?
Solution: Code your plugin that it first checks if one of your themes is installed - if it is installed, get the styles from there, if it is not installed get the styles from the plugin itself.
You see: Problem, Solution
Oh and btw @FinalDestiny:
FinalDestiny saidJust check the number of topics for “missing stylesheet” and you’ll see how many people out there are having trouble installing just the theme. Not talking about additional plugins, tweaking them, etc.
On the other hand you need to compare how many customers actually purchase a theme and haven’t any troubles with it - and even then, there would be plenty solutions for that. Some could be initiated by envato, some could be easily implemented by each developer/author.
greenshady saidYour theme should work without any plugins.
this concept has been lost on tf, look how many themes use OptionsTree or Options Framework but would completely break without them and all it takes is a simple check…
a little more to the topic shortcodes should never be used in themes as like Justin says it locks the content to users, I always chuckle when reading blogs and see [shortcode] in the content, now Ill have to argue that CPT can be used “sparingly” and if youre going to use a portfolio post type, this is the one time you’ll here me say dont prefix it
Now including plugins in themes, Id say the best solution is using something like TGM(posted earlier) as including them in themes can be a hassle, many users have issues with simply installing themes because the way themeforest zips them, and some have no concept of FTP programs not to say Authors shouldnt be educating people on how to use them(or pointing to resources that do)
anyways
http://wordpress.org/extend/plugins/shortcoder/
http://wordpress.org/extend/plugins/synved-shortcodes/
http://wordpress.org/extend/plugins/shortcodes-ultimate/
and theres always
http://www.themezilla.com/plugins/zillashortcodes/
now I havent dug into the code of those plugins but Id say itd be pretty easy to hook a stylesheet into your theme http://justintadlock.com/archives/2009/08/06/how-to-disable-scripts-and-styles
and
http://codex.wordpress.org/Function_Reference/is_plugin_active
scenario: autor A releases theme + own coded plugins which break/no longer work with author B theme.
question: who’s going to support the buyer and why.
BF
pixelentity saidscenario: autor A releases theme + own coded plugins which break/no longer work with author B theme.
question: who’s going to support the buyer and why.BF
I think more of the point would be to either develop as a collective and post to the codex and leave it full GPL then have the community support/develop it so that issue never happens
Irrespective of whether the practice of embedding shortcode behavior in a theme is the “correct” thing to do or not, it the most practical approach when selling theme on a premium marketplace like TF. The original poster asked why do authors not account for the situation when a buyer wants to change their theme later on, while keeping their current layout which has been created using embeded shortcodes. The answer to this is because it to complicated and impractical.
Many of the complex themes here on TF use a range of different frameworks as a basis for developing a theme. All of these frameworks require layout elements to use specific markup and specific CSS. Because of this, it would be almost impossible to create a plugin which your buyer could use with your theme and then keep using with a totally different theme. At the very least, even if the framework was compatible, the whole CSS of most shortcodes would need to be changed to fit the style of the new theme. This is not something which TF buyers want to have to do after buying a premium theme, and as such is not a recipe for good sales.
Assume then that you want to be a very “correct” developer and you only make plugins for your own themes and dont care what happens when your buyer changes theme later on. Well then you are back at square one, only now you have to support your less experiences buyer while they struggle to install/ update your range of plugins. You also now have several different code bases, instead of one if the shortcodes were intrgeated into your framework. Furthermore, when your buyer does change theme and your plugins spits out the markup suitable for your theme, inside a 3rd party theme, then they will come looking for support and answers why this plugin is not working. This hence doesn’t achieve anything except giving yourself more work.
While it may be possible to produce a free plugin which would output the most generic markup and css which would have some chance at rendering in most themes, this would put a severe restriction on your shortcodes complexity as well as bring you a lot of support requests. This tradeoff is not worth it, neither for you nor for your buyer. Nothing is achieved except “correct” development, which actually doesn’t solve the original poster’s problems.
DOK
pixelentity saidMany of the complex themes here on TF use a range of different frameworks as a basis for developing a theme. All of these frameworks require layout elements to use specific markup and specific CSS. Because of this, it would be almost impossible to create a plugin which your buyer could use with your theme and then keep using with a totally different theme. At the very least, even if the framework was compatible, the whole CSS of most shortcodes would need to be changed to fit the style of the new theme. This is not something which TF buyers want to have to do after buying a premium theme, and as such is not a recipe for good sales.
have you heard of filters? a properly developed plugin this wouldn’t be an issue, as long as authors use those filters(and modifying the styling)
real question how many buyers actually use shortcodes?
OrganicBeeMedia saidyes and ? a bunch of filters in this collective shortcode plugin will cover every author needs so it could be used into each TF theme ?have you heard of filters? a properly developed plugin this wouldn’t be an issue, as long as authors use those filters(and modifying the styling)
real question how many buyers actually use shortcodes?
can we assume whoever posts in this thread actually knows what he’s talking about ? because a certain wordpress evangelist tone assumed more than once in this thread starts to get really annoying.
OrganicBeeMedia saida lot. They even asks for more and somebody pay for custom ones also.real question how many buyers actually use shortcodes?
BF
pixelentity saidyes and ? a bunch of filters in this collective shortcode plugin will cover every author needs so it could be used into each TF theme ?
yes it could be done, but youre never going to fill everybody’s needs 100% and not everyones going to use the plugin the point is how to make things better for buyers and not sacrificing full functionality…
for example almost all themes have button,icon, tabs,columns, accordion etc shortcodes all of those could easily be wiped out with a plugin and allow authors to completely customized it
Im guess the better question is what dont you think could be done? the only thing I could really think of is if the plugin used A script for a slider shortcode and you wanted to use b script instead , it could be filtered(but wed still be at the same issue as the start it would break on theme change)
OrganicBeeMedia saidWhich is why it will never work: complex shortcodes like gallery, slider, filterable portfolio requiring all kind of custom css/js.Im guess the better question is what dont you think could be done? the only thing I could really think of is if the plugin used A script for a slider shortcode and you wanted to use b script instead , it could be filtered(but wed still be at the same issue as the start it would break on theme change)
btw, since this common shortcode component doesn’t exist (hardly believe it ever will), the original question still remain unanswered.
By moving theme features in custom plugins, who’s going to support the buyer when nothing works out of the box ?
BF
I like the thing OrmanClark is doing - making themes compatible with his set of stuff and advertising it with that.
Both things are important - compatibility and the information about compatibility. Even if a theme has special modules that won’t work with themes - the user needs to be informed about what that theme is using. The user needs to know from the beginning what a theme supports and how the content will be handled.
pixelentity saidjust because the solution doesnt work for you doesnt mean it hasnt answered the first question as I listed plugins that handle shortcodes earlier, though it may not be the solution for every authorbtw, since this common shortcode component doesn’t exist (hardly believe it ever will), the original question still remain unanswered.
pixelentity saidBy moving theme features in custom plugins, who’s going to support the buyer when nothing works out of the box ?
I think that would vary, I know authors who use OptionTree and support it when theres issues with it, I no I do quite a bit (for the author I provide support for)
I also know of tons of Premium Plugin developers who have to fix things in themes that break their plugins(loading scripts wrong etc)
it depends on the author and their willingness or how much they care about their customers
Here’s a great idea that many of you should take to heart… quit making overly complex themes because it’s obvious many of you don’t really have a clue what you are doing.
Some of the comments in this thread make it clear that some of you don’t get the impact your poor development decisions have on the community as a whole. If you did, maybe the Gravity Forms support team wouldn’t have to spend so much time helping ThemeForest customers fix poorly developed themes that break plugins that are developed correctly.
As it is we practically need a dedicated support team member specifically to assist customers running poorly developed ThemeForest themes.
ThemeForest needs more developers like Orman Clark and Mike McAlister. The fact that some of you are discounting what Justin has to say is extremely disheartening and it’s those developers that contributes to making ThemeForest the butt of so many jokes in the WordPress development community.
Many of you have no business selling themes to the public.
pixelentity saidNonsense. TF theme authors could easily code a plugin for use with their themes in which the CSS and JS necessary to power the functionality could be overridden by including specific files in the theme directory itself. It actually makes it easier for TF theme authors this way since authors can offer a consistent operational experience across all of their themes from a single plugin codebase, and yet still offer each theme a specialized look for that functionality.Which is why it will never work: complex shortcodes like gallery, slider, filterable portfolio requiring all kind of custom css/js.
Orman Clark an Mike McCalister are both doing it right: they aren’t including any short codes in their themes but instead relying on the external plugin to be installed. This works beautifully because the short codes work no matter what theme is installed. There is absolutely no problem doing this, just make it noted and make it easy for the user to install the plugin.
Stop trying to claim you have to include short codes in themes because that’s the only way you can style them. Come on! Have you ever heard of deregistering a plugin’s default styles and loading your own?
Sure, there are some short codes, such as really complex galleries, that can’t always rely on a plugin, but it’s okay to have some exceptions. But there is zero, absolutely ZERO reason to include column, button, notices, and contact form short codes in your theme. ZERO.
I will reiterate what Carl (yeah, ever heard of Gravity Forms? That’s him) said: the amount of time I have lost as a plugin developer providing support to customers that are using a TF theme is huge. Literally hours every single week.
Justin (Green Shady), Carl, and I all write a lot of plugins, and we have all delivered plugins to the masses in the global WordPress community. You think 500 - 2000 users of your theme is a lot? Try 20,000 - 100,000 users. I assure you, with our significantly larger user base, we have seen every single problem out there, and the issues discussed in this thread are extremely real. If you discredit them or say things like “it’s better for business” then you really need to open your eyes, or step into our shoes for day.
Stop saying “what is best for business” and start thinking about what is best for the users as a whole, and that absolutely includes other developers of both plugins and themes. I can assure you, having a bunch of other well-known and very respected developers (Carl and Justin especially) call out your products because of issues like this is NOT good for business.
arconix saidsure thing, i can tell by the number of top TF theme sellers posting in this thread, there's a serious interest in building a common framework.Nonsense. TF theme authors could easily code a plugin for use with their themes in which the CSS and JS necessary to power the functionality could be overridden by including specific files in the theme directory itself. It actually makes it easier for TF theme authors this way since authors can offer a consistent operational experience across all of their themes from a single plugin codebase, and yet still offer each theme a specialized look for that functionality.
which would also be pointless since, by the look of things, only a couple of authors here know how to code themes.
BF
carlhancock said[…]
Many of you have no business selling themes to the public.
