Hi everyone! Here’s the ninth weekly roundup of theme-related discussions, fixes, and developments in Gutenberg.
Since conversations are ongoing, some of the issues & PRs mentioned were also present in previous weeks. We’ve tried to put brand new ones at the top of each of the bulleted lists.
Please weigh in on the tickets below — your voice and feedback are welcome!
In progress / Discussions:
General
Custom gradients cannot be edited if there are no explicit stops specified. 23501
Gradient stops should be allowed to fully overlap in the gradient UI. 23816
Discussion around adding font unit options to the font size selector. 23323
Block-based Themes
Add a tutorial about how to build a block-based theme. 23732
Discussion about the support of shortcodes in block-based theme templates. 23626
Discussing the use of conditional logic in experimental-theme.json. 22324
Tracking issue for Template Tags in Full Site Editing. 22724
Add Template lock to templates created in editor. 23532
FSE Blocks
A set of blocks are available with the Gutenberg plugin to enable building templates in FSE.
2 more were approved but are waiting to be made live.
21 tickets were not-approved.
0 tickets were closed-newer-version-uploaded.
The current waiting time for new themes is 4 weeks. 73 themes are in the new queue.
Using reusable blocks to ease the transition to block based themes
@aristath Has written a post about using reusable blocks outside the content.
Reusable blocks can be used as a stepping stone for themes that want to make use of the block editor for header/footer/sidebars etc. before FSE is officially released.
It was suggested during the chat that theme authors should try full site editing instead of a temporary solution. Full site editing is not stable enough to be used in production, but reusable blocks are stable and can be used with existing themes.
Theme uploads that are blocked by Theme Check because of their images
Older themes with images from Unsplash and Pixabay, where the images were added to the theme before the website’s license change, have been blocked by Theme Check when uploaded to the WordPress.org theme directory.
It was decided that Theme Check will be updated to no longer block the images. This is a very small code change.
Allowing themes to place their admin page outside the appearance menu for increased visibility
This topic arose from a question about whether themes are allowed to add a panel with information to the block editor sidebar/tools panel. This is not allowed.
To keep the editor free from clutter, advertising and upsell, with the customizer being used less, and no dashboard widgets being allowed, can we give theme authors a better place to include their information, and limit upsell to that area?
If a top level menu item would be allowed, these restrictions were suggested:
No priority may be used.
No UI or color changes are allowed for the menu item.
The title must be kept short and not include spam.
If a custom icon is used it must be a single color.
No more than 3 subpages.
A longer more heated discussion took place after the meeting, and the decision was postponed. A new post will be created on the teams make blog to discuss it further.
We want to remind everyone that the requirement for not adding any obtrusive upsell is still in place.
How do we best handle updates to themes that have not been updated in two years?
Updates to themes that had not been updated in two years used to “get stuck” because reviewers were not able to see that they did not go live automatically.
There are not enough reviewers to cover all queues.
Theme authors may not be aware that their update is not going live automatically
Theme authors may not be aware of that old themes has to follow the current requirements.
It was suggested that these themes should be set live, and there was a short discussion about if it was safe to set them live. It is common for these themes to not follow the current requirements.
The discussions resulted in no changes being made to the queue. We need to remind theme reviewers to also review themes from this queue.
Update on the navigation block/navigation screen
The navigation block and navigation screen will not be ready in time for WordPress 5.5. Please help test these features.
There is a new meeting about navigation on Wednesdays at 07:00 UTC in the #core channel on the WordPress slack.
@aristath Has created and written about a menu filter that helps theme authors add markup and CSS classes used by the block to the current nav menu.
This will help theme authors use the same styling for their current navigation and the navigation block.
Full-Site Editing (or FSE for short) is scheduled to be released with WordPress 5.6. In the meantime, the Gutenbergplugin includes a Navigation Block that theme-authors can use to experiment and preview what their navigation will look like once users are able to use FSE on their sites.
You can already start preparing for this shift by making the default WordPress navigation use an HTML structure similar to what the Navigation block is going to print.
To do that, you can paste the following code in your theme’s functions.php file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
/**
* Filters the CSS class(es) applied to a menu list element.
*
* @param array $classes Array of the CSS classes that are applied to the menu `<ul>` element.
This will allow you to see what the future structure of navigation will be in WordPress themes and you can start converting your styles & scripts accordingly to accommodate these changes and be ready for when they land in WordPress Core.
(which produces identical output to the original post)
In the current example, having the nav and ul HTML outside of the call to wp_nav_menu makes it impossible to override/change using filters, meaning the header.php file must be edited manually to remove/change them. I think it’s good practice to let wp_nav_menu handle as much of the menu related markup as possible.
This looks interesting.
Could I request you update the last piece of example code, so that all menu related markup is handled by wp_nav_menu()?
Either this:
wp_nav_menu(
array(
'container' => 'nav',
'container_class' => 'wp-block-navigation',
'menu_class' => 'wp-block-navigation__container',
'theme_location' => 'primary',
)
);
(which looks neat and produces almost identical output to the example in the original post, but does unfortunately lack the “role” attribute)
Or this:
wp_nav_menu(
array(
'items_wrap' => '<nav class="wp-block-navigation" role="navigation"><ul class="wp-block-navigation">%3$s</ul></nav>',
'theme_location' => 'primary'
)
);
(which produces identical output to the original post)
In the current example, having the nav and ul HTML outside of the call to wp_nav_menu makes it impossible to override/change using filters, meaning the header.php file must be edited manually to remove/change them. I think it’s good practice to let wp_nav_menu handle as much of the menu related markup as possible.