search

Automattic / wp-calypso

The JavaScript and API powered WordPress.com
https://developer.wordpress.com
GNU General Public License v2.0
12.42k stars 1.99k forks source link

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

Open annezazu opened 1 week ago

annezazu commented 1 week ago

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

Image

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

Robertght commented 1 week ago

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

ianstewart commented 1 week ago

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

taipeicoder commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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

Image

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 commented 1 week ago

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 commented 1 week ago

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

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 6 days ago

@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 commented 6 days ago

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 commented 6 days ago

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 commented 6 days ago

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 commented 6 days ago

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 commented 6 days ago

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 commented 6 days ago

@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 commented 5 days ago

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:

https://github.com/user-attachments/assets/a9616b52-5262-4b0a-843f-e3d8177ce50f

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.