Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#24216 closed defect (bug) (duplicate)

wp_unique_term_slug uses variable that doesn't exist

Reported by: lonnylot Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.5
Component: Taxonomy Keywords: has-patch
Focuses: Cc:

Description (last modified by SergeyBiryukov)


$args['term_id'] doesn't exist. It should be $term->term_id.

This means that even though the DB schema allows for different taxonomies to have the same slug the code will never allow it.

Attachments (1)

24216.diff (687 bytes) - added by Sebastian Klier 5 years ago.

Download all attachments as: .zip

Change History (7)

#1 @SergeyBiryukov
5 years ago

  • Milestone changed from Awaiting Review to 3.6
  • Version changed from trunk to 2.5

Introduced in [6326].

#2 @SergeyBiryukov
5 years ago

  • Description modified (diff)

#3 @lonnylot
5 years ago

On further inspection the whole 'unique slug' system is a little faulty. I'm not sure if this warrents a new ticket or if the scope of this ticket should be broadened, but I wanted to make a note of it.

If you create a category w/ the name of 'Foo' and the slug 'foo' automatically gets created. Create a new category with the name of 'foo' and the slug 'foo-2' gets created. This works properly, but here is the problem:

If you create a new category w/ the name of 'Foo' you get 'A term with the name provided already exists with this parent.', but if you create a new category w/ the name of 'foo' you get a new category w/ a slug of 'foo-3'.

#4 @Sebastian Klier
5 years ago

  • Cc Sebastian Klier added
  • Keywords has-patch added

#5 @Sebastian Klier
5 years ago

I had a look at this today and I believe the part referenced in the ticket can simply be removed. Using


does not work, as $term was originally cast to stdClass from $args and does not have this property. You could look up the ID again, or make more changes so we can pass the ID, but I'm not sure that is necessary as the method to get the numbered slug has worked like that for years now?

As mentioned in the comment above, there are many more things going wrong here, and I'm not sure what the intended behaviour is, else I would look into it further. According to the codex, there should never be duplicate names, not even for terms with different parents. However currently it seems only the first returned name is checked against, and lower/upper case is not taken into account. Duplicate names within other parents seem also possible.

Last edited 5 years ago by Sebastian Klier (previous) (diff)

#6 @nacin
5 years ago

  • Milestone 3.6 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #12729.

Note: See TracTickets for help on using tickets.