Add Two New Theme Tags on Theme Directory

[kafleg]

As per the ​discussion of theme review team, we want to add two tags align-wide and block-styles.

• align-wide - Support for Wide Align
• block-styles - Has styles for the block editor

Also, we need this tags on the theme filter.

[Otto42]

Theme tags also need to be added to core. We cannot do it unilaterally from the wordpress.org side of things.

[joyously]

I think align-wide is not very user friendly. Something like full-width would be more accurate.

[dd32]

Replying to Otto42:

Theme tags also need to be added to core. We cannot do it unilaterally from the wordpress.org side of things.

Core does fetch the list of tags from WordPress.org (and we version-gate tag changes), and only falls back to an internal list in the event the API is unavailable.

WordPress.org should be updated before WordPress is updated, it's often that WordPress.org/themes will have support for a month or more before WordPress itself does, to allow time for themes to be tagged with the new labels. It can be done in the reverse, but it's not as friendly as end-users then get mostly empty filters :)

​https://core.trac.wordpress.org/browser/branches/5.0/src/wp-admin/includes/theme.php#L225

Replying to joyously:

I think align-wide is not very user friendly. Something like full-width would be more accurate.

full-width is a little clashy with the existing full-width-template tag, but I agree that 'Wide Align' isn't very self-explanatory.

As an aside, for the full list of previously-supported tags, that's all helpfully in the API here: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/theme-directory/class-themes-api.php#L174

---

What's needed to move this forward:

• The category to put these tags under - I'd assume: Features for block-styles and Layout for align-wide
• A Short description (one or two words maximum) that explains what the end-user is selecting.

While I don't love the tag names, they're not as important as the name that the end-user see's/selects to filter by

[dd32]

Also noting that this is the core ticket to make the change in core once it's changed on WordPress.org:
​https://core.trac.wordpress.org/ticket/45344

[poena]

The wide align theme support is for both full width blocks and wide blocks, that is why the wide-align was suggested, but how do we communicate that to users?

Using this theme support does not necessarily mean that the theme supports full width blocks -
For example a theme with a sidebar could support wide width blocks but might not technically support full width blocks, that is why I would prefer not to only use a tag called full-width.

Do we need two tags?
wide-blocks -Support for wide blocks (We don't need to use "align", to me, a non native English speaker, align is more left/right/justify/center)
full-width-blocks -Support for full width blocks

[dd32]

It's also worth remembering that the end-user is often non-english speaker and/or isn't well versed with the developer terminologies used by WordPress.

"Blocks" while not in the users vocabulary currently, will be in 5.0+ eventually, so something like Wide Blocks seems useful enough to me.

I don't think we need to be too fine-grained on the tags, wide-blocks and full-width-blocks seem like the same thing (although we know they're not).

[poena]

So
tag: wide-blocks, name: Wide Blocks, description: Support for wide blocks, category: layout.
tag: block-styles, name: Block Styles, description: Styles for the block editor, category: features.

(The review teams list of descriptions is here: ​https://make.wordpress.org/themes/handbook/review/required/theme-tags/)

[joyously]

tag: wide-blocks, name: Wide Blocks, description: Support for wide blocks, category: layout.
tag: block-styles, name: Block Styles, description: Styles for the block editor, category: features.

This is much better.

Doesn't "Support" mean styles? Do "Block Styles" only live in the editor? Does it only mean that there are choices? (Are we talking about palette support or font size support?)

[poena]

I did not understand you.

I used the word support because thats what many of the other descriptions do:
Support custom menus,
Support custom logos,
Support feature images, and so on.

I thought it was for any block styles
not only custom things.

[joyously]

I'm trying to get this changed, but according to the ​Theme Support page,

If you’d like to use default styles in your theme, add theme support for wp-block-styles

Note that it doesn't mention palette colors or custom font sizes, just that the theme isn't doing anything about block styles, but taking the defaults.

For reference:
​https://github.com/WordPress/gutenberg/issues/9534
​https://github.com/WordPress/gutenberg/issues/11779
​https://github.com/WordPress/gutenberg/issues/12299

[Andre Jutras]

Just my two cents.... I would recommend/suggest the tags be: gutenberg
At the very least: block-styles

For the tag gutenberg, I would imagine a lot of people will want to find what themes (even plugins) support gutenberg when they do a search with the filter.

[poena]

We can't use the tag gutenberg, it will be used for the development plugin/code base, but not for the editor.

"Support" can mean anything we want it to. It is only a matter of the theme review team to decide what
the minimum requirement is for using the tag.
I am fine with any support.

Would you prefer

tag: block-support, name: Block Support, description: Support for the block editor, category: features.
or:
tag: blocks, name: Blocks, description: Support for the block editor, category: features.

And I still think the color palette fits under the existing "custom-colors" tag, it doesn't need a new tag, just like editor styles fits under "editor-style", no matter if it is block editor styles or classic editor styles.
But we need to help users find themes that won't look broken when blocks are added :)

[Andre Jutras]

Replying to poena:

We can't use the tag gutenberg, it will be used for the development plugin/code base, but not for the editor.

"Support" can mean anything we want it to. It is only a matter of the theme review team to decide what
the minimum requirement is for using the tag.
I am fine with any support.

Would you prefer

tag: block-support, name: Block Support, description: Support for the block editor, category: features.
or:
tag: blocks, name: Blocks, description: Support for the block editor, category: features.

And I still think the color palette fits under the existing "custom-colors" tag, it doesn't need a new tag, just like editor styles fits under "editor-style", no matter if it is block editor styles or classic editor styles.
But we need to help users find themes that won't look broken when blocks are added :)

I forgot that Gutenberg cannot be used...my bad. Possibly this:

tag: blocks, name: Blocks, description: Support for the block editor, category: features.

[joyously]

The way the other tags work is the add_theme_support matches the tag. As long as this is clear to reviewers, that the theme doesn't have to use add_theme_support to use the tag, I can see condensing it all into one tag like block-support. My theme supports blocks, but doesn't use any of the add_theme_support calls because I want to support both editors equally and I don't like what happens with those add_theme_support calls.

[acosmin]

@dd32 @Otto42

We had a discussion regarding new tags and we think that block-styles and wide-blocks would be ok for now. We can revise in 6 months

block-styles - Themes must have custom styles for the core blocks on the front and back-end

wide-blocks - Must support both .alignwide and .alignfull classes

[Otto42]

It would be nice if for "block-styles" they were also required to have editor styles, to style the editor to match the front end view.

[dd32]

Replying to acosmin:

@dd32 @Otto42

We had a discussion regarding new tags and we think that block-styles and wide-blocks would be ok for now. We can revise in 6 months

@acosmin Sorry, I missed this notification for some reason, I'll follow up today.

[dd32]

In 8124:

Themes: Add two new Block-related tags.

See #3921.

[dd32]

In 8273:

Theme Directory: API: Return the 'custom-logo' theme tag for WP 4.6+ and setup the wide-blocks and block-styles tags for WP 5.2+.

See ​https://core.trac.wordpress.org/ticket/46272
See #3921.

[dingo_d]

This has been implemented, right? So the ticket can be closed. If we'll need new ones, we'll open a new ticket :)

If I missed something feel free to reopen it.

[SergeyBiryukov]

Replying to dd32:

Core does fetch the list of tags from WordPress.org (and we version-gate tag changes), and only falls back to an internal list in the event the API is unavailable.

Looks like that's no longer accurate as of WordPress 4.9:

• ​[WP41648] removed a bunch of theme features from the core list.
• ​[WP42003] then disabled the API call on Add Themes screen "due to inconsistencies and to ensure tags are translated".

With those changes, every instance of get_theme_feature_list() as of WordPress 4.9 no longer calls the API and just returns the hardcoded list. One exception is the instance in install_themes_dashboard(), however that function is not used anywhere.

Created ​#WP50165 to track the changes and try to reconcile the differences, so that the API could be used again.

[dd32]

Looks like that's no longer accurate as of WordPress 4.9:

Well that's a shame, I'd suggest reverting ​[WP42003] instead. I'll comment as such.