Updated WordPress Requirements

[crerem]

Any answer ?

[Typps]

The requirements regarding base64 is mentioned for themes:

General Requirements
Themes must not include unused code fragments (ie., commented out code), todo lists in comments, or any other comments that do not contribute to understanding the code.

Themes must not obfuscate or hide code in any way, including through the use of base64 encoding.

So if you should really need to use base64 encoding, move that functionality into a plugin as this is plugin territory anyway. Check following response by themecheck on github, quoting response below:

It is perfectly okay to use base64__ functions in wordpress and plugins. But this practice is highly suspicious in a theme. Many malicious themes use this technique to hide malicious code.
Moreover, if you think about it, themes should contain code about presentation, not application logic, especially if you design themes to be used by others. base64__ functions are probably avoidable in presentation code. If you really need this logic, you may transfer the logic in a plugin.
Note that things are different when you code a theme dedicated to a website. In this case, it is often easier to put some logic in the theme. But themecheck.org does not aim at verifying such themes

Issue: So I am not allowed to use base64_encode|decode() in themes?

[crerem]

Thank you, that means i should also move the sdk from stripe and facebook into plugin. Thank you again .

[kemoboy]

I use WP Bakery page builder in all my themes.
I should style only the core blocks of Gutenberg to look the same as the ones in the theme?
Should I try to recreate all the elements from page builder in Gutenberg, which is kinda impossible for the moment, since there are a lot of problems in Gutenberg when it’s comes to even handle the JavaScript that comes with WordPress.

[kemoboy]

Yes, for the moment is not!
The idea is that, even if I make my theme compatible with Gutenberg, the elements that are in builder can’t be reproduced in Gutenberg at this moment, so what should I do in this case, I’ll be unable to sell theme anymore, until Gutenberg will fix it’s problems or just customize somehow the existing blocks of Gutenberg, which will be wired, since my theme is a dark theme.

[Typps]

Don’t want to rub it in but perhaps you should post a separate post and ask for help as this is off topic. Regardless, it’s fair to say that the ones able to solve this will be making money on the Envato market no doubt.

Therefore if nobody solves a problem like this one, you are onto something. Lots of sales to be made, good luck

[SkatDesign]

I think we should style only the core Gutenberg blocks. To fix all sections of page builder to be compatible would be madness.

[rayoflightt]

@jamesgiroux

quote: “To take advantage of these new benefits, when all of your items are up-to-date, we will soon be introducing a way for you to nominate yourself and your items for review against the new requirements.”

When is this going to happen, can you please confirm?

And what about questions about Gutenberg? Only basic styling is required?

[rayoflightt]

No answer?

[BenLeong]

Hi @rayoflightt. James is still in transit to Melbourne from the EuroTour events at the moment - he’ll be able to respond to your questions once he’s back.

[jamesgiroux]

Hey @rayoflightt thanks for your questions. We’ll be making a follow up announcement soon about the requirements and submission process. We’re still finalising the system and don’t want to release until it’s ready to go.

As far as Gutenberg goes, what’s written in the requirements is the minimum requirement. Styling is the first requirement of four.

[tommusrhodus]

Any rough idea on a timeframe for release? If there’s a marketable bonus to being up to code it would be great if we had a date to work towards, those of use with larger portfolios may have quite some work to do!

[wp-kitten]

TGMPA is a “must”… roflmao… mwahaha… so if I have a theme with a perfectly plugin system I must change it to use a code written by… whom??? who the heck is behind tgmpa? does they code better than me? why the heck must I change my perfectly working code for something that someone else written? no, freacking seriously now… I understand that some people have crap code in their themes, no question about it, I understand you want to provide clients with a standard and help the crap themes, but my problem is with your must… why isn’t it should and let people with perfectly working code as it is?

tgmpa… FML… I can’t believe this sh!t…

[ThemesDepot]

Can I use my own solution instead of tgma? Tgmpa throws php errors when wp is in debug mode.

[ewizz]

Lol for both of you, if you understand tgm code you will see it cant be done better

[wp-kitten]

LOL @ you, ewizz, but whatever…

[mwtemplates]

Instead, new widgets should be registered via a plugin.

Can you please apply this rule only for new themes?
What will happen with widgets that will be removed from existing theme after update? Site layout will be broken on existing theme installations.

[StephenCronin]

Hi All,

Firstly, sorry for the long delay. I’ve been away for a little while. I’m going to answer some questions today, then I’ll be away again for almost two weeks, then I’ll be back and answering questions again.
 

---

As it’s said on WordPress Plugin Requirements for JavaScript standards: “Provided code needs to pass JSLint.”

So please answer the following:

1. 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 ?

2. 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?

We will provide the JSLint options we use so that you can check your item against them. I’ll let you know when we’ve linked the requirements to them.
 

---

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?

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…

We wouldn’t want you to bundle plugins together, for the reasons outlined by @LSVRthemes. Also note that for plugins on wp.org, you need to install the latest version directly from wp.org.

I think LSVRthemes‘ suggestion to bundle the known compatible versions would be okay, as long as customers were only told to use them as a last resort and you put every effort into making your theme work with the latest version as soon as possible.

We do understand that sometimes plugin updates can break themes and that addressing the issues can take time, but we need to balance that with the security implications. As a general principle, users need to be able to keep things up to date, so we’re asking authors to support this as much as possible.
 

---

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.

In the Third-Party Plugins & Libraries section we say: “Libraries and scripts included in a theme are considered to be part of the theme and must meet these requirements” and “The one exception is the TGM Plugin Activation library, where it has been generated using the ThemeForest option.” We may add other exceptions in future, but this is not guaranteed.

Note we also say: “Included third-party plugins do not need to meet these requirements, but theme-specific plugins must meet the WordPress Plugin Requirements”.

The Plugin Requirements allow some things the Theme Requirements don’t (like use of base64_encode), so moving things to an accompanying plugin may be your answer.

I’m moving a payment processing code from Curl to wp_remore_post. However in order for code to work we need to user base64_encode , which is not allowed by the theme check plugin.
Code ex: ‘Authorization’ => 'Basic ’ . base64_encode( $clientId . ‘:’ . $clientSecret ),

Also based64_encode is used by many theme on import/export options features (a popular featured used by client when moving a site from devel domain to live domain).

@Typps has pretty much answered this (thanks!). We do not allow base64_encode in themes. We do allow it in plugins.

You shouldn’t have payment processing code in a theme anyway, it should be in an accompanying plugin. You can have import/export functions in a theme, if necessary to make a theme set up wizard work, but we generally prefer that in a plugin. If it’s in the theme, then it should not use base64_encode.
 

---

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.

We have discussed this and decided it’s fine as long as only logged in admins can see the placeholders and they are only displayed if no menu has yet been set. We’ll amend the wording of the requirement to reflect this.
 

---

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?

We have discussed various ideas in this space (ie just as ideas, not on a roadmap at this point). It would be great and it would solve a number of problems, but I can’t promise if or when this might actually happen. We do know that piracy is a common concern amongst authors, but at the moment we do need the plugins in the zip file somewhere.
 

---

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?

We don’t allow that in the theme, but it would be okay in an accompanying plugin, as long as the user understands what’s happening and gets to make the choice whether to enable that or not.
 

---

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.

Here can be a lot of limitation (maybe I am wrong).
For example, I create a demo where I am using Some Slider only on “Home Page” and I am loading JS/CSS files only there. What if user want to use it also on “About” and on “Contact Page” but I don’t load JS/CSS files there?

Good point! In many cases, it’s possible to find a way to work out whether scripts needs to be loaded on the page. For example, if it’s only needed for particular pages in the backend, or if it’s only needed when a certain shortcode is present in the_content, etc. However, there are likely to be cases where it’s not possible to know. It is a good principle to follow if you can, so we’ll add it as a recommendation.
 

---

Not about initialization: obviously script parameters are related to that specific instance.
I’m referring to scripts customization !

• Author adds custom CSS affecting Chosen globally
• Author adds custom JS doing the same ( is a rare case though )

Is extremely simple to prevent this and is a normal practice: target everything with unique classes!
Wrap your Chosen with an XYX class and apply the CSS code to Chosen within that XYX.

Oh, got you (only took me 3 weeks! ). We have prefixing rules to prevent clashes where two items create something with the same name, but nothing to prevent clashes where two items are working with the same third party library. Maybe we can add something like:

“When using CSS or JavaScript to manipulate elements, you must make sure that only your elements are affected. For example, when applying CSS to jQuery UI elements you’ve added to a page, you must make sure any jQuery UI elements that may be added by another item are not affected.”
 

---

Any results marked as Required must be resolved, as the theme will be rejected for these
Soft rejection or hard? @StephenCronin Can you please confirm?

It would generally be a soft rejection in the normal queue. We very rarely hard reject for code issues.

When we start spot checking authors who have said their themes are compliant, we will have a threshold (yet to be defined) where we will stop the spot check. If only a few issues are found, we’ll ask the author to fix them and resubmit. If too many are found, we will ask the author to go through their themes again and re-submit again after 3 months.
 

---

On coding standards

@ThemeSphere @Smartik @vincenttheman - I went back to look at our original draft and it says “It is strongly recommended”, which somehow morphed into “It is very important to” when we created the the final version. We will revert that to “strongly recommend”. Sorry for the confusion.

That said, we do have a strong preference for the WordPress Coding Standards. Some customer segments, such as end users, don’t care about coding standards. Others, such as WordPress developers who maintain and support sites, sometimes do.

Ideally, a developer looking after a WordPress site should be able to navigate through the code in themes and plugins in as consistent manner as possible. Obviously the code will be different in every plugin / theme, but having consistent coding standards makes it easier than if everyone is using something different.
 

---

On widgets

@CreativeDive @rayoflightt @CocoBasic @mwtemplates - We’ll discuss this internally and will post back here with a formal response.
 

---

Gutenberg blocks

@kemoboy @SkatDesign - As I said above: If you are not considering deeper integration with Gutenberg, then the main thing we’re asking you to do is to ensure that the core blocks are styled appropriately for your design. If a customer chooses to use Gutenberg with your theme instead of a page builder, the content should look like it fits the design.

You don’t have to provide the equivalent functionality of a builder.
 

---

On TGM PA

@wp-kitten @ThemesDepot - As I said above: 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.

Also if TGM PA is throwing PHP errors in DEBUG mode, we’d strongly recommend you create an issue on their GitHub repo.
 

---

That’s all for now. Apologies in advance for the delay in getting back to you on the next round of questions.

[LCweb]

Oh, got you (only took me 3 weeks! ). We have prefixing rules to prevent clashes where two items create something with the same name, but nothing to prevent clashes where two items are working with the same third party library. Maybe we can add something like:

“When using CSS or JavaScript to manipulate elements, you must make sure that only your elements are affected. For example, when applying CSS to jQuery UI elements you’ve added to a page, you must make sure any jQuery UI elements that may be added by another item are not affected.”

Finally I was able to explain myself

Yeah, exactly this. Thanks!

[Smartik]

Thank you for response. Long awaited response…