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.
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 have my themes made with page builder and i use page builder s addons. So my demo pages from theme are made using addons from page builder and page builder "Blox page Builder ".
I updates to wp 5, so i have editor gutenberg. No issues or errors in page or console.
What i need to do to have my theme gutenberg optimized?
I need to have an option to include all page builder s addons in gutenberg editor?
Or what can i do? I want to use the same page builder on my themes so i don’t make design with gutenberg, only in article posts where i will add few images and text.
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 isplugin 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).
@StephenCronin 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?
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.
Sorry for the delay, but I’m back with some more answers:
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.
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.
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.
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.
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.
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.
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.
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.
Yes, it refers to the actual widget registration, not the widgetized areas.
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.
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.
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.
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.
Yeah your comment pretty much covers it. Thanks!
Initially it was unclear whether the “Classic Block” needs to be styles the same as the other blocks or left in the “Classic” style (i.e. no styling at all), but it is true it makes a more sense to style everything within the Block Editor to match the front output.
As per the Theme Unit Test data, it’d be best to use some other method, perhaps custom made. There’s the great Block Unit Test plugin (created by Rich Tabor), but it won’t cover many of the markup related elements.
This is problematic for the review process at the moment, because the point of reference is quite outdated.
It means more work for theme author and for the reviewers, so perhaps fully covering only regular blocks and broadly covering the Classic Block.
Firstly, you may be interested in today’s TF Search Boosting announcement for TF authors who have the WP Requirements Compliant badge. If you have questions about the search boosting, please ask them over on that post.
Now, on to some more answers:
@DAEXT@acmee - We’ve now had an discussion about the Gutenberg Optimized attribute on CC based on your feedback.
We believe users will recognize that the term ‘optimized’ means that the item has done something to integrate better with Gutenberg, and won’t see it’s absence as a sign that the item won’t work with it. The attribute will remain in place for now. However, we will monitor the impact and reconsider if we notice any problems.
I know that may not have been the answer you wanted, but we will keep an eye on this.
@hevada - The WordPress 5.0.x entry should be added to the Software Version field in the next day or so.
@mypreview - The WooCommerce 3.5.x entry should be added to the Compatible With entry sometime after that.
Yes, we’ll try to sort this out in the near future. Sorry for the inconvenience and thanks for your patience!
That’s not correct. I’ll try to explain:
If you want to set the Gutenberg Optimized attribute to Yes (for a theme), then you need to make sure the theme meets the Gutenberg Optimized definition. Basically you need to make the Gutenberg editor look like the front end, so that if users choose to use it, then what they see is what they’ll get (ie same style). You don’t need to make Gutenberg the recommended experience or convert builder addons to blocks. That said, it’s probably worth considering customer expectation. Some are likely to want to use Gutenberg, and the WP project will continue to improve it, so demand is likely to grow. It may be worth catering for these customers.
If you set the Gutenberg Optimized attribute to No (for a theme), then you don’t need to meet the Gutenberg Optimized definition.
In either cases (ie for all themes), you need to meet the Mandatory Gutenberg requirements. Basically, you need to make sure there are no errors, that the output of the core blocks look okay (and fit the theme style) on the front end, and that you’re not registering or blacklisting blocks.
That’s the situation for the forseeable future. We don’t have any plans to require authors to make all themes meet the definition of optimized for Gutenberg, although we do recommend authors consider that this is now part of WordPress and demand/expectations are likely to grow.
Hope all that make sense, but let me know if not.
Also, a heads up: I’ll be off again after tomorrow for 3 weeks (until Mon 14 Jan). We may have others answering some questions while I’m away, but some of it may have to wait until my return. If you have any questions that you can ask today, then I will try to answer them tomorrow before I leave. And I’ll make it a priority to answer any outstanding questions when I get back.
So, we tried to make an older theme ready for the actual WP Requirements… the update got rejected for 3-4 times because the default installation doesn’t look presentable… On the code side everything is ok, Gutenberg mandatory requirements ok, all plugin territory functionalities ok but now, the reviewers reject the items for the default installation…
This way, the authors with + 50 themes to update will be blocked in a reviewing loop… Hey @StephenCronin is there a way to inform the reviewers that a particular update is only made to make the theme WP compliant and get the badge?
Updating the design on 3-4 years old themes is not a solution.
Again thank you for clarification.
What i don’t understand is what you mean by
‘’ Basically you need to make the Gutenberg editor look like the front end, so that if users choose to use it, then what they see is what they’ll get (ie same style). ‘’
Do you mean if i use page builder with design A, on gutenberg need to look exactly the same?
If you could please lodge a ticket saying attention to me, with some details, ie the name of the themes this happened for, I’ll look into it.
In general you shouldn’t have to change the design, but we do have a requirement that the theme should look reasonable and show content etc out of the box. Anyway, if I have some specifics, I can look into it.
You don’t need to make the demo content editable in Gutenberg, but you need to load the front end styles so that if the user creates new content in Gutenberg, it looks like it will on the front end.
If you install the latest version of Twenty Seventeen and edit a post, you will notice that the content in the Gutenberg editor does not look like it does by default. Instead it looks like it will on the front end of the website. Headings are styled the same, the same fonts are used etc etc. Twenty Seventeen is loading the theme styles inside Gutenberg so it looks the same as the front end.
Which is the same as the front end of Twenty Seventeen:
That’s what we mean by optimised for Gutenberg. If the user edits content in Gutenberg then it should look like the front end. Ie you need to style the editor content to match the frontend output as closely as possible, including any fonts used and any dynamic styles coming from settings etc.
Okay, I’m off now for 3 weeks (until Mon 14 Jan). Keep asking questions if you have them. We may have others answering while I’m away, but some of it may have to wait until my return. I’ll make it a priority to answer any outstanding questions when I get back.