Theme showcase: selecting feature:block-themes only displays one theme

[annezazu]

I'm setting up a new site to build out a project for someone and tried to filter by feature:block-themes only to find one theme displayed (and a partner one at that! I'm on a premium plan!):

@ianstewart which team is best suited to address this asap?

[Robertght]

Flaggin this for @Automattic/t-rex @Automattic/lego as well.

[ianstewart]

The teams above. ^^ Looks like Dean has grabbed it.

[taipeicoder]

I've added to the Lego board as well in case we have capacity to pick this up in the upcoming weeks if T-Rex hasn't already addressed this.

[Copons]

FWIW, it returns one theme because only one theme is tagged block-themes.

This is not a development issue, as much as a categorization one. I don't know what the most efficient way to do this would be, but it's really a matter of going into the source site and updating the Theme Feature taxonomy on all the relevant themes.

[annezazu]

Digging into this further, it looks like we need to do a few things:

• Remove full-site-editing OR rename to site editor as we confirmed proper naming years ago at this point. The reason to remove is that it would match the current WordPress.org experience where we show everything as "Block Theme" (even though the URL remains as full-site-editing):

• Ensure anything tagged with full-site-editing or site editor is tagged as block themes.

If we remove the full-site-editing tag, we'll need to ensure all themes are tagged as block themes first. If we keep the full-site-editing tag (or site editor), we'll want to ensure users can find the same themes in either case. My opinion is to ensure anything tagged with full-site-editing is also tagged as block themes and remove the full-site-editing tag.

@richtabor curious what you think? Also curious to hear from theme designers if there's something I'm missing here since you all handle the launches @iamtakashi @henriqueiamarino @beafialho ❤

[taipeicoder]

My opinion is to ensure anything tagged with full-site-editing is also tagged as block themes and remove the full-site-editing tag.

+1. And ensure that the full-site-editing tag is removed from theme's wp-admin.

Worth noting that the full-site-editing tag had some functional purposes, such as detecting whether the theme was a block theme, or the theme switch behavior. IIRC, we've updated the logic to remove the tag dependency since it was a fragile approach. @fushar @arthur791004 can you confirm if this is the case?

[fushar]

The full-site-editing tag is technically no longer required. We've removed its requirement from:

• Design Picker logic Design Picker: Use wp_is_block_theme to Determine Whether a Theme Is a Block Theme #79732
• Live Preview logic Theme: Determine whether a theme is a FSE theme only by the block_theme attribute #95605

The only thing that could be a blocker is that our HEs are used to giving https://wordpress.com/themes/filter/full-site-editing URL to customers to suggest block themes. Not sure if that's still the case now...

[taipeicoder]

Would a Calypso re-routing work? Another approach is to have full-site-editing tag as an alias for block-themes in wpcom but feels like hidden logic.

[Copons]

The only thing that could be a blocker is that our HEs are used to giving https://wordpress.com/themes/filter/full-site-editing URL to customers to suggest block themes. Not sure if that's still the case now...

That would be my only (minor) concern too. I'd say it's not a problem as long as we communicate the new URL to HEs. 🤔
@tanjoymor do you have any opinions?

[dsas]

How many customers already have the current URL and occasionally use it? How long will it take all HEs to update their predefs and get used to the change? If we can keep the old one working then lets do that. Cool URIs don't change.

[Copons]

@dsas We could debate whether it's a cool URL. 😄
The term itself is obsolete, and the URL is virtually unused: counting all versions (logged-out, logged-in, with site selected) it averaged <40 daily uniques in the last month.

I'm not opposed to create a routing exception, it should be fairly trivial. I'm mostly questioning the usefulness of the URL altogether.
If it has no user value, and it's only a matter of updating HE predefs, then why keep an exception around that will come back to bite our future selves? 😄

[tanjoymor]

One thought is because updating HE predefs equates to many, many hours of work combined. Another thought is because breaking URLs is bad for everyone.

[dsas]

Generally speaking, for things that are trivial, and are unlikely to have a huge bite then I'd rather prioritise the HE + Customer experience over the developer experience.

<40 daily uniques in the last month is a gnats bite I guess, it might lead to a trivial number of tickets. Communicating to hundreds of HEs to check and update their pre-defs sounds time consuming and error prone. We'd also have to check and update our support docs etc too.

[Copons]

Right, since @tanjoymor has a strong opinion on this, it totally beats my lukewarm contrarianism.

I also reserve my right to, one day, say to everybody that "I told you so". 😄

@dsas, @taipeicoder: Whoever grabs this issue, we have several alternative approaches that we can take here:

1. Double tagging
   • Tag all block themes as both Full Site Editing and Block Theme.
   • And that's it. We'll have to live with having two labels for the same taxonomy, but it should be fine.
2. String filtering
   • Tag all block themes as Full Site Editing.
   • Filter the taxonomy name — or rename it on Calypso — to return Block Theme instead. (I think this is roughly what we did with the Theme Tier names when the plan names changed.)
3. FSE redirecting
   • Tag all block themes as Block Theme.
   • Redirect all /themes/filter/full-site-editing to /themes/filter/block-theme through the Calypso routing.

[tanjoymor]

I’m no expert on the technical side of this, but to me option 3 of redirecting feels like the better long-term option. (And may prevent @Copons from getting an I told you so moment 😂)

Curious though if search terms can also create a redirect environment? Like if someone searches for “full site editing” can it show the “block-theme” results?

It is a worthy exercise to update predefs and docs over time, it just doesn’t feel like the highest and best use of immediate time in terms of priority. Redirects allow more time for those updates to occur, and prevents broken URLs.

Also noting that ~40 daily uniques potentially equals 14K+ users per year. With discussions around every customer matters, this doesn’t feel insignificant in terms of user experience imo. 🤷‍♀️

[Copons]

Curious though if search terms can also create a redirect environment? Like if someone searches for “full site editing” can it show the “block-theme” results?

I think for that it would be enough to not delete the FSE tag. Maybe there are checks to prevent showing empty tags, but it should solvable via code. 🤔

[Copons]

@annezazu I'd like to make these tags as consistent to the Core theme library as possible, so I have some questions!

When we talk about "block themes", are we specifically talking about themes with a theme.json file, or any theme that plays well with the site editor?

For backward compatibility, Dotorg uses the full-site-editing styles.css tag and (presumably) re-labels it as "Block themes" on the front end. We already use the full-site-editing tag on Dotcom, so in that sense we are already doing the Core-compliant thing.
The problem here happened because one third-party theme has been tagged as block-themes, introducing a new tag and the whole confusion.
What if we removed the block-themes tag from that theme, or replaced it with full-site-editing?
This way, the "Block themes" filter would disappear from the search options, clearing the confusion. Users will be able to search for block themes either by using the "Full Site Editing" feature (which at this point could be safely re-labelled), or by simply typing "block themes".

[annezazu]

Here's what Core did for context: https://meta.trac.wordpress.org/ticket/7524 While the full site editing tag is still there, everything in the interface shows "block theme"! That's what I want.

What if we removed the block-themes tag from that theme, or replaced it with full-site-editing? This way, the "Block themes" filter would disappear from the search options, clearing the confusion. Users will be able to search for block themes either by using the "Full Site Editing" feature (which at this point could be safely re-labelled), or by simply typing "block themes".

Core shows the "Block Theme" feature filter and I think we should too. Since it seems like my screenshot didn't help, here's a quick video to help explain how Core has it set up:

Core.approach.mov

We should align with Core here to make it easier for launching themes but we also can and should offer a better experience! Unlike in the Theme Directory, we have full control here to make changes. Part of this includes searching for block themes. When that happens, I think we should automatically just set the feature to "block theme" and display all.

[jeryj]

What's the status of this? Was a decision made? I see two themes now when using the block-themes tag.

Also, I don't see a big difference between Block Themes, Block Patterns, and Block Editor Styles. Should they consolidated into Block Themes? If not, I think we should at least update the tags to match the first letter capitalization standard and add descriptions.

[annezazu]

What's the status of this? Was a decision made? I see two themes now when using the block-themes tag.

No work has been done on this unfortunately despite being on two team's list. As I stated above, we should be showing all block themes when searching for that feature.

Also, I don't see a big difference between Block Themes, Block Patterns, and Block Editor Styles. Should they consolidated into Block Themes? If not, I think we should at least update the tags to match the first letter capitalization standard and add descriptions.

I agree! @fditrapani has it on his list to loop back on our overall features/tags and perhaps this is something the broader designers coming from our division could help with too?

[annezazu]

Adding this to the design board but I believe the larger task is outlined in this issue: #98287 @crisbusquets sorry to potentially create more noise but I've added them both to the design board for you all to sort through! Do what you think is best in terms of keeping just one or both.

[Robertght]

i'm flagging this as In Progress on the One Board for now since it's actively being worked on. Feel free to ping us if you need PAs/PEAs input.

[annezazu]

I am going to manually fix this. We have 280 themes with the Full Site Editing feature tag and only 4 with the Block theme feature tag. I'm going to have any theme marked as Full Site Editing also marked as Block theme. The result will be that themes will show up in both places and (we could) in theory deprecate the Full Site Editing feature tag. Either way, it greatly lowers the urgency.

I'll update when I'm done.

[annezazu]

Tag teamed with @taipeicoder who kindly jumped in! I'm going to update the block theme feature description and close this out.

For future reference, if I can ever fix something manually, let me know. I will always happily dive in.

[fditrapani]

Nice work Anne!