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

https://github.com/WordPress/gutenberg/issues/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: https://github.com/WordPress/gutenberg/issues/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 blockeditor 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: https://github.com/Automattic/blocks-everywhere/issues/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) https://github.com/WordPress/gutenberg/issues/17099#issuecomment-1515854204

[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. 😄

[asafm7]

@colorful-tones, I went over the issue you mentioned, but, unless I'm missing something, it doesn't seem to be closely related to the issue of enabling the Block Editor for archive page descriptions. The issue you referred to also feels like an extensive project, making it unlikely to progress significantly soon.

Do you think there is another way to raise and promote the issue presented in this thread?

[djcowan]

Might it suffice to add block support to the category description editor. Similar to the support/issue reporting field in the Wordpress codex. Perhaps implemented in a similar way to the Freeform core/ block?

As a postscript. Adding a Category image programmatically has always required a conditional check or adapter for woocommerce, third-party brand plugins etc. it would be nice to standardise the term post meta

[goaround]

I submitted a PR https://github.com/Automattic/blocks-everywhere/pull/178 to Blocks Everywhere to enable Gutenberg for the term description. It works quite well with the help of @1ucay. Feel free to give it a try. As far as I know, Blocks Everywhere is used in bbPress as well.

The only issue is that Blocks Everywhere requires the Gutenberg Plugin. That holds me back from using it in production.

[asafm7]

@djcowan @goaround it looks like a good direction.

The Blocks Everywhere plugin has only about 30 active installs though, and hasn't been updated for 10 months. Adding the fact that as @goaround mentioned it requires the Gutenberg plugin which is beta by definition, it doesn't feel like a good solution for production.

Maybe a similar solution can be brought to core as a temporary solution until the admin side gets refactored (which I assume can take a long while).

[kraftner]

Maybe a similar solution can be brought to core as a temporary solution until the admin side gets refactored (which I assume can take a long while).

While I am also desperately waiting for this I have to strongly disagree here. Due to the backwards compatibility commitment of WP nothing ever is temporary. If it takes time that sucks but is still better than getting a half-baked stopgap solution that will only cause much more pain in the long term.

Just as an idea: If you really need something like this a competent developer could probably create a stop-gap solution that e.g. creates a post type that shadows a taxonomy and keeps them in sync. Honestly though if anyone has the time or money to fund that it would probably be better spent in working on the core admin overhaul.

[asafm7]

@kraftner that's interesting.

I understand what you are saying, but I'm not sure it applies here.

I feel like moving away from the current admin to the new editor experience is something that is bound to happen, so a temporary fix won't prevent it from happening. It will take time though. I'm not familiar with the process, but my gut feeling is that it can take years (again, just a gut feeling).

If you really need something like this a competent developer could probably create a stop-gap solution that e.g. creates a post type that shadows a taxonomy and keeps them in sync.

Yes, something like this can be created, but such a workaround also needs to be maintained and is prone to breaking.

Considering that moving away from the current admin will eventually happen, that it will take time though, that many people need this change in the meantime, and that a decent fix has already been found and implemented (just not in a stable way), I don't see a true downside in bringing this change to core.

It can be disabled by default and enabled with a filter or a similar method.

But maybe I'm missing something.

[kauaicreative]

On a recent build I needed this functionality. My solution was to create a block that displays related page data in the archive template - I place this block into the archive template. The block checks if a page existed with the same permalink as the archive e.g. services/planning. If there is a match then I insert that page content into the block. This was a nice solution because the client only needs to edit the related page and I can continue to use the term description in the archive template as it was intended. You can see it in action here https://destinationbydesign.com/services/

This could just as easily be done with a simple shortcode:

// Place [page-content] anywhere in the archive template
// And make sure that there is a page with the exact same permalink e.g. services/planning

add_shortcode( 'page-content', function ( $atts, $content = '' ) {
  global $wp;

  if ( is_tax() ) {
      $taxonomy_slug = add_query_arg( [], $wp->request ); // e.g. 'services/recreation-master-planning'
      $page          = get_page_by_path( $taxonomy_slug );
      if ( isset( $page->post_status ) && $page->post_status === 'publish' ) {
          $content = do_blocks( $page->post_content );
      }
  }

  return $content;
} );

[WesCook]

I came up with a similar solution, @kauaicreative. Instead of modifying a template, I wrote a function to serve a regular page instead of a category page if it matches the same path. Specifically it looks for matching slugs under a child page /category-replacements/ to keep things organized. That page can be hidden or redirected to avoid duplicate content issues.

// Replace any category pages with a regular page of the same slug found under the /category-replacements/ parent
add_action('template_redirect', function() {
    // Do nothing in wp-admin
    if (is_admin()) {
        return $query_vars;
    }

    if (is_product_category()) {
        // Get the current category object
        $current_category = get_queried_object();

        // Get the full URL of the category
        $category_url = get_term_link($current_category);

        // Parse the URL to get the path
        $parsed_url = parse_url($category_url, PHP_URL_PATH);

        // Remove leading and trailing slashes, then replace slashes with hyphens
        $category_path = trim($parsed_url, '/');
        $page_slug = str_replace('/', '-', $category_path);

        // Check if the parent page exists
        $parent_page = get_page_by_path('category-replacements');

        if ($parent_page) {
            // Get the ID of the parent page
            $parent_id = $parent_page->ID;

            // Query for a child page with the constructed slug under the parent page
            $args = array(
                'name'        => $page_slug,
                'post_type'   => 'page',
                'post_parent' => $parent_id,
                'numberposts' => 1
            );
            $child_pages = get_posts($args);

            if (!empty($child_pages)) {
                // Redirect to the child page template
                global $wp_query;
                $wp_query->is_page = true;
                $wp_query->is_single = false;
                $wp_query->is_category = false;
                $wp_query->queried_object_id = $child_pages[0]->ID;
                $wp_query->post = $child_pages[0];
                $wp_query->post_count = 1;
                $wp_query->posts = array($child_pages[0]);

                // Set up the post data
                setup_postdata($child_pages[0]);

                // Use the child page template
                include(get_page_template($child_pages[0]->ID));
                exit;
            }
        }
    }
});

For example, if you wanted to replace the Services > Accounting subcategory (/services/accounting/), then you'd create a regular page at the path /category-replacements/services-accounting/. The top-level page is always required, and hyphens are used to separate children after that.

It's definitely a hack, but it does work. Of course I'll dismantle it the very day that WordPress gets native support for Gutenberg in categories. Especially for cases like WooCommerce that require feature-rich content, the classic text editor just doesn't cut it anymore.

My thanks to anyone working on this problem. I hope that any potential solution will also be available in classic themes, and not exclusive to block themes.

[sangtlee]

Good to see some chatter on this again! I agree with @kraftner and others that you can achieve what we need with technical workarounds...but IMHO, the real benefit of enabling Gutenberg natively in Term edit pages is improving content editor user experience. Workarounds like mine, using shadow posts or ones using shortcodes inside term description fields are not very intuitive to content editors.

My team also works with Drupal...and almost every Drupal site we've built has at least one Taxonomy (e.g. blog category or degree program) with Terms in those Taxonomies that have block content managed on them which is then displayed on the Term pages...and the content mgmt experience in the Term page is the same as any other block-enabled page.

So what is the typical dev workflow for changes to core? Can anyone submit PR's? Or must the work be initiated by a core maintainer? How can we elevate the visibility of this? This thread is 5 years old.

[djcowan]

It can be disabled by default and enabled with a filter or a similar method.

---

Would love an opt-in mechanism via theme_support, hook or filter. The post except field includes the [excerpt_allowed_wrapper_blocks] action hook (https://developer.wordpress.org/reference/hooks/excerpt_allowed_wrapper_blocks/) which is used by the excerpt_remove_blocks function I might be over simplifying due to ignorance, but the term description field doesn'tappear to be far removed from the post excerpt field. (Ignoring the stack of excerpt generative and santization filter requirements) My point. The Wordpress Classic Editor block allows for an entity to be edited in both classic and editor modes and the content and assiciated functions survive both experiences. Though as I am composing this post it occurs to me that both the excerpt and core/comment blocks require the block-editor to function, and the form fields required for settings/options would be the same form fields which are still in experimental development phase. For some reason I was dreaming of an opt-in switch that would magically interchange admin settings page with block editor page. (aka wordpress-classic editor plugin) - but realilty just slapped me upside-the-head.