Make WordPress Core

Opened 12 years ago

Closed 10 years ago

#21539 closed enhancement (maybelater)

category_description filter not applied to Description field on Categories page

Reported by: stephencronin's profile StephenCronin Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.4.1
Component: Taxonomy Keywords: has-patch
Focuses: administration Cc:

Description

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 12 years ago.
Patch for ticket #21539

Download all attachments as: .zip

Change History (8)

@StephenCronin
12 years ago

Patch for ticket #21539

#1 @SergeyBiryukov
12 years ago

  • Keywords has-patch added; needs-patch removed

#2 @dd32
12 years 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)

#3 @SergeyBiryukov
12 years 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 12 years ago by SergeyBiryukov (previous) (diff)

#4 follow-up: @StephenCronin
12 years 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?

#5 in reply to: ↑ 4 @SergeyBiryukov
12 years 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.

#6 @nacin
10 years ago

  • Component changed from Administration to Taxonomy
  • Focuses administration added

#7 @wonderboymusic
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

"close it later if it gets no more traction" - no traction in 22 months

Note: See TracTickets for help on using tickets.