WordPress.org

Make WordPress Core

Opened 14 months ago

Closed 14 months ago

Last modified 14 months ago

#23597 closed defect (bug) (fixed)

Alert message, "No tags found!" cannot be set for a non-hierarchical custom taxonomy.

Reported by: alexmansfield Owned by: SergeyBiryukov
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.0
Component: Taxonomy Keywords: has-patch
Focuses: Cc:

Description

I think the easiest way to explain this will be by stepping through the process I used to find this bug.

  1. Create a new non-hierarchical taxonomy (non-hierarchical just means they function like tags, not categories). For the sake of argument, let's say this taxonomy applies to posts.
  1. Go view a post in the admin (or create a new post). The meta box for the bew taxonomy is displayed and contains an input box for creating items in this taxonomy, a message about separating multiple items with commas, and a link to view the most used items in the taxonomy. The text for this link can be set when creating a custom taxonomy, which is great!
  1. Click the link to display the most used items in this taxonomy. Typically this displays a tag cloud of the most used items. However, if no items have been saved yet, it instead displays the message: "No tags found!"

The text for this message cannot be set when creating a custom taxonomy. Regardless of the taxonomy name, the word "tags" is used.

I've attached an image of a custom taxonomy called "Classifications" where the "tags" message is still in use.

This message is defined on line 654 of the wp-admin/includes/ajax-actions.php file (at least it is in WordPress 3.5.1).

Since this isn't in the same file as the rest of the labels that can be set when creating a taxonomy, I'm not sure how to go about making it editable. Maybe just change the text from "No tags found!" to "None found!" I can't say it's the greatest solution, but at least it wouldn't say the word "tags" when the taxonomy isn't actually "tags".

Any thoughts?

Attachments (4)

no-tags-found-error.jpg (9.4 KB) - added by alexmansfield 14 months ago.
Example of the "No tags found!" message that cannot be re-labeled for custom taxonomies.
23597.diff (1.9 KB) - added by DrewAPicture 14 months ago.
23597.2.diff (2.4 KB) - added by SergeyBiryukov 14 months ago.
23597.3.diff (2.6 KB) - added by SergeyBiryukov 14 months ago.

Download all attachments as: .zip

Change History (17)

alexmansfield14 months ago

Example of the "No tags found!" message that cannot be re-labeled for custom taxonomies.

comment:1 alexmansfield14 months ago

  • Cc alex@… added

comment:2 SergeyBiryukov14 months ago

  • Keywords ui-feedback removed
  • Milestone changed from Awaiting Review to 3.6
  • Version changed from 3.5.1 to 3.0

Although it's not documented anywhere as far as I can see, it's actually possible to customize the string by adding no_tagcloud parameter to your register_taxonomy() call (see [13538]):

register_taxonomy( 'classification', 'post', array(
	...
	'no_tagcloud' => __( 'No classifications found!', 'your-textdomain' ),
) );

Seems like the string was missed in [15190], so it didn't make it into the labels array. I guess we should move it there. We could also change the default to "No items found" or "No terms found".

Last edited 14 months ago by SergeyBiryukov (previous) (diff)

comment:3 follow-up: thee1714 months ago

  • Version changed from 3.0 to trunk

Or the default could be "No (taxonomy name) found." Although I'm not sure if that would cause i18n or l10n issues.

comment:4 thee1714 months ago

  • Version changed from trunk to 3.0

DrewAPicture14 months ago

comment:5 DrewAPicture14 months ago

  • Cc xoodrew@… added
  • Keywords has-patch needs-codex added

23597.diff adds no_tagcloud to the labels array as "No terms found."

comment:6 in reply to: ↑ 3 SergeyBiryukov14 months ago

Replying to thee17:

Or the default could be "No (taxonomy name) found." Although I'm not sure if that would cause i18n or l10n issues.

It would, see dd32's comment for why we're trying to avoid post type and taxonomy names in generic strings.

SergeyBiryukov14 months ago

comment:7 follow-up: SergeyBiryukov14 months ago

23597.2.diff is basically a follow-up to [15190].

It keeps the current string for consistency, since the other default strings in get_taxonomy_labels() also refer to tags.

comment:8 in reply to: ↑ 7 DrewAPicture14 months ago

Replying to SergeyBiryukov:

23597.2.diff is basically a follow-up to [15190].

It keeps the current string for consistency, since the other default strings in get_taxonomy_labels() also refer to tags.

Oh right. And since it's now in the labels array it's overrideable.

comment:9 SergeyBiryukov14 months ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 23483:

Move 'no_tagcloud' argument to the taxonomy labels object. props DrewAPicture for initial patch. fixes #23597.

comment:10 DrewAPicture14 months ago

  • Keywords needs-codex removed

Labels array parameter updated with no_tagcloud entry. See: http://codex.wordpress.org/Function_Reference/register_taxonomy#Arguments

comment:11 nacin14 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

As done in [15190], can we rename this so the label key matches the value?

Normally I would say no_items_found, but in this case, not_found probably makes more sense, to be parallel with register_post_type().

SergeyBiryukov14 months ago

comment:12 SergeyBiryukov14 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 23484:

Rename 'no_tagcloud' taxonomy label to 'not_found', for consistency with the post type label of the same key. fixes #23597.

Note: See TracTickets for help on using tickets.