20 posts
  • Has been part of the Envato Community for over 1 year
teamCrisis says


Suppose that I have one plugin that can handle all the functionallity, however when it is activated nothing shows, because I must initiate parts of it somewhere. Now the question I want to know if this is allowed, to init these parts inside my theme or I must create another plugin for this(let’s say “Theme Functions”).
Example:
Plugin Core: contains multiple PHP classes.
class My_Metabox {...}
class My_theme_Options{...}
class My_CPT{...}

Theme: Init these classes inside my theme so when the user activate my theme and if the plugin(Plugin Core) is activated it will show the options required for this particular theme:

if(class_exists('My_Metabox ') ) {
    $meta_options = array(
        //all options for my metaboxes
    )
    new My_Metabox($meta_options);
}
//A similar call for other classes: My_theme_Options, My_CPT, etc.
...

So, is allowed to do such calls from theme?
It should be, that’s how I’m doing it too.

So if a user installs and activates your theme and plugin and everything works fine, then switches to new theme, your plugin metaboxes and CPT no longer show? Is this the general idea?

If so, doesn’t that defeat purpose of making it a plugin to begin with? Plugin idea is to allow user to access the information no matter what theme they use. I think it should always show in backend, but maybe not do anything or not look good on the frontend if the plugin is activated on a theme you didn’t create it for.

Maybe I misunderstand what you mean.

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



Suppose that I have one plugin that can handle all the functionallity, however when it is activated nothing shows, because I must initiate parts of it somewhere. Now the question I want to know if this is allowed, to init these parts inside my theme or I must create another plugin for this(let’s say “Theme Functions”).
Example:
Plugin Core: contains multiple PHP classes.
class My_Metabox {...}
class My_theme_Options{...}
class My_CPT{...}

Theme: Init these classes inside my theme so when the user activate my theme and if the plugin(Plugin Core) is activated it will show the options required for this particular theme:

if(class_exists('My_Metabox ') ) {
    $meta_options = array(
        //all options for my metaboxes
    )
    new My_Metabox($meta_options);
}
//A similar call for other classes: My_theme_Options, My_CPT, etc.
...

So, is allowed to do such calls from theme?
It should be, that’s how I’m doing it too.

So if a user installs and activates your theme and plugin and everything works fine, then switches to new theme, your plugin metaboxes and CPT no longer show? Is this the general idea?

If so, doesn’t that defeat purpose of making it a plugin to begin with? Plugin idea is to allow user to access the information no matter what theme they use. I think it should always show in backend, but maybe not do anything or not look good on the frontend if the plugin is activated on a theme you didn’t create it for.

Maybe I misunderstand what you mean.

@teamCrisis</srong> Your missing the point of making the custom functionality in themes into a plugin. Its not to allow ALL your functionality in your theme to be available to other themes. The STAFF and SUPPORT have said that its to separate the custom functionality you add to the theme, from the core. It is to also make sure that when a user switches to a different theme, that the content doesn’t break because of shortcodes and custom post types for the content and data.

So we are still waiting on clarification from STAFF and SUPPORT, if theme specific options (Like Slider options and Theme options) that are made into plugins, that don’t affect content and data will be allowed to have a theme check, to only be available to our theme. While still keeping all the users content and shortcodes intact.

138 posts
  • Has referred 10+ members
  • Has sold $75,000+ on Envato Market and is now an Elite Author
  • Has collected 50+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+2 more
M-Theme says

Suppose that I have one plugin that can handle all the functionallity, however when it is activated nothing shows, because I must initiate parts of it somewhere. Now the question I want to know if this is allowed, to init these parts inside my theme or I must create another plugin for this(let’s say “Theme Functions”).
Example:
Plugin Core: contains multiple PHP classes.
class My_Metabox {...}
class My_theme_Options{...}
class My_CPT{...}

Theme: Init these classes inside my theme so when the user activate my theme and if the plugin(Plugin Core) is activated it will show the options required for this particular theme:

if(class_exists('My_Metabox ') ) {
    $meta_options = array(
        //all options for my metaboxes
    )
    new My_Metabox($meta_options);
}
//A similar call for other classes: My_theme_Options, My_CPT, etc.
...

So, is allowed to do such calls from theme?

If the plugin has not actived, the theme will lost the CORE CLASS. The theme must be running without the plugin.

366 posts WordPress Guy
  • Has referred 1+ members
  • Has sold $100+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Member of the Envato Team
+5 more
Japh Envato team says

Hey everyone, I hope the following responses help provide some clarifications.

If I missed your question, or my response is actually more confusing than clarifying, I apologise and will happily clarify further.

Again, I apologise for the long reply, and the long wait, I didn’t expect 6 pages! ;)

====================================================================


Continue to my above question: If the theme must be running without my plugin, I think the metabox and options both need to in the theme. Otherwise the user just got a twentytwelve theme after they paid $30-50.

Agreed :)


I have two question though, and i’ll take a practical example to illustrate my concerns. Let’s take my theme WowWay. I have two custom post type, but let’s say that i’ll move all the functionality inside a plugin and do the following:

...

Maybe i wasn’t too clear, but i would definitely like to hear your input on these concerns of mine.

I agree with @ChapterThemes’ reply to you on this.


Assumption is the killer of all!!!

I have in-fact owned my own web design agency for 10 years now, we have well over 50 WordPress clients a year (Not much I know but I tend to not push WordPress due to it being heavy code) and not once have I ever been asked these questions.

Please don’t think I’m against this because I am not, I think its a good thing that users will have easy to switch theming but they are not the problem.

As every author on here knows, its the bad developers, who like to steal code, this just makes it easier to do this, because all they have to do is change a few variables and style them and voila they have there self some amazing functions.

I felt for sometime that authors have been taken for a mug a lot by some authors and Envato, and it just seems that we will get more frustrated by theft than we did before.

Envato in the past just say: “You are the copyright owner and you need to fight it”.

I think if you are making things more transparent for thieves then we need more help from yourselves!

You’ve been lucky not to have been asked then! :)

Regarding thievery, can you please elaborate on how you think this creates/exacerbates a thievery problem?


Question 1: Is it allowed to let a plugin check the current theme info and let it only work if the info matches the theme it has arrived with? Question 2: Is it allowed to require the theme purchase code as a setting before any of the plugin features work?

I would need to check this with the review team. Though I imagine if this kind of behaviour was acceptable, it would be better to do it by requiring the key to access the plugin prior to install, rather than having the plugin there but disabled.


basically when a user sets the Twitter Widget ID in the admin in one place, versus having to put that Twitter Widget ID in a input field in every Twitter Widget block.

This seems to me like it could be just as easily done in the plugin.


i can see how both possibilities they can do now, but it looks like that making the slider options into a plugin, just make it easier for people to just grab your code since now its portable via a plugin

I already am using TGMPA. How would you make it available on a server with a key?

Also what the point on making slider options into a plugin, when a user can not use it on another theme, since all the files for it to work on the frontend are in the theme itself??

thanks again JAPH !!

See @QBKL’s post above yours.


What made Envato/Themeforest what is it today is using “complete-website-in-one-for-$45” as a selling point, if they were simply skins from the start there is absolutely no way it would be as big as it is today.

This is an interesting point, because in my personal experience of assisting freelance clients with ThemeForest themes, this was certainly the original selling point, but it quickly became obvious that there was a lot more work involved in actually getting the theme to play nicely.


Suppose that I have one plugin that can handle all the functionallity, however when it is activated nothing shows, because I must initiate parts of it somewhere. Now the question I want to know if this is allowed, to init these parts inside my theme or I must create another plugin for this(let’s say “Theme Functions”).
Example:
Plugin Core: contains multiple PHP classes.
class My_Metabox {...}
class My_theme_Options{...}
class My_CPT{...}

Theme: Init these classes inside my theme so when the user activate my theme and if the plugin(Plugin Core) is activated it will show the options required for this particular theme:

if(class_exists('My_Metabox ') ) {
    $meta_options = array(
        //all options for my metaboxes
    )
    new My_Metabox($meta_options);
}
//A similar call for other classes: My_theme_Options, My_CPT, etc.
...

So, is allowed to do such calls from theme?

I guess it depends what you mean by ‘init’, but assuming you are describing something like WordPress’ add_theme_support(*) functions, that sounds sensible to me.

Essentially, the plugin has certain functionality that themes can then opt to support. The plugin then should display the configuration options for the aspects of functionality that are a) generically needed by the plugin, and b) that the theme has opted into.

The theme doesn’t need to do anything more than say to the plugin “Enable X functionality please, and I will provide styling overrides etc. for it, you handle the configuration”. Make sense?


Im not just randomly saying this. The reason i said that my slider options and theme options need to go in a plugin, in Phase 2 starting in November, is because that’s the answer Enavto Support gave me TODAY when i emailed them about it. They said they will be requiring all functionality, even theme and slider options and pages ported to a plugin. Thats what they told me. So thats what im going by!

Can you please provide me with the support ticket ID on this so I can clarify?


Can you please clarify an issue we are having regarding a support email reply we have received regarding these new requirements? The actual back-and-forth conversation is too long to post here but here is a snippet

Can you please provide me with the support ticket ID on this so I can clarify? The requirements are the requirements. If we change them, they will be updated.


So if a user installs and activates your theme and plugin and everything works fine, then switches to new theme, your plugin metaboxes and CPT no longer show? Is this the general idea?

If so, doesn’t that defeat purpose of making it a plugin to begin with? Plugin idea is to allow user to access the information no matter what theme they use. I think it should always show in backend, but maybe not do anything or not look good on the frontend if the plugin is activated on a theme you didn’t create it for.

Maybe I misunderstand what you mean.

This should definitely be taken into account. On deactivation, nothing should really be deactivated to the point that a user loses access to their data, surely?

631 posts
  • Has referred 50+ members
  • Has sold $40,000+ on Envato Market
  • Has been a beta tester for an Envato feature
  • Has collected 100+ items on Envato Market
+6 more
UBLThemes says


Assumption is the killer of all!!!

I have in-fact owned my own web design agency for 10 years now, we have well over 50 WordPress clients a year (Not much I know but I tend to not push WordPress due to it being heavy code) and not once have I ever been asked these questions.

Please don’t think I’m against this because I am not, I think its a good thing that users will have easy to switch theming but they are not the problem.

As every author on here knows, its the bad developers, who like to steal code, this just makes it easier to do this, because all they have to do is change a few variables and style them and voila they have there self some amazing functions.

I felt for sometime that authors have been taken for a mug a lot by some authors and Envato, and it just seems that we will get more frustrated by theft than we did before.

Envato in the past just say: “You are the copyright owner and you need to fight it”.

I think if you are making things more transparent for thieves then we need more help from yourselves!

You’ve been lucky not to have been asked then! :)

Regarding thievery, can you please elaborate on how you think this creates/exacerbates a thievery problem?

Its not a recent problem, its been around since Themeforest has been around…

But just recently its getting worst, for instance only a couple of months ago a top author had their theme taken down 2 or 3 times and eventually the item was permanently disabled for purchasing another theme and then using the functionality from that theme to go within their theme.

I am sure you can remember which theme I mean without spelling it out ;)

Now, to do what that author did would have taken a bit of knowledge to do so, because some functions were a little more complex.

Now you are opening the gates for even novices to do this by giving them the code within a plugin and basically saying all you need to do is change the names of a few variables and style it to your theme.

The problem is, because WordPress is a GPL, these users are infact not breaking any laws in doing this.

If you are making things so transparent to users then I believe that Envato needs to up its game when it comes to fighting the cause with Authors rather than against.

Granted you may not hold the copyrights to any theme on here but you hold a bigger punch than 99.9% of authors.

Again I must stress we are not against this, if you check some of our feedback, especially on our latest themes you will see we are listening to our buyers and giving as much as we can to achieve their goals, but again they are not the problem, they deserve the world… Its the people who are stealing the codes which are the problem, and if anyone says this is not making it easier and could not potentially cause a little headache is being a little naive.

24 posts
  • Located in Europe
  • Sells items exclusively on Envato Market
  • Has been part of the Envato Community for over 2 years
neutrico says


Envato in the past just say: “You are the copyright owner and you need to fight it”. I think if you are making things more transparent for thieves then we need more help from yourselves!
Regarding thievery, can you please elaborate on how you think this creates/exacerbates a thievery problem?

Let’s assume we got theme which contains php files on GPL License and some css/js/images on TF License purchased.

I understand that it’s kind of dual licensing. And it’s ok.

But what about plugins that contains ONLY php code which is GPL?

In fact these plugins could be distributed via wp.org. There is no legal restriction and argument that could forbid users from taking actions which are permited on GPL License.

410 posts Keep Walking
  • Has been part of the Envato Community for over 3 years
  • Elite Author: Sold more than $75,000 on Envato Market
  • Has sold $125,000+ on Envato Market
  • Has collected 100+ items on Envato Market
+2 more
UXbarn says

I totally agree with the new guidelines. But, i am a little bit concerned about user experience. Imagine this scenario:

Common user, that does not know nothing about what is meta boxes, custom post type, shortcodes, widgets. One day this user buy a theme A, after the installation, he is asked to install a bunch of plugins too, then he do.

Plugins:

- A MetaBoxes - A Custom Post Type - A ShortCodes - A Widgets

Then, he change his mind and buy another theme, B. Oh, and he is asked to install another bunch of plugins too.

- B Widgets - B ShortCodes - B Misc.

I can keep this forever, but lets say, he stops on the fourth theme. And suddenly he realize that his admin has 3 “Portfolios” menu itens, 2 “Sliders” menus and worst, when he try to add a new Post, he discovers a lot of custom fields that he does not know how to get rid off.

In the end, there will be maybe 20-30 plugins installed, and probably with common names like “Nice ShortCodes” or “Awsome ShortCodes”. How the “noob” user, will know how to deal with that information?

I think this is an interesting point. Even though an author only create a few plugins (say 1-2 plugins) to be using with his/her theme, end users still get a number of unwanted and useless plugins installed after switching themes.

By the concept that a theme must port all functionality into plugins, the users are “forced” to install and use the plugins that come with the theme in the first place (*Well, actually they are not forced to and they can choose not to install any, but in order to make the theme works as promoted, they couldn’t refuse right? :) ).

Also, since those theme-specific plugins serve only the functionality and styles for their own brand/theme, they might be useless to be used on any other themes. Unlike other general plugins on repository or other premium third-party plugins that are designed to be used as “stand alone” and independent.

So, how can authors prevent the situation that the users will have useless theme-specific plugins installed after switching the themes?

P.S. I’m all in for the new requirements and that’s totally great for most authors to comply with standards. I think Envato is surely going to the right direction in a long-term business. But there’s just something still unclear to me. :)

1473 posts
  • Has referred 1+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Made it to the Authors' Hall of Fame
+3 more
OriginalEXE says


So if a user installs and activates your theme and plugin and everything works fine, then switches to new theme, your plugin metaboxes and CPT no longer show? Is this the general idea?

If so, doesn’t that defeat purpose of making it a plugin to begin with? Plugin idea is to allow user to access the information no matter what theme they use. I think it should always show in backend, but maybe not do anything or not look good on the frontend if the plugin is activated on a theme you didn’t create it for.

Maybe I misunderstand what you mean.
This should definitely be taken into account. On deactivation, nothing should really be deactivated to the point that a user loses access to their data, surely?

CPT should of course be preserved, but I see no reason to display options and meta fields on those cpt’s.

Since every theme will have different field needs there is no way to put them all in a plugin.

Well I can think of ways to preserve those but only if you state it’s necessary.

1336 posts
  • Elite Author: Sold more than $75,000 on Envato Market
  • Made it to the Authors' Hall of Fame
  • Has been part of the Envato Community for over 5 years
  • Has sold $250,000+ on Envato Market
+6 more
fuelthemes says

If every author has a plugin for himself, how is this modularizing themes? User will be able to see their previous data, but won’t be able to use them in the new theme. This does not really solve anything.

If we are really going forward with moving shortcodes and cpts to a plugin, I believe its best that Envato supply a boilerplate plugin.

A boilerplate plugin by Envato will push authors to use the same codes for their supporting plugins which will in return, make lives of reviewers easier.

1473 posts
  • Has referred 1+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Made it to the Authors' Hall of Fame
+3 more
OriginalEXE says

If every author has a plugin for himself, how is this modularizing themes? User will be able to see their previous data, but won’t be able to use them in the new theme. This does not really solve anything.

If we are really going forward with moving shortcodes and cpts to a plugin, I believe its best that Envato supply a boilerplate plugin.

A boilerplate plugin by Envato will push authors to use the same codes for their supporting plugins which will in return, make lives of reviewers easier.
That was already discussed and me personally don’t think it’s such a good idea.

I don’t want to have the same codebase or features as other authors, or be restricted to certain possibilities.

The ultimate goal is for data not to disappear, not from the frontend, but from the backend, where user can then use that data and decide if he wants to get rid of it or transfer to his new theme.

by
by
by
by
by
by