WordPress Requirements Update and New Gutenberg Optimized Attribute

themeforest
codecanyon

#24

Exactly. And what do we need to do with all the theme prefixes when we move the widget files out of the theme folder to a plugin folder. All functions, text domains, PHP classes and image sizes which are prefixed need to match the name of the plugin, which will obviously not exactly be the same as the theme name. Changing this will not only make the widget disappear from your website or break the layout but also every text string that’s translated will be gone. How are we going to avoid this?


#25

Hi, @StephenCronin,

If the theme has a right/left sidebar active (with widgets), can all blocks match the available width of the post area, no matter if the blocks are set to be wide or full? Check the following images.

Condition 1 - Blog without sidebar: .alignwide and .alignfull will work as intended:

Wide:

Full:

Condition 2 - Blog with sidebar: all blocks will fit the available width of the post area, no matter if they are set to be wide/full width or not:

Cheers,
Eduardo


#26

Hi! It seems that you did not understand the problem. Please read comment by JamesWebba below.
Widgets will disappear from site after moving them into plugin.


Must WP themes be Gutenberg ready ?
#27

Hi All,

I’m back with some answers:

========

We are still working on this and will advise you of the details closer to the date.

Yes, old themes need to be updated to meet the current requirements. For themes, the best place to start is the main theme requirements page, which lists the pages you need to consider.

Most of these are how we’ve been reviewing for several years, so newer themes should mostly meet these already. For older themes, there could be a significant work that needs to be undertaken to bring them up to speed.

The philosophy is that themes that are currently available for sale now should meet the current requirements. Over time requirements will change and themes should update to stay current. This does create more work for authors, especially to update themes in a way that does not negatively impact on customers, but is something that needs to be factored in to selling themes.

That said, we are considering whether we can provide an exception on prefixes (just prefixes). We’ll let you know here in the next week or two.

You need to update all themes to meet the requirements by 31 May, including the plugin territory requirements. However you can also have a fallback in the theme until 30 November to minimize disruption to users. Note, this is not compulsory.

For example, if you have a Custom Post Type defined in the theme, you would need to define it in an accompanying plugin by 31 May. That raises the potential problem: If the code registering the CPT was moved to the plugin and the user updated the theme but not the plugin, then CPT entries would no longer appear on the website.

We are therefore suggesting that you leave it in the theme as well for 6 months (obviously making sure to avoid any fatal errors); ie: If the plugin is active and updated, it will register the CPT. If it is not, then the theme would register it instead. This would prevent the CPT entries from disappearing from the website and give you time to tell the users what they need to do (ie install/update the plugin) to avoid problems after 30 November.

When we do the spot check, we will notice that the CPT is being registered in the theme. If it is also in the plugin, then this will not stop you from getting the badge. However, if we can’t find it in the plugin then you would not be eligible for the badge. It is probably best to tell us in the notes when you submit the request so we know what to look for.

As mentioned above, it needs to be in the plugin by 31 May 2019, but can remain in the theme as a fallback until 30 November. After this time, any fallbacks should have been removed from the theme.

We’ll be doing spot checks every so often and if we find it in the theme after that date, then the theme will fail the spot check - this will most likely lead to the loss of the badge and whatever other consequences are decided on (which we’re still working on).

We don’t want authors to simply submit their items without thoroughly going through the requirements. That wouldn’t be fair to the authors who put a lot of work into it, only to have a long wait because we are spending lots of time on authors who didn’t. It would also likely mean the queue would get really long.

If you’re close, then we’ll go into something similar to a soft rejection cycle. It’s only if you have lots of errors that you’ll get the timeout.

========

We actually added the following to the requirements when we re-launched them 6 months ago:

> Themes must not unregister default WordPress widgets. Instead, new widgets should be registered via a plugin.

However, you raise some interesting points. We will reconsider this and get back to you (probably will take a couple of weeks). No promises, but that we’ll take a look at it.

These should be in a plugin as it’s functionality rather than presentation.

========

If the additional custom fields will contain content, then it needs to be in a plugin, not the theme. If it is design related only, then it can be in the theme.

=======

There are no guarantees that we will implement search boosting for people who earn the badge, but we are actively investigating it.

I’m not aware of any plans around ADP - that’s not my area at all and this probably isn’t the best place to ask, sorry.

========

Thanks for the suggestion, We’ll add it to the list of things to look at in the future, but it’s probably not a short term thing.

The boosting in search (if it happens) will be based on the WP Requirements Compliant badge, not the Gutenberg Optimized attribute. So you can still earn that even if your plugin is not Gutenberg Optimized.

Yes, you can get the WP Requirements Compliant badge as long as your item follows all of the requirements (which does not include Gutenberg optimization).

========

That line is from the Gutenberg Optimized Definition for plugins. You do not have to do this unless you want to turn the Gutenberg Optimized attribute on. So you can choose to not do that and to leave the attribute off.

If you were to choose to do it, you’d have to find a way to do it sensibly. How do users enter up to 130 attributes for the shortcode? Through shortcode attributes? I imagine it would be possible to add a block control where the user entered a string of attributes in the same way - although that might not be a good customer experience.

========

Sorry we never got back to you. It was actually this issue that lead to the 6 month fallback period, although we ended up applying it to all plugin territory functionality, not just widgets.

You need to move the widget to the plugin by 31 May, but you can also register it inside the theme until 30 November. You will need to take care not to cause a clash (eg probably need to use if not class_exists when declaring the class), but this should allow a transition period where the widget is defined by the plugin if they have installed / updated it, or by the theme if they have not. As long as they install / update the plugin by the end of the fallback period, they should not lose anything.

========

Gutenberg is now part of WordPress (as of today!). If you don’t offer a minimum of support for Gutenberg, then you don’t offer support for WordPress 5.0+ and should probably no longer be selling this item to customers.

We really want authors to shift to a mindset of creating items that are kept up to date and support the current version of WordPress. There is actually a requirement that you do this now:

>You must make sure that themes work with the latest released version of an advertised compatible software, such as WordPress or WooCommerce, even if the Compatible With item attribute is set to an older version.

========

As mentioned above we are considering giving an exception for prefixes. However, I would expect in most cases that this wouldn’t be too much of an issue? For example, with moving a widget from a theme to a plugin, the prefix of the function that calls register_widget could change without causing a problem, as long as the register_widget call used the same widget handle. If that was prefixed with the theme name then you would be allowed to keep using this.

========

That should be fine. We put support for .alignwide and .alignfull into the Strongly Recommended section, rather than making it part of the Gutenberg Optimized definition, for this very reason.

========

That’s it for now. Unfortunately I’m away next week. Please continue to ask questions and I will answer when I get back. Thanks in advance for your patience.


#28

Thanks, Stephen, for your answers.
The discussion got me to come up with a new question:
Can we create our themes from the ground with all new requirements and make a major theme update which will be incompatible with old ones and put old version to download package for backward compatibility?


#29

Nice, thank you.


#31

great job keep it up


#32

Loud and clear :+1:


#33

Hi,
We have our theme made on underscore and redux framework.
All stuff in page is made using page builder.
We don’t use Gutenberg plugin, i saw after update wordpres to 5, gutenberg is already installed.

My question is : i need to create blocks in gutenberg to have the same design like in page builder or which requires are for this?

I don’t use gutenberg on creation at theme, also no apply for badge.

Gutenberg is ok in our themes, no error or issues after updating on 5 wp.


#34

If my plugins use only shortcodes, is it enough or I should create Gutenberg blocks for user friendly experience?


#36

@StephenCronin For this Gutenberg Optimized Requirement " * Enqueue a specific Gutenberg stylesheet in order to match the editor styling to the frontend output as closely as possible (where the plugin outputs CSS on the front end)." should also be specified that this is required only for non-dynamic blocks.

A dynamic block where the Gutenberg block is actually only a selector should not be styled as the front-end output even if the plugin outputs CSS on the front-end.

Thank you.


#37

@StephenCronin Another thing, and I’m talking specifically for CodeCanyon. In my opinion the best thing you can do with the Gutenberg Optimized flag of the item is to completely remove it from CodeCanyon and simply add the three following points in the WordPress Plugin Requirements page:

  • Create equivalent blocks in Gutenberg for any shortcodes created by the plugin.
  • Enqueue a specific Gutenberg stylesheet in order to match the editor styling of non-dynamic Gutenberg blocks to the frontend output as closely as possible (where the plugin outputs CSS on the front end).
  • Integrate any editor screen controls/content seamlessly with Gutenberg.

I think that you should instead treat Gutenberg like any other WordPress feature. It’s no longer a plugin and there is no need to force authors at supporting any feature of it even when it’s not appropriate.

The CodeCanyon customers might even think that a non Gutenberg Optimized item doesn’t work with or breaks the Gutenberg editor (and that’s not true because a plugin can simply be non Gutenberg Optimized by not having any relation with the Gutenberg editor) and the marketplace can lose a lot of sales for this.

Gutenberg is going to be used by the majority of WordPress users in few months and you can’t keep an ambiguous flag like this. Gutenberg is WordPress and in CodeCanyon the customers should find WordPress plugins that always support Gutenberg.


#38

@StephenCronin I need an information useful in case you are planning to keep the Gutenberg Optimized flag active, or during the period in which the Gutenberg Optimized flag will be present in the marketplace. Can you please specify if a plugin that have no relation with the Gutenberg editor can have the Gutenberg Optimized flag set to “Yes”? In case this is not possible plugins that have no relation with Gutenberg might be penalized in terms of sales for the reasons I explained in the previous post.

Thank you.


#39

Also i see this

Mandatory

Following are the Gutenberg editor support requirements:

  • Themes must ensure that all WordPress core blocks are styled to match the design of the theme/demos. You can choose toload the core block styles, but you may need to add additional styling to ensure it matches your design.
  • Themes must not register blocks as that is plugin territory. If extra blocks are required, they must be added via an accompanying plugin. The plugin requirements must be followed.
  • Themes must not blacklist blocks.
  • Themes must ensure there are no console errors coming from their Gutenberg implementation (theme or plugin).

If i use page builder, i need to create all blocks for gutenberg? I don’t want to use gutenberg in my page sections.
Only in post because is default wp editor, like normal editor, nothing special.


#40

You’re ignoring the majority of the site maintainers. Most of us manage multiple sites and backward compatibility is extremely important. If this happens as-is, each of us will have to waste hundreds of hours redoing parts of sites, with many disappointed clients.

I hope it’s an oversight and they will make the necessary corrections. I am listing the problems below with solution under each to consider.

What’s Wrong

ThemeForest authors are notorious when it comes to backward compatibility. You need to consider the points below and write proper guidelines that authors must follow. Most of the old themes if rewritten based on new rules, without proper guidelines, are going to suffer from some or all of the following problems:

- Theme widgets will likely disappear - setup and configure again!

Widgets are Plugin Territory so they will be moved to a plugin. So, two scenarios here:

  • Widgets will completely disappear.
    If the Author renames the widget PHP class or ID to comply with prefixing rules of Envato, all the theme widgets will completely disappear. They will have to be setup and configured again.
  • Widgets will become Inactive. Move to correct Widget Area.
    If the Author moves the widget to a plugin, but manages to not rename it, widgets will likely be moved as Inactive. Configurations will stay, but you will still have to move them to correct widget area.

Can you imagine having to do this for 100 sites? Absolutely ridiculous.

Solution: Keep widgets untouched for old themes. They have a theme-specific design either way.

- Custom HTML code in Headers, Footers may no longer work

If you used a theme feature to insert HTML code in Header or Footer, as they’re plugin territory now, they may no longer work. Even if they do work, they will use wp_kses() which can only allow limited HTML. Scripts are likely to get stripped.

Solution: Allow unescaped HTML here, at least for old themes. This data comes from Customizer or Theme Options which is usually under manage_options - it’s obviously intended HTML by an admin.

- Adsense and other Ad Network codes likely to get stripped

Many themes had options for ads. With the new rules, these will be escaped and stripped. Same as Custom HTML and same solution applies. There’s no way to whitelist all the known networks in wp_kses - and it’s unnecessary too if an Admin added this code.

- Translations will no longer be complete

With Plugin Territory, as the code is moved to a plugin, the strings textdomain will be renamed to match the plugin slug.

The old translations will no longer be valid. We will have to translate the new plugin. Yes, we will have to translate theme in two places now, one in main theme, and then in plugin.

- Activating a new plugin on each site to get things working again

This will have to be done for most of the old themes. Most of us managing many sites use auto-updates on 100 of sites, when the update happens, all our sites will be broken. We will have to login and activate it on each site.

Solution: Ask authors to auto-activate this plugin for old sites. Or make a standard script to do it for all themes. These plugins will have all the old functionality, no permission is needed.

- All sidebars and Widget Areas likely to go missing

If theme authors rename and add prefixes according to this rule, these will also go missing. As mentioned previously, this is disastrous. You can’t expect us to resetup so many widget areas on each site.

Solution: Drop the prefix requirement for old themes. DO NOT rename sidebar handles. A a standard migrator, if it runs before data is removed as soon as the theme upgrades, may also work.

- Navigation and other menus will have to be re-assigned

If theme authors rename and add prefixes according to this rule, these will also go missing.

Solution: Drop the menu prefix requirement for old themes. Or a standard migrator.

- Theme feature configurations for features like Social Media may be lost

Social Media - even if just a simple button - is Plugin Territory now. Most themes have settings for social media etc. in theme options. When moving to plugin, these settings are likely to be lost and will have to be re-configured.

Solution: Make it compulsory for authors moving settings around to keep using old settings. Or better yet, don’t move design-only social media.

- Potential issues of missing CPTs

If theme authors rename and add prefixes according to this rule, these will also go missing.

Solution: Inform authors not to rename CPTs for old themes.

- Broken Child Themes: Asset Handles, Hooks

If theme authors rename and add prefixes according to this rule, Child Themes that relied on these handles, for example, to add a parent theme asset as a dependency will break.

Example: If previous handle was main-css and the Child Theme used it in a $deps array for another CSS enqueue, to add inline CSS wp_add_inline_style('main-css'), this will break as handle changes to theme-main-css. Same goes for any asset or a parent JS. Also applies to dequeues (more common).

Hooks are also another issue. Authors may start adding prefixes to previously unprefixed hooks and the old hooks will no longer work.

Solution: I can’t think of a solution for asset handles other than skipping a rename. For hooks, advice authors to not rename old hooks.

Other issues

This isn’t a comprehensive list nor have I thought all of the issues list. These aren’t specific to this change, but they are normal issues we face with any major theme rewrite.

PHP Customizations Redo

If you have ever modified or overridden a file whether in parent or Child Theme, you will have to figure out how to do the customization again now that the old code will be shuffled between a plugin and a theme. Sadly there’s no solution it.

Missing Metabox Options

Should the theme authors rename their metabox prefix, the metabox options will also go missing.

Solution: Inform theme authors not to rename metabox options.

Huge potential for Bugs

We all know how careless authors at ThemeForest generally can be. No offense and I understand their reasons. But the fact is, Theme authors here are pretty bad at keeping track of backward compatibility. So when they rewrite and move things around to plugins, it’s almost guaranteed new bugs will be introduced.

Solution: Advice theme authors to not rush it and do proper testing. Give them ample time.


Suggestions On Approach:

Please reconsider the details of how you’re approaching this massive change. Consider how this impacts your most loyal power buyers - most have to manage hundreds of websites and breaking changes would mean less buying of new themes, being busy fixing old sites.

I have highlighted solutions to problems above, but what really needs to be done is writing a strict guide for authors. With no offense intended, authors can be quite uninformed about backward compatibility. Just like you overlooked the trouble agencies and site maintainers go through, they do too.

Ideally, skip the prefix rules

Renaming is the major cause of troubles listed above. Skipping would be the easiest way here with no issues.

Or better yet: Skip many of the rules for old themes.

But if you really have to implement all the rules for old themes, consider:

Write a Strict Guide on Backward Compatibility

Guide authors on how to approach each of the problems listed above. If there are no strict guidelines, the authors will mess up. They simply don’t care for backward compatibility.

Make a Standard Migrator: For all Authors to use

A standard migrator that deals with most of the issues listed above, that’s well-tested and every theme author can use consistently is the only really solution:

  • It should automatically run on theme upgrade to prevent loss of widgets.
  • It should take care of the suggestions listed above under each problem.
  • If a large migration task is to be performed, a notice should be added with an AJAX-based step migrator.

It’s of utmost importance that you take this matter seriously and inform authors to be extremely cautious about backward compatibility.


#41

@phpplus What an irony :slight_smile: If a powerful user buys a very old outdated theme now, it is rated junk, But if he’s bought the same theme at the beginning of the life cycle, he prefers no major changes that may make him invest time in the process. Change inflicts pain, there is no other way. Those changes are long overdue. The authors will invest huge resources to comply with them but in the end, the quality of the themes will be improved enormously and this will benefit people like you as well.
Most of the things you mentioned are indeed potential issues, but the resolution is not as simple as you want it to be.


#42

Absolutely agree with you. I don’t see any sense, for example, to put widgets into plugins for OLD themes.
And all of your other cases that you have described are also really important.
One of the options to resolve this situation is an ability to create a new theme with new major version from scratch with no backward compatibility and put old version in download package for old users.
But this is also a big piece of work, however I think it will be easier than making tons of checks in theme, like ‘is plugin activated’ for backward compatibility.


#43

@vamtam adding prefixes for theme static files, functions or putting theme widgets into plugins for OLD themes is not going to make those themes’ quality much better. It may help prevent some conflicts with other plugins, but once again - we are talking about themes that already have been set up, customized and are working good. What sense does it make to do dummy work for authors and after that - for customers.
And let me quote myself:

One of the options to resolve this situation is an ability to create a new theme with new major version from scratch with no backward compatibility and put old version in download package for old users.
But this is also a big piece of work, however I think it will be easier than making tons of checks in theme, like ‘is plugin activated’ for backward compatibility.


#45

I personally think the “backward compatibility” must be included. What if some customer is using your themes on 10, 50 or 100 websites and he need to do all work again (to set up all sites).

Imagine if with each new update on your smartphone you need to install app’s again and to set up or to manually add all contacts again in your list.

That is how I am looking on this situations, and hope there will be solutions for all of as - for authors and for customers to go forward without recreating all things again from the scratch


#46

As a long time Envato subscriber, I’m opposed to this. I have no interest in using Gutenberg at present. Theme builders like Elementor are better and have worked fine for years.

I should not be forced to convert my themes to use a plugin or feature that I don’t need or want. If my template dev agrees, why should they need to make me a template that I don’t want? This is authoritarian nonsense. What happened to freedom of choice?