WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 19 months ago

#28033 assigned defect (bug)

post_categories_meta_box on non-hierarchical custom taxonomy

Reported by: ByronicEntity Owned by: rufein
Milestone: Future Release Priority: normal
Severity: normal Version: 3.9
Component: Taxonomy Keywords: good-first-bug needs-patch
Focuses: ui, administration Cc:

Description

Slightly based on the work done in #14206

Using a non-hierarchical custom taxonomy in combination with meta_box_cb 'post_categories_meta_box'. Creates a new term with the id name of the selected term_id on submission. (See attached file)

First time added term "Custom", selected it Published post. (It auto added the term "207") Published post. (It auto added the term "208")

Attachments (5)

nonhierarchical-taxonomy.jpg (4.9 KB) - added by ByronicEntity 4 years ago.
Example of bug
patch (686 bytes) - added by rufein 4 years ago.
patch to taxonomy.php
28033.patch (613 bytes) - added by rufein 4 years ago.
28033 patch
28033.2.patch (613 bytes) - added by rufein 4 years ago.
28033 patch
28033.3.patch (628 bytes) - added by rufein 4 years ago.

Download all attachments as: .zip

Change History (20)

@ByronicEntity
4 years ago

Example of bug

#1 in reply to: ↑ description @ByronicEntity
4 years ago

Replying to ByronicEntity:

Slightly based on the work done in #14206

Using a non-hierarchical custom taxonomy in combination with meta_box_cb 'post_categories_meta_box'. Creates a new term with the id name of the selected term_id on submission. (See attached file)

First time added term "Custom", selected it Published post. (It auto added the term "207") Published post. (It auto added the term "208")

/wp-includes/post.php: line: 3171: $tags = array_filter($tags);

Should be changed imho to: $tags = array_map('intval', array_filter($tags));

Since hierachical terms should be passed by id instead of names.

Changing this allows non hierachical taxonomies with custom callbacks like this one, to submit by an array of id's instead of a list of strings containing mutliple terms

#2 @ByronicEntity
4 years ago

  • Component changed from General to Taxonomy

#3 @wonderboymusic
4 years ago

  • Focuses ui administration added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

@helen and I have chatted about tax meta boxes - if we pick up work on those, we can address this in 4.0

#4 @boonebgorges
4 years ago

  • Keywords good-first-bug added

#5 follow-up: @rufein
4 years ago

I've done my first ticket.

The documentacion in register_taxonomy() says explicitly:

meta_box_cb - Provide a callback function for the meta box display. If not set, defaults to post_categories_meta_box for hierarchical taxonomies and post_tags_meta_box for non-hierarchical.

The author of this ticket is setting manually the wrong function to manage non-hierarchical terms.

I've reproduced the error and when an user create throungh Ajax a new term, the upper function creates the output reported in this thread. When the Ajax call is executed in server, it creates a new term that stores in database. At the end of the proccess, it creates options to be added to the form, but the function duplicate it because it also attach a parent option that not exist. So, finally, ajax add an non-existing term to the form. If you submit a non-existing term in the form, it will be created. If not, it will disappear.

I've created a patch to avoid that function post_categories_meta_box() being assigned to a non-hierarchical taxonomies.

@rufein
4 years ago

patch to taxonomy.php

@rufein
4 years ago

28033 patch

@rufein
4 years ago

28033 patch

@rufein
4 years ago

#6 @rufein
4 years ago

Sorry, i brake the standards, so i reupload the patch. The last version is the good one.

#7 @helen
4 years ago

I'd rather make the different UIs work for different types of taxonomies - see #14877.

#8 @marsjaninzmarsa
4 years ago

  • Keywords has-patch added; needs-patch removed

#9 @DrewAPicture
3 years ago

  • Owner set to rufein
  • Status changed from new to assigned

#10 @SergeyBiryukov
3 years ago

  • Keywords needs-patch added; has-patch removed

See comment:7.

#11 in reply to: ↑ 5 @unknowndomain
3 years ago

This is a really poor solution, blocking the developer from doing something because WordPress is a bit rough round the edges isn't the correct solution.

There seems to be a number of people who want to use the checkbox (category) style UI on non-hierarchical taxonomies. I don't see why there are two different ajax handlers, and ways of displaying taxonomies which are essentially in the back end identical...

In my view the correct solution would be to make both the category and tag meta box's use either IDs or slugs but be consistent and use the same AJAX call back. This way the developer above and myself and others who have the same issue would be able to switch the call backs out and know it will work correctly, and use that AJAX endpoint for their own custom metaboxes.

Replying to rufein:

I've done my first ticket.

The documentacion in register_taxonomy() says explicitly:

meta_box_cb - Provide a callback function for the meta box display. If not set, defaults to post_categories_meta_box for hierarchical taxonomies and post_tags_meta_box for non-hierarchical.

The author of this ticket is setting manually the wrong function to manage non-hierarchical terms.

I've reproduced the error and when an user create throungh Ajax a new term, the upper function creates the output reported in this thread. When the Ajax call is executed in server, it creates a new term that stores in database. At the end of the proccess, it creates options to be added to the form, but the function duplicate it because it also attach a parent option that not exist. So, finally, ajax add an non-existing term to the form. If you submit a non-existing term in the form, it will be created. If not, it will disappear.

I've created a patch to avoid that function post_categories_meta_box() being assigned to a non-hierarchical taxonomies.

This ticket was mentioned in Slack in #buddypress by djpaul. View the logs.


3 years ago

#13 in reply to: ↑ description @son9ne
19 months ago

This is still an issue, exactly as the original post states. This is on WordPress 4.6.1. Cannot believe it's still an issue 3 years later...

#14 follow-up: @boonebgorges
19 months ago

It may be possible to fold this into #36514.

#15 in reply to: ↑ 14 @tbuers
19 months ago

Replying to boonebgorges:

It may be possible to fold this into #36514.

I haven't read all the comments but it seems like the other issue is exactly the same as the one as the original poster was experiencing. Allowing a custom callback for sanitization is probably the best way to go. The patch you provided would be sufficient.

Last edited 19 months ago by tbuers (previous) (diff)
Note: See TracTickets for help on using tickets.