Allow commas in tag names

[mdawaffe]

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.

"double""quote"

This may also help with #7897.

[mdawaffe]

The patch makes use of a slightly modified version of ​http://www.bennadel.com/blog/1504-Ask-Ben-Parsing-CSV-Strings-With-Javascript-Exec-Regular-Expression-Command.htm

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

[scribu]

Pretty neat solution.

[Denis-de-Bernardy]

​http://bugs.php.net/bug.php?id=50686

[mdawaffe]

Replying to Denis-de-Bernardy:

​http://bugs.php.net/bug.php?id=50686

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.

[mdawaffe]

Replying to mdawaffe:

The patch makes use of a slightly modified version of ​http://www.bennadel.com/blog/1504-Ask-Ben-Parsing-CSV-Strings-With-Javascript-Exec-Regular-Expression-Command.htm

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.

[wonderboymusic]

#13606 was marked as a duplicate.

[joehoyle]

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.

[joehoyle]

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.

[joehoyle]

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

[joehoyle]

Actually added tags

[bhwebworks]

Any progress being made on this?

[iv.dimova]

Is there any chance for some progress on this?

[jbenes]

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

[lisota]

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.

[boonebgorges]

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

[mgwhitfield]

This ticket is six years old, lol

[piersb]

Seven years, now.

[johnbillion]

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.

[piersb]

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.

[inlate]

A use case of comma in tag is 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:
​http://porto.polito.it/view/creators/
​https://www.researchgate.net/publication/291754505_InViTo_An_interactive_visualisation_tool_to_support_spatial_decision_processes
(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:
​https://wordpress.stackexchange.com/questions/25043/how-can-i-allow-commas-in-tag-names

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,
Riccardo

[boonebgorges]

#44525 was marked as a duplicate.

[danielbuth]

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?

[danielbuth]

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?

[SergeyBiryukov]

#54890 was marked as a duplicate.

[sandn]

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.

[sitebolts]

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)

2. The Classic Editor individual post editing screen

It doesn't affect:

1. The tags page

2. 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.

[pressworthammer]

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 , 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?

[desrosj]

#60125 was marked as a duplicate.