WordPress Requirements Update and New Gutenberg Optimized Attribute





That will be the lovely post and wordpress update it will be so helpful post keep sharing such a wonderful post and it will be also for those who will be the beginner



There are a few things we’d like to learn more about regarding the May 31st deadline for the WordPress requirements update, and the possible repercussions of not meeting the said deadline.
It is not very clear how compulsory obtaining the badge really is, or how much of a boost it could provide to a creator.

Namely, in order to comply with the requirements, we’d have to put in a significant amount of time and resources towards this, considering the amount of themes we have in our portfolio. If these requirements are something that will have a paramount impact, we’d be prepared to do so.

However, since it is not very clear what would happen to those who fail or are for any reason disinterested in obtaining the badge, we are unsure how to handle the situation.

Could you please provide more information and advise what the best course of action is for authors who have to put enormous amounts of work into this? We are not the only author here who’d have quite a bit of work with this ahead of them, so we’re sure they would also like to know how to prioritize things.
Would it be best we redirect all our efforts towards meeting the deadline, since that may very well be the only way we could achieve this? Or could we take our time with this, and manage the requirements update the way our resources allow us at this time?

Thanks in advance,


Good news


Is not clear for me if ‘Customizer’ is mandatory at this point or just recommended ?

Thank you


@steve_lam @StephenCronin
I have doubts on the guy who does the reviews for plugin-compliance-badge competence or the way how does Envato understands the Plugin requirements:
I got this reply from him:

  1. Classes should be prefixed: https://envato.d.pr/ILY8Df

Have he EVER heard about NAMESPACES?

This item:

All functions and classes, hooks, public/global variables, and database entries should be prefixed with a unique identifier to avoid conflict issues with plugins and other themes.

on WP Plugin’s compliant page ( https://help.author.envato.com/hc/en-us/articles/360000510603-WordPress-Plugin-Requirements ) has to be fixed by including the phrase:
all plugin’s classes has to be either prefixed by unique phrase, or the class has to sit under unique namespace.

All my plugin code stays under unique namespace of “NativeRentalSystem” that stays at the top of each class file, and that is FULLY accepted by WordPress.org.
I been last year on WordCamp Europe, came to WordPress contributors day, I joined the “Coding standards” team, I presented to all WordPress board the SolidMVC micro-framework to everybody - including Ma.tt, Dion Hulse (@dd32), Joost de Valk (@joostdevalk), and release leads of two major WP versions.

I even raised a question about issue on supporting namespace name for the plugin folder name on Wordpress.org, meaning that WordPress CMS itself does allow you to have the namespace now, but for the w.org there is SVN used and the “plugin-directory” plugin that sets the folder name equal to url path. And I run a long discussion at WP track about this, and the answer was - if I have time, I can make a patch for that there, but there is long to-check list, so the core team does not have time for that now, while @joostdevalk now is responsible after this to make improvements to w.org, as everybody at the conference heard my discussion with Ma.tt about S.O.L.I.D. MVC, and CamelCase support for plugin folder name, while for the w.org plugin’s directory URL’s using the same existing information from Text-domain value, that is lower-cased and dash separated. And they started this task with officially accepting the Namespaces by default and dropping out-dated PHP 5.2 version support, as before PHP 5.2 was supported by WordPress, and now it is PHP 5.6 starting this April, and one of the key reasons for this is the NAMESPACES as those are supported from PHP 5.3.

Additionally, in April 2019, WordPress’ will increase its minimum supported PHP version to 5.6. To help you check if you’re prepared for this change, WordPress 5.1 will show you a warning and help you upgrade your version of PHP, if necessary.

Read more here:

What they all said that the biggest issue about WordPress plugin developers is that many developers don’t even know that the S.O.L.I.D. principle means, and what is the MVC.

Just to confirm that I’m fully correct with using NAMESPACES instead of prefixes, I’ve uploaded the “ExpandableFAQ” plugin to w.org ( https://wordpress.org/plugins/expandable-faq/ ), that is an MVP-example of SolidMVC, Version 6, and the @Ipstenu (Mika Epstein), which is the lead reviewer of plugins’ acceptance to coding standards, did reviewed all the code over there, and agreed that it is accepted as correct coding standards, means SolidMVC, Version 6 does suits the WP coding standard.

My current plugin on Envato runs older-generation - SolidMVC, Version 5, and I agree that there is things that can be improved, but the Version 6 of SolidMVC has to be fully accepted by Envato - it got discussed across whole WP board, and there is nothing wrong about it.

Another thing about SolidMVC, Version 6, is that I does not use LESS/SASS, that is out-dated now, and uses CSS4-Variables instead, which is again, also allowed by WP core team to use in plugins, as long as the ‘without two dashes’ (default color) version is used together.

So they item:

The use of @import should be avoided.

Should be expanded to “**avoided in PHP files - in CSS files it is allowed to use”. And this is because it is a MUST for implementation of CSS4-Variables:

The content of ‘/UI/Common/Assets/Front/CSS/Local/Shared/CrimsonRedColorsPartial.css’ is the following:

 * Colors style sheet (CSS4 VARIABLES)
 * License: Licensed under the AGPL license.
:root {
    --primary-color: #DE2E2F; /* Crimson Red */
    --primary-light-color: #F05858; /* Light Red */
    --secondary-color: #BA0001; /* Dark Red */

The content of the /UI/Common/Assets/Front/CSS/Local/CrimsonRed.css is the following:

 * Plugin Stylesheet
 * Style Name: Crimson Red
 * License: Licensed under the AGPL license.
/* #1. First - Load the style colors (variables) */
@import url("Shared/CrimsonRedColorsPartial.css");

/* #2. Then - Load the layout */
@import url("Shared/LayoutPartial.css");

And the Shared/LayoutPartial.css is the CSS file where the all CSS regular rules stays, that uses the CSS4-Variables.

All this again was discusses with all coding standards team, and even with Software Architecture lectors in the TOP-500 Universities, and this is the correct approach to deprecate use of LESS/SASS with CSS4-Variables.

And the third issues is with the point:

Files must use only <?php tags, not the shorthand variations.

This has to be fixed by adding a phrase "except, for templates where <td><?=$greatId;?></td> is allowed.
Again, I showed this to @dd32 - Dion Hulse, and to the Joost de Valk (@joostdevalk), they even invited the guy from PHP standards (not just WordPress), who worked on PSR-2, PSR-4 Autoloaders standards, to the discussion, and they agreed, that the goal of template is that it should only have HTML and PHP variables, no calculations, with minimum to zero functions call - this is first of that because of that web-designers, has to be able to understand the code as easy as they read. What they said that only the “<?” is not allowed, which is logical, as it can mess with other languages. So please clarify, that on templates the “<?=$variable;?>” is also allowed.

Short echo tag WordPress CS repository ticket link on Issue on GitHub:

Short echo tag issue ticket link on WordPress META ticket for Handbook:

So, can you guys please fix the issues of the page:

As I’m going to upload another plugin in couple of weeks, that is fully based on SolidMVC, Version 6, and I’d be really disappointed if it would got rejected because of these three points. A plugin, that uses CSS4-Variables and Namespaces, and has a configuration setting on W.org that is as well supported by w.org of:

Requires PHP: 5.4

And Namespaces are supported since PHP 5.3, and starting this April, even WordPress itself will require PHP 5.6.


I have a question about Uninstallation. Most of Wordpress plugins are updated by uninstalling and installing again. Is there a example how this requirement should look in real live?

Best, Michael


Can you tell me please, if i put On for my all WP themes on Gutenberg to recive badge, and Envato will say that changes are not enought for gutenberg, what will happen?

Themes will be disabled until will be made all changes or can you tell us more?



Another issue is regarding the escaping at the template and missing esc_br_html function, as I described at the ticket in WP.org:


CC: @StephenCronin @steve_lam


No one is tracking this post, we are waiting for a reply for so many days! In the meantime, emails like this one are being sent to authors, just like that:

Seems that there is no interest to clarify lots of questions…that’s so sad! :expressionless:


There is no Gutenberg badge. There is only WP Requirements Compliant badge. You must understand the difference between this 2 parts.

First, and important part is that all your themes are updated and meet the current requirements - and you have 4 months to do that. If not, there will be “some consequences” (but there is no official answer what will happen to this themes). The Gutenberg Optimized attribute has nothing to do with this. So, your themes at first must be coded to meet the current requirements and that mean that themes must not be (it can but “not must”) Gutenberg Optimized to get that badge. When you are done with this changes (which are important) you can start doing on Gutenberg Optimization.

And here is what they are saying about if your item is not Gutenberg Optimized and you are turning on the “Gutenberg Optimized” to “Yes” (you have that in first post).


Regarding all of this.
Let’s say we make all changes, even gutenberg, and after review will tell us that changes are not enough. Until we finish all changes theme will be disabled?

Other case: in some themes we use layerswp framework, and themes are only childs for thia framework and this need to be installed from their site, if layerswp don’t make this changes, what we can do?



I know the same as you:

So, first update all themes and submit the form. If all is ok, you get the badge and that is. If not, you will get some kind of “soft reject” (small number of issues) or you will get some kind of “hard reject” (you will need to wait for 2 months to resubmit).

What will be if you don’t finish this in next 4 months - I don’t know - there is no official answer about that. Will items be removed or temporary disabled until you finish all this updates or nothing from that - I don’t know. Hope we will get answer on this soon.

On other side, all we know how is going when we submit our new themes here - if you get soft reject many times for the same reason/issues, and you don’t fix that - you will get hard reject at the end.


Hi All, just a quick one to let you know I’ve been tied up with something else, but will try to respond here tomorrow. Apologies for the delay.


@StephenCronin @steve_lam what you guys think about this ALTERNATIVE APPROACH to the code quality:

  1. Instead of creating ‘general’ WP-Requirements’ compliant badge, where everyone may have different interpretations and favors, instead of that you guys could add a new section called “Compliant With:” to plugins/themes and Micro-framework.

CODING STANDARDS (“Compliant With:”)

Coding Standards list can be a similar to tag cloud in StackOverflow - here defined tags can be added automatically, but the new tags has to be approved by moderator:

PSR-2 - created by PHP evangelists, but is pretty much cross-platform, any C# or JAVA developer can pick-up this.

PSR-4 Autoloaders - created by PHP evangelists, but is also, pretty much cross-platform, as in C# or JAVA the loading is done automatically as well.

Semantic Versioning - again, evolved from PHP.net’s version_compare(), and became a cross-platform dependency-hell preventer.

BCNF Database Structure - there can also be a lower level definition of Third Normal Form or more strict - Fourth Normal Form

Unicode CLDR KEY=>VALUE language package support - Open-Source “Unicode CLDR” is cross-platform KEY=>VALUE translation-based solution for databases of GEO-CODING (country names, city names, ares, Airport Codes (IATA), phone regions etc.), and is largely sponsored by Google.
Notes: Google also developed Google AMP for WordPress (Accelerated mobile pages) and was main sponsor of WordCamp Europe 2018. As well as this is most popular language translation solution. Also it is the fastest solution, as the language data gets to the memory right away without parsing, can be edited by any editor, including Notepad++, and is suitable for enterprise project with different extensions on same code-base, where LANG_ITEM_TEXT in template, based on extension and loaded file might describe a car or a boat.

POT (Portable Objects Template) files - popular only within WordPress and WPML. The biggest drawback of it, that is is pretty-much commercial tool - the only useful editor is PO-Editor, which is free to translate, but is paid for plugin developers to generate - those files. It is not cross-platform, and is not suitable for extensions and large enterprise projects that needs to run different extensions on same code base.


2 of 3 modern medium+ size plugins and themes runs on some kind of micro-framework, developed by the company or MIT-open-sourced.
None - for the WordPress plugins, that are not based on some kind of micro-framework.

SolidMVC - a GDPR-compliant micro-framework that based on collection of most popular coding-standards (PSR-2, PSR-4 Autoloaders, Semantic Versioning, Unicode CLDR support, BCNF Database Structure) and Technologies (Font-Awesome) to allow any Object-Oriented Software Architect from C# or Java, PHP Software Architects comming to WordPress from Symfony or Laravel, to pick-up and start coding in WordPress withing the same day, without any need to learn any new coding standards. I, as software architect, developed the SolidMVC together with professors and lectors from worlds TOP-500 universities, that are the creators of Software Engineering Master Degree courses of Software Architecture and Design courses. The SolidMVC was developed in 4 years (2015-2019) and is licensed under almost unlimited - MIT-license, meaning that it can be used for both - commercial and non-commercial use. The SolidMVC was presented to all WordPress core contributors, including Ma.tt, Dion Hulse (@dd32), Joost de Valk (@joostdevalk), and release leads of two major WP versions in Contributors Day 2018 and WordCamp Europe 2018, and it was accepted by lead reviewer of WordPress plugins at w.org - Mika Epstein (@Ipstenu). The example MVP (Minimum Viable Product) of SolidMVC is at w.org as “Expandable FAQ”.

Redux framework - popular solution for options for theme authors.

Unison framework - also popular framework by theme authors, it was also used by older versions of Avada.

So keeping in mind, that I put 4 years to develop a micro-framework to create plugins, as well as there is many other micro-frameworks, as well used by hundreds of authors, as a micro-framework author, I’d really love to know who are enjoying and creating the plugins on given technology. As well as that could be a perfect way to understand whose coding quality is high enough - if the framework is accepted by WordPress community, the there should be no issues to get boosted on Envato’s CodeCanyon.



Is there an update to this question (especially for plugins)?

What happen if we don’t get the theme updated by 31 May 2019? Will items be removed or something?


And what is it if it is impossible to meet all requirements. One of my plugins does dynamically generate Javascript depending on configurations and parameters in the url! Everything else is extracted properly to an external file but there are parts which need to be rendered on the fly…


I also have a question mark behind:

  • Upon uninstallation, a plugin should prompt a user that it will be deleting its data and receive a confirmation that the user is okay with deleting the data before doing so and a plugin should also allow the user the option to keep the data upon uninstallation.
  • An option to export/import settings can be presented during uninstallation so that settings can be saved outside of WordPress prior to deletion.

Because Wordpress does NOT offer this! There is a hook and a uninstall.php file that can be used but no confirmation option! What is possible is to have a option in the plugin where users can select if they want to keep or delete data during uninstallation!

So please clarify this part! Because you have requirements which are not even supported by Wordpress!

Best, Michael


Hi All,

Apologies again for the delay, here are some responses:


@modeltheme Thanks for the examples, we’ve fed them back to the team. These requirements do need to be met by all themes by 31 May, but a) they don’t need to be met for existing themes until that time; and b) only serious design issues need to be addressed. We’re working on getting the Reviewers as consistent as possible. If you have questions about a particular decision, please lodge a ticket and we’ll look into it. Thanks.


@ThemeSLR - as per correspondence on the ticket, sorry for the mix up and the delay. I believe you have a response from the spot check now.


The badge and search boost were created as an incentive for early adoption. We are still working out the consequences of not meeting the requirements by 31 May, so I can’t tell you exactly what they will be - but there will be consequences for authors who have not updated all of their items. We know it will be quite a lot of work for some authors, which is why was gave authors a year to update existing items.


Using the Customizer is strongly recommended, but not mandatory. We’ve tried to be careful about our wording, using “must” for mandatory things and using “strongly recommended” and “should” for things that are recommended but not required - but we have not been clear enough in this particular case. We’ll make this clearer in the next update. Thanks for bringing it to our attention.


@KestutisIT - I see you’ve submitted a ticket about this, so I will answer you there in the next day or so. I’ll circle back here later with anything relevant to everyone.

I do need to remind you that there are rules about not calling specific people out here on the forums. That applies to Envato staff as well as the rest of the community. It’s fine to discuss a particular person on a ticket, but not the forum, so I’ve edited your post to remove the name of the person you mentioned.


Thanks for picking this up! You are of course correct and we’ll need to rework this requirement in the very near future. Sorry for the confusion.

Could you use wp_localize_script for that? Maybe submit a ticket with more information and I will investigate further. Thanks.


As @CocoBasic said, there are two separate things going on:

  1. The WP Requirements (covers a lot more than Gutenberg) must be met by 31 May. Once all your themes meet them, you can request the WP Requirements Compliant badge. Your themes do not need to be optimized for Gutenberg in order to do this.

  2. The ‘Gutenberg Optimized’ attribute is something you can turn on yourself IF your theme meets our definition of optimized. It does not need to meet all the requirements in order for you to do this.

The two things are not directly related. We will be checking for both issues (using different processes), but we are still working out the consequences relating to both of these issues.

Once again, @CocoBasic has basically answered this! :slightly_smiling_face:

With the spot check process for authors requesting the WP Requirements Compliant badge, we won’t be disabling items as they don’t have to meet the requirements until 31 May. If there are a small number of changes required, we’ll go through a soft-rejection cycle until the items meet the requirements. If there are a large number of changes required, we’ll ask you read the requirements closely and try again, then resubmit after a timeout period.

We haven’t worked out the consequences for items not meeting the requirements after 31 May, so I can’t say for sure what will happen then. I’d expect that if you were close, we’d go through the soft-rejection cycle (ie not disabling them), but I can’t guarantee that at this point.

We have separate LayersWP Child Themes Requirements that you need to meet. You also need to follow the general theme requirements where possible, but only for your child theme. The LayersWP parent theme does not have to meet our requirements.


Sorry! It’s my job to track this post, but I also have quite a few other things I need to work on. I’ll try to be more timely from now, but there will be times I disappear. It’s not that I don’t care, I’m just neck deep in other stuff!


As mentioned above, we haven’t worked that part out yet.



about wp_localize_script. It does generate inline Javascript. So what is the difference? As my plugin need also working standalone I don’t see a big difference here as the result is almost the same. Also it only work for some parts because I actually completely create dynamic Javascript, css. Rewriting at stable php implementation in Javascript is actually also not a really good idea.
I maybe try to save the generated script to a file and include this. Not sure if this works but as all the scripts need to be actually at the places where they are right now.