Enabling Gutenberg in WP categories #17099
Comments
talldan
added
the
[Type] Question
|
Same here, I'd like to edit category-descriptions with Gutenberg. |
|
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? |
|
This would be a cool idea |
mtias
added
[Feature] Blocks
|
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 |
|
@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. |
|
Thank you Greg! |
|
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. |
|
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?🥺😐 |
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:
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 |
|
How can WordPress be upgraded to FSE without supporting this feature ? |
|
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: 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? 🤔 |
|
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 don't understand this comment. The community can do more than one thing at once. |
|
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. |
|
Yes, I agree, the community, contributors, and core team can work together on multiple facets of the system. |
|
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.
|
|
@djcowan Not at all, I just didn't understand the statement and it didn't really feel like it contributed to the discussion. @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 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. |
|
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. |
|
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 |
|
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. |
|
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. 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:
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) |
That was me suggesting in Slack 👋
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. 😄
|
|
@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? |
|
Might it suffice to add block support to the category description editor. 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 |
|
I submitted a PR Automattic/blocks-everywhere#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. The only issue is that Blocks Everywhere requires the Gutenberg Plugin. That holds me back from using it in production. |
|
@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). |
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. |
|
@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).
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. |
|
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;
} ); |
|
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 // 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 ( 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. |
|
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. |
Would love an opt-in mechanism via theme_support, hook or filter. |
On principle I agree with this BUT consider that this is a 5 year old thread and one of the biggest hurdles in my opinion with WP as an eco system is that we are consistently falling behind due to this mentality. WooCommerce now has a block editor experience for product pages which are far more complex than a terms edit page.. @goaround have made a decent POC using the block-everywhere plugin. On a constructive note how we decided to "solve" this for our clients is that we've made a "Block areas" post type which is just a non-public post type where one can create posts containing blocks. Then in edit screens for any terms or other locatiosn where blocks are currently not supported we have two inputs "Add block areas above content" and "Add block areas below content". which allows for searching and picking any number of these posts in both locations. |
bph
added
the
[Focus] Blocks Adoption
|
Also suggested on this Reddit comment:
|
|
I really don't understand why team spending time on changing colors and moving fonts here and there in Gutenberg. Also making full block themes in parallel when taxonomy system is still in Netscape era. |
|
I feel that this thread isn't reaching the right people. I wonder who they are. |
|
@mtias @youknowriad Could this be part of WP redesign project? It seems to be a adoption blocker to not be able to add blocks to Category pages and still have to deal with a basic textarea box. |
|
Obviously this thread hasn't reached the right people. |
and others
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.
The text was updated successfully, but these errors were encountered: