Add UI to Category page to indicate default category

[kraftbj]

Currently, the default category is set in Settings->Writing and it only indicated on the Category page (Posts->Categories) via the lack of a checkbox to delete.

1. Add a visual indicator on the Categories page to indicate the default category.
2. Add an option to change the default on the Categories page.

[helen]

I like this. Possibly with the word "Default" next to the term name in the list table (the way Sticky shows in the posts list table) and another row action to "Set as Default". Probably needs some thought about the individual edit term screen.

I would then add 3. Remove from Settings -> Writing.

[paulwilde]

Created a patch which will do the following:

• Adds a "Default" label in the same style as Sticky/Draft shows in the post rows.
• Adds an action titled "Set as Default" if the user has permission to manage options which sets the default taxonomy. This is limited to only for the category taxonomy, but could be abstracted in future should other taxonomies need the ability to have a default.
• Removes the Default Category setting from Settings -> Writing.

[nacin]

Nice, paulwilde! We'll get someone to review this.

[kraftbj]

This works for me. Patch is stale for /wp-admin/includes/class-wp-terms-list-table.php, so attaching an updated one. No changes to the patch itself.

[kraftbj]

Refreshed version of paulwilde's patch

[helen]

Thanks for the patch, paulwilde, and thanks for refreshing, kraftbj. It's working great, and I like how it feels. There are a few things it's exposing to me at the moment:

• After you set the default, you get redirected back to the first page of the list table, rather than the one you were on. Editing a term does return you to the appropriate page.
• We need an updated message at the top letting the user know the action was successful.
• We should probably do the same thing for link categories - the UI for links is hidden in new installs, but when it is shown, it would be nice to use the same paradigm.
• We should probably set the "Set as Default" string to not wrap (CSS).

Going to try running this shift by jenmylo for a UX check as well.

[kraftbj]

Taking @paulwilde's initial patch and adding in the suggestions by Helen, particularly:

• Updated the redirect URL to included a paged query arg to redirect back to initial page.
• Added a message indicating Category default was set. Though unused, added similar messages to the other cases to keep the arrays consistent.
• Duplicated the work for Links (including it in the conditional for displaying the Set as Default and removing the default from Settings->Writing)
• Set CSS to nowrap the line, and removed the nbsp from Quick Edit in the same set of action items for consistency.

Additionally, I added a nonce check for it, just to be safe.

[kraftbj]

Updated per https://core.trac.wordpress.org/ticket/26268#comment:8

[seanchayes]

I found this patch worked really well. I also found that it was being applied to Tags or non-hierarchical taxonomies. For example, with the 26268.2 patch I found I could set a tag as default and then I couldn't remove it.

So I have the following modified patch:

26268.3 - this modifies the "Is this the Category or Link Category" check so that the "Set as Default" option is only active on the Category admin page.

[kraftbj]

Thanks for catching that. I had it working right, but must have changed it up and not properly tested it.

Confirmed that .2 is deficient as stated and .3 resolves it.

[keita_kobayashi]

I really like this new UI, but realized that the user may not remember which category was set as default when authoring a new post. I'm not sure this is in the scope of this patch, but maybe having a "(default)" will remind the user that that category will be automatically applied if no other category is manually selected? I've attached a simple implementation of this in 26268.show.default.diff .

[keita_kobayashi]

Wraps the (default) in for i18n

[kraftbj]

@keita_kobayashi: I don't know if it is within the scope of the ticket or not, but it's a nice touch :-)

My thoughts on that piece:

1. What about, in addition to the label, on a new post it is outputted first? e.g.

Category 1 (default)
AAA
BBB
CCC

2. When editing an existing post, does the user care what the default category is? Does the label still need to be there?

I defer to the core developers on if this should be part of this ticket or figured out before deciding on the rest of the patch.

[helen]

26268.3.diff​ works well, looks good at a glance. It exposes something to me though - you can't quickly get an idea which category is your default if you have lots of them. What could be done there? Possibly show the default at the top of the list?

[seanchayes]

I've updated the patch - now 26268.4.diff - so it displays the default category above the table list of categories. This allows the default category to persist in display when navigating through the category list.

I have also added a screenshot of how it looks.

[wonderboymusic]

26268.5.diff​ accounts for [29782] - this seems like a good enhancement for 4.1

[helen]

What are the chances we can float the default term to the top of the list? I have a feeling it might not be pretty, given paging.

[kraftbj]

@helen: First glance, not pretty.

What is your thinking behind floating it to the top? Add visibility? Quicker to find to edit? Would linking the "Default Category: X" text added in 26268.4.diff to the edit terms page meet the objective?

[seanchayes]

I took 26268.5.diff and added the idea from comment:19.

I've applied the code changes into 26268.6.diff and uploaded three images showing how I interpreted that comment.

The default category shows at the top of the list :

• The first time the list is displayed. (image 1)
• For times when the category list is processed for paging. (image 2)
• When a column is chosen as the column to sort on including when paged. (image 2)
• When a search is performed using "Search Categories" (image 3)

[DrewAPicture]

Just a couple of things that jumped out at me about 26268.6.diff​:

• We probably need a more specific selector on nowrap-ing the 'Set to Default' string, .row-actions a is pretty global and could have more far-reaching effects elsewhere in the admin
• Something else wasn't really well-illustrated in the screenshots is that row actions are now forced to two lines because of the width of the column (see row_actions_hover.png​). At first I figured the row actions count was off because the separator was on the end of the line but then I realized it was wrapping

I kind of wonder if maybe instead of trying to add a seldom-used action link to the row actions, perhaps that might be a better fit in edit-tags and/or quick edit.

[kraftbj]

@seanchayes - As confirmation, did the user-edit.php diff slide in my mistake in 26268.6.diff ?

@DrewAPicture

• We could argue that the .row-actions a is a good idea either way since having a line break within a link in row actions is poor UI. May be better discussed in a separate ticket, though, since it would impact more than this and/or more specific selector.

• The two-line doesn't concern me, in and of itself. It is already two lines on thinner viewports (~<1300px).

[seanchayes]

@kraftbj - did I lose some code that you provided? I'm not sure I recall any changes to user-edit.php? Sorry. I pulled down 26268.5 and then created .6 from that. So I hope I've not messed anything up.

I'm thinking that the ability to set the default category at anytime whilst browsing through the category list is useful. I do also agree it's a seldom used option (comment:22), but it is now in a more logical place and with a visual cue compared to where it was before this patch.

As @kraftbj says, forcing the action text to display on two lines does already occur.

[kraftbj]

@seanchayes - On the contrary, looks like extra changes were added in 26268.6.diff (see the end of the patch). Maybe testing out another patch and hadn't svn revert -R .?

In either event, refreshing the patch.

[kraftbj]

Same as .6, minus the user-edit.php revision.

[seanchayes]

Ugh - thanks and apologies.

[johnbillion]

Adding a "Set as default" link to every row seems like a lot of unnecessary visual noise. How often do you change the default term for a given taxonomy?

[kraftbj]

Chatted with @helen in Slack: ​https://wordpress.slack.com/archives/core/p1424923581006944

Where we're at now is we're trying to push too much in this one ticket.

This ticket will focus exclusively on the UI for indicating the default category, which should be a quicker win for users.

The CSS change I'm dropping completely. Checking /wp-admin/ more, using a   is what is used elsewhere (with the exception of #31482) and provides the same benefit.

The UI for *changing* default category will be discussed in #31483

[kraftbj]

26268.7 with the CSS and UI to change default removed.

[kraftbj]

26268.8 without the bad intent on one line :)

[seanchayes]

In the spirit of Trac Gardening I've refreshed this patch. It:

1. Displays the default category as the 1st item in the list table regardless of the page number / count in the list. It is also annotated "- default"
2. As @kraftbj said in comment:20 the UI for changing the default category is not included in this patch.
3. It reflects the screenshots in between comment:21 and comment:22
4. I changed the default category a couple of times and sure enough the newly changed default showed up at the top of the list table.

Testing welcome / required.

[chriscct7]

@seanchayes that's the spirit! Unfortunately, it looks like your patch didn't upload. Can you try uploading it again please? Thanks!

[kraftbj]

.10 works well in testing. It stuck the default at the top of the list table and remained there as I advanced to addition pages of categories.

One edge case: If the default category is a child category.
Previously: It would be shown as a child category (without the checkbox to delete and without the delete option).
.10: It remains at the top of the list table with no difference in appearance compared to a top-level category.

Do we need to preserve the visual indication of a child category on edit-tags.php?taxonomy=category?

[wonderboymusic]

26268.11.diff​ - would lurve your eyes on this

[tzon]

I added the patch 12684 that added an edit btn for bulk actions for categories. I added some categories at 3 levels of parenthood. All looked well. I then added this patch to show default category. It showed the default but then did not list the child categories I added previously. I'm not sure why.

[arvindsinghu]

yes this can be something new for wordpress , we should work on this :)

[boemedia]

We triaged this ticket in the design team today and it seems to need a new patch first. The last one tested is 4 years old and didn't seem to work. The design team is happy to circle back to give feedback on a new patch. Would be great if a video or screenshot could be included for less technical contributors!

[joyously]

I think the list of categories should only list each category once. Showing the default category in the list at the top of each page is confusing and not helpful (the user doesn't need to edit it, just might want to know), because the list is sortable. If I saw the same one on every page I would wonder why I have so many with the same name.

So if the list really needs to show which one is default, I prefer indicating it outside the list itself. But the consideration is that the default does not have a Delete action, and using a label "-- Default" on the term helps to explain why there is no Delete action.

[huzaifaalmesbah]

I attempted to test the latest attached patch using:

npm run grunt patch:26268

The patch did not apply cleanly against current trunk.

The following file had failed hunks:

• src/wp-admin/includes/class-wp-terms-list-table.php

A reject file was generated:

• src/wp-admin/includes/class-wp-terms-list-table.php.rej

Given the age of the latest patch and the amount of changes in list tables, taxonomy UI, and admin screens since it was created, the patch appears to be outdated and needs to be refreshed against current trunk before meaningful testing can be performed.

Since the patch cannot currently be tested against trunk, I have removed the needs-testing keyword.

This ticket already has needs-refresh, and a refreshed patch would be required before further testing or UX feedback.

This patch adds UI to the Categories admin page to clearly indicate which category is the default:

1. Shows the default category first in the list
2. Adds a "Default" label next to the default category name

This helps users quickly identify and understand the default category behavior, as discussed in the Trac ticket.

Test failures appear unrelated — CI tooling tripping.

One thing seems to be missing in the user interface and that is discovery for how to change the default category. Should there be a link to the Writing Settings screen, linking to the specific field on that screen?

[huzaifaalmesbah]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/10831

Environment

• WordPress: 7.0-alpha-61215-src
• PHP: 8.2.30
• Server: nginx/1.29.4
• Database: mysqli (Server: 9.5.0 / Client: mysqlnd 8.2.30)
• Browser: Chrome 144.0.0.0
• OS: macOS
• Theme: Twenty Twenty 3.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps taken

1. Created multiple categories.
2. If you want changed one category as the default via Settings → Writing.
3. Applied the PR patch.
4. Visited Posts → Categories.
5. Observed that the selected default category is clearly displayed with a "Default" label.
6. ✅ Patch is solving the problem.

Expected result

• Default category should be clearly visible in the Categories list.
• Default category should be easy to identify without guessing why Delete is missing.
• "Default" label is clearly.

Screenshots/Screencast with results

Before Apply Patch	After Apply Patch ✅

Should there be a link to the Writing Settings screen, linking to the specific field on that screen?

I'm open to that. The main intent was to simply explain versus the user needing to infer why that category is acting differently in the list.

Trying it as a row action:

Trying it as a row action:

Good idea!

I had only been thinking about doing so from the Categories list table, at /edit-tags.php?taxonomy=category, like somewhere in this paragraph below the table:

Would adding a link there as well be redundant? Or helpful?

Oh, I like that. I don't think it would be redundant. "The default category can be renamed or changed, but not deleted" or something like that with "renamed" going to the edit category page for that term and "changed" going to the settings page seems lightweight and direct. Going to try that. I'll leave the row action too.

Just like us, I thought about the category in the table and you thought about the text at the bottom (which I didn't think about at all), this is an area that I'd rather just help people find what they need no matter where their focus is, especially if it can be done in a relatively "invisible" way if you're thinking about other things.

Used language similar to elsewhere in Core (src/wp-admin/user-edit.php:63 - __( 'Your username cannot be changed, but you can use other fields to enter your real name or a nickname, and change which name to display on your posts.' ) in the profile help center.

This is looking really good. I asked Gemini to provide another review and I think it has some valid points:

I have reviewed the changes and identified a functional regression regarding hierarchical display, along with some code style improvements.

### Review of src/wp-admin/includes/class-wp-terms-list-table.php

1. Functional Regression: Children of Default Category Hidden

In the _rows() method, the logic to skip the default category prevents its children from being processed.

// Skip duplicating display of default category.
                        if ( $default_category_id && $default_category_id === $term->term_id ) {
                                continue;
                        }

When continue is executed, the loop advances to the next iteration immediately. However, the recursive call to process children is located *later* in the loop:

if ( isset( $children[ $term->term_id ] ) && empty( $_REQUEST['s'] ) ) {
                                $this->_rows( $taxonomy, $terms, $children, $start, $per_page, $count, $term->term_id, $level + 1, $default_category_id );
                        }

As a result, if the default category has children, they will never be reached or displayed in the list. The logic needs to be adjusted to ensure recursion still happens even if the parent row (the default category) is skipped for display.

2. Strict Comparison & Type Casting

In column_name(), loose comparison is used:

$default_term       = get_option( 'default_' . $taxonomy );
                $default_term_label = '';
                if ( $tag->term_id == $default_term ) {

For consistency with WordPress coding standards and the other changes in this PR (e.g., in display_rows_or_placeholder and handle_row_actions), this should cast the option to an integer and use strict comparison:

if ( $tag->term_id === (int) $default_term ) {

3. Documentation

The _rows() method docblock was updated to include @param int $default_category_id, but it is missing a description.

### Review of src/wp-admin/edit-tags.php

4. Link Safety

The use of get_edit_term_link( $default_category_id, 'category' ) is generally safe here since $can_edit_terms is checked earlier in the file, but it's worth noting that if it were to return null (e.g., error condition), esc_url() would return an empty string, resulting in a link to the current page. Given the context (default category should always exist and be editable here), this is likely acceptable.

### Summary

The changes look good overall, but the regression in handling hierarchical children needs to be addressed before merging.

Key changes to fix:

• Ensure _rows() recurses into children even when the default category row is skipped.
• Use strict comparison (===) and (int) casting for the default term check in column_name().

Nice find from Gemini on the children issue. If we keep the pinning and iterate through children, we'd have a few options—none great:

1. Display children under the pinned default category at the top (but they're not special, just regular subcategories)
2. Show the default category twice—pinned at top and in its natural spot with children
3. Show children in their natural position without their parent visible above them (broken hierarchy display)

Rather than adding complexity to handle this, I've removed the pinning entirely. The default category now stays in its natural position in the hierarchy. The "Default" label and "Change Default" row action still clearly identify it, and the text below the table already explains the default category behavior.

I feel like we might be getting into space where if we try to be too clever, we're making things harder. That said, @westonruter—if you think an alternative approach works better here, I'm game to go with that instead.

@kraftbj skipping the pinning of the default category makes sense to me. Does the post list table have any facility for showing sub-posts under a post marked as sticky? I don't believe so, since sticky posts are only relevant to chronological posts not hierarchical ones (e.g. pages). I agree with your conclusion. In any case, the footer has a persistent mention of what the default category is:

So even when it isn't displayed on the first page, it will still be discoverable.