WordPress
Enabling Gutenberg in WP categories
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.
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?
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!
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.
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.
@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.
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.
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!
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
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.
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
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.
+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? 🤔
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.
- See this as an opportunity to build a plugin to enhance the system.
- Join the contribution team and assist in developing Wordpress
- Adjust your approach to working with the system as it currently is.
- 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.
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.
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 🪙 🪙
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. :)
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.
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.
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.
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.
I think the system described by @jonathan-dejong makes perfect sense. Huge vote of approval here.
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)!
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...
I'd rather the community remained focused on refactoring Wordpress' core functionality. Oh, and the incredible work they're doing with accessibility.
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 🤔