WordPress.org

Making WordPress.org

Opened 5 months ago

Last modified 2 months ago

#3921 assigned defect

Add Two New Theme Tags on Theme Directory

Reported by: kafleg Owned by: dd32
Milestone: Priority: normal
Component: Theme Directory Keywords:
Cc:

Description

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.

Change History (28)

#1 follow-up: @Otto42
5 months ago

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

#2 @joyously
5 months ago

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

#3 in reply to: ↑ 1 @dd32
5 months ago

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

Last edited 5 months ago by dd32 (previous) (diff)

#4 @dd32
5 months ago

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

This ticket was mentioned in Slack in #themereview by dd32. View the logs.


5 months ago

#6 @poena
5 months ago

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

#7 @dd32
5 months ago

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

#8 @poena
5 months ago

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/)

#9 @joyously
5 months ago

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?)

#10 @poena
5 months ago

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.

#11 @joyously
5 months ago

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

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


5 months ago

This ticket was mentioned in Slack in #themereview by poena. View the logs.


5 months ago

#14 @Andre Jutras
5 months ago

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.

#15 follow-up: @poena
4 months ago

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 :)

#16 in reply to: ↑ 15 @Andre Jutras
4 months ago

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.

#17 @joyously
4 months ago

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.

This ticket was mentioned in Slack in #themereview by poena. View the logs.


4 months ago

This ticket was mentioned in Slack in #themereview by acosmin. View the logs.


4 months ago

#20 follow-up: @acosmin
4 months ago

@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

Last edited 4 months ago by acosmin (previous) (diff)

#21 @Otto42
4 months ago

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.

This ticket was mentioned in Slack in #meta by joyously. View the logs.


3 months ago

#23 in reply to: ↑ 20 @dd32
3 months ago

  • Owner set to dd32
  • Status changed from new to assigned

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.

#24 @dd32
3 months ago

In 8124:

Themes: Add two new Block-related tags.

See #3921.

This ticket was mentioned in Slack in #themereview by joyously. View the logs.


3 months ago

This ticket was mentioned in Slack in #themereview by dannycooper. View the logs.


3 months ago

This ticket was mentioned in Slack in #meta by joostdevalk. View the logs.


3 months ago

#28 @dd32
2 months ago

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.

Note: See TracTickets for help on using tickets.