WordPress Requirements Update and New Gutenberg Optimized Attribute

[StephenCronin]

Hi All,

Sorry for the delay, but I’m back with some more answers:

========

@"mwtemplates

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?

We don’t prevent you from doing this, but we don’t recommend it either. You’d want to think very carefully about the experience for current customers and give them detailed information outlining their options (ie stay on old version or detailed instruction on how to update to the new version, etc). You’d also want to give them as much notice as possible, ie maybe pushout an update with a notification of what will happen, etc.

========

@"payothemes

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.

You don’t have to replicate the page builder layouts etc in Gutenberg, but you do need to make make sure there are no errors and nothing looks wrong if the user chooses to use Gutenberg instead. Basically you need to follow the Mandatory Requirements for Gutenberg.

You can choose whether you want to meet the Gutenberg Optimised Definition or not, but you only need to do this if you turn on the Gutenberg Optimized attribute. So in your case, you can just leave this attribute off.

As for the WP Requirements Compliant badge, you have to meet all the requirements (not the strongly recommended points) for all your items by 31 May 2019. As far the Gutenberg part goes, this means you need to meet the mandatory requirements mentioned above, but not necessarily the strongly recommended or optimised definition ones. If you finish that early, then you can apply for the badge!

You asked some similar questions to this after this one, but I think this covers all of it. Let me know if you have any more questions.

========

@"Avirtum

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

You don’t have to recreate shortcodes as blocks, unless you have a plugin on CC and want to turn on the Gutenberg Optimized attribute (see the definition here). However, it’s probably worth considering that Gutenberg is now part of WordPress and more and more people will start using it. Over time they are probably going to expect plugins and themes to fit into the block mentality, so it’s probably worth planning for how to address that.

========

@"DAEXT

@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.

We’ll consider this one further. There may be an argument that to meet the definition of optimized, the representation of dynamic blocks should be similar to what’s shown on the front end (like the Recent Posts eg from core) and should therefore be styled as on the front end. Obviously this would not be a mandatory requirement, but it may (or may not) fall in the optimized definition. We’ll consider and post back here later.

@"DAEXT

@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.

At this point we are not requiring that plugins need to convert shortcodes to blocks, enqueue a stylesheet or integrate controls, etc. We’d obviously like them to do so, which is why we added the attribute (to encourage authors to adopt these), but plugins don’t have to do these things.

We did choose "optimized" instead of "compatible with" to try to make the purpose of this attribute clearer, but I take your point that the attribute could be confusing to customers. I will discuss with others internally and post back here.

@"DAEXT

@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.

We plan to keep the attribute in place indefinitely, although as phases 2, 3 and 4 of Gutenberg roll around, we may need to adjust our plans.

Plugins that do not create shortcodes, create metaboxes, add controls to the editor or output content on the front end would not be allowed to set the flag to Yes. It’s only for those plugins that do one (or more) of these things and choose to go above and beyond to make sure that they are optimized for Gutenberg.

As mentioned above, we’ll discuss this internally.

========

@"phpplus

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.

If the themes were no longer being sold then it wouldn’t be an issue. However as these themes are still being sold, we want them to be doing things right way, so that future customers are not impacted when they change themes.

We obviously want authors to make sure current customers are not impacted by the changes, which is why we have given them an extra six months to keep a fallback in the theme while customers are educated on what they need to do. In most cases, this will simply be to install and activate the plugin (or update the existing one) at some point during the fallback period. I appreciate this will be a lot of work if you have a lot of sites and not all authors will follow the fallback approach, but we’re hoping most will.

Many of your points mention the prefixing rules - as mentioned in my Dec 7 response above, we are considering a exception to the prefixing rules for old themes. We’ve not yet finalised this, but will add your points to our discussion.

Your point about the translations is a good one and we’ll look further into that.

========

@"Clubware3

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?

Gutenberg is now the default editor in the current version of WordPress. It is no longer a plugin, it is THE WordPress editor.

Themes can continue providing tight integrations with page builders. They don’t have to build a tight integration with Gutenberg instead. They do need to make sure that if a user decides to use the default WordPress editor instead of their recommended page builder, that the output fits the general theme design and that nothing breaks.

We don’t think it’s unreasonable to require that Themes currently being sold support the current version of WordPress.

========

@"rayoflightt

• Is replacing widgets from theme to plugin reffers to specific theme widgets or widgetized areas? I suppose it reffers to first thing.

• If my theme uses page builder, and page builder can’t work in the same editor together with Gutenberg (and I think that is the case with all page builders), can I state that Gutenberg can be used only for new posts and pages

in that theme, and can’t be used in demo pages that already are created with page builder? And still get theme approved as Gutenberg optimized.

1. Yes, it refers to the actual widget registration, not the widgetized areas.

2. You can recommend to users that they use the page builder you’ve integrated for all posts/pages. However, if a user chooses to use Gutenberg instead, then it needs to work (ie meet the mandatory requirements). And if you want to use the Gutenberg Optimized attribute, then it needs to meet our definition of optimized. But that doesn’t mean you can’t be recommending the page builder as the primary experience or telling users that demo pages require it.

========

@"SecondLine

What is Envato’s policy about styling the “Classic Editor” block within the new (Gutenberg) Block Editor?

Should it be styled to match the old, clasic , editor, or contain the new styles that should be applicable for the new blocks as well?

The current requirement seems to be a bit broad - authors need to cover the current blocks, the classic editor (i.e. making sure no styles are being applied) and the block editor along with classic blocks for backward compatibility.

It makes sense to support all scenarios, but perhaps using the old Theme Unit Test from the 2013 as a testing reference should be updated.

I’m not quite sure what you mean, so you may need to explain it further to me!

The mandatory requirements basically say that the output of blocks (including the classic editor block) on the front end need to match the theme design. The output of the classic editor block should be the same as the output of the old editor, so should match the theme design.

The definition of optimized for Gutenberg basically says that the back end editor/Gutenberg needs to look like the front end. If you wanted to turn the Gutenberg Optimized attribute on, then you’d need to make sure that the classic editor block (and all other default blocks) in the back end looked like the output on the front end.

If that doesn’t clear it up, please give me some more details, thanks! As for the Theme Unit Test data, we are currently looking at what we should be recommending these days and we’ll have more news of that in the future.

========

@"acmee

For Codecanyon: I think Gutenberg optimized attribute has nothing to do with other WordPress plugins (which doesn’t have relation for blocks creation) but confusion for buyers. If a plugin marked as Not gutenberg optimized but the plugin has no relation to the editor, there might be more chances for the buyers to think that the plugin doesn’t support the latest version of WordPress. Why not you just categorize the WordPress plugins for Gutenberg by creating a new category “Gutenberg” and list all Gutenberg related plugins? So from my perspective, Gutenberg optimized attribute is useless for codecanyon.

For Themeforest: Shall we force activate Classic editor using TGM? Because many buyers who are not using Gutenberg are started to ask

> WPBakery page builder is not working, only showing codes. It doesn’t support or not compatible with WordPress 5.0?

And what is the usecase for styling Gutenberg blocks when we bundle Premium page builders and complicating theme creation process with extra styles. Did you have like this styling requirements added for themes bundled with premium page builders prior to Gutenberg? I mean for Classic editor before the arrival of Gutenberg?

For the CC attribute, as I mentioned somewhere up above in this long answer, I’ll take that away and discuss with others internally.

The latest version of WPBakery Page Builder should work with Gutenberg - maybe Gutenberg overrides it the first time they edit the post after the WP5.0 update? If the user clicks the WPBakery Page Builder button, it should use that from then on. Anyway, you can use TGM to recommend the user activate the Classic Editor, but of course we don’t allow force activate. The user needs to be informed what’s happening and take the action to make it happen.

The use case for styling Gutenberg blocks is that Gutenberg is now THE WordPress editor and if a user decides they want to use it instead of the bundled page builder, it needs to work. The output needs to fits the general theme design and nothing should break. Themes currently being sold need to support the current version of WordPress.

We did have this styling requirement for the old editor. We used the Theme Unit Test data to check that all content was output as expected. If the theme didn’t style something appropriately or if something clashed with the general theme design, we asked for it to be fixed. The new editor includes more types of content (eg galleries), but it is the same principle: whatever is added via the current WP editor needs to appear on the front end styled appropriately and fitting the overall theme design.

========

@"hevada

Hi, since WordPress 5.0 is already out (and also 5.0.1 already) I was wondering if the “Software Version” field in item detail pages on codecanyon and themeforest can be updated with a WordPress 5.x option.

I used this form a few days ago to report this, but I don’t know if this form is still used: http://www.formstack.com/forms/envato-versionupdate

Umm, that’s a pretty bad oversight on our behalf! And not the first time either. I’ll request that to be added ASAP. Sorry for the inconvenience.

========

Thanks everyone!