Essential WordPress Gutenberg Needs

Following Are The Gutenberg Editor Support Needs:

• Themes need to ensure that all WordPress core blocks are styled to match the design of the theme/demos. You can select to load the core block styles, but you may require to add additional styling to make sure it matches your design. This is essential WordPress Gutenberg needs.
• Themes need not not register blocks as that is plugin territory. If extra blocks are needed, they must be added by way of an an accompanying plugin. The plugin needs must be followed.
• Themes need not not blacklist blocks.
• Themes must make sure there are no console errors from their Gutenberg implementation (theme or plugin). You need to focus on WordPress Gutenberg requirements.
• Much Recommended

It is recommended that all themes are optimized for Gutenberg. Additionally, below are recommended in order to give a better user experience:

• Provide support for the .alignwide and .alignfull classes by theme support for broader-images and style these classes. More information.
• Add a color palette to the editor where needed, remembering to:
• Create the classes that apply the colors in multiple contexts. For example core blocks use “color” and “background-color” contexts, eg: .has-strong-red-color { color: red; } and .has-strong-red-background-color { background-color: red; }
• Use sensible defaults,  instead of creating an infinite number of custom colors.
• Consider the users who are not making use of Gutenberg and provide  fallbacks with sense or alternatives wherever possible. Remember that any functionality is available to customers or the item may be disabled, so please be aware about any limitations. Have a clear focus on WP Gutenberg requirements.

Gutenberg Optimized Definition

Themes having the Gutenberg Optimised attribute turned on, or advertising themselves as optimized for Gutenberg, must do the mentioned below as a minimum:

• Make sure that the Gutenberg editor is styled to match the output at frontend as closely as possible. This should include any used fonts and any dynamic styles coming from settings etc. More information.  
• Change the editor widths for matching the widths used in the theme as closely as possible.  Gutenberg WordPress requirements are essential, no doubt to enhance towards perfection.

Plugin Requirements

Mandatory

• Plugins need to ensure there are no console errors coming from  Gutenberg implementation.
• Blocks need to define basic block styles that any theme can use when they display the block on the front end.
• Gutenberg functions need to be be checked for existence before being called, in case the user is on a version of WordPress that does not take Gutenberg and they are not operating the plugin version. For example, before calling register_block_type it’s existence should be checked using:
  
  if ( function_exists( ‘register_block_type’ ) )
• Blocks must use wp.i18n.__() to enable translations. Available functions for translations below:// Deconstruct just the __ function from wp.i18n
  const { __ } = wp.i18n;
  // Just pass in the text to make it available for translation
  __( ‘This text can be translated’ );

Gutenberg Optimized Definition

Plugins may be considered as optimised for Gutenberg if they do the rest, where appropriate:

• Create blocks, whether a) for the user to enter content directly through the block or b) to output content created elsewhere through the plugin’s functionality.
• Make equivalent blocks in Gutenberg for any shortcodes made by the plugin.
• Convert any metaboxes made by the plugin to blocks / controls in Gutenberg.
• Make a particular Gutenberg stylesheet in order to match the editor styling to the frontend output as close as possible (where the plugin outputs the CSS on the front end).
• Integrate the editor screen controls/content seamlessly with Gutenberg.

If the Gutenberg Optimised feature is turned on, the plugin needs to do all that is mentioned above that applies to their context.

Needs Update

We have released an update to the needs based on feedback from announcement 475, as well as other factors. The key amendments are:

• The Gutenberg needs have been reworked and separated out into a page.
• A 6 month fallback period has been added for plugin territory functionality. Functionality migrated to a plugin can also remain in the theme.
• The creation of widgets is added to the list of plugin functionality.
• The use of create_function() is not allowed due to it being deprecated in PHP 7.2.
• The use of the purchase code for items on Elements is Clarified

There are other alterations too. If you want to see the line by line amendments, you can view them.

Please update your items where needed, to take these changes into account. The deadline for existing items to meet the present requirements remains as told in the actual announcement.

This must only be selected for themes as well as plugins that meet the needs of Gutenberg Optimized in the reworked Gutenberg requirements:

• Definition for themes
• Definition for plugins

We will be correcting items we find that have turned on but don’t meet the Gutenberg Optimised definition. We will take action against authors who are found to be abusing this.

We understand some people of you will have selected this in recent weeks before it was published. Please reconsider the items and ensure that this is turned on where we meet the definition. Clearly focus on WordPress Gutenberg requirements.

WP Needs Compliant Author Badge

As mentioned in the requirements announcement, we are looking at ways to increase the visibility of authors whose items are compliant.

As part of this, we introduced a new WP Requirements Compliant badge:

This badge is assigned to authors who pass a spot check on a choice of their items.

When all of the items have been enhanced to meet the current requirements, to nominate yourself for a spot check. Once we receive the completed form, we will check a selection of  items and:

1. If all the items checked meet the present requirements, we will award the badge.
2. If there are a few issues, we will ask you to solve these and resubmit. We will then recheck the items.
3. If there are more issues, we will not be able to consider you at this time. You need to go through your items again and ensure they meet the requirements, then again for a check after a 2 month waiting period.

Please do not submit the form unless all of items meet the current needs.

Please maintain your items so that they always meet present requirements, even after receiving the WP needs Compliant badge. We will proceed to reassess items belonging to badge holders and remove it from those who fail spot checks in future. Above the new badge, we are actively looking at  ways to increase the visibility of compliant authors, that includes changes to our search algorithm. We will update with extra information on these additional benefits before the end of the calendar year.

Thanks to everyone for sharing their thoughts and pointing out areas for clarifying in needs and guidelines. We value the feedback as well as input. We  are around for the other seven days responding to the questions as well as comments in batches. Please remember the community guidelines that you post.

 If the WP themes are not adjusted with Gutenberg and we click ‘no’ in ‘Gutenberg Optimized’ option, will we still get the badge?

1. What happens if we do not get the theme updated by a certain deadline/ Will items be deleted or something?
2. By making old themes to be compliant with new, how much do we require to change in old themes? The way we do the coding of themes might not be needed for pre-fix, now we have to put pre-fix in all previous themes? Just to make it compliant with major needs.
3. The point is needs in past 4-6 years ago and today are so separate.

 Regarding ‘6 months fallback period’ for ‘Plugin territory functionality’. Does it mean that if we enhance all themes upto a certain time period but do not do ‘Plugin territory functionality’, will we  get the badge? The good suggestion is to have a clear outlook of WordPress Gutenberg requirements.