Enabling Gutenberg in WP categories

[FerrielMelarpis]

Related thread: https://wordpress.org/support/topic/gutenberg-category-editor/

Not sure if this is possible now but I haven't seen any documentation regarding this.

Is WP category going to be supported by Gutenberg as well?

Right now, for our use case, we depend on ACF to contain the data needed for representing the structure for our category pages. It would be nice to have a way to represent the category data as blocks as well.

[TenentePM]

Same here, I'd like to edit category-descriptions with Gutenberg.

[Flaschenzug]

I'd like that too! Wordpress has taken a big step with Gutenberg. But this step is only meaningful if it is also consistent. Why shouldn't the categories be handled in the same way as posts and pages?

[mtias]

This would be a cool idea

[danyork]

Just noting that several of us left comments expressing our support for this task over in the now-closed #12511 .

For my employer's main site, we use category archives pages extensively in the navigation and main design. They are currently built them out using ACF with rows of text, images, etc. above the posts for the category (or tag). We've been doing more and more with the block editor across our site and building some excellent pages. We really want to now use some of the Gutenberg blocks and techniques on the Category pages as well (and also Tag archive pages - but our priority is on the Category pages).

Unfortunately, I don't have the programming expertise to help with the work, but I would be glad to help with whatever testing is needed!

[Jeff1Jeff]

We use Woocommerce category pages as a main landing pages in our store. This structure is pretty common for many stores. And abundance of Gutenberg editor on category pages really restricts further development of our site, I think category and taxonomy pages should be treated as posts and pages and have similar functionality to them.

Also when I want to add a link Gutenberg isn't showing Woocomerce category pages as available option.

[paaljoachim]

This post, by @gziolo mentions new filters/hooks that seems to make easier to blockify the WP categories page. (Recreate it with Gutenberg.) https://make.wordpress.org/core/2021/06/16/block-editor-api-changes-to-support-multiple-admin-screens-in-wp-5-8/

@critterverse @javierarce
Perhaps this would be an interesting screen to design.

[gziolo]

@paaljoachim, as explained in my response to your comment on a linked post, it's a more complex process to enable the block editor on a new screen that using a few API methods described in the dev note. The widgets screen might be a good way to think about it. It took a lot of effort to get the block paradigm integrated there.

[paaljoachim]

Thank you Greg!

[skorasaurus]

With the increased focus and transition to full site editing; this shouldn't be forgotten :)

#37746 has a clear use case that reminds me some retail/woocommerce shops use categories extensively.

[gingerling]

Hi, now that there are templates for category and product category pages coming out, this issue becomes more important I think.

In my view there is no "full site editing" without this vital feature.

I can totally see people doing hacky things like making a separate template for each category page, for example.

How to we get this issue on the roadmap? I have no idea of the scale of this task. Could we team up and try and fund some development on this? Seems like a fair few WooCommerce stores on here!

[only-sadeghi]

is there a way to do it?🥺😐

[gingerling]

is there a way to do it?pleading_faceneutral_face

Hi, this https://en-gb.wordpress.org/plugins/visual-term-description-editor/ gives a basic editor, but not a block editor. Perhaps this in combination with the new theme editor for category archives will allow a better experience while this issue is worked on

Please, if you have other suggested plugins add them while it's not a support forum I think it's helpful for us to assess the need and current capabilities

[sangtlee]

We would also love to see block editing enabled on term edit screens. It's not uncommon to need block editing features on entities that need to function as taxonomy terms. This is our current workaround to accomplish this:

• Custom post type called "Industry" with rewrite set to false << all of the "block" content is managed on these posts
• Custom taxonomy called "Industries" with slug of "industries" << used for usual taxonomy tagging, querying, etc
  -- Taxonomy has a ACF post object field ("parent_post") that lets editors associate this term with a specific "industry" post
• Content items across the site can then be tagged with an Industries term, but when the term archive page is requested, we grab the Block content from the associated page and inject that into the archive page template above the normal loop output << this task is rather trivial with Timber/Twig:

{% set parent_post = Post(post.parent_post) %}
  {{ parent_post.content }}

• Some additional rewrites and customs are needed to ensure users don't end up on the CPT post, breadcrumbs, etc.

It's not elegant but it works...new editors get confused between the "Industry" CPT and the "Industries" taxonomy...and often they forget about that all-important "parent_post" field on the term.

[jwflory]

Another +1 for this feature… the use case I had was to add a Jetpack newsletter subscription widget at the top of a category. Personalizing the category page is an important part of how we use WordPress.

CC: @vansika

[MrVibe]

How can WordPress be upgraded to FSE without supporting this feature ?

[klockfeber]

This would be very useful for our category pages as well, see an example of how the content looks now when it is only text here. I am surprised that WordPress 6.0 was released without Gutenberg on categories.

[Jabe64]

+1 I created an issue about it 4 years ago:
#12511

The issue was closed because Gutenberg was still in early stage. Full Site Editing improves but still no news about this.

Every update I hope to see something then my hopes varnish 😢

@mtias Is it still considered or will categories description be abandoned and should we use FSE template per category instead? 🤔

[djcowan]

This is an interesting thread. I have always assumed the non inclusion of advanced term features was due to the original implementation of the taxonomy system. Given Wordpress' evolution: Posts, Tags => non heirachical, transient to the addition of Pages, Categories = Heirachical, static; it makes sense -to me- that a universal one-size-fits-all approach would entail an extensive rewrite of a lot of core functionality.
One of the greatest appeals of the Wordpress system has always been Wp's adherance to compatibility, usability and accessability. Where a number of -other- systems continue to add features regarless of bloat, backward compatibility or viable upgrade path, the Wordpress team and contributors consider every user of the ecosystem at every stage of the development cycle.
So, yes; additional taxonomy and term features would be nice for some -me included- but they are not essential to the core functionality of Wordpress. As Wordpress evolves, perhaps these enhancements can be made; perhaps not.
There are serveral alternatives.

1. See this as an opportunity to build a plugin to enhance the system.
2. Join the contribution team and assist in developing Wordpress
3. Adjust your approach to working with the system as it currently is.
4. Hire a development team to build the functionality you can't live without.
   Thank you for listening: Please like and subscribe to my soapbox for more uniformative and unwanted opionated comments.

[jak-kal]

Any movement on this? Was about to finally take the plunge with Gutenberg but this is a serious drawback! I really don't want to use Gutenberg on pages and ACF repeaters on WooCommerce categories.

The only feasible way around this that I can see is to create a corresponding page for each landing category but that's going to really confuse other users.

[jonathan-dejong]

I've been thinking about this. I agree with the general consensus that this would be very powerful for many use cases. Especially for stores that use shop categories as landing pages which is extremely common.

Even with FSE in the state it is today it has one huge drawback, there is no context.
I can create a Block Template part to show on location N on each term archive, but the content within does not adjust to the specific term that is being displayed.

As to the claim that this requires a whole lot of rewrite I'm not so sure it does?
The wp_terms table currently has term_id, name, slug and term_group.
What if we were to add a term_content column which would act the same way post_content does for posts?
sidenote: Lets please not stick this into termmeta, making it utterly inefficient

We could add a new parameter to register_taxonomy() to opt in on the block editor , something like enable_block_editor OR maybe even consider some more consolidation with how we register CPTs and future proofing by adding a supports parameter which can take several future parameters.
Sidenote: I wish CPT registration had block_editor as a parameter here as well, but that's a different topic.

So it would be fully backwards compatible. Very unlikely to clash with any existing plugins.
Custom registered fields can be treated the same way they are on block post types, as "meta" added to the bottom of the page.
Core fields like "name" and "slug" becomes the title and permalink same way as with posts.
"Description" becomes a paragraph block (if one exists).

I'm sure this'll be met by some as "make it a plugin" and sure I don't disagree with that.. But then make it part of the core feature plugin https://wordpress.org/plugins/gutenberg/

That's my 🪙 🪙

[aurooba]

Just popping in here to add my support for this (literally because I'm about to dive into a project that would be simplified if this was already a thing) and I like the approach suggested by @jonathan-dejong. :)

[goaround]

I think a good place would be the https://github.com/Automattic/blocks-everywhere Plugin. I've created a request some time ago: Automattic/blocks-everywhere#20 but no progress for now.

[eric-michel]

I've run up against this issue several times as well. It seems like extending Gutenberg support to term descriptions would be integral to the Full Site Editing project. But with the recent announcement that phase 3 is the next big focus going forward, that implies that Full Site Editing improvements are going on the back burner. I'm worried term descriptions will just get left behind, especially given how old this issue is.

[michael-sumner]

I too am also expressing support for the Gutenberg within taxonomy 👋

We have a set of taxonomy templates which must contain particular blocks for each taxonomy.

However, as it is not baked into WP Core, we are attempting to make use of other methods to create the templates for the taxonomy.

Furthermore, we are specifying the template in the back-end, so that we can make use of "available templates" to work from.

This stops the use of "hard-coded slugs" in the WP template hierarchy.

Of course, we can cache the request made to specify the template.

[alex-t445]

Hello, from the perspective of a user on this subject:

I resisted Gutenberg for years, something that I regretted later. Today Classic Editor seems so clunky and out-of-date. To me, having to use it, it's like telling an adult to get on a tricycle again.

I switched my site to an FSE theme a few days ago. I really had to twist the arm of the young man who does coding for me to learn FSE. He is slowly getting it. Over and over, I beseeched him to embrace new technology. Lecture after lecture.

But then right in the middle of all this talk about blockifying everything: BANG! I run into the fact that the Term Description block can only be edited with Classic. It is so bizarre. Why? Why? I keep asking.

Our site uses categories and terms as landing pages. There is so much we want to do with terms and categories, but having to use Classic is like trying to work with one hand tied behind your back.

I can't emphasize how ridiculous this makes the Wordpress FSE infrastructure look. Please give us Gutenberg and free us from this albatross from the days gone by.

[michaelbourne]

I think the system described by @jonathan-dejong makes perfect sense. Huge vote of approval here.

[AntoinePBorg]

Ooh - +1 - me too! me too!

I'm surprised this hasn't been done already given there are so many people who want it (and have wanted it for so long)!

[MathieuMarteau]

I also don't understand why this feature is still not present. So many people use taxonomies and categories... It's frustrating not to be able to use our modular blocks on this kind of page. Please do something about it...

[djcowan]

I'd rather the community remained focused on refactoring Wordpress' core functionality. Oh, and the incredible work they're doing with accessibility.

[jonathan-dejong]

I'd rather the community remained focused on refactoring Wordpress' core functionality. Oh, and the incredible work they're doing with accessibility.

I don't understand this comment. The community can do more than one thing at once.
Also wouldn't this very much be qualified as "refactoring WordPress core functionality" anyway 🤔

[paaljoachim]

The thing is that anyone can spend a bit of time adding wireframes/mockup with suggestions as to how this might look like. That will create some motion. It will naturally need a bit forth and back in regards to design. After a design has been decided upon then a developer can go ahead and create a PR (Pull Request) and so the coding exploration begins. Core designers and developers will need to also give feedback along the way.

[djcowan]

Yes, I agree, the community, contributors, and core team can work together on multiple facets of the system.
But when I referred to 'core' functionality, I was thinking more in term of the Wordpress' core DNA rather than the core application code.
Sure, there are many volunteer contributors and there can always be room for more but the project needs to be planned, coordinated, managed and rigorously tested as well. This obviously includes the code, which is a minefield in itself but also requires input and advice from the teams who work on accessibility, design, user experience, marketing, translation and more besides.
I've personally not contributed so I am not one to complain but @paaljoachim is correct, there are lots of ways for each of us to become involved. I apologise if my comment caused undue offence. It was not intended as such.

[sangtlee]

IMHO, taxonomy terms should retain all existing functionality...i.e. name, slug, parent terms, description, tag_id, archives...and layer in the new aspects: block editor, templates, draft/published states, featured image, and author. A quick mockup of the merged UI might look like the attached.

[jonathan-dejong]

@djcowan Not at all, I just didn't understand the statement and it didn't really feel like it contributed to the discussion.
I'm sorry you felt the need to apologise :)

@sangtlee I like that rough mockup. It makes sense to actually put those fixed fields currently on the term edit screen as fixed fields in the sidebar.

AFAIK the things to cover would be:

• slug
• Parent
• Description

Slug would be auto-populated by title same as current behaviour.

I still think it would be nicer to not have description as a fixed field but I recognise that its probably a must to maintain decent backwards compatibility.

[legshooter]

Same as many others mentioned, old-time WP'er here that was a way for a while, and kinda astonished that in 2024 Taxonomies are still not treated like posts/pages by the entire ecosystem. Slugs, revisions, SEO plugins, etc. etc. are all needed and missing, and we're left hacking away with ACF.

[samunderwood]

I've noticed a trend where many websites use WordPress's taxonomy system for organising content in the backend, but don't utilise taxonomy term pages on the frontend due to its limited flexibility for content.

They're instead using pages, which are then supplemented with custom blocks to display the post list, alongside all the other custom blocks they want to be able to use on term pages.

I'm still surprised how long Gutenberg has been out and we still are relying on hacky workarounds to use its functionality on something as prevalent on websites as category pages

[gregdotelphotography]

This is a must have for Wordpress. I have 5 websites and all of them need this feature. I have to use hacks for it to work properly.

[asafm7]

I recently posted a message about it in the core-editor WordPress Slack channel:

https://wordpress.slack.com/archives/C02QB2JS7/p1714163585750229

Feel free to chime in.

[jonathan-dejong]

I recently posted a message about it in the core-editor WordPress Slack channel:

https://wordpress.slack.com/archives/C02QB2JS7/p1714163585750229

Feel free to chime in.

Hah okay .. ill buy that the issue title could be clearer but when it was created there wasn't a proposal, just a grievance to discuss.
The thing is.. my experience is that when I create a new issue to address something that already exists, the issue gets closed immediately referencing that "there is already an issue for this".

So I'm curious what the process looks like here.

I wouldn't mind taking the time to create a new structured issue with a clear title provided that the approach I've had in mind is sound. But I would like to know:

1. Is it sound? From someone actually part of the Gutenberg team.
2. Will it not just be closed as a duplicate? What is the defined process (if any)?

I'm not intentionally trying to come off as a bit sour here, but Ive experienced too many times that my efforts to contribute to this OS projects haven't made the slightest change due to the gatekeepers disinterest.

For reference here's my proposal (and then there's som discussions around it later in the comments)
#17099 (comment)

[colorful-tones]

I recently posted a message about it in the core-editor WordPress Slack channel:
https://wordpress.slack.com/archives/C02QB2JS7/p1714163585750229
Feel free to chime in.

That was me suggesting in Slack 👋

the issue title could be clearer but when it was created there wasn't a proposal, just a grievance to discuss.

I feel like #37746 does a far better job explaining (with screenshots) what the issue is and the suggested solution. I have the ability to edit this Issue's (17099) description and title, but I feel like it could be misleading for the original creator: @FerrielMelarpis. This was why I suggested we think about creating a new issue with a reference to this issue (17099), and then close it.

For what its worth - I think this overall functionality will eventually be explored in the Phase 3: WordPress admin redesign #53322. 👈 I highly recommend folks review the videos and overall conversation and contribute your feedback on #53322. Here are some screenshots (please see below) of areas that could possibly be explored for the category screen (please do not read this and assume it is fact - it is currently being discussed and you should feel empowered to contribute your thoughts) based on @SaxonF original video artifacts in #53322

There may even be more recent work that is moving closer to the category redesign, but I just could not find it when searching through the many issues. 😄