Create taxonomy fields from the taxonomy administration page

Not really a bug more a task.

+1.

The UI for taxonomy took a big step back with D7, albeit for considerably more power.

Sorry but this isn't a bug in the sense of a straight regression from Drupal 6.

If we'd tried to make taxonomy vocabulary forms simpler but ended up making them worse it would be, but instead what we did was replace that part of the form entirely with a generic UI - i.e. field UI.

That means there's the following actionable responses to this issue:

1. Remove field UI from core.
2. Add back a custom taxonomy UI in addition to the field UI (IMO this would be a regression from 7 since it would be less learnable/consistent with the rest of core - if you want to do that I as taxonomy module maintainer would consider it won't fix).
3. Add form builder to core so the workflow can be inverted (you add term reference fields to a node form, possibly creating vocabularies in-line).
4. #28480: Create generalized relationship module - although that makes this even more generic, although in combination with #3 it might end up being a net improvement from a usability point of view (it'd definitely unify a lot of code).

...really?

That looks rather over the top.

Surely all you'd need is:

- set of ticky boxes for node types in the taxonomy vocab edit form
- on submit, automatically create/update a termref field called field_taxonomy_VOCABNAME, and add instances of that to those node types

There's no need to rip anything out at all.

Even to someone coming to Drupal fresh on D7, you have to admin that applying a vocabulary to a node type is a really long-winded process.

That's option #2. What happens when that same user visits the field UI and sees a completely different UI for doing exactly the same thing?

Even to someone coming to Drupal fresh on D7, you have to admin that applying a vocabulary to a node type is a really long-winded process.

No different to creating a node type that's going to be used in a node reference field though is it?

subscribing

> No different to creating a node type that's going to be used in a node reference field though is it?

True. But that wasn't a workflow in core in D6 -- and for that matter, nor is it on D7!

What's happened here could be termed a usability regression. (And perhaps we should think of a way to fix it that also works for improving the workflow for other reference fields in contrib.)

If #28480: Create generalized relationship module gets in core in D8, then it will be important to have a UI solution that covers all relationships

Given it really doesn't look like this will get fixed in D7, I made this: http://drupal.org/project/field_tools.

#1347448: [META] Taxonomy admin usability Improvements looks to be a more holistic look at the entire taxonomy administrative experience, so I'm marking this one as a duplicate.

Ok in that case let's make this a sub-issue of that one and sharpen it :)

That's cool, but then this is no longer major. The other task is.

I'm actually thinking that the thing to do would be to put a dropbutton operation for creating a field at admin/structure/taxonomy. Brainstorming some possible labels for the operation:

• Add 'vocabname' to...
• Add as a field
• Create a taxonomy field
• Add to content type
• etc.

Following #631038: Add Manage Fields and Manage Display links to the vocab dropbutton and #1340500: Merge "list terms" page into "edit vocabulary" page, this would look something like:

Then:

1. The user selects the dropbutton.
2. The dropbutton pre-selects the correct field type and bundle for a taxonomy ER field, and then takes the user into a modified field UI workflow.
3. The user selects the bundle to add the field to. We could restrict this to nodes as the 80% case and let ER via the field UI be responsible for fielding other entity types, or we could use #states to first select a fieldable entity type, and then the bundle.
4. The user enters the field label, widget, and other field settings (only the # values probably) on the same form, and submits. (This is a change I'd like to make in the regular Field UI as well, but that's another issue.)
5. The user is then taken to the normal field instance configuration page. The correct ER reference type/method and bundle are pre-selected, or even hidden.
6. The user submits the field instance form and is redirected to the manage fields page for the appropriate content type (or other bundle if we opt to add to more than content.)

Filed #1963340: Change field UI so that adding a field is a separate task.

Related: #1956134: Provide helpful editing links on "admin/structure/block" for deriver blocks (menu, views, block content, etc.)

Wouldn't #394482: Users should be able to enable a vocabularly from the content type configuration page render this redundant? ...well, unless we want to enable people to do the same thing from two different places I guess. Is that desirable?

If we decide to go with one, I favor #394482: Users should be able to enable a vocabularly from the content type configuration page over this one here.

The rest of the time you are configuring the fields and their display, not adding new ones.

I disagree, I add new fields about as often as I configure them and their display.

Part of the goal here is to resolve the problem of "I made this thing, now where does it go?" like we also have for things like menu blocks.

Manage fields / Manage display now happens on a higher level, therefor people will be better able to connect the dots that this is a fieldable thing.

Hmm, not really... The conceptual problem--and the reason I struggled with a good name for this operation--is that this is both fieldable and also supplies a field. "Manage fields" for the taxonomy vocabulary is managing fields that appear on the form when creating taxonomy terms in that vocabulary. This option is an option to apply a field to a different entity/bundle, like a content type.

If we decide to go with one, I favor #394482: Users should be able to enable a vocabularly from the content type configuration page over this one here.

The problem with #394482: Users should be able to enable a vocabularly from the content type configuration page is that it special-cases a specific kind of field on the content creation form, circumventing the field UI, and it also special-cases a particular entity type (nodes) when taxonomy fields can be added to any fieldable entity. Maybe we decide that that is worthwhile, but I'm personally a bit uncomfortable with it, especially since it wasn't there in D7.

This solution, on the other hand, is generic, so I'd prefer to do something like this to "close the loop" and to make entity reference fields less baffling by skipping past unneeded complexity that most of the time the user does not care about. Sort of analogous to the Views Wizard vs. the full Views UI. But the goal is to help the user get from the process of creating a vocabulary to the step of adding it to something else.

Edit: If it's too confusing to have multiple entry points, or too confusing to handle both fielding for this and making this a field for something else from the same point, that's fine. But in the past we've discussed multiple entry points as one solution to the underlying problem.

I would maybe want to tweak some small details, like maybe "Apply 'Tags' to..." rather than "Add Tags to...", but generally I think this is a very good proposal.

Ooh, "Apply" is a good word, because it's clearly distinct from any of the CRUD terminology.

I've made a proof of concept of this as a sandbox project: https://www.drupal.org/sandbox/joachim/2728879

This still a valid task?