Guys, just posting this once again, to make sure it’s known, because this is pretty big.
Are we not allowed to construct our own plugin importers and must rely on TGMPA? Even with the biggest themes I saw, they don’t use TGMPA fully, just pull data from its globals.
Can I not make my very own plugin importer?
Hello,
I have a question about customization and basically theme initial design without plugins and demo import. All reviewers complaining about how theme should work without plugins and demo content and it must be exactly the same as a demo but without plugins or demo. I have created a similar post on a forum, I have reported it to Envato support but no answer. I’m using theme builder so all website is built with dynamic templates and blocks so basically every even smallest element has lots of style options and can be changed via page builder. It automatically makes all initial content (when no plugins or demo imported) and customizer pointless since no initial template theme files or styles are used. Basically, other developers who are using theme builder can use any default theme and after importing the demo settings the default theme will look and work like a premium one. So my question is how your new requirements cover this issue?
Thank you
Hi,
As it’s said on WordPress Plugin Requirements for JavaScript standards: “Provided code needs to pass JSLint.”
So please answer the following:
Are we allowed to tolerate…
a) long lines
b) multiple vars
c) single quote strings
d) this
e) for statement
as this is possible at http://www.jslint.com ?
Are we allowed to use Google closure compiler (https://closure-compiler.appspot.com/home) for compiling JS files because that minified files often don’t pass JSlint?
Thank you.
Hi All,
I have some more responses for you. I know there are some that I haven’t gotten around to yet, but I’ll try to do so in the next day or two.
Meeting the requirements for existing items within 12 months
Yes, that is correct.
We realise this will be a challenge for some authors, especially those with many items. In some cases it may take significant effort to meet these requirements in a way that doesn’t create problems for existing customers. We originally planned the period to be 6 months, but extended it to 12 months in recognition of this.
However, we want customers to know that the items they receive will a) be of high standard and b) be kept up to date with changing best practices and standards. We don’t want them receiving items today that fall short of the current standards simply because they were submitted in the past.
We are still working this out. We know that all items will need to meet the requirements after 12 months, but have not decided what will happen with those that do not. It will likely take us some time to create the plan, but we will communicating it with you when it’s ready.
Design metaboxes
We ask for your patience on this one, as we are discussing it further internally.
Custom CSS functionality
After further consideration, we have decided to allow the custom CSS functionality to remain for new users, as long as it does not disable or interfere with the core Additional CSS functionality. We will be updating that section of the requirements to reflect this in the next day or two.
Purchase verification - further questions
You need to make sure that the user can unlock the keygated features using just the Purchase Code. If you want to make other methods work as well, you can - so you can give the user the choice to unlock the theme using your current method OR by entering just the Purchase Code.
No, once the message is dismissed, it must remain dismissed.
We understand you want to protect your work. However, global notification messages need to follow the general usability principle of being dismissible and they cannot take over the WordPress backend. You can display non-dismissible notifications or banners, etc in the theme options panel.
Thanks for raising these concerns. I’ll pass them on and try to get an answer regarding them.
In the meantime, for your info (although you may know this already): One of our requirements is that the plugins must be in the main zip file somewhere, so Elements subscribers will have access to the plugins and can manually install them. Likewise theme updates are available by manually downloading the theme again from Element and uploading it to your server. The demo content one is trickier as it may or may not be in the zip file.
Anyway, I’ll pass on the concerns that you raised.
Bundled plugins
There are reasons we need the plugins in the zip file. In fact, one of the current (unpublished) requirements that we review to right now is that plugins must be in the zip file and cannot be offloaded. We’ve relaxed the offloading part, but we still need the plugins in the zip file (not necessarily in the theme part of it). At some point in the future we may have a better system for this, but at this point I can’t tell you if or when that will happen.
Customizer
Please see my answer above. Additionally, note the Core Settings requirements, which say:
So - you can have your own controls for core settings that are in the Customizer, as long as they can also be used in the Customizer and both are changing the same setting.
If you are using Kirki as a plugin, regardless of whether it is installed via TGM, Merlin WP or their installation script, then you do not need to sanitize the fields in your theme. If you are embedding Kirki in your theme, you should read the Plugin Inclusion requirements which say that baking plugins into your theme is not allowed and then please consider moving to use it as a plugin.
TGM PA
It has to be a TGM based system, but it doesn’t have to be plain old TGM. For example, dtbaker has a WordPress Theme Setup Wizard and Rich Tabor has Merlin WP (still in beta), both of which are based on TGM. You could use one of these or create your own experience on top of TGM. You can also have a separate process that doesn’t use TGM, as long as TGM is there and loaded in the background so it can be used via TGM WPL CLI.
Footer links
This is an SEO best practice, as footer links can trigger penalties from Google.
So, in practice, all I really have to do is, if users wish to use TGM, they are free to do so, on their own, or if developers wanna work with my theme, I must provide a way for TGM to work, but I don’t have to use it on my own setup experience, just as long as it also works (I’ve integrated it) to my theme.
Correct? 
A more technical view is: I can just integrate within the WP_Plugin_Upgrader (Used to install plugins) on my own and build my own TGMPA, but I also have to support TGMPA if customers wish to use it, instead of my functionality.
@StephenCronin Thank you for the detailed answer, You are making the market better place for us and for the people who buy our products with these updates.
As these updates are really big we hope themeforest reviewers give us more detailed reasons for the soft rejections if this will take a lot of resource then at least attach an updated reference link to the reject reason.
Thanks in advanced.
Hi,
Following the Plugin Territory Functionality:
==============================
Themes execute the presentation and styling of content, while plugins handle content creation and functionality. Anything users will lose upon switching themes is classified as plugin territory. Following are some common examples:
==============================
Question regarding forms: If my theme is considered to be a “specialty theme”, being in Real Estate category and I have features like Submit New Listing Form which is included in a special page template, is this form considered to be plugin territory?
Thank you!
Another scenario: is allowed to bundle Kirki plugin and e.g. Meta Box plugin in my own single mega-bundle plugin (also with shortcodes and another options) and then include this mega-bundle via TGMPA?
Another scenario: is allowed to bundle Kirki plugin and e.g. Meta Box plugin in my own single mega-bundle plugin (also with shortcodes and another options) and then include this mega-bundle via TGMPA?
Why would you want to do that?
In fact, I already have such a plugin for my own needs and treat it as a framework for adding additional functionalities to WordPress: custom customizer controls, shortcodes, custom fields etc. - everything what should belongs to plugin territory world. I think about better user experience. Let’s assume that a new version of the Meta Box plugin, for example, conflicts with my theme. Then I can react behind the scenes to this fact, make corrections and update the whole mega-plugin, and the client is not exposed to any inconvenience. I wonder if it makes sense…
It does make sense for your own custom functionality (CPT, widgets, shortcodes) but not for 3rd party plugins. Simply bundle the latest tested 3rd party plugin to your main .zip file and if there will be some new update which won’t be compatible with your theme you can always tell your customers to downgrade to the bundled version.
Also what if your users want to use some kind of add-on plugin for the 3rd party plugin? That add-on plugin may be written in a way that if it won’t detect that 3rd party plugin as a standalone plugin, it won’t work. If you put 3rd party plugins into your mega plugin then you are actually worsening the user experience for your buyers.
Potential downgrade idea sounds good. Thanks.
@StephenCronin as other plugin developers have outlined previously, I too face a lot of support due to plugins and themes inserting their javascript and css includes globally in the WordPress admin pages.
This practice always causes some sort of conflict in my admin pages. Please add a requirement to force all plugin and theme authors to target their admin pages only. It’s not hard and there are WordPress guidelines as to how to include assets within your respective admin pages without doing this globally.
Hi,
I’m looking over the new theme requirements and i have a question that may be fairly common. On guidelines for Envato Check Plugin we have this “Themes are required to fix all issues that result in a REQUIRED notice in the Envato Theme Check plugin. There are no longer any allowable exceptions.”
But what happens when you include some sdk (facebook, stripe etc ) and you start getting REQUIRED notices like
REQUIRED: Found base64_encode in the file libs/resources/src/service/Google_Utils.php. base64_encode() is not allowed.
Line 26: $b64 = base64_encode($data);
REQUIRED: Found Email( in the file libs/resources/src/contrib/Google_StorageService.php. Mail functions are plugin territory.
Line 692: public function setEmail($email) {
REQUIRED: Found base64_encode in the file libs/resources/facebook_sdk5/Facebook/SignedRequest.php. base64_encode() is not allowed.
Line 310: return strtr(base64_encode($input), ‘+/’, '-’);_
etc…
Is there any guideline for these kind of situations or the reviewer will allow them ?
Thanks
@StephenCronin A question regarding this part:
All menu locations must not use placeholders such as Add Menu, Set Menu, etc., as this forces the user to either add a menu or modify the theme to remove the placeholder.
Why not allowing to use menu placeholders if it is wrapped within a conditional, so only admins can see the message? Can you please check this? From our own experience, these small UX tweaks reduce customer support significantly.
P.S. This is basically the same UX approach as for edit_post_link() native WP function to make it easier for users to access the specific thing while logged in.
<?php if ( current_user_can( 'manage_options' ) ): ?>
<ul class="menu">
<li>
<a href="<?php echo esc_url( admin_url( 'nav-menus.php' )); ?>">
<?php esc_html_e( 'Click here to add navigation', 'theme' ); ?>
</a>
</li>
</ul>
<?php endif; ?>
Hello Stephen, thanks for the clarification and let me say I appreciate your good work and kind approach to authors. Anyway, what muffingroup is saying, is more than important.
By following the original themes requirements, which stated that plugins can be in our repository, we are now pointing them to our server, and periodically updating the URL for new versions.
This automatically invalidates the pirate copies, as you need an udpated theme to install the plugins.
Once this happens, our sales have an immediate peak. We need to update plugins location every week, otherwise sales goes to ZERO.
Pirated copies of updates themes are for download within 24 hours from the publication.
Envato is now stating that we have NO way to defend ourselves.
So, if authors won’t make sales, Envato won’t make money.
I understand there might be legal implications regarding products and download contents, anyway if you pursue this path, I’m sure Envato should, ad the same time, provide a valid purchase confirmation system.
For exmaple, as the Envato Market updater, why can’t TGM be directly connected to Envato, and manage the activation of the product, allowing only 1 domain at a time for each purchase code?
I’m sure this won’t be a hard job for you guys, and can provide a standard verification method that follow all the rules.
I’m still reinforcing @muffingroup concept.
Plugins in zip = piracy = no sales = I can go to bake pizzas instead of themes
Other thing: if there is no “Envato side” verification on the amount of installations/domains using the same purchase code, it means that if a pirate download contains the purchase code, we are back to the beginning.
There should be a system that stores any activation with the domain, and establish some boundaries.
In this way, Envato will also be able to identify who are the users that diffuse pirate copies.
None of those useful tools are actually provided from the marketplace, I’m pretty sure this is a big loss for Envato as well. Shouldn’t this be the biggest concern? People are literally stealing from all of our pockets, and instead of doing something about it, we are just making pockets bigger.
Yet another case when Authors bite the dust here. And this comes after the rating blackmailing and the refunds policy changes.
Technical question about this: https://help.author.envato.com/hc/en-us/articles/360000479946
Combining Scripts
Third-party scripts and libraries must not be combined. They must be enqueued individually to ensure that:
If a theme offers an optional loading method to load a combined script of particular JS libraries (not from WP and not common ones), is this ok?
Let’s say, if you want to improve performance, you can enable a customizer option, and it will load combined minified scrips instead, is it ok?
I’m asking this for a simple reason (not to mention that we already implemented this technilogy): there are quite some minification/combination plugins out there, but most of them are poorly developed, and they just make a big ball of every script, breaking them.
This “plugin” procedure, 99.9% of times, breaks the functionality, while our minified script regards only the theme’s peculiar scripts and is tested and working fine, and doesn’t require any knowledge or special setting.
So, is this ok if it’s optional?
Thanks
Just spotted right now a user with a pirate copy, that was not able to install the plugin cos his theme was 2 days old, and the plugin path changed last night. Went to his themeforest verification page and he had no license for the product.
His pirate copy was 2 days old, which means somebody is keeping them pretty up to date in the black network.
We get about 10 like this a week, means about 2000$ loss of pirate copies AT LEAST, only for what we can know. After we spot them, they usually buy the product.
If this user had the plugins in the zip, I would have never knew about it.
Please be aware of this real concern while making theme requirements. Not talking about unicorns 
Hi All,
Here is some more responses for you. Apologies in advance to @CreativeDive and to people who posted questions in the last few days, as I didn’t get to your questions this time. I’ll try to respond to them on Monday.
Design Metaboxes
Thanks for your patience on this one. After discussing it internally, we’ve decided that we will change the Theme Check message to a Warning rather than Required. We’ll check each case to determine whether the metaboxes are design related or not.
We’ve also tweaked the wording of the ‘Strongly Recommended’ section of the relevant requirement, although we still recommend that you put all metaboxes in an accompanying plugin (if you have one).
Also, while some metaboxes are clearly design related and others are clearly not, there is some grey area between them. We’ll therefore be putting together some examples of what’s allowed and what’s not, so as to minimize the confusion around this. I don’t have an exact timeframe for when this will be done, but I’ll post a link here when it’s complete.
Keygates
Thanks for your patience. I’ve now clarified the situation with keygates in WordPress themes on Elements.
We are planning to resolve this in future, but in the short term, we will maintain the existing Elements rule that only an update mechanism can be placed behind a keygate. This keeps the rule the same as it is at present and Elements subscribers can manually update by downloading the item again.
Themes that are on both Market and Elements will need to follow this rule (update mechanism only), while themes that are not on Elements can follow the new requirements (update mechanism, installing plugins, importing demo content).
Gutenberg
The Gutenberg requirements are around making sure that themes style the default blocks where necessary, so they don’t clash with the theme (and also that themes don’t create or blacklist blocks).
You can still support other builders, but if a user chooses to use Gutenberg instead, then it should look good and shouldn’t break.
Out of the Box
This is covered by the “Out of the box” section:
Themes must work out of the box before any plugins are activated. Full advertised functionality is not required, but they must do everything a basic WordPress theme should do, such as display posts, pages, archive pages, home page, blog page, search, etc., and they must be styled as closely as possible to the full design as shown in the demo.
It doesn’t need to be exactly the same as the demo, but it can’t look broken or too basic. We understand it’s designed to be used with the plugins in place and that 99% of customers will use it that way, but it is a theme first and should still function as such if for some reason the customer chooses to not use the plugin (thought obviously they won’t get most of the features).
TGM Plugin Activation
The background to this is that we use the wp-cli package for TGM PA to automate things, so we need that to work. You can build your own installer, as long that still works. You probably don’t want to confuse the user too much, so you may want to hide the TGM interface from the WordPress back end.
JavaScript Targeted To Necessary Pages
I think this is what you’re talking about, but let me know if I’ve misunderstood it: Themes should make sure that any scripts they are using are only loaded on the pages that they are actually needed on. That’s a great point and we’ll consider adding that to the requirements.
Forms
Yes, it would still be considered plugin territory, so should be in an accompanying plugin.
For contact forms, it’s probably best to integrate with one of the third party contact form plugins out there and let them handle all the complexity around spammers etc - we’ve seen a few too many themes that could turn a site into a spambot because they didn’t handle the To field correctly for example.
For submitting new listings, it may be possible to use a third party plugin, but of course you can write your own - but it should be in a plugin as it’s functionality.
Soft Rejection Reasons
Our plan is to do that, although we still have some work to do in the soft rejection reason space, so it may take a little time for us to get it right. Please bear with us!
I should be back on Monday with some more responses - thanks for your patience.