Any answer ?
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
1 Like
Thank you, that means i should also move the sdk from stripe and facebook into plugin. Thank you again .
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.
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.
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 
I think we should style only the core Gutenberg blocks. To fix all sections of page builder to be compatible would be madness.
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?
1 Like
No answer?
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.
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.
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!
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… 
1 Like
Can I use my own solution instead of tgma? Tgmpa throws php errors when wp is in debug mode.
1 Like
Lol for both of you, if you understand tgm code you will see it cant be done better 
LOL @ you, ewizz, but whatever…
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.
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.
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.
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.
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.
@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.
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.
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.
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.
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.
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.”
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.
6 Likes
Finally I was able to explain myself 
Yeah, exactly this. Thanks!
Thank you for response. Long awaited response…