is this applies to Plugin Developers who also sells on CodeCanyon ? and also which dose not have any integration with Gutenberg ?
Sorry, quite confused here.
So, if our themes are not compliant with Gutenberg and we check ‘no’ in ‘Gutenberg Optimized’ option. Will we still get the badge?
edited: came up with some more questions so I will list my questions here.
As mentioned above, if our themes are not compliant with Gutenberg and we check ‘no’ in ‘Gutenberg Optimized’ option, will we still get the badge?
What happen if we don’t get the theme updated by 31 May 2019? Will items be removed or something?
By requiring old themes to be compliant with new requirement, how much do we need to change in old themes? Every single things here: http://take.ms/G891Y ? Example, in the past, the way we code themes might not be required for pre-fix, now we have to put pre-fix in all old themes?
Or just to make it compliant with new major requirements in this topic : Updated WordPress Requirements (and also Gutenberg) is enough for changing in old themes?
The point is requirements in past 4-6 years ago and today are so different and it will be HUGE changes if every single things needed…
4.1 Regarding ‘6 months fallback period’ for ‘Plugin territory functionality’. Does it mean that if we update all themes by end of May but not doing ‘Plugin territory functionality’, will we still get the badge? Because it states that ‘Functionality migrated to a plugin can now also remain in the theme until November 30, 2019.’
4.2 And what will happen if we don’t do ‘Plugin territory functionality’ by November 30, 2019
- A second time checking will be performed after two months waiting period. I think it would be fair to change it to third time because in the first time, author might still don’t really know where they really need to focus on. When we submit for new items these days, even we made sure everything was perfect, still got many rejections so this is something quite really hard.
Hope to get accurate answers from Envato team regarding my questions.
I’m not quite sure if this is the place to discuss this matter (and seems like I’m late too, sorry) but as for widgets in themes I have 2 questions:
(1) Enhancing native widgets
There is a usecase that wasn’t taken in account, I think:
I tend to enhance WordPress native widgets with additional functionality. That requires unregistering a native widget and registering a new enhanced code instead. This is forwards and backwards compatible way though.
It was discussed in WordPress.org theme repo too:
- Issue explanation: https://themes.trac.wordpress.org/ticket/46546#comment:8
- Conclusion/resolution: https://themes.trac.wordpress.org/ticket/46546#comment:26
So, are widget enhancements allowed by Envato too, or should all of these be a new widgets in a separate plugin?
(2) Functional widgets (with no content generation)
If a theme adds a custom search widget (for a Staff post type), should this also be added as a plugin? The widget produces no content at all, it’s just a functional widget providing better search options for dedicated post type.
Could these types of widgets be included with theme?
Thanks for any input on these!
Seems that all the themes should have the “Gutenberg Optimized” to “yes” in order to get the badge…which is a pain for authors with lots of themes
I would like to know what if a theme has some unique features that require specific custom fields? Could we include the code for those field registration in the theme?
For example, for portfolio themes, we already have a portfolio plugin which registers a custom post type and standard custom fields for portfolio functionality. If the theme we are going to build has its own unique features that need additional custom fields (or to override the plugin’s custom fields), could it be done in the theme?
To be honest, author who meets all requirements, will not get any search boost. All will be worked as now: themes with better sales ratio be on top of search results. IMO.
P.S. I’m just curious: is there any plans about future of ThemeForest? Is there any plans about ADP (new field with old price/new price, coupons system, etc)?
This a big confusing for plugins. It is a great step, but when A is said B has to be done as well.
WordPress plugins can be done in two ways:
- Via front-end (Guttenberg, Shortcodes).
- Via RESTAPI - https://developer.wordpress.org/rest-api/ . There is official way how to do these API via POST, GET, PUT, DELETE, HEAD, PATCH JSON params. But 9 of 10 plugin authors DOES NOT follow the standard procedure.
So, the REST_API only (i.e. validator) plugin is allways Guttenberg ready, as it DO NOT HAVE ANY front-end part. And many authors use custom-make ‘hacks’ for API calls, they also use ‘admin-ajax’ for the front end, where there REST-API is official since WP 4.7.
So my suggestion is that you would add another line:
“REST API optimized”:
No API (N/A)
As otherwise, even if I release a MindBlowing REST-API plugin, it won’t be boosted in search because it is not guttenberg-optimized (as there is no front-end). So I’d suggest to consider this is as a full scope (REST-API / Guttenberg). And boost those that are either “REST-API” optimized or Guttenberg-optimized.
REST-API is a big thing, maybe even bigger than a Guttenberg when we talk about multi-server communications, as there is no no language-barrier if REST-API is used, and .NET can work with PHP apps.
And one more question. If I have plugin that follows all coding standards and is based on shortcodes, shortcodes are supported by the Guttenberg, and they are not deprecated. So there is no blocks yet, but that is not required by WordPress either, as Guttenberg supports shortcodes. So am I able to get that “WP Requirements Compatible” badge?
I have read in the requirements for plugins the following:
- Create equivalent blocks in Gutenberg for any shortcodes created by the plugin.
My shortcode has 0 to max. 130 optional attributes. Adding all 130 possible attributes to a block makes this completely unusable. So how should this be solved to be optimized?
There seems to be lots of confusion about the new Gutenberg Optimized attribute and the new WP Requirements Compliant badge and how they are related, so I’m going to just address that issue in this update. I’ll be back later in the day to address the other issues.
The Gutenberg Optimized attribute and the WP Requirements Compliant badge are not directly related. We just chose to put them in the same announcement post so that it would be less likely for people to miss one of the announcements.
Gutenberg Optimized Attribute
This is an item level attribute. You can choose to turn on the Gutenberg Optimized attribute yourself when you upload. If you do this, then your item must meet our definition of Gutenberg Optimized. The theme definition is here (the Gutenberg editor must look like the front end of the site) and the plugin definition is here (depends on what your plugin does).
Your item does not need to meet all of the requirements to turn this attribute on. Of course your items will need to meet all requirements by 31 May 2019 (or earlier if you want the badge), but that has nothing to do with this attribute.
WP Requirements Compliant Badge
This is an author level badge, which is awarded by Envato. It will only be awarded to authors who have passed the spot check process, ie all items meet the current/updated published requirements (for themes and plugins respectively).
Note: Items don’t have to do the things in the strongly recommended sections - these are recommendations. In regard to Gutenberg, items don’t have to meet the Gutenberg Optimized definition, but they do have to meet the Mandatory requirements for Gutenberg so they aren’t breaking people’s sites.
I’ll now answer some of the specific questions around this:
Yes, this applies to plugin authors as well. Your plugin needs to meet the current plugin requirements by 31 May 2019. If they meet the requirements earlier than that, you can nominate for a spot check and if you pass, you will get the WP Requirements Compliant badge.
If you don’t have any integration with Gutenberg, your item won’t be breaking any of the Mandatory Gutenberg plugin requirements so it will be okay. Obviously you must not turn the Gutenberg Optimized attribute on for this item.
If your themes don’t meet the Gutenberg Optimized theme definition then you can’t turn on the Gutenberg Optimized attribute. That won’t affect whether you get the badge or not. You can still get the badge if all your themes meet the requirements, but note, that means meeting the mandatory Gutenberg requirements.
No, as explained in previous answers you can get the badge (if all your items meet the requirements) without items having to be Gutenberg Optimized. Please note: They do need to meet the mandatory Gutenberg requirements so that your items aren’t breaking people’s sites.
Gutenberg will be added to WordPress 5.0, which is scheduled to be released tomorrow. Your current and potential customers are going to start wanting to use it, so it’s worth considering optimizing for it.
Yes, you would be able to get the WordPress Requirements Compliant badge (if you pass the spot check), but you would not be able to turn on the Gutenberg Optimized attribute.
I’ll leave it here for now, but will be back later today to answer some of the other questions. I hope this has made things clearer, but please let me know if there is still any confusion.
I was asking about putting custom widgets into plugins for existing themes that has registered custom widgets inside these themes and had no answer.
If customer will update theme with widgets that was registered inside theme and now they are in the plugin this will break theme layout until the plugin with custom widgets will be installed and activated and widgets are set correctly.
Question: can you apply this requirement for new themes only to avoid this problem?
Just add check
if ( class_exists( 'Your_Super_Custom_Widget' ) ) register_widget( 'Your_Super_Custom_Widget' )
Ok, even if we don’t want to set the Gutenberg Optimized option to Yes we still need to work and make the theme semi-compatible… which also doesn’t make sense (for old themes).
Styling all the elements from the Gutenberg to match with the design of the theme is likely: full compatibility in one word .
If we don’t offer support for Gutenberg, why should we style the elements?! Where is the sense here?
Unstyled elements from Gutenberg will not break people’s sites…as you mentioned before.
Looking for a reply on this… we just want to clarify this matter…because for authors with + 50 themes, styling each element from the Gutenberg will be just a Pain…
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?
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:
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:
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.
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.
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?