Make WordPress Core

Opened 20 months ago

Last modified 2 months ago

#21539 new enhancement

category_description filter not applied to Description field on Categories page

Reported by: StephenCronin Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version: 3.4.1
Component: Taxonomy Keywords: has-patch
Focuses: administration Cc:


The category_description filter is not applied to the Description field on the Posts > Categories page (wp-admin/edit-tags.php?taxonomy=category).

Need: I use very long category descriptions, which are displayed on the front end of the site. This means that the Posts > Categories page is blown out by the long descriptions. I wrote a plugin to filter the category_description to limit it's length in the admin area. However, I then discovered that the filter is not applied on this page.

I'm wondering if there is some reason this was left out by design, but I can't see any reason why the filter should not be applied at this point. If I've missed something, please let me know.

It is easy to fix - simply apply the category_description filter to the description field in column_description() in wp-admin/includes/class-wp-terms-list-table.php

I have applied this on my local install. Now I just need to work out how to create a patch and submit it for review (this is my first attempt).

Note: It may be sensible to limit the length of the category description displayed on this page, but that's outside the scope of this ticket, which is just about the filter not being applied.

Attachments (1)

21539.patch (468 bytes) - added by StephenCronin 20 months ago.
Patch for ticket #21539

Download all attachments as: .zip

Change History (7)

StephenCronin20 months ago

Patch for ticket #21539

comment:1 SergeyBiryukov20 months ago

  • Keywords has-patch added; needs-patch removed

comment:2 dd3220 months ago

The obvious downside to this as it stands, is back compat with plugins/filters written that expect to be displayed on the front end only, suddenly showing within the admin might not be the intended purpose of them.

The other thought that comes to mind, is what about cases where the term isn't a category, such as a hierarchical custom tax? should that get the same filter?

There's no harm in having a filter here, but perhaps a new filter, and one that takes other taxonomies into account (even if it's just passing the taxonomy as context to the apply_filters call)

comment:3 SergeyBiryukov20 months ago

A workaround would be to hook into get_terms filter on that screen:

function filter_category_descriptions_in_admin( $terms ) {
	global $current_screen;

	if ( empty( $current_screen ) || 'edit-category' != $current_screen->id )
		return $terms;

	foreach ( $terms as $key => $term )
		$terms[ $key ]->description = apply_filters( 'category_description', $term->description, $term );

	return $terms;
add_filter( 'get_terms' , 'filter_category_descriptions_in_admin' );
Last edited 20 months ago by SergeyBiryukov (previous) (diff)

comment:4 follow-up: StephenCronin20 months ago

Thanks guys for your feedback. Much appreciated. I hadn't considered backwards compatibility, but can (now) see that's a huge issue.

Sergey, thanks for the workaround - it looks good and I'll try it out. That should take care of my need.

Does that mean we don't need to progress anything and we can close this ticket?

comment:5 in reply to: ↑ 4 SergeyBiryukov20 months ago

Replying to StephenCronin:

Does that mean we don't need to progress anything and we can close this ticket?

Not necessarily, we can leave it open to see if there might be more use cases for a new filter here and close it later if it gets no more traction.

comment:6 nacin2 months ago

  • Component changed from Administration to Taxonomy
  • Focuses administration added
Note: See TracTickets for help on using tickets.