611 posts
  • Member of the Envato Team
  • Had an item featured in an Envato Bundle
  • Made it to the Authors' Hall of Fame
  • Contributed a blog post
+10 more
Siddharth Envato team says


Isn’t this what a lot of complaints are about?
Umm, no, I don’t think that’s what the main concern is about.


And, as a customer, I don’t want to have to install and maintain a bunch of plugins…

This is the kind of situation that the TGM class is meant to fix. The class can handle automatic installation and activation which is what I’m seeing the main pain point is about. You can reference pre-packaged plugins, plugins from the WordPress Plugin Repository or even plugins hosted elsewhere on the internet.

What we’re asking for us is modularization and a little more flexibility.

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

This is the kind of situation that the TGM class is meant to fix. The class can handle automatic installation and activation which is what I’m seeing the main pain point is about. You can reference pre-packaged plugins, plugins from the WordPress Plugin Repository or even plugins hosted elsewhere on the internet. What we’re asking for us is modularization and a little more flexibility.

But, it doesn’t fix anything, it just adds complexity and shifts the responsibility to the user where before there was none for them.

I understand what you’re asking for and why, I just think the user is going to be the one who really suffers as a result. And ultimately, they will be the ones who decide if this was a good move or not.

My gut feeling says that TF is getting dangerously close to being just another theme repository like on WordPress.org. Nothing wrong with WP.org, it serves millions of people, but TF currently serves those who are not served by WP.org. Just bear that in mind. ;)

Scott
“These are just my opinions, I could be completely wrong.”

578 posts
  • Has referred 10+ members
  • Has sold $40,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Located in Slovakia
+3 more
LubosVolovar says

This whole shortcodes thing can easily lead to the point when the authors and buyers just move to another marketplace without such restriction. But don’t be apocalyptic here. Envato should really release some official tutorial on how to do the shortcodes properly and maybe it will be ok at the end.

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

include_once "file.php" == bad
require_once "file.php" == ???
Just making sure.
Is file including bad, or is “unimportant file” including bad ?

Neither are inherently bad, it’s situation-dependent. We’ll put together some further clarification on this.


Correct me if I am wrong (didn’t read the whole thread) but I think the point of using “shortcode plugins” is to prevent the “lock in” effect you get if you use a theme and then want to switch and none of your shortcodes work any longer.

Therefore it should be sufficient to provide a small self written plugin for your customers so they can switch theme whenever they want and keep their shortcodes working. Thats what I plan to do.

I definitely wouldn’t use a public repository plugin for my shortcodes. (And to be honest: if envato wants to enforce these requirements to existing themes that wouldnt work anyways, since all these plugins use different shortcodes than the ones used in themeforest themes. Implementing them now would break all existing shortcodes which is probably not the best idea ;D )

In all honesty I think Envato did a rather mediocre job with this requirements (most of them are good but a lot of them lack examples or clarification).

A handfull Elite Authors were pitched with these requirements months back. I at least provided extensive feedback and I think none of my suggestions or clarifications found their way into this draft. I am not surprised about this 18 page discussion :P

Thanks so much for the feedback you gave. I’m still advocating for some of the changes you suggested. I imagine you’ll see them in v2.0 :)


One thing I have to mention, again, is that for something so important to the core of this site, it’s products, and thousands of peoples sole way of earning a living, you did another awesome job of placing this on a blog (notes) that no one reads, started a forum thread on the 4th of July (the biggest holiday in the US and many have taken a few days off and may miss this), and didn’t put a message on authors dashboard, nothing in the notices section of my dashboard and no banner at the top to inform us. A real disappointment yet again Envato – you do seem to excel at this issue…..

Thanks for the feedback, but we did globally sticky this forum thread, and closed comments on the Notes post (as it was a secondary announcement for those who do read it). Apologies for the conflict with the 4th July too, that was definitely an unfortunate oversight.

There is now a notice in the author dashboard about this announcement!


After the grace period is over how will you handle themes that aren’t fully meeting these requirements. Will you be treating the top selling items and the not-so top selling items equally? If an existing item that isn’t selling much doesn’t meet these requirements, you will most likely soft reject it but will you do the same for an item that has 300+ sales a week?

Firstly, we’re currently only talking about newly submitted themes, so it would be impossible for a newly submitted theme to have any sales. However, when the time comes to apply these standards (after revision based on this discussion) to existing themes, I don’t see why we would be more lenient based on sales. If anything, it’s more important that a theme selling well complies with standards.


1. It will be ok to use shortcodes if I put them into a plugin? And for shortcodes that are inadmissible I have to provide other plugins to do the job? So all in all in the end we will provide a theme with TGM that will install 20 other plugins right?

The list of admissable and inadmissable shortcodes relates to inclusion in the theme itself. Inadmissable shortcodes, or any shortcodes for that matter, should be implemented via a plugin (custom or existing).


Just one thing I disagree (as many others here); my honest opinion is that add a limit to the shortcodes functionality affects creativity and flexibility coding a WP theme; every author has a way to create great items to be released here. The shortcodes is an interesting feature in the WordPress themes. A lot of people is happy adding just few words between [] instead of adding widgets in (only) the available sidebars. Following the new requirements, sidebars would define the limit for the shortcodes usage.

Can you explain why you think this? It’s not “No shortcodes anywhere ever!”, we’re just saying that certain shortcodes must be implemented via a plugin.


Custom headers and custom backgrounds are not always needed. Similarly, add_editor_style() isn’t always needed if the theme’s typography matches the editor.

Great catches, thank you :)


Good, and how about portfolio features? Like, we have some incredible portfolio idea and of course, no plugin is available for it. Why would I create it in a plugin for another user to use with another theme? It’s my idea, my plugin, created for that specific theme, not for all the themes available here. Why would I provide support for someone using another theme? About social options or icons, maybe I want my own icons, there’s no plugin for them, I should create a plugin for them too, yeah, because of damn standards.

Standards means no creativity and use of as-generic-as-possible layout with as-many-free-plugins-as-possible. The best combination.

And for pricing tables, why would I be limited to some dummy generic layout some plugins offer me, when I maybe have like some killer ideas for those pricing tables? Because standards, that’s why

We have a really neat marketplace called CodeCanyon, you could always sell your portfolio plugin there and recommend it for use with your themes to get that functionality.


@FinalDestiny I don’t have an answer for you on portfolios. That is a tricky one, but I don’t think Envato is disallowing portfolio post types, so you are still free to do those as you wish.

As @Astoundify mentioned, perhaps Justin Tadlock’s Custom Content Portfolio plugin could work for some authors?


Even though you modified the plugin you can still use your version > zip it up and utilize the TGM class. I have plugins I’ve written and I still use the activation class instead of including them directly in the theme files.

Yes, exactly! Nice work :)


note TGM Plugin Activation class. throws a bunch of warnings not listed in the acceptable cases(theme check plugin)

Good note, thanks Chris. Thomas is looking into that for an update to TGMPA.



Also by placing your major features in a plugin, you can really easily include those features in all of the themes you build. Update the plugin once and all of your themes have the update. So much easier to maintain.
This statement right here should at least strike something in the heads of those theme developers here that don’t think they should be using plugins. If nothing else, think of the amount of hours you will save using (even your own) plugins when developing your themes.

I’m actually surprised this wasn’t raised earlier in the discussion. It seems to make a lot of sense to me, I’d be interested to know more about you guys’ thoughts on it. Why might you think this isn’t easier / better?


can we also add a SSL check for all external scripts/styles loaded, Ive had some cases where assets fail because of SSL.
function prefix_styles(){
//Check if is ssl
$schema = is_ssl() ? 'https://' : 'http://'; 
wp_register_style( 'cw-font', $schema . 'fonts.googleapis.com/css?family=Noto+Sans:400,700,400italic' , array(), 1.0 , false  );    
}

Perhaps it would make more sense for these assets to be loaded without the protocol so they adopt whatever the current protocol is? Thoughts?


Unsure about the whole plugin concept – theoretically you’re making it hard for buyers to “buy” a theme. If what your stating is concrete a user will buy a theme via TF and have to download additional plugins for that theme to work, doesn’t this mean that a user is purchasing a broken theme from the start and will have to piece it together like a jigsaw puzzle – this is very bad for business and will force a lot of users to start selling away from TF (We saw it and thought we might move somewhere else for our debut theme).

Themes should work fine without the plugin in this case, and just gracefully degrade. Once the plugin is activated, the theme then incorporates that functionality.


And my another little problem would be the fact that, each theme being unique, having one plugin for shortcodes isn’t enough, each theme has individual features, individual shortcodes, basically demanding a new plugin for each theme. And this only for the shortcodes, if you have a portfolio too, you need another plugin. If you have something else, another plugin, we end up selling more plugins than the whole theme itself, let’s not forget that we’re on ThemeForest and not CodeCanyon.

Why is that? Why not be on both? (Genuine question!)


twitter api v1.1 need curl and base64_encode, so it’s allowed? or ignore it and don’t use twitter feeds as widget

Twitter API v1.1 doesn’t need curl (use WordPress functions instead, it’s what they’re there for), and base64_encode is listed as an exception to the rule (so is allowed) :)


If Themeforest wants me to add this functionality to a plugin, there should be a way for me to also be able to update my plugin. simple as that. Its the distrubution that’s the problem.

Quite right. The auto-update functionality we have for ThemeForest doesn’t yet work the same way with CodeCanyon. We need to fix this!


Just saying it’s an option. If you do not want to share your plugin (which is fine), then include your own custom updater like @Astoundify mentioned. As far as I know TF does not prevent this, but if they do, it SHOULD be allowed.

It is allowed, and at some point CodeCanyon itself will support this, as ThemeForest does.


Most of the discussion here is simply the result of bad communication by Envato if you ask me. The draft for those rules was available months ago and was sent to some authors for feedback. This is part of what I provided as feedback:

...

I still think this makes sense and I think if it would have been added to the requirements this thread would probably have 15 pages less :P

Agreed :(

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

Ouch… sorry about the mammoth post! :shocked:

28 posts
  • Has referred 10+ members
  • Has sold $40,000+ on Envato Market
  • Has collected 100+ items on Envato Market
  • Sells items exclusively on Envato Market
+2 more
Tiguan says

Hi everyone,

I’m still a bit confused about inclusion of commercial plugins via the TGM Plugin Activation class.
If commercial plugins used by most theme authors, should be included via the TGM Plugin Activation class only, how buyers can auto update those commercial plugins? Thus new standards will force themes buyers to buy plugins already included in their themes, so that they can update them? But, how about if I’ve modified such comercial plugin embedded in my theme to meet my theme design requirements?
It seems that the new standards will increase sales on Codecanyon, but the Themeforest sales will drop dramatically if there will exist only blog style themes, limited to design. Maybe I’m wrong and I’m sorry for that, here is still morning and I might not be completely sobered :)

But would be interesting to see some feedbacks from buyers. In fact, Themeforest is made it chiefly for buyers.

Thanks.

10 posts
  • Has been part of the Envato Community for over 5 years
  • Has collected 10+ items on Envato Market
  • Located in United States
georgestephanis says

can we also add a SSL check for all external scripts/styles loaded, Ive had some cases where assets fail because of SSL.
function prefix_styles(){
//Check if is ssl
$schema = is_ssl() ? 'https://' : 'http://'; 
wp_register_style( 'cw-font', $schema . 'fonts.googleapis.com/css?family=Noto+Sans:400,700,400italic' , array(), 1.0 , false  );    
}

Actually, since WordPress 3.4, I believe, you can just enqueue scripts and styles as

wp_register_style( 'cw-font', '//fonts.googleapis.com/css?family=Noto+Sans:400,700,400italic' , array(), 1.0 , false );

Leave off the http: or https: entirely—the browser is built to automatically use whichever version the current page is on.


twitter api v1.1 need curl and base64_encode, so it’s allowed? or ignore it and don’t use twitter feeds as widget

Or just use Jetpack’s Twitter Timeline widget, and let it handle all the API wrangling for you. :)


stuff

other stuff


A little something to think about … What do the buyers want?

Is every buyer a full time or part time web dev? Absolutely not, in fact from what we’ve experienced I’d be confident in saying at least 50% of our users are Tom, Dick and Harry building their website for their own local business.

They want an all in one package, and that’s why they bought a theme from Themeforest.

To an extent, perhaps, but as creators, we all have the responsibility to provide a quality product, which (in my view) necessarily entails being responsible with regard to the methods used to create said product. Don’t break things, play nice with others. Respect the decisions of the users—and embrace it. If you only support the one crappy contact form with the limited options you’re bundling with the theme, then you’re limiting your users, as opposed to supporting a couple third party offerings (which will be more reliable, more features, and happier users)


Sad but true, these WP guys cannot understand that we build custom WP theme here. Seems they push us to providing theme that can work for any type of business. First GPL problem, now this new requirements, what next ? “We will move all your themes into wp.org theme repository” :D

Oh come now, that’s just silly. Then how could Envato make money?

But seriously, GPL is just a licensing option. Nobody is forcing it on anyone. It’s making more options available to creators that want it, not taking any options away or limiting you in any fashion.

Yeesh, overdrama much?

IN SUMMATION

Most of these guidelines are built around the principle of forward-thinking. Consider the full life cycle of your theme. Eventually, your users will want to move from your theme (or ‘full website solution’) to another theme instead. When that happens, will their existing content that they’ve spent the past few years building suddenly break? Disappear? It shouldn’t. If it does, you’re doing_it_wrong().

49 posts
  • Has been part of the Envato Community for over 6 years
  • Has collected 1+ items on Envato Market
carlhancock says

As a customer, I see these as turn-key site packages, not strictly as themes. And, as a customer, I don’t want to have to install and maintain a bunch of plugins, or care whether WordPress is being used properly with style and functionality split between themes and plugins.

As a WordPress expert and one f the co-founders of one of th most successful commercial WordPress plugins in existence I would say your quote above scares the shit out of me.

WordPress isn’t set it and forget it. The more functionality a theme provides, the less likely it will ever be updated because of how most people implement themes by not using child themes. Which means the more vulnerable it will be down the road for those with malicious intent to take it over and put it to work as part of a malware botnet, etc.

Plugins allow functionality not just to be enhanced, not just for new features to be introduced, but more importantly for bugs to be fixed and even more important than that… security patches to be applied. And to do so on its own schedule without having to update everything else. Only the plugin containing the functionality that needs to be updates or fixed would need to be updated, not everything else.

Users should ALWAYS keep WordPress up to date. Users should ALWAYS keep all of their plugins up to date. If you don’t, you leave your site vulnerable to malware, being hacked, etc.

Themes incorporating large amounts of functionality that should really reside in a plugin this means the theme is introducing large amounts of functionality that likely will never be updated because the truth is most users don’t update their theme once it’s been customized because most users don’t use child themes. They simply edit the theme directly to customize it which makes theme updates difficult, if not impossible, to do. Which is why themes are rarely updated after installed on a site.

You don’t care if WordPress is being used properly with style and functionality being split properly between themes and plugins? That is shocking because as important as my own web sites are to our business I would want to make sure that the theme I use and all plugins I use are built using best practices.

What you just said is you wouldn’t care if you bought a house that is architected incorrectly and while it looks beautiful on the surface, a few months or a year down the road the entire thing could collapse on you. That is what will happen if you don’t take which themes and plugins you choose to power your WordPress site seriously AND neglct them by not keeping them up to date.

Out of curiosity, are you buying these themes to use for yourself of are you buying these themes to build sites for clients? Because if this is your attitude towards best practices you need to educate yourself on WordPress best practices and start taking them more seriously because they are critical to the security of a WordPress powered web site. And if this is your attitude towards best practices and your passing this attitude on to your clients you are doing an extreme disservice to your clients

The very thing you love about the poor practices being used by some theme developers is the very thing that could lead to disaster for any sites you manage down the road.

Just because something looks good on the surface doesn’t mean it isn’t a disaster under the hood. In the past some of the top selling themes on ThemeForest caused us constant support tickets related to conflicts they caused due to not following besg ractices. they were themes that looked beautiful, which is why they were best seller, but they we rotten under the bood

If all you care about is the surface, then sooner or later you’re going to run into major problems due to what is under the hood.

Not caring if your site is built with themes and plugins that follow best practices is baffling to me. Truly baffling.

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

Gonna play devil’s advocate here…


We have a really neat marketplace called CodeCanyon, you could always sell your portfolio plugin there and recommend it for use with your themes to get that functionality.
CodeCanyon is great, but I don’t think it’s a viable solution here. If I’m a user and I buy a theme on TF that has some certain functionality, then I find out I have to buy a plugin on CC, I’m going to be very upset. Selling functionality twice is very dishonest, IMHO.



As @Astoundify mentioned, perhaps Justin Tadlock’s Custom Content Portfolio plugin could work for some authors?
Perhaps for some authors, but last I checked (which has been a while), it was a very generic plugin that didn’t support the fields I use.




Even though you modified the plugin you can still use your version > zip it up and utilize the TGM class. I have plugins I’ve written and I still use the activation class instead of including them directly in the theme files.
Yes, exactly! Nice work :)
Doesn’t the TGM class require the plugin be hosted on a free repository in order to be “automagically” installed? If I’m an author and I’m selling functionality on TF, I wouldn’t want it available for free. Otherwise, what am I selling?





Also by placing your major features in a plugin, you can really easily include those features in all of the themes you build. Update the plugin once and all of your themes have the update. So much easier to maintain.
This statement right here should at least strike something in the heads of those theme developers here that don’t think they should be using plugins. If nothing else, think of the amount of hours you will save using (even your own) plugins when developing your themes.
I’m actually surprised this wasn’t raised earlier in the discussion. It seems to make a lot of sense to me, I’d be interested to know more about you guys’ thoughts on it. Why might you think this isn’t easier / better?
Personally, I think it a wash. You can make valid arguments for and against its usefulness.




can we also add a SSL check for all external scripts/styles loaded, Ive had some cases where assets fail because of SSL.
function prefix_styles(){
//Check if is ssl
$schema = is_ssl() ? 'https://' : 'http://'; 
wp_register_style( 'cw-font', $schema . 'fonts.googleapis.com/css?family=Noto+Sans:400,700,400italic' , array(), 1.0 , false  );    
}

Perhaps it would make more sense for these assets to be loaded without the protocol so they adopt whatever the current protocol is? Thoughts?
I believe scripts should ideally be loaded with no protocol specified ex:
//domain.tld/filename.ext
, but keep in mind that that doesn’t work on local (MAMP-based) servers where the protocol is
file://dir/dir2/filename.ext
.




And my another little problem would be the fact that, each theme being unique, having one plugin for shortcodes isn’t enough, each theme has individual features, individual shortcodes, basically demanding a new plugin for each theme. And this only for the shortcodes, if you have a portfolio too, you need another plugin. If you have something else, another plugin, we end up selling more plugins than the whole theme itself, let’s not forget that we’re on ThemeForest and not CodeCanyon.
Why is that? Why not be on both? (Genuine question!)
Because as Siddarth stated above, the reason you’re doing this in the first place is flexibility and modularity. ;)


Scott
“These are just my opinions, I could be completely wrong.”
435 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 have a question: By using plugin for functionality, if I have 2 portfolio features for 2 themes and both portfolios are totally different in functions, it means that I need to create 2 separate plugins for each portfolio as well? Then I need to use TGM to point to the plugin zip that bundled with the theme. Am I correct about this?

Does the whole concept mean to just moving any functionality into the plugin? Just like that?

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