20 posts
  • Has been a member for 1-2 years
teamCrisis says


Hey, why does columns shortcode is in Inadmissible list? We have seen on our buyers sites, that they use this shortcode a lot actually and find it very useful.

Why? Because of how it is implemented it typically changes the content output and breaks things such as shortcodes that may be used within one of the columns. Typically in order to implement the columns there is code that manipulated the output.

This manipulation then has unintended consequences. So while the column functionality works great for basic text. It causes problems for other plugins when a user tries to do something like use a shortcode within a column.

This is a great example of theme developer implementing a feature that appears to be great, and users love… only to discover it has major implications down the road because it causes problems with shortcode output for other plugins.

It’s like the RAW or NOFORMAT shortcode that allows you to disable WordPress autop on a block of text in your content using that shortcode. Sure it works and does disable autop on the block of text within that shortcode. But it has the unintended consequence of the. Applying autop to ALL other shortcode output, which WordPress doesn’t do by default. So by introducing a feature, it changes default WordPress behavior in a negative way and breaks other plugins that use shortcodes to output content.

This type of situation is why I’m guessing the columns shortcode is not being allowed anymore. I’m sure they are looking into what types of features seem to cause the most issues and conflicts with plugins, etc.

Apparently some in this thread seem to think Envato is just making up these guidelines out of thin air while I can assure you they wouldn’t be implementing changes like this lightly. They’ve put a lot of time and research into the support issues and conflicts caused by certain functionality and that has contributed a lot to why some things are no longer going to be allowed.

Maybe I misunderstand what you are saying, but from my understanding the new guidelines don’t say column shortcodes are not allowed anymore. You simply can’t bundle them within the theme, they must be in a plugin so they can be made portable…

66 posts
  • Elite Author
  • Sold between 100 000 and 250 000 dollars
  • Author had a File in a Mini Bundle
  • Author had a File in an Envato Bundle
  • Most Wanted Bounty Winner
  • Exclusive Author
  • Author had a Free File of the Month
  • Envato Studio (Microlancer) Beta Tester
+3 more
smartdatasoft says

Hello, I am a prestashop expert and just finish out wordrpess theme to submit on themeforest. All the work is done 100%

But i am totally confused what to do. Here is what i did 1. I modified SMO for theme option fremwork. 2. Use short code generator via tinymce editor which use in our theme function. 3. use column short code for column as we use bootstrap framework.

So what i have to do or modified to meat the standard. :( i am totally confused about the new standard. As i all time maintain the coding standard like wordpress. But wordpress have simple blog and all the author themes is not only blog there are lots of new features on themes. Will envato clear more about this.

1466 posts
  • Has been a member for 2-3 years
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 10 and 49 items
  • Referred between 1 and 9 users
  • Croatia
OriginalEXE says


Hey, why does columns shortcode is in Inadmissible list? We have seen on our buyers sites, that they use this shortcode a lot actually and find it very useful.

Why? Because of how it is implemented it typically changes the content output and breaks things such as shortcodes that may be used within one of the columns. Typically in order to implement the columns there is code that manipulated the output.

This manipulation then has unintended consequences. So while the column functionality works great for basic text. It causes problems for other plugins when a user tries to do something like use a shortcode within a column.

This is a great example of theme developer implementing a feature that appears to be great, and users love… only to discover it has major implications down the road because it causes problems with shortcode output for other plugins.

It’s like the RAW or NOFORMAT shortcode that allows you to disable WordPress autop on a block of text in your content using that shortcode. Sure it works and does disable autop on the block of text within that shortcode. But it has the unintended consequence of the. Applying autop to ALL other shortcode output, which WordPress doesn’t do by default. So by introducing a feature, it changes default WordPress behavior in a negative way and breaks other plugins that use shortcodes to output content.

This type of situation is why I’m guessing the columns shortcode is not being allowed anymore. I’m sure they are looking into what types of features seem to cause the most issues and conflicts with plugins, etc.

Apparently some in this thread seem to think Envato is just making up these guidelines out of thin air while I can assure you they wouldn’t be implementing changes like this lightly. They’ve put a lot of time and research into the support issues and conflicts caused by certain functionality and that has contributed a lot to why some things are no longer going to be allowed.

That’s not true, all that column shortcode does is restricts container width, which should be handled by other plugins by using fluid daylotu (we are in responsive era after all).

Same goes for dealing with autop, it can be set to be used only on custom defined shortcodes and not globally.

127 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Exclusive Author
  • Referred between 50 and 99 users
  • Bought between 1 and 9 items
  • Has been a member for 1-2 years
Cubell says

I’ve just re-read the guidelines and the “Functionality will need to be added via bespoke plugins instead of via shortcodes as much as possible.” line – at first I thought they were only referring to all shortcodes to be moved to plugins. But it says “functionality”, what exactly are they referring to? where is the line drawn on that?

Custom meta boxes? Custom post types? Theme Options Panel? Theme Options Panel with built-in homepage builder? Theme-specific widgets? Review systems (that use meta boxes)? etc?

And why are some shortcodes allowed/disallowed, don’t all have to be plugins anyway? So you could create your own plugin for an accordion for example and require it. No?

Does all of that stuff need to be transferred to a plugin to?

31 posts
  • Elite Author
  • Sold between 100 000 and 250 000 dollars
  • Has been a member for 1-2 years
  • Europe
  • Exclusive Author
  • Referred between 50 and 99 users
  • Bought between 50 and 99 items
lollum says

Why? Because of how it is implemented it typically changes the content output and breaks things such as shortcodes that may be used within one of the columns. Typically in order to implement the columns there is code that manipulated the output.

But this is not true for page builders. Or to be more precise, not true for every page builder. For example my page builder have separate fields for every element, completely “the_content()” independent. I have zero conflicts with other plugins.

22 posts
  • Elite Author
  • Exclusive Author
  • Has been a member for 1-2 years
  • Sold between 250 000 and 1 000 000 dollars
  • Referred between 200 and 499 users
  • Bought between 1 and 9 items
  • Europe
ThemesIndep says

I’ve just re-read the guidelines and the “Functionality will need to be added via bespoke plugins instead of via shortcodes as much as possible.” has just slightly sunk in, at first I thought they were only referring to all shortcodes to be moved to plugins. But it says “functionality”, where is the line drawn on that?

Custom meta boxes? Custom post types? Theme Options Panel? Theme Options Panel with built-in homepage builder? Theme-specific widgets? Review systems (that use meta boxes)? etc?

And why are some shortcodes allowed/disallowed, don’t all have to be plugins anyway? So you could create your own plugin for an accordion for example and require it. No?

Does all of that stuff need to be transferred to a plugin to?

Good point. Also wanted to know more what to do with all this stuff. If we use third party theme options panel, do we have to make it a plugin? What about post types and custom fields?

20 posts
  • Has been a member for 1-2 years
teamCrisis says

I’ve just re-read the guidelines and the “Functionality will need to be added via bespoke plugins instead of via shortcodes as much as possible.” has just slightly sunk in, at first I thought they were only referring to all shortcodes to be moved to plugins. But it says “functionality”, where is the line drawn on that?

Custom meta boxes? Custom post types? Theme Options Panel? Theme Options Panel with built-in homepage builder? Theme-specific widgets? Review systems (that use meta boxes)? etc?

And why are some shortcodes allowed/disallowed, don’t all have to be plugins anyway? So you could create your own plugin for an accordion for example and require it. No?

Does all of that stuff need to be transferred to a plugin to?

This is my exact concern too. How is “functionality” defined? I assume we are not just talking about shortcodes then. What about sliders, portfolios, custom post types, metaboxes, galleries, theme options panel, etc?? As you say, where do you draw the line? What needs to be portable and in a plugin, what is acceptable to be included in the theme and not portable?

49 posts
  • Bought between 1 and 9 items
  • Has been a member for 6-7 years
carlhancock says

I was carefully following this discussion and I am trying to figure out what will be next step for our team, question that many other authors are asking themselves. We are relatively new to ThemeForest (joned it in February) but become very successful in just couple of months. We spent lot of effort building our framework and learning the things one way. Now things are changing. Although initially I didn’t like the request to move theme’s built-in features into plugins, I am starting to change my mind. I have to admit, some of our themes had problems with Gravity Forms and other plugins and we had to fix that. Who knows how many other reported problems we will need to fix in the future. I would rather do it right way and not worry about that anymore. I am just thinking that there is no other solution to make the people to learn how to make their themes compatible with plugins if they don’t make their own plugin. Maybe this is just practical way to fix this and I agree with many authors here that it doesn’t make sense to move everything to plugins. Maybe that’s not the point here at all, maybe that just a way to improve things. Think about that. I agree with @carlhancock that Envato is more imortant to us, then we are important to them. I trust people from Envato on their decision to change when it’s right time, not when it’s too late.

So glad to see someone with a more positive outlook on here that understands Envato is making these changes because they feel its best for everyone involved for the longterm. Wil, it suck in the short term? Definitely. But in the long run it will result in a better product.

The question of if code should be in a plugin or a theme doesn’t impact things like conflicts with Gravity Forms as much as things related to properly using jQuery, JavaScript, CSS and WordPress don’t output manipulation,

Most theme conflict ps with Gravity Forms are caused by one of the following:

- Not properly enqueuing JavaScript and simply outputting it without enqueuing it on every page.

- Using enqueue to enqueue JavaScript and CSS globallg and on every page and not enqueuing it only when it’s needed. For example, 99% of themes and plugins should have no need to output ANY JavaScript within the Gravity Forms admin pages.

If you go to a Gravity Forms admin page in your WordPress Dashboard such as the Form Editor and you view source and see calls to JS or CSS from your theme, you aren’t outputting things selectively enough. Only output JS and CSS when it’s actually needed. Sometimes it may be necessary if you are doing something globally in the WordPress admin, but this typically is not the case.

- De-enqueuing the version of jQuery that is built into WordPress and enqueuing a different version of jQuery. This will cause conflicts with any or JS using jQuery that isn’t expecting this to occur because its expecting the jQuery that WordPress ships with.

- Manipulating the output of post and page content. Such as manipulating how autop behaves. This can have serious negative impact on how shortcode content is output. By default, autop is not applied to shortcode output. Manipulate the content output to change this behavior and you can unintentionally then make autop be applied to all shortcode output… which isn’t default WordPress core behavior and therefore not expected by plugins and can break things. We see this a lot with shortcodes such as the RAW shortcode, columns shortcode, etc

These are a few examples of what themes do that can cause conflicts with plugins. There are of course others, but these are the major ones. These are the types of things the new guidelines will help curb, along with many other issues.

None of the above even touches on the whole theme we vs. plugin issue when it comes to features that should be in a theme vs. a plugin. That’s more of a best practice thing than something that’s going to help prevent conflicts. Because if your plugin still does the things I describe above, it could still cause a conflict with Gravity Forms.

3 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 1-2 years
  • Power Elite Author
  • Power Elite Author: Sold between 1 000 000 - 1 999 999 dollars
  • Referred between 200 and 499 users
QODE says


I was carefully following this discussion and I am trying to figure out what will be next step for our team, question that many other authors are asking themselves. We are relatively new to ThemeForest (joned it in February) but become very successful in just couple of months. We spent lot of effort building our framework and learning the things one way. Now things are changing. Although initially I didn’t like the request to move theme’s built-in features into plugins, I am starting to change my mind. I have to admit, some of our themes had problems with Gravity Forms and other plugins and we had to fix that. Who knows how many other reported problems we will need to fix in the future. I would rather do it right way and not worry about that anymore. I am just thinking that there is no other solution to make the people to learn how to make their themes compatible with plugins if they don’t make their own plugin. Maybe this is just practical way to fix this and I agree with many authors here that it doesn’t make sense to move everything to plugins. Maybe that’s not the point here at all, maybe that just a way to improve things. Think about that. I agree with @carlhancock that Envato is more imortant to us, then we are important to them. I trust people from Envato on their decision to change when it’s right time, not when it’s too late.

So glad to see someone with a more positive outlook on here that understands Envato is making these changes because they feel its best for everyone involved for the longterm. Wil, it suck in the short term? Definitely. But in the long run it will result in a better product.

The question of if code should be in a plugin or a theme doesn’t impact things like conflicts with Gravity Forms as much as things related to properly using jQuery, JavaScript, CSS and WordPress don’t output manipulation,

Most theme conflict ps with Gravity Forms are caused by one of the following:

- Not properly enqueuing JavaScript and simply outputting it without enqueuing it on every page.

- Using enqueue to enqueue JavaScript and CSS globallg and on every page and not enqueuing it only when it’s needed. For example, 99% of themes and plugins should have no need to output ANY JavaScript within the Gravity Forms admin pages.

If you go to a Gravity Forms admin page in your WordPress Dashboard such as the Form Editor and you view source and see calls to JS or CSS from your theme, you aren’t outputting things selectively enough. Only output JS and CSS when it’s actually needed. Sometimes it may be necessary if you are doing something globally in the WordPress admin, but this typically is not the case.

- De-enqueuing the version of jQuery that is built into WordPress and enqueuing a different version of jQuery. This will cause conflicts with any or JS using jQuery that isn’t expecting this to occur because its expecting the jQuery that WordPress ships with.

- Manipulating the output of post and page content. Such as manipulating how autop behaves. This can have serious negative impact on how shortcode content is output. By default, autop is not applied to shortcode output. Manipulate the content output to change this behavior and you can unintentionally then make autop be applied to all shortcode output… which isn’t default WordPress core behavior and therefore not expected by plugins and can break things. We see this a lot with shortcodes such as the RAW shortcode, columns shortcode, etc

These are a few examples of what themes do that can cause conflicts with plugins. There are of course others, but these are the major ones. These are the types of things the new guidelines will help curb, along with many other issues.

None of the above even touches on the whole theme we vs. plugin issue when it comes to features that should be in a theme vs. a plugin. That’s more of a best practice thing than something that’s going to help prevent conflicts. Because if your plugin still does the things I describe above, it could still cause a conflict with Gravity Forms.

Thanks a lot for your suggestions :)

If you can share some links to articles explaining other common problems theme authors are causing, as well as resources where we can learn how to develop clean plugins and themes, I am sure everyone here will appreciate it a lot :)

49 posts
  • Bought between 1 and 9 items
  • Has been a member for 6-7 years
carlhancock says

Same goes for dealing with autop, it can be set to be used only on custom defined shortcodes and not globally.

I have yet to see a RAW or NOFORMAT shortcode to disable autop that didn’t have a global impact.

YES you can create a shortcode that content contained within it does not have autop applied to it.

But because of how you must implement the code necessary to do this, it changes the order in which functionality in WordPress is executed and while content within the shortcode does not have autop applied to it, it will now apply autop to ALL shortcode output.

By default WordPress dot not apply autop to shortcode output. S when this change is made it can cause proble s for plugins that don’t expect their shortcode output to have autop applied to it,

This is why the new guidelines specifically mention you can’t make modifications to WordPress core functionality related to wptexturize and wpautop. Precisely because of the issue I describe above.

by
by
by
by
by
by