Make WordPress Core

Opened 14 years ago

Last modified 6 months ago

#14691 new defect (bug)

Allow commas in tag names

Reported by: mdawaffe's profile mdawaffe Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0.1
Component: Taxonomy Keywords: needs-refresh
Focuses: Cc:


Adding tags to posts via the web interface involves a lot of what boils down to

explode( ',', join( ',', array( $tag_name, ... ) ) );

both in PHP and JS.

We settled on commas so we could have tags with spaces in them (see #10320, for example).

It'd be nice if tags (and other taxonomies) could have commas in them, though. Example use case: normalized locations ("Portland, OR"). Admittedly, commas in tag names is an edge case.

The attached treats tag inputs as "real" CSV strings instead of just exploding by commas.

That way, you can enter:

hello, "hello, world"

in the tags input field and the following tags would be added to the post.

  • hello
  • hello, world

This addresses commas in tag names but makes entering double quotes in tag names more annoying. If you wanted a tag named double"quote, you'd have to enter the following.


This may also help with #7897.

Attachments (4)

14691.diff (14.5 KB) - added by mdawaffe 14 years ago.
tags-with-commas.diff (8.2 KB) - added by joehoyle 11 years ago.
tags-with-commas.2.diff (9.1 KB) - added by joehoyle 11 years ago.
tags-with-commas.3.diff (11.4 KB) - added by joehoyle 11 years ago.
Actually added tags

Download all attachments as: .zip

Change History (36)

14 years ago

#1 follow-up: @mdawaffe
14 years ago

The patch makes use of a slightly modified version of

I've emailed the author asking him under what license the code was released.

#2 @scribu
14 years ago

Pretty neat solution.

#4 @Denis-de-Bernardy
14 years ago

  • Keywords needs-unit-tests added

#5 in reply to: ↑ 3 @mdawaffe
14 years ago

Replying to Denis-de-Bernardy:

I'm not too worried if fgetcsv/fputcsv don't quite meet the spec as long as they're each other's inverses and that the JS code is compatible enough. I don't know if either is the case.

I agree it needs unit testing, thanks for the tag.

#6 in reply to: ↑ 1 @mdawaffe
14 years ago

Replying to mdawaffe:

The patch makes use of a slightly modified version of

I've emailed the author asking him under what license the code was released.

Ben Nadel, the author, says the code can be used however WP may like to use it. If WP needs an explicit license, he's happy to give it.

#7 @nacin
14 years ago

  • Milestone changed from Awaiting Review to Future Release

#8 @mau
12 years ago

  • Cc ngomau@… added

#9 @abackstrom
12 years ago

  • Cc abackstrom added

#10 @wonderboymusic
11 years ago

#13606 was marked as a duplicate.

#11 @joehoyle
11 years ago

I am not a fan of this implementation. In my opinion there should be better separation of concerns so the front end is responsible for passing an array of terms to the backend. The current implementation passes the terms as a CSV string (in a textarea) which seems like a total hack - we can pass arrays in POST so let's use that.

This would require changing the tax meta box's javascript to store each term in a separate input with a name like tax_input[post_tag][] rather than parsing a CSV string on the backend.

I am inclined to think including the library is more than necessary, also the patch is so old it doesn't apply as post.js has changed significantly since it was written.

#12 @joehoyle
11 years ago

So, I took a bash at getting this working, which included updating some of the tags JavaScript as it's frankly rather convoluted right now. Rather than having to rely on a storing the current tags in the <textarea> which makes parsing difficult when removing tags etc, it just parses the <textarea> once on page load, and then uses a jQuery data object on the tagsdiv. This means we don't need to do any flushTags or cleaning because the tags are stored in <input type="hidden" /> and also on in the tagsdiv jQuery object.

Here is a quick demo of me using it:

I also had to patch the jQuery Suggest library as it currently doesn't support selecting options that contain the delimiter. I think this is a "bug" with the current library so don't see any issue with the fix I propose.

This is still compatible with JS disabled.

#13 follow-up: @joehoyle
11 years ago

Added some qunit tests and tweak the functionality of removeTag so it removed the hidden <input> field too.

11 years ago

Actually added tags

#14 @bhwebworks
10 years ago

Any progress being made on this?

#15 @iv.dimova
9 years ago

Is there any chance for some progress on this?

#16 in reply to: ↑ description @jbenes
9 years ago

Just a follow up - has anyone had any chance to tackle this? I'm still running into this problem.

#17 in reply to: ↑ 13 @lisota
9 years ago

Replying to joehoyle:

Added some qunit tests and tweak the functionality of removeTag so it removed the hidden <input> field too.

Any way we can get this ticket moving forward? The bug has been around for 5 years and still exists in 4.3.

It is not unreasonable that someone would want to have a taxonomy name with a comma included. Ours is "Asbestos, Mold & Lead Testers". The taxonomy picker still misbehaves when there is a comma, dividing it improperly.

#18 @boonebgorges
9 years ago

  • Keywords needs-refresh added; has-patch needs-testing needs-unit-tests removed

Basic approach seems OK to me, but the patch needs some love in order to apply to trunk.

#19 @mgwhitfield
7 years ago

This ticket is six years old, lol

#20 @piersb
7 years ago

Seven years, now.

#21 @johnbillion
7 years ago

Long running issues such as this one can be very frustrating, but comments such as this one are not productive.

The last patch for this was written four years ago and needs to be updated. If you want this to move forward, a more productive means would be to find somebody to update the patch and ensure it the proposed functionality still works as expected.

#22 @piersb
7 years ago

I wasn't sure how to express my interest in the patch and thus push it to the top of the queue, other than flagging it with a watch and a comment.

This ticket was mentioned in Slack in #core by piersb. View the logs.

7 years ago

#24 @inlate
7 years ago

A use case of comma in tag are names.

In publications name and family name are separated by comma:
Doe, John
Multiple names are separated by a semicolon or other character.

You can have a look at some publication db:
(on the top right try download citation, whatever format)

At present it is very difficult to reproduce the same behavior in Wordpress and not particularly effective hacks are suggested as:

It is my opinion that it is appropriate to have the ability to change the separator, per taxonomy.
Or, even better, the ability to disable the parsing feature, uploading taxonomy one at the time.

Thank you,

Last edited 7 years ago by inlate (previous) (diff)

#25 @boonebgorges
6 years ago

#44525 was marked as a duplicate.

#26 @danielbuth
4 years ago

In addition to custom separators, I second the notion that one should be able to toggle the parsing feature. In fact, there are instances with heavily extended and managed taxonomies, where editors should not be able to register any new terms at all during the edit. I have a bunch of use cases right now, that would – if they were more taxonomy-heavy – quickly evolve into a maintenance race with the authors, ever accelerating as the taxonomy increases in size; and one particular project of mine in the pipeline for 2020 definitely will.

Is there any chance to interest contributors in this? I will be able to help out with anything PHP related (as little as it may be in this case), once I finish reading up on how to use this platform properly.

Until then, here are two suggestions for someone to perhaps pick up:

  • WP_Taxonomy needs a new public $separator = ','.
  • WP_Taxonomy::set_props() needs a new $default 'separator' => ',' in line 255.

On a last note: Is 'needs-refresh' even applicable anymore or should we move straight back to 'needs-patch' at this point?

This ticket was mentioned in Slack in #core by danielbuth. View the logs.

4 years ago

#28 @danielbuth
3 years ago

I can't tend to this issue, and nobody else did so in the meantime. But, I suppose, 13 months after the last Slack mention, it's not too crazy to bump it up once more.

Can someone, who understands this part of WP, please deal with this ancient ticket?

#29 @SergeyBiryukov
2 years ago

#54890 was marked as a duplicate.

#30 @sandn
9 months ago

Just running into this bug after having migrated a database of thousands of academic publications and implementing Authors as a custom taxonomy. Author names being listed ("Lastname, A"). Import went fine of course, now the Editors run into this bug.

Wild that this ticket has been open for 13 years now.

#31 @sitebolts
9 months ago

  • Type changed from enhancement to defect (bug)

A client of ours just ran into this bug as well.

It apparently affects:

  1. The bulk editor (including for other taxonomies like WooCommerce product tags)
  1. The Classic Editor individual post editing screen

It doesn't affect:

  1. The tags page
  1. The Gutenberg individual post editing screen

What's really interesting is that the bulk editor and Classic Editor will both suggest terms with commas in them as if they're a single term, but then they get split into multiple terms once submitted.

Gutenberg, by contrast, recognizes that terms with commas in them are still just a single term and submits them as such, preventing the issue from occurring.

At least it's half-solved in Gutenberg, although Gutenberg still doesn't fix the odd behavior on the bulk editor, so this issue still isn't fully resolved.

I'm voting to reclassify this as a bug since the UI behaves differently on different pages and in a manner that's unintuitive and was very likely an oversight.

#32 @pressworthammer
6 months ago

I just ran into this as well and was honestly quite disappointed that it actually IS an issue in such a mature system.
I created tags like this: "Faculty of Law, Humanities And Social Sciences"
Now when I try to assign that tag to posts (either in Quick Edit or in the Meta Box) it gets populated correctly into the box, but on saving WP obviously separates it at the comma and creates two new tags. I would call that bug or at the very least unexpected behavior. It's impossible to tell all the editors to use &#44; instead of a comma and I'm on the lookout for a workaround for the time being. A simple hook which disables the comma-separation would suffice, but afaik there is none?

Note: See TracTickets for help on using tickets.