[UX] Allow bulk-adding/editing vocabulary terms and menu items.

[klonos]

As it is right now, it is very tedious to add multiple terms to a vocabulary, because you have to add one term at a time, and each time requires a page load and an additional click to add another term (#1004). I did a bit of research, and the only ways that I found for adding multiple terms is either a) by importing CSV/XML files or b) using a text area instead of a text field.

IMO the import way is not suitable for core, but a simple UI would be a great addition. I looked at various modules like Taxonomy Batch Operations (only D4/5 versions and issues about porting to D6/7 that never flourished) and Manage Multiple Terms as well as the popular Taxonomy Manager and the way they do things while having in mind that if we are to get something into core, it'd have to be very minimal/simple. Here's a few ideas what I think might work...

1. Keep the current way of one term, one single term name text field.
2. Add a "Create multiple terms" button/link next to the the term "Name" text field that converts it to a text area (related?: #684). That text area would work the same way that the select list field form works (allows to add one value per line, in the format key|label): add values/entries one per line, in the format term_name|term_description|term_extra_field - the rest of the form settings (parent/URL alias) could apply to all terms entered in the text area.
3. If we need to specify different parents per entry, we could do what Taxonomy Manager does: Child terms can be prefixed with a dash - (one dash per hierarchy level).

1. ...or we could use a similar UI/mechanism as Options Element:

These are and/or things that we could implement. They are not 100% original ideas and I have not come up with the perfect way to do it either - just saw the need and though that we could discuss/brainstorm and see if we can come up with something as good and the Layouts UI.

[docwilmot]

I agree that adding terms one by one is usually unacceptable. I'm thinking though that terms are entities just like nodes etc so it would be great if any method of bulk adding terms could be adaptable as an API to bulk add entities.

Terms are unique there in that you usually have to add multiple, so probably just expose this new API to the UI for terms.

[klonos]

Terms are unique there in that you usually have to add multiple...

Same goes for options in select lists. It's not that common to have those with only one or two options - usually there's multiple of them.

[docwilmot]

Yep agreed, and I agree with options element as a good UI for adding multiple anythings in Backdrop.

But I meant the code that takes the typed in terms from options element (or textarea or whatever) and converts them into term entities could be made generic enough to also mass create other entities too.

[klonos]

In that case, your opinion would be much appreciated in the more generic #1005 because @quicksketch asked for more views on the mater.

[jenlampton]

I'm adding the contrib candidate label because I'm not sure this is an 80% use-case, but would make a great contrib module (I believe there are already a handful from Drupal that we could port?). Adding needs more feedback label because it would be great to get some more opinions.

[docwilmot]

Youre right: pretty sure this is near a 100% use case. 😄 Who ever adds one taxonomy term?

[jenlampton]

Well, who ever adds only one node? Adding more than one is a 100% use-case too, but we'd never add a bulk-create form in core. It's the same reason here.

The same goes for menu items. Who ever adds only one menu link?

I was talking about wanting to add them all on a single page. That's what is rare.

[docwilmot]

Maybe I shouldnt have put the smiley. The difference of course, is that those other entities 80% of the time require configuring before clicking that save button. Nodes might need fields and full stops and images and whatnot; menus need paths and titles and whatnot. 90% of the time a taxonomy term needs one word in that textarea and you're done.

Pretty sure I'm not alone in thinking that is a perfect scenario for a bulk form. And pretty certain wanting to add them all on a sinlge page is near universal.

[jenlampton]

90% of the time a taxonomy term needs one word in that textarea and you're done.

I'm not finding this to be the case in either Drupal 7 or Backdrop. On most of my sites the only terms that are a single word are tags, and those are added as part of the creation of other content (so, not usually in bulk). Can you provide some real-world examples? @klonos, you too, if you have some you can share :)

[klonos]

@jenlampton I cannot think of any use cases at the moment, but a generic and rather common pattern is that taxonomy term fields are often (mis/ab)used in the place of select lists. I think this is mainly because we have separate/granular permissions to edit/delete terms per vocabulary, which makes it easy/safe to delegate the task of populating/editing the options of taxonomy-generated select fields; while editing the options included in a select list field provided by the Field module requires far more "permissive" setups.

One thing to consider here is that although all vocabularies come with a "Description" field added by default, and although they also have the ability to have more fields added to them, the 80%(+) use cases according to my experience are as @docwilmot described:

Nodes might need fields and full stops and images and whatnot; menus need paths and titles and whatnot. 90% of the time a taxonomy term needs one word in that textarea and you're done.

[klonos]

...I think that we should provide the same UI to allow bulk-creating/editing menu items as well. In D7, there's https://www.drupal.org/project/menu_editor, which does a pretty good job:

This is practically the same UI as the newly-added Options Element (#1005), with the added feature to be able to drag items left/right in order to configure nesting.

We do not need to be exposing all fields (the description field for example can be excluded), and we could also retain the current term UI and menu link UI; just add this new UI as a separate tab (the contrib module calls is "power edit", we can call it "bulk edit" instead).

[jenlampton]

A separate UI should definitely be a contrib module.

On Mon, May 27, 2019, 2:45 PM Gregory Netsas notifications@github.com wrote:

...I think that we should provide the same UI to allow bulk-creating/editing menu items as well. In D7, there's https://www.drupal.org/project/menu_editor, which does a pretty good job:

[image: Screen Shot 2019-05-28 at 7 35 19 am] https://user-images.githubusercontent.com/2423362/58440194-c7575400-811b-11e9-9082-02be33f9ee12.png

This is practically the same UI as the newly-added Options Element (#1005 https://github.com/backdrop/backdrop-issues/issues/1005), with the addition to be able to drag items left/right in order to configure nesting.

We do not need to be exposing all fields (the description field for example can be excluded), and we could also retain the current term UI and menu link UI; just add this new UI as a separate tab (the contrib module calls is "power edit", we can call it "bulk edit" instead).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1006?email_source=notifications&email_token=AADBER5ATUL64SAN47VDPO3PXRI57A5CNFSM4BIH7M42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWKRRXQ#issuecomment-496310494, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBER47L6FCHHHXXQCI7GLPXRI57ANCNFSM4BIH7M4Q .

[jenlampton]

I would rather fix the ux problem with people misusing tags for something that's shouldn't really be tags than rework something that might not really need a fixing. Can we open an issue about that, too?

On Mon, May 27, 2019, 2:36 PM Gregory Netsas notifications@github.com wrote:

@jenlampton https://github.com/jenlampton I cannot think of any use cases at the moment, but a generic and rather common pattern is that taxonomy term fields are often (mis/ab)used in the place of select lists. I think this is mainly because we have separate/granular permissions to edit/delete terms per vocabulary, which makes it easy/safe to delegate the task of populating/editing the options of taxonomy-generated select fields; while editing the options included in a select list field provided by the Field module requires far more "permissive" setups.

One thing to consider here is that although all vocabularies come with a "Description" field added by default, and although they also have the ability to have more fields added to them, the 80%(+) use cases according to my experience are as @docwilmot https://github.com/docwilmot described:

Nodes might need fields and full stops and images and whatnot; menus need paths and titles and whatnot. 90% of the time a taxonomy term needs one word in that textarea and you're done.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1006?email_source=notifications&email_token=AADBER3KKP2HXZ7KXFLMPJ3PXRH4FA5CNFSM4BIH7M42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWKRJYI#issuecomment-496309473, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBER65D4ZUNHZVHNCTBPLPXRH4FANCNFSM4BIH7M4Q .

[olafgrabienski]

taxonomy term fields are often (mis/ab)used in the place of select lists

fix the ux problem with people misusing tags for something that's shouldn't really be tags

Using term fields "in the place of" select lists, isn't wrongful even if there might be a ux problem with select lists. Using term fields is just a more flexible approach, in my opinion. (I'm not intending to give a pro or a con statement regarding bulk-adding terms.)

[jenlampton]

I still think maybe we should look into making select options more flexible if thats an issue.

On Tue, May 28, 2019, 1:20 AM Olaf Grabienski notifications@github.com wrote:

taxonomy term fields are often (mis/ab)used in the place of select lists

fix the ux problem with people misusing tags for something that's shouldn't really be tags

Using term fields "in the place of" select lists, isn't wrongful. It's a more flexible approach, in my opinion. (I'm not intending to give a pro or a con statement regarding bulk-adding terms.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1006?email_source=notifications&email_token=AADBER5UKDGJ7YUVVGHS3WLPXTTMRA5CNFSM4BIH7M42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWLLA6I#issuecomment-496414841, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBER2PJM5XYDEHWUDPQXLPXTTMRANCNFSM4BIH7M4Q .

[docwilmot]

Can you provide some real-world examples I cannot think of any use cases at the moment,

The use-case here is any taxonomy that isn't tags. If you want to categorize anything, say product colors in a shop, you have to manually add terms. In all cases you will already know the terms you want to add (blue, red, orange, green, black). With the current UI, type "blue" submit, type "red" submit, ad nauseum.

And this is the case for every taxonomy except tags.

I have never not wished that I could just type all of these in bulk.

And I actually feel this is better in core; requiring installing a contrib module for a single use event like this seems bad UX. Its usually that you create the taxonomy with the contrib module then uninstall it, because its of course no longer necessary.

I still think maybe we should look into making select options more flexible

Options element just uses JS to make a bulk-add textarea look like a list; we'd still need a textarea that accepts bulk adding, so thats the decision I think we need to make first.