22 posts
  • Elite Author: Sold more than $75,000 on Envato Market
  • Had an item featured on Envato Market
  • Sells items exclusively on Envato Market
  • Has sold $250,000+ on Envato Market
+4 more
ThemesIndep says

There was another question about who’s going to offer support for the plugins that persist beyond your theme. The way I see it – and this works well with that bitfade said above -giving support for that plugin falls on your shoulders, as the client paid for what he got, BUT with a twist. After theme-switch (except cases where users switch to a theme from the same author), the author COULD or SHOULD only provide support for functionality issues, not styling issues. For styling issues it falls on to the client to support the consequences of their decisions, thus to pay either the author or a freelancer to restyle the plugin in line with their new theme.

+1. When a buyer switch themes he will stuck with, lets say a CPT plugin without the design and the data on the front-end, he/she will contact the author of a new theme about this issue. The author will answer that he is not responsible for this plugin, so the buyer will contact the author of the old theme. This author will have somehow to find a solution or the buyer will have to delete this plugin. This situation will create a mess, both for buyers and theme authors. Another solution is of course to duplicate the code, in a plugin (as a fallback) and in a theme, but it will create a situation uncomfortable when we have to update the theme, more working time and there is a big chance that fallback design in a plugin will not match the new theme design.

33 posts
  • Has been part of the Envato Community for over 2 years
  • Has collected 1+ items on Envato Market
  • Sells items exclusively on Envato Market
  • Located in United States
JonnyShogun says

It looks like a lot of people on this discussion are worried like i am regarding having to make everything into a plugin. And then having the plugins be an issue due to the following reasons.

  • Code in a plugin will be portable and easier to steal. What protects us from this misue?
  • Since its a plugin, are we responsible for the plugin working in other themes? (with the exception of shortcodes markup staying intact)
  • If a user switches themes, some functionality wont be on the theme they switched to because all the js, css supporting it will be in our theme?
  • How do we update the plugin, with a new theme update, tell the user to upload the new files into the plugins directory?
  • If we are using the TGMAC, can we set the plugin to force deactivate if the user switches the theme so are plugin is only used with our theme? (with the exception of shortcodes)
  • So now it seems we are now becoming plugin developers and will get no compensation since the plugins we make that are specific to our theme, will now be used in other developers theme. And we will have users who buy our theme, why someone else’s theme plugin is not working in our theme.

This will be a problem !!

Any help from STAFF and/or JAPH will be highly appreciated :)

642 posts
  • Has been part of the Envato Community for over 3 years
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Sells items exclusively on Envato Market
ChapterThemes says


There was another question about who’s going to offer support for the plugins that persist beyond your theme. The way I see it – and this works well with that bitfade said above -giving support for that plugin falls on your shoulders, as the client paid for what he got, BUT with a twist. After theme-switch (except cases where users switch to a theme from the same author), the author COULD or SHOULD only provide support for functionality issues, not styling issues. For styling issues it falls on to the client to support the consequences of their decisions, thus to pay either the author or a freelancer to restyle the plugin in line with their new theme.
+1. When a buyer switch themes he will stuck with, lets say a CPT plugin without the design and the data on the front-end, he/she will contact the author of a new theme about this issue. The author will answer that he is not responsible for this plugin, so the buyer will contact the author of the old theme. This author will have somehow to find a solution or the buyer will have to delete this plugin. This situation will create a mess, both for buyers and theme authors. Another solution is of course to duplicate the code, in a plugin (as a fallback) and in a theme, but it will create a situation uncomfortable when we have to update the theme, more working time and there is a big chance that fallback design in a plugin will not match the new theme design.

I disagree, this is too complicated thinking.

It’s plain and simple:

Authors are not the only people who need to work with the given rules. If a person buys a theme with one or a set of plugins for that particulair theme, the buyers knows / or needs to know, that things like design for the plugin features won’t be the same or won’t we compatible when they switch to another theme. Simple as that.

How they want to fix it is up to them. They can contact one of the authors or another person for payed or free work – that’s up to the person they contact. No big deal further.

642 posts
  • Has been part of the Envato Community for over 3 years
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Sells items exclusively on Envato Market
ChapterThemes says

—code in a plugin will be portable and easier to steal. What protects us from this misue?

What protects you from a person using a theme 20 times? What protects anyone who want to steal code from a plugin or theme?

: Nothing. Never will be since in every case they get the sourcecode.

This is always been the case even with themes without plugins.


—since its a plugin, are we responsible for the plugin working in other themes? (with the exception of shortcodes markup staying intact)

Ofcourse not. Like i said above: buyers also need to know the rules.


—if a user switches themes, some functionality wont be on the theme they switched to because all the js, css supporting it will be in our theme?

Depends, if you code your plugin correctly the plugin has it’s own js and css files. You could always define the very basics inside the plugin, and theme-styling inside the theme.


—if we are using the TGMAC, can we set the plugin to force deactivate if the user switches the theme so are plugin is only used with our theme? (with the exception of shortcodes)

You can put in a theme info check inside plugins to only work with a certain theme or you could also use a purchase key check or something. – don’t know if thats allowed btw. Waiting for response for that in an earlier question.


—So now it seems we are now becoming plugin developers and will get no compensation since the plugins we make that are specific to our theme, will now be used in other developers theme. And we will have users who buy our theme, why someone else’s theme plugin is not working in our theme.

Maybe you can see the whole thing as an opportunity to get more payed work. Buyers want a plugin from your theme to work in another theme? That’s possible, for a certain amount maybe…

478 posts
  • Has been part of the Envato Community for over 6 years
  • Has sold $10,000+ on Envato Market
  • Had an item featured in an Envato Bundle
  • Won a Most Wanted contest
+5 more
QBKL says

- So now it seems we are now becoming plugin developers and will get no compensation since the plugins we make that are specific to our theme, will now be used in other developers theme. And we will have users who buy our theme, why someone else’s theme plugin is not working in our theme.

Sorry for interfering… I know I’m not Japh or the part of the staff, but how about this:

1. “we are now becoming plugin developers”. Haven’t you been a developer already!? Just because you move PHP code from theme to a plugin that has a definition, activation and deactivation hooks makes you any different. That’s just a wrong, wrong perception.

2. “will get no compensation”. Last time I checked, feature jam-packed themes sold for more than regular, simpler themes. This means… what does it mean? Compensation.

@ChapterThemes, I am sorry to disagree with your way of seeing things, but IF the issue is within your plugin’s CODE, its functionality, it falls on your shoulder to fix it, no matter the theme it gets applied to. If you have a poorly written PHP or JS block that causes the thing to crash, it is your responsibility to fix it, just as it is now. And that’s how it should be fair both to users and for a respectable author. Again, and I need to reiterate this -> IT WOULD NOT fall on your shoulders to fix design/styling issues of your plugin in another author’s theme, as long as the mechanism of the plugin works perfectly. Let me give an example:

You create a tab shortcode functionality. User switches themes. Tabs stop floating, lose colors and whatever else you want from the styling, BUT they retain the translation from shortcode to visual HTML, maybe even the JS actions of clicking to show each tab.

- OR:

A buttons shortcode will return a simple unstyled A tag, instead of one using predefined color, backgrounds, border-radius and so on.

These two examples SHOULD NOT fall on your shoulders as to support and to update to a user’s new theme. Catch my drift?

1556 posts
  • Has been part of the Envato Community for over 7 years
  • Has referred 100+ members
  • Has sold $40,000+ on Envato Market
  • Made it to the Authors' Hall of Fame
+3 more
dSKY says
I’m a little confused about CPT’s and I have a couple of questions.
  1. Should plugin be used only to house cpt functionality, or should it include js, and css files that are required for front end design?
  2. Can the plugin use custom pages, with the ability that theme pages and custom post pages, if present will take precedence plugin-templating-within-wordpress
  3. If the plugin creates metaboxes for custom pages , post types, where should the logic for parsing the meta information go? And if I have some custom functions for retrieving and using that meta data, where should I put them ( functions.php or inside the plugin ) .... they will have to be used on the pages that are rendering custom post types.
  4. Where should I put all the helper functions which I use through the theme? underscores.me (_s theme) has a “inc” folder with the extras.php file that has all the extra functionality. Is it okay to have files in that folder with custom functions separated in to different files depending on their usage?
465 posts
  • Helped several times protecting Envato Market against copyright violations
  • Elite Author: Sold more than $75,000 on Envato Market
  • Has sold $125,000+ on Envato Market
  • Sells items exclusively on Envato Market
+7 more
Jaynesh says


- So now it seems we are now becoming plugin developers and will get no compensation since the plugins we make that are specific to our theme, will now be used in other developers theme. And we will have users who buy our theme, why someone else’s theme plugin is not working in our theme.

Sorry for interfering… I know I’m not Japh or the part of the staff, but how about this:

1. “we are now becoming plugin developers”. Haven’t you been a developer already!? Just because you move PHP code from theme to a plugin that has a definition, activation and deactivation hooks makes you any different. That’s just a wrong, wrong perception.

2. “will get no compensation”. Last time I checked, feature jam-packed themes sold for more than regular, simpler themes. This means… what does it mean? Compensation.

@ChapterThemes, I am sorry to disagree with your way of seeing things, but IF the issue is within your plugin’s CODE, its functionality, it falls on your shoulder to fix it, no matter the theme it gets applied to. If you have a poorly written PHP or JS block that causes the thing to crash, it is your responsibility to fix it, just as it is now. And that’s how it should be fair both to users and for a respectable author. Again, and I need to reiterate this -> IT WOULD NOT fall on your shoulders to fix design/styling issues of your plugin in another author’s theme, as long as the mechanism of the plugin works perfectly. Let me give an example:

You create a tab shortcode functionality. User switches themes. Tabs stop floating, lose colors and whatever else you want from the styling, BUT they retain the translation from shortcode to visual HTML, maybe even the JS actions of clicking to show each tab.

- OR:

A buttons shortcode will return a simple unstyled A tag, instead of one using predefined color, backgrounds, border-radius and so on.

These two examples SHOULD NOT fall on your shoulders as to support and to update to a user’s new theme. Catch my drift?

If I’m not mistaken, the whole point of these new guidelines and the whole point of moving everything to plugins is so when the user switches themes, the user would still have all his content displaying properly. For example, the shortcode plugin. The idea of this is, if the user switches themes, he can still keep the shortcodes, but this idea wouldn’t work if the shortcodes won’t include the appropriate style and layouts. It will only create additional work for the buyer because now he either has to restyle these shortcodes or switch to the new themes shortcode plugin.

This whole concept of moving everything into plugins has drifted so much from it’s original intentions.

If we are now going to be creating plugins that won’t be appropriately styled for other themes, then I don’t know what the point is for all this.

33 posts
  • Has been part of the Envato Community for over 2 years
  • Has collected 1+ items on Envato Market
  • Sells items exclusively on Envato Market
  • Located in United States
JonnyShogun says

1. “we are now becoming plugin developers”. Haven’t you been a developer already!? Just because you move PHP code from theme to a plugin that has a definition, activation and deactivation hooks makes you any different. That’s just a wrong, wrong perception.
2. “will get no compensation”. Last time I checked, feature jam-packed themes sold for more than regular, simpler themes. This means… what does it mean? Compensation.

i know the difference between developing themes and plugins. I can understand shortcodes being made into a plugin. Im just saying that by making all functionality into a plugin for things like slider options, widgets.. just makes it easier for someone to steal your code since they don’t have to search through your whole theme. Now its in a plugin, and easy pickings.

When i talk about compensation.. im talking about compensation for your theme specific plugin being used in another theme. I understand separating our functionality into a plugin for our theme but i don’t see the purpose of having it available to be used in other themes when it was created to be used with just your theme. With the exception of shortcoodes, so the content doesn’t break when the theme is switched, which was the main reason all this plugin stuff started anyway.

642 posts
  • Has been part of the Envato Community for over 3 years
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Sells items exclusively on Envato Market
ChapterThemes says

@ChapterThemes, I am sorry to disagree with your way of seeing things, but IF the issue is within your plugin’s CODE, its functionality, it falls on your shoulder to fix it, no matter the theme it gets applied to. If you have a poorly written PHP or JS block that causes the thing to crash, it is your responsibility to fix it, just as it is now. And that’s how it should be fair both to users and for a respectable author. Again, and I need to reiterate this -> IT WOULD NOT fall on your shoulders to fix design/styling issues of your plugin in another author’s theme, as long as the mechanism of the plugin works perfectly. Let me give an example:

You create a tab shortcode functionality. User switches themes. Tabs stop floating, lose colors and whatever else you want from the styling, BUT they retain the translation from shortcode to visual HTML, maybe even the JS actions of clicking to show each tab.

- OR:

A buttons shortcode will return a simple unstyled A tag, instead of one using predefined color, backgrounds, border-radius and so on.

These two examples SHOULD NOT fall on your shoulders as to support and to update to a user’s new theme. Catch my drift?

Well in this case you don’t totally disagree with me.

Like i said before – it’s easy to supply simple function styling so that every feature keeps working but in a very basic form. And have theme-related styling inside the theme stylesheet.

Also, when discussing this, i talk about good coded themes and plugins ofcourse.

People worry about lame simple things as column shortcodes, tabs? Hell those things are like a gazillion around – those are not features that make a theme unique.

I do however have the oppinion that advanced super features for some niche theme should not be portable as a fully working plugin inside other themes – EXCEPT if the theme price will go from say 45 to 70 bucks – since then people will also purchase a plugin which they can fully use.

But i’m just debating some points here, trying to get an answer and see how other think about it.

I myself see no problems as i already know how i’m going to set things up: Already since a while i’ve been working on a set of super plugins. Besides that i’m working on beautiful themes that work perfectly and look nice with my own plugins. Plugins go on Codecanyon, themes go here on TF :) a voilà, besides the fun of creating – i see business

478 posts
  • Has been part of the Envato Community for over 6 years
  • Has sold $10,000+ on Envato Market
  • Had an item featured in an Envato Bundle
  • Won a Most Wanted contest
+5 more
QBKL says

@Jaynesh, mate, don’t get me wrong. I don’t see that solution as good practice and I’d never consider it myself. It was merely a suggestion for people that think that if a user that has already paid for that functionality should not be able to use it for as long as he wants to, properly, as long as it’s used IN JUST ONE PLACE at a given time. I don’t think that the license of the plugin expires once you’ve uninstalled the theme because authors are getting paid for that functionality in addition to the design. Bottom line, I do believe in fallback styling for the plugins than can be overwritten from the theme’s stylesheet and that should be standard.

PS: There was no need to quote such a long post. A simple @QBKL would have sufficed.

@Theme-Desert, maybe I was not clear the first time. Let me give it another shot. So, you’re saying…

Im just saying that by making all functionality into a plugin for things like slider options, widgets.. just makes it easier for someone to steal your code

We have 3 scenarios here:

1. Someone downloads a RIP of your theme from somewhere. Goes into it and grabs the plugin code. And the fact that they stole your plugin is your main issues? Bro, they stole your WHOLE theme! The plugin part is just an “added bonus”.

2. A user buys your theme and “steals” your plugin by using it on another theme. Well, they paid for it. Even more than they would have on CodeCanyon, as they also paid for the design. How is this stealing?

3. An unknown author gets (buys/RIPs) your theme from somewhere and ports your plugin to their theme. Any author that would want to steal your functionality DOES NOT need it to be a plugin. The knowledge required to move such functionality from one theme to another is pretty darn simple and a person of bad faith would do so anyway.

My point is that the whole stealing issue is A NON ISSUE as it always, always falls in a smaller part of a bigger “crime”. Again, you can always sell simple themes and recommend users to pay that extra buck on CodeCanyon for the premium plugin. And this leads to compensation>

When i talk about compensation.. im talking about compensation for your theme specific plugin being used in another theme.

Why should you receive extra compensation if a user decides to use your plugin in another theme? Did the user pay for the initial package? Yes. Does he use more than one copies of it if he bought a regular licence? No. Did he pay extra for that plugin? You’re damn right he did! He paid on average $45 to $60 compared to $30-$35, a simple theme’s price. So how’s the extra $15 to $30 as compensation for your plugin? Sounds good to me.

The only difference here my friend is that THE USER pays the whole amount in just one place: ThemeForest for $55, instead of buying your simple theme (or as some like to call it – skin – though it’s the same thing no matter how pompous you want to make it sound) from ThemeForest for $35 and your plugin from CodeCanyon for $20.

You get compensation.

Helpful Information

  • Please read our community guidelines. Self promotion and discussion of piracy is not allowed.
  • Open a support ticket if you would like specific help with your account, deposits or purchases.
  • Item Support by authors is optional and may vary. Please see the Support tab on each item page.

Most of all, enjoy your time here. Thank you for being a valued Envato community member.

Post Reply

Format your entry with some basic HTML. Read the Full Details, or here is a refresher:

<strong></strong> to make things bold
<em></em> to emphasize
<ul><li> or <ol><li> to make lists
<h3> or <h4> to make headings
<pre></pre> for code blocks
<code></code> for a few words of code
<a></a> for links
<img> to paste in an image (it'll need to be hosted somewhere else though)
<blockquote></blockquote> to quote somebody

:grin: :shocked: :cry: Complete List of Smiley Codes

by
by
by
by
by
by