Give some priority to Block themes(FSE themes) in the WordPress themes repository

[kafleg]

As we are assuming block themes are the future. Our default theme is a block theme. This means we're more dedicated to Block themes.

I think that we need some priority for block themes in the themes repository.

Here are my suggestions(We can choose one of them):

• Add a new tab in the theme's repo. ( Popular, Latest, Block)
• Change the popular themes algorithm and add 1 block theme in 1 out of 10 popular themes.

Or, there might be some other way to encourage block theme authors to contribute more.

We don't need this always, but we can try this for at least 1 year and we can see how it will go.

Block themes need some attention and encouragement. Only very few FSE themes are maintained properly.

[joyously]

I think that we need some priority for block themes in the themes repository.

If block themes are the future and are better and easier, they don't need any extra promotion.
Since the WP software handles both, it is very disrespectful to the authors that followed all the rules to build up their placement in the repository, for WP to suddenly give the new type an advantage. (The site editor still has a "beta" label.)
All themes should be treated equally.

[mikachan]

As block themes are a different type of theme from classic themes and enable so many different features, I think it makes sense to separate them out in the directory somehow.

I like the idea of having a 'Block' tab next to 'Latest', as shown in block_themes.png​. This sounds like a good, small first step.

Would this show the same results as the Full Site Editing tag ​https://wordpress.org/themes/tags/full-site-editing/? There could be some confusion around 'Full Site Editing' vs 'Block' for new users.

[richtabor]

I think that we need some priority for block themes in the themes repository.

I don't think that priority is quite the correct context. Block themes are categorically different than "classic" themes, because of the nature of the theme, the Site Editor experience, and Global Styles.

It's not that we should prioritize block themes, but rather indicate that these are a new class of themes that diverge from the classic theme WordPress experience. If someone unknowingly switches from a block theme (like the default Twenty Twenty-Two theme) to a classic theme, they'll loose the core WordPress functionality that they may be familiar with/reliant on.

If block themes are the future and are better and easier, they don't need any extra promotion.

It's not about promotion, but education and discoverability.

[Anariel Design]

I agree with @richtabor, we need to indicate somehow the new era of the WordPress themes and also to bring them closer to the users. If we want more people to use FSE themes (as this is a future) then we need to make it more discovarable, easier to find. I don't think this is about promotion. Now u can find FSE themes just if u filter and search for Full Site Editing and many people still don't know what's this plus many are not using filter and just checking the first page 🤷‍♀️

[elmastudio]

Thank you so much @kafleg for this ticket.

Last week in the FSE hangout, we also discussed the issue of block themes not getting featured in the theme repository. As a result, users simply don't know that WordPress is introducing these new themes along with Full Site Editing features. I don't think this is beneficial for WordPress.

I want to add a third solution: We can add a similar second section on the theme page in the same fashion as on the plugin page with 'Block-Enabled Plugins'. So we could add 'Block Themes' or 'Full Site Editing-enabled Themes' above the regular theme list. This would add to a consistent experience between searching for plugins and themes, which make sense to me. What do you think?

If block themes are the future and are better and easier, they don't need any extra promotion.

I don't believe that statement to be true. Everything that is new needs to be introduced and given an introduction to users. This is a standard procedure for a new product or feature release.

Otherwise, we would also not add a Welcome page with each WordPress release to introduce the new features that ship with the release.

[kafleg]

Thank you all for adding your valuable suggestions and more ideas and suggestions are welcome.
There are a few things we need to apply at least from my idea.

• Make more resources to know what is block themes, FSE, and important over classic themes.
• We need more block-based themes in the theme repo. (Giving priority to the block themes will encourage theme authors to invest their time and resources in it.)
• Conduct meetup and WordCamps sessions more in FSE.

If we don't market the features, it will take a longer time to get matured.

I like the idea @elmastudio

[MatthiasReinholz]

Just yesterday, I was looking for FSE-oriented themes. In the past years, I never looked at the theme section of WordPress.org and I got really confused by its design.

As someone who uses the plugin section of WordPress.org very often, I was expecting a similar way to browse the themes. I can agree with the proposals above about adding better visibility for block based themes. Here are my additional ideas:

Better theme pages
The theme pages are not presenting any insightful information about the theme but only a small description text. This is a huge contrast to the plugin pages where the author can write an extensive readme and add screenshots.
When browsing the theme library, to me, there are two things that I want to know about a theme: 1) technical capabilities (what features does it support?) and 2) look and feel.
I can't find meaningful information about both on the current theme pages before installing and testing a theme.

Optimized feature filter
There is already a filter function on the theme library. But honestly, the filter options are super confusing to me. There is a list of filters with some super narrow things such as "Front Page Posting" (what is that even?) or "Sticky Post" and on the other hand some much bigger topics such as "Translation Ready" or "Accessibility Ready".
It was super hard to me to find the item "Full Site Editing". A quick solution could be to put all the block-related filters into a separate filter category. Alternatively, the FSE filter could be highlighted in bold and put to the top of the list.

P.S.: thanks to @elmastudio for bringing up this topic on Twitter

[tsiger]

I agree with @elmastudio

Also, I think it could be really useful to have a landing page like ​https://wordpress.org/gutenberg/ (at least as long as the site editor is in beta) where people could easily get information about the differences between FSE and classic themes.

[mikachan]

I want to add a third solution: We can add a similar second section on the theme page in the same fashion as on the plugin page with 'Block-Enabled Plugins'. So we could add 'Block Themes' or 'Full Site Editing-enabled Themes' above the regular theme list.

I think this is a great idea, @elmastudio. With this, we could maintain a consistent format and wording between the theme and plugin directories.

I also agree with @MatthiasReinholz's ideas, there are so many improvements we could make to the themes directory. Is it worth opening separate tickets for these?

[joyously]

Is it worth opening separate tickets for these?

The tickets already exist. Some are very old, but have gotten no attention. That's why it's frustrating for those of us that have pushed for improvements for classic themes. The glaring problems are only interesting to you because you want your pet project to shine.
I think that is an affront to all of the hard-working theme authors that will be overshadowed by "the shiny new thing". I'm all for fixing the problems, but the playing field should be level for all theme authors.

[onemaggie]

I think that the theme directory definitely needs a refresh, and that's been mentioned plenty, but this is pretty urgent. Block themes have a different UI exposed to the user and are built very differently, and they should be shown separately in a prominent way so that users know what they are installing, both in case they want to try them and if they want to avoid them too!

[dd32]

From a technical point of view, here's the three main options I see.

1. Redo the front page to be more like the plugin directory. This was asked for a long time ago, but was put off as to do it properly would require some deeper changes to the directory theme. Due to some changes since, this is probably easier to do now in a hacky way.
2. Add a new Tab browse/block-themes and set that as the default for w.org/themes, this wouldn't help WordPress installs though.
3. Some strange logic behind the scenes to preference Block Themes in all views/searches/etc, ie. Every archive of themes would show the matching Block Themes, followed by the Classic Themes.

Each of those comes with various tradeoffs, 3 is probably going to be awkward until there's a lot more themes present, 2 is simple but might not provide the intended effect, and 1 is probably the hardest out of all of them but will probably solve the needs here better than the others.

I've just verified that ​https://github.com/WordPress/theme-directory-env works (and updated it with the newer headers) if someone wants to try any of those out.

I've also added some development notes to the readme, see ​https://github.com/WordPress/theme-directory-env/blob/trunk/README.md#development for getting started.

The theme directory is well overdue to an overhaul, both technically and visually, which is why many changes just haven't been made IMHO. Changing the homepage (1 above) seems well overdue.

[joyously]

If you want to get technical about it, answer why are more than a few FSE themes needed when there is the Pattern directory and Style Variations and the block directory?
I thought the whole point of supplying blocks in HTML files was that the software could rearrange it into anything. Do we really need all the themes done again as FSE themes?

[poena]

#5465 was marked as a duplicate.

[poena]

#6060 was marked as a duplicate.

[ilovewpcom]

This goes against everything that was discussed about the role of themes in the past 10 years at least.

In the past there have been a lot of instances when a new tab with themes, a different algorithm, a different order, different X, Y, Z have been appropriate.

Every single time theme authors heard the same song: it is not the role of .org to promote or market any particular product. It is not the role of .org to make the themes repo look like the plugins repo.

The logical request of removing the default Twenty themes from the Popular tab fell on deaf years.

But now there's a new shiny toy (that is not even ready or wanted by the general public).
And suddenly people with a direct interest in having a spotlight on their themes are pushing this "new" idea.

This is a spit in the face of the hundreds (if not thousands) of theme authors that have been contributing to .org until now.

"Classic themes already have too much attention in the repo, let's take away some of it (or what's left of it)."

This is an ill-conceived idea that will have bad consequences.

[chzumbrunnen]

Many great ideas here. Besides the most obvious idea of having a 'Block' tab next to 'Latest', I especially like @elmastudio's take to "promote" block themes.

I don't think this would be unfair against "classic" themes. Of course, changes always will have winners and losers as every Google Search algorithm also shows.

My suggestion, as an enhancement of the already existing proposals, would be to add a "Block" label as an overlay to the screenshot image (or besides the name of the theme).

Then classic themes should have a label too, like "Classic" or more radical (and too early now): "Deprecated".

Yes, there is the feature filter but as of now the distinction between "Classic" and "Block" is much more important than any other label or feature as it's a differentiation between two versions/variants of WordPress (or two ways to work with WordPress).

P.S. I tried to do a mockup but it looked awful and I think you get it without an image ;-)

[ilovewpcom]

Replying to chzumbrunnen:

Of course, changes always will have winners and losers as every Google Search algorithm also shows.

There have been no changes in 10 years. We haven't even got a simple thing like new theme tags, which is "being worked on" for who knows how long. No tags, no search, no filters, no multiple screenshots, no readme files, absolutely nothing. The Twenty themes still in the Popular tab.

Now suddenly there's the desire to throw everything at FSE themes, which is not even a finished "feature".

I have to agree with @joyously, how do you go against this argument?
"If block themes are the future and are better and easier, they don't need any extra promotion."

The repo should not bend under any specific feature that is popular (allegedly) on that day. It should have an efficient search and a proper browsing/filtering experience.
If that would be addressed instead, then it would make all these discussions obsolete.

[uxl]

I don't like the idea of giving block themes "priority". Make block themes more discoverable sure but please don't fudge the popular algorithm in such a way.

Perhaps something like a separate "Trending" tab for all themes taking into account more variables than simply total installs over total days. I don't know exactly how this would work or if this is something that has already been mentioned previously.
If a brand new theme that is not bundled in WP by default has 300 downloads in its first full day, that could be said to be trending more than a theme with 100 downloads. Also if the less initially popular theme has a higher ratio of active installs to downloads then that too could be taken into account.
From what I understand all the data are already collected, its just a matter of working with it to produce something a little bit more meaningful.

Is there any reason why we can't optionally order by popularity when filtering?

The current list of tags/filters is woefully out of date, with most of the tags feeling irrelevant. The exception is 'full-site-editing' as it is so very distinct from say 'custom-logo' or 'sticky-post', so I would would be in favour of a "Block" tab as a first step to see how it goes.

[critterverse]

I agree with folks above that the Theme Directory definitely needs a refresh! Not sure what the timing might be but I can imagine it being one of the next steps in the ongoing ​WordPress.org redesign work to revisit this section (both on the website and in the CMS).

As an near-term solution, I love the idea of adding a new tab for Block themes (alongside Popular, Latest, etc) as suggested in the OP. This enhancement seems like it would add clarity to the current experience and help a lot with discoverability/awareness around there being different types of themes.

This PR adds a 'Block' tab to the Theme Directory filter list. This will filter the themes list using the full-site-editing feature tag. This works in the same way as using the Feature Filter to filter by 'Full Site Editing'.

These types of themes are more commonly referred to as block themes, so by adding this tag, we are reducing the confusion between these terms and making it clearer how to filter by block themes in the directory.

Please see this discussion for more details: https://meta.trac.wordpress.org/ticket/6330

[mikachan]

Thanks, @dd32, for the repository information. I know we haven't reached a consensus yet, but I've gone ahead and tried out adding a 'Block' tab next to Latest in the filter menu. I thought this would make it easier to see how we feel about adding it: ​https://github.com/WordPress/wordpress.org/pull/85

This certainly seems to be the easiest and quickest solution for now, and as mentioned above, hopefully the Themes Directory will see some bigger updates in the near future.

[ocean90]

#6400 was marked as a duplicate.

[jeffikus]

I looked into this today and created #6400, moving that conversation here.

A quick way to improve the visibility of Block Themes could be to add an item to the navbar which currently only has Commercial Themes in.

This would mean a visible Block Themes clickable link, instead of drilling down into the feature filter and then searching.

A few benefits of this approach;

1. Quick to implement.
2. It’s front and center on the page.
3. Will likely get indexed higher than the filter in Google.

Here is a visual representation of what I had in mind: ​https://cloudup.com/cmBebBo0Tex

[jeffikus]

Add link to navbar for Block Themes.

[jeffikus]

Alternative Add link to navbar for Block Themes.

[bgardner]

I support this 100% and feel as though it will not only make block themes more discoverable, it will entice theme developers to consider the move from classic.

[annezazu]

Moving my thoughts over from the prior issue too. I'd love to see this implemented as feedback has repeatedly come up in the FSE Outreach Program around how hard block themes are to discover. Most recently, this came up in a hallway hangout in June: ​https://make.wordpress.org/test/2022/06/02/hallway-hangout-discussion-on-full-site-editing-issues-prs-designs-1-june/ See the section under "Naming of bock themes and the theme directory".

Part of why I like this specific approach is that we can add context to the page itself, similar to what you can see for Commercial: ​https://wordpress.org/themes/commercial/ This provides a chance to introduce the concept of block themes and set some important context for those who might use them. To me, this strikes a good balance of "education and discoverability" that Rich mentions above. I would be more than happy to help with writing the content for that page too if that helps move this work forward :)

[ilovewpcom]

As an alternative, it is also a possibility to just get rid of classic themes, or at least shadowban them. That way FSE themes will be front and center.

[ndiego]

I completely agree with providing more visibility to block themes. I think the link suggestion by @jeffikus is pretty lightweight and a good first step.

[ThemeZee]

+1 for making block themes more visible and easier to discover in the theme repo!

[luminuu]

+1 on more visibility for block themes from me too. I'm currently leaning more towards @kafleg's suggestion, as it is - in my opinion - more visible than the suggestion by @jeffikus, although this is also a great idea. However I think it would be overlooked to easily, as you first focus on the first theme previews, then go up to the filter bar and then as third step, see the navbar.

[jeffikus]

Adding further context to why I opted for the area I did instead of the filter area (with Popular, etc), the filters are inside the main content container element, while the Commercial Themes link is inside a <nav> container element id="site-navigation" - so my suspicion is that's better for Google search, but I'd love it if someone with more expertise in that area could comment.

[elmastudio]

Thanks so much to everyone adding to the discussion here. I believe we are moving into the right direction and as @ndiego said even the smallest step is a good first step.

From @jeffikus mock-ups, I definitely prefer the left-aligned solution.

First it's more visible, the other one gets easy overlooked, as @luminuu mentioned before.

Second, placing it next to commercial themes could suggest that these two are related somehow, while they have nothing in common. Instead, in my opinion if we place something next to each other it should be classic vs. block themes.

One issue I see with @jeffikus approach is that this helps to distinguish block themes on the WordPress.org website, but it still does not differ them when searching for themes under Appearance / Themes inside the WordPress admin area. Wouldn't it be great, to solve these together?

[melchoyce]

Replying to luminuu:

+1 on more visibility for block themes from me too. I'm currently leaning more towards @kafleg's suggestion, as it is - in my opinion - more visible than the suggestion by @jeffikus, although this is also a great idea. However I think it would be overlooked to easily, as you first focus on the first theme previews, then go up to the filter bar and then as third step, see the navbar.

Agreed — it took me a while to locate the links in @jeffikus's mockups. 😅 I saw it pretty quickly in the filter bar. Additionally, it feels like a filter to the existing theme directory, not a separate page like the Commercial Themes page, which lists premium theme foundries (not themes themselves).

[dd32]

This PR adds a 'Block' tab to the Theme Directory filter list.

This PR seems the most straight forward way forward here, making the most impact today.

I however have one question - Is 'Block' the best title/word here? "Latest", "Popular", "Favorites" are descriptive terms that anyone would be able to understand.

Yes, we understand what Block means in this context, but will others? end users?

For plugins, we use Block-Enabled plugins, Block-Enabled makes less sense than just Block for a theme filter though in my opinion.

Perhaps this is the best way to title it, and I'm over thinking it, and realistically we need to name it like so to encourage others to figure out what we mean when we say Block.

[kafleg]

Experiential?

I'm not sure what can be the exact term. But, it's better we find the descriptive term.

[Anariel Design]

+1 for making block themes more visible. As much as I love @jeffikus idea I agree with the @luminuu. I think we need something a bit more visible. And if we go with this idea, agree with @elmastudio, the left positioning is much better than beside the Commercial Themes. Maybe, in that case, to make the Block Themes as a button. I'm also leaning more towards the @kafleg suggestion :)

[Anariel Design]

Replying to elmastudio:

One issue I see with @jeffikus approach is that this helps to distinguish block themes on the WordPress.org website, but it still does not differ them when searching for themes under Appearance / Themes inside the WordPress admin area. Wouldn't it be great, to solve these together?

Agree with Ellen, it would be great to solve it together as many are searching themes from Appearance/Themes and block themes are very hard to find at the moment.

[tsiger]

+1 for adding an item in the navbar for the block themes. Although I think it needs a way (another item) for people to easily go back to the classic themes section. Maybe something like that?

[ilovewpcom]

For 7 weeks straight people are just ignoring all the arguments brought by @joyously.

"If block themes are the future and are better and easier, they don't need any extra promotion."
Can anyone reasonably argue against this?

And another question: why would my non-FSE themes built for the Block Editor be relegated to the "classic themes" category? Why give priority specifically to FSE themes, all the while calling them "block" themes? My classic themes work perfectly well with blocks. Why create any more confusion under the false pretense of making things "easier and clearer"?

[Anariel Design]

Replying to tsiger:

+1 for adding an item in the navbar for the block themes. Although I think it needs a way (another item) for people to easily go back to the classic themes section. Maybe something like that?

I like this idea :)

[tsiger]

Replying to ilovewpcom:

For 7 weeks straight people are just ignoring all the arguments brought by @joyously.

"If block themes are the future and are better and easier, they don't need any extra promotion."
Can anyone reasonably argue against this?

And another question: why would my non-FSE themes built for the Block Editor be relegated to the "classic themes" category? Why give priority specifically to FSE themes, all the while calling them "block" themes? My classic themes work perfectly well with blocks. Why create any more confusion under the false pretense of making things "easier and clearer"?

As someone who also (still) makes a living from classic themes I think this should be communicated to the users. I don't think that "better and easier" is at play here. People will eventually decide on this, no matter how it is communicated but at least they should get a visual indicator that we are talking about something different.

[luminuu]

Replying to ilovewpcom:

For 7 weeks straight people are just ignoring all the arguments brought by @joyously.

"If block themes are the future and are better and easier, they don't need any extra promotion."
Can anyone reasonably argue against this?

And another question: why would my non-FSE themes built for the Block Editor be relegated to the "classic themes" category? Why give priority specifically to FSE themes, all the while calling them "block" themes? My classic themes work perfectly well with blocks. Why create any more confusion under the false pretense of making things "easier and clearer"?

I disagree with this. Block themes are:

• Fundamentally different.
• Have their own editing experience, which classic themes don't have. They may or may not have some extra settings, but no direct editing experience.
• Are currently opt-in only. You only get to work with a block theme if you actively decide to do so.
• They may not be considered "easier", because you need to learn about how to use them, as I mentioned in my first point, they're fundamentally different.
• Classic themes that are optimized for the block editor are great too, but they don't enable the user the full potential of Full Site Editing. They're the first step in this new direction, so they're great too.
• However, when people are not able to distinguish what a classic theme and a block theme is, when it's all in the same spot and can just be filtered through a form that is initially hidden, how are they going to learn about this? This topic is about making it easier for people to explore the themes and get a better idea of what is currently possible with block themes.

Overall, it will be a long process for every user to learn and adapt the new way of working with block themes, and enhancing the visibility on the theme directory is one small step towards this goal.

[ilovewpcom]

Replying to luminuu:

Which is why the whole directory needs to be improved. It's not right (or fair) to prioritize one type of themes, when many of them aren't even production-ready.
Funneling all WordPress users towards an unfinished and clunky product won't do anyone any good. WordPress is not known for its elegant UI, and this will make things worse. WordPress users are not guinea pigs to force Gutenberg and FSE on them at every step. Let this process take its natural course.

Address the whole issue instead: improve the directory, better theme tags and search, implement the things that we have been waiting for 10+ years.
Multiple screenshots, descriptions with markup, better readmes, links to documentation and maybe even custom demos.
With all these in place, both classic and FSE themes will have all the necessary tools to attract their target audience.

If this many Automattic employees (with 0 themes in the repo) are so worried about the state of the themes repo, then maybe a few resources could be allocated to improving the whole system.

Don't take the food from one starving person to feed another.

[luehrsen]

I think we need to be clear about what we're talking about when we use the term "blocks." For plugins, "blocks" are the appropriate choice because that's what they offer. However, when we're talking about Full Site Editing (FSE), we should use a different term and name it as such.

I would suggest introducing the concept of Full Site Editing to the discovery of themes. This would make it clear that we're talking about a different product with a different target audience in comparison to "classic" themes.

Also: Calling one type of theme "classic" implies that it is old and deprecated, which is not the case. I think a more neutral term, such as "hybrid," would be more accurate and fitting.

[kafleg]

Regarding the name of the Block theme and Classic theme, we discussed in the themes team meeting and agreed to use that term. Here is the meeting note. ​https://make.wordpress.org/themes/2021/12/15/themes-team-meeting-notes-december-14-2021/

[luehrsen]

Replying to kafleg:

Regarding the name of the Block theme and Classic theme, we discussed in the themes team meeting and agreed to use that term. Here is the meeting note. ​https://make.wordpress.org/themes/2021/12/15/themes-team-meeting-notes-december-14-2021/

Okay, that made me raise my brow a bit. That discussion was held with 8 (eight!) people in agreement on the same day as SotW, on the open floor (meaning not on the agenda), in SIX minutes.

Is that considered official?

[luminuu]

Replying to ilovewpcom:

Replying to luminuu:

Which is why the whole directory needs to be improved.

Well I agree on this.

It's not right (or fair) to prioritize one type of themes,

Have you ever looked at the plugin repository either on w.org or from a WordPress installation and ever wondered why plugins from Automattic are displayed under "Featured" or as very first results? Or why the default themes are on popular results too? Apart from the fact that this is a whole different thing to discuss, it's not about changing the priority, this topic is about enhancing the discoverability of block themes. Just because it was mentioned earlier, it feels like the majority of people is agreeing that it should be a separate filter setting instead of a change in the algorithm.

when many of them aren't even production-ready.

I think I know what you're ranting about here, but that's another topic for discussion.

Funneling all WordPress users towards an unfinished and clunky product won't do anyone any good. WordPress is not known for its elegant UI, and this will make things worse. WordPress users are not guinea pigs to force Gutenberg and FSE on them at every step. Let this process take its natural course.

It is okay to criticise the product and have a negative opinion on it, but it doesn't really helping this topic and this discussion here.

Address the whole issue instead: improve the directory, better theme tags and search, implement the things that we have been waiting for 10+ years.
Multiple screenshots, descriptions with markup, better readmes, links to documentation and maybe even custom demos.
With all these in place, both classic and FSE themes will have all the necessary tools to attract their target audience.

How about searching the Trac if there's already a ticket on this somewhere, or opening a new one with this topic to further discuss?

If this many Automattic employees (with 0 themes in the repo) are so worried about the state of the themes repo, then maybe a few resources could be allocated to improving the whole system.

Don't take the food from one starving person to feed another.

Again, another topic to discuss but not on this ticket.

This will be my last reply for this discussion, let's get back to the original topic of this.

[ilovewpcom]

Replying to luminuu:

I think I know what you're ranting about here, but that's another topic for discussion.

I'm glad that you see my opinions and arguments as "ranting" (​https://www.dictionary.com/browse/rant).

If someone disagrees, then it's "another topic for discussion". After disagreeing voices are excluded or ignored, a decision will be gloriously made with "unanimous agreement".

This will be my last reply for this discussion, let's get back to the original topic of this.

I never left the original topic, whether you see it like that or not.

[Anydog]

+1 for promoting Block or FSE themes. This might help for better adoption from users, and encourage developers and designers to engage more with what will stay here for the future.
There is a "Full site editing" filter, though, but the separate link would be better IMO. Perhaps adding a link "Legacy themes" (or "Classic themes") next to "Block themes" would be something to consider, too?

[bph]

Call me naive: I don't see how a link to the /tag/full-site-editing page harms classic themes.

If an user knows what a block theme is they are there to search for it, and the link gives those users a faster path to find them.

If a user doesn't know what block themes are they won't click on it and search the Themes directory as they do before, probably clicking on "Popular" to leverage social proof one way or other.

I can see that the label "Block Themes" for an outsider might mean "can handle blocks" in a more general term. I don't have a good suggestion as an alternative label, apart from "Site Editor Themes" Or "Themes with Site Editor".

The ticket's title is definitely misleading, using the word 'priority' as that doesn't seem to be actually the intention of this Link request. I would call it visibility.

[poena]

Replying to luehrsen:

Replying to kafleg:

Regarding the name of the Block theme and Classic theme, we discussed in the themes team meeting and agreed to use that term. Here is the meeting note. ​https://make.wordpress.org/themes/2021/12/15/themes-team-meeting-notes-december-14-2021/

Okay, that made me raise my brow a bit. That discussion was held with 8 (eight!) people in agreement on the same day as SotW, on the open floor (meaning not on the agenda), in SIX minutes.

Is that considered official?

The team meetings are never held to exclude anyone.

What does "official" mean? Do the attendees of that meeting speak for the entire WordPress project and make decisions for the project? Of course not.
Does it mean that descriptions can never change? Of course not.
The team needed to choose which terms to use so that we could try to reach an understanding of what we were talking about when we say "block theme" and "full site editing".

The only guidance I have seen from a lead regarding naming is to not use "block-based".

[luehrsen]

Just to reiterate and clarify my point: I absolutely believe that Full Site Editing Themes should get more attention and should be easier to find.

One worry of mine is how we do that without downgrading the rest of the themes (so the remaining 98% in the repo) or without creating an Osborne Effect. (see ​https://en.wikipedia.org/wiki/Osborne_effect)

So while I'm in favor of the intent of the ticket, I'm struggling with the wording.

[jeffikus]

Hi everyone,

I'd like to encourage us to form some kind of consensus on a solution, while at the same time reinforcing that we can iterate on this later - I don't think we're going to arrive at a perfect solution for this on our first attempt :)

It's important to highlight that block themes can only get better with improved exposure by usage, which seems to be what most folks in here agree on. The solutions in this ticket don't seek to demote classic themes, but rather they seek to improve the discoverability of Block Themes instead of the current filter approach.

If there are issues with decisions around the project regarding themes, that should be a separate discussion in my opinion. I don't think a trac ticket is the best place for that, perhaps bring this up in Slack core meetings.

[eidolonnight]

I'd like to chime in as a contributor to the ​Marketing team. Having a separate page for block themes, as proposed via the tab solution, would be extremely beneficial for us when writing content for News, social posts, newsletters, etc.

Being able to speak about the new features available via block themes, and then sending readers/followers directly to the block themes, is a way better experience for all of our readers/followers IMO.

[rfletcher73]

Hi there. A few of my own thought on this subject.

1. I agree "Block" might be too generic of a term. Do you think the average user who comes to download a theme will know what is meant by that term? Perhaps the name "Block" and a little tooltip next to it to explain what it is for average users.

2. I agree a filter for "Block" (for lack of a better term), "Full Site Editing", and "Classic Themes" should all have a place as a link or as a filter by these 3 different types of themes.

3. I would really make sure the "Block" themes and "Full Site Editing" themes are really ready for production before we start shining a spotlight on them.

4. @poena "Does it mean that descriptions can never change? Of course not." -- you must admit that the response given to @kafleg from @luehrsen did seem dismissive. It seemed like there was an event where 8 people decided the term and since they decided it back then, it can't be changed. If that is not the case, then let's talk about the "Classic" term and its negative implications. The use of that term does imply "old" especially when we talk about technology. (Now in some cases, like "New Coke" vs "Classic" -- the Classic was way better!) Most of the time, "old" is not considered better.

Anyway, thank you for letting me join this conversation.

[poena]

Note that the original proposal does not include a suggestion to change the other labels in the theme directory to "classic".
I believe we are still discussing adding a single link to a single page here.

Classic is used across the official documentation because the documentation, marketing, training, editor and core contributors needed a way to separate and describe the new and old features.
Considering the larger context, please understand that the themes team discussion had very little bearing but adds some context.

Personally I think it is too late to change a term that is already established.
If anyone wants to create a proposal please do that, nothing is preventing that. I can even review the document before you publish it if that helps. Please use the proper channels for it.

[luehrsen]

Replying to poena:

Note that the original proposal does not include a suggestion to change the other labels in the theme directory to "classic".
I believe we are still discussing adding a single link to a single page here.

I tend to disagree. Some of the designs shown above include the first broad mention of that term. That term (or the avoidance thereof) is clearly within the scope of the proposed designs and therefore this ticket.

Additionally: While that might be reaching, adding a dissenting voice towards a possible first, broad, public usage of a term cannot and should be out of scope. It's a simple act of taking the worries of community members seriously... or not.

[melchoyce]

For the label, I agree with @mikachan et. al that "Full Site Editing," linking to ​https://wordpress.org/themes/tags/full-site-editing/, makes the most sense.

@dd32 Are you able to shepherd this forward?

[rfletcher73]

@melchoyce I agree with that label. It is clearer what exactly those themes will do and is the premier feature / benefit of using Gutenberg.

@luehrsen @poena I tend to agree with @luehrsen here.

I think that if the plan is to add a filter special for "Full Site Editing", then there should also be a link to filter by "Classic". I think it would be helpful to see just FSE themes but equally as helpful to see "Classic" themes without seeing FSE. I think adding the two filters should be up for consideration as well.

This might go against what you are trying to do (shine a light on Full Site Editing themes) to increase there exposure and discoverability. It will help perhaps to get them some much additional attention. I would only make this change if those themes are Production ready.

If they aren't, then I wouldn't shine the light yet. Thank you.

[poena]

Please stop insinuating that people do not listen to the community and do not care just because they do not immediately agree with your opinions.
Again that is offensive.

[dd32]

In 11963:

Theme Directory: Add the 'Full Site Editing' Tag to the theme filter bar.

Props dd32, mikachan, Anariel Design, annezazu, Anydog, bgardner, bph, chzumbrunnen, critterverse, eidolonnight, elmastudio, ilovewpcom, jeffikus, joyously, kafleg, luehrsen, luminuu, MatthiasReinhol, melchoyce, ndiego, onemaggie, poena, rfletcher73, richtabor, ThemeZee, tsiger, uxl.
Closes ​https://github.com/WordPress/wordpress.org/pull/85.
See #6330.

[luehrsen]

Thank you for tackling this, @dd32!

I just tested the change, it does not seem to work for me.

Clicking the link sends me to https://wordpress.org/themes/browse/undefined/

Chrome 103 on Mac OS 12.4
Safari 15.5 on Mac OS 12.4
Firefox 101 on Mac OS 12.4

On the other hand, accessing the linked URL https://wordpress.org/themes/tags/full-site-editing/ directly via the browser url bar works as intended. I guess there are JS shenanigans intercepting the click action.

Edit: Yes, disabling JavaScript makes it work as intended.

Edit2: As of 12:38 GMT the link seems to work when testing in the most common Windows configs (Chrome, Edge) in Browserstack. On mac I cannot reproduce that behavior consistently. Maybe its a propagation issue or something. Maybe it fixes itself with time.

[mikachan]

Thanks for the update, @dd32!

@luehrsen, you may just need to refresh your browser cache.

[melchoyce]

Thanks @dd32!

BTW — I'm also seeing "undefined" across multiple browsers right now, even when clearing cache.

[jeffikus]

@melchoyce are you seeing this in Chrome, I can replicate this in Safari, but Chrome either a cache clear or incognito mode clears it for me.

[melchoyce]

Replying to jeffikus:

@melchoyce are you seeing this in Chrome, I can replicate this in Safari, but Chrome either a cache clear or incognito mode clears it for me.

I'm seeing in Chrome and Firefox, but Safari seems to be working for me. Maybe we can follow up with a cache bust commit?

[jeffikus]

@dd32 could you assist with this?

[apeatling]

There is a PR here for cache busting, but someone with access will need to merge it: ​https://github.com/WordPress/wordpress.org/pull/87

[adamwood]

Cache busting deployed https://meta.trac.wordpress.org/changeset/11965