At the University of Baltimore we saw several users go to edit their content type to try and enable a vocabulary. Currently users cannot enable vocabularies from this page.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

derhasi’s picture

Assigned: Unassigned » derhasi
Status: Active » Needs review
Issue tags: +d7uxsprint
FileSize
2.64 KB

Added this functionallity with attached patch.
* additional taxonomy fieldset via taxonomy_form_alter
* additional #submit function saving vocabulary data

tic2000’s picture

What is vocabularies_old for? I don't see it being used in the code so why is there?
I could see it useful if we check that the vocabulary will actually change (it's added now to the node type, or it was removed from the node type) before saving the vocabulary. Otherwise we do a save that doesn't change nothing.

derhasi’s picture

tic2000, you are right. That's redundant data. I used it for comparison in my first approach, but don't need it anymore. I changed it, and also moved the form to FORMI-form_alter (taxonomy_form_node_type_form_alter), as the old form was only a pseudo-form-function.

Patch attached.

Dries’s picture

Before and after screenshot for our non-technical friends?

tic2000’s picture

One minor problem. The documentation standard (at least for now) says that it should be "Implement" not "Implementation of"

derhasi’s picture

FileSize
58.54 KB
38.01 KB

Some screens...

Bojhan’s picture

Yes - I think we can make the label better, so that we don't need the description.

derhasi’s picture

So instead of simply "Vocabularies", something like...

* Vocabularies for node terms.
* Vocabularies for node tagging.
* Active vocabularies for node term selection.
?

Bojhan’s picture

What about.

*Vocabularies enabled on content form.
*Vocabularies enabled on content creation.

I am thinking the last one is the best, but this will need some feedback

Bojhan’s picture

Status: Needs review » Needs work

*Vocabularies enabled on content creation.

Let's go with this one for now.

derhasi’s picture

* Changed to "Vocabularies enabled on content creation"
* removed #description
* Corrected documentation to "Implement ..."

Patch and new screen attached

derhasi’s picture

Status: Needs work » Needs review
tic2000’s picture

The only nitpicking I would have is to change $voc to $vocabulary.

Bojhan’s picture

Ok, changed it.

tic2000’s picture

Now $vocabularies became $vocabularyabularies.

Bojhan’s picture

Jeez, I just replaced wrong. I am sorry, but I fully understand nitpicking - but it doesn't really aid me if you say I made a mistake you can fix by posting a new patch in like 1 minute.

Anonymous’s picture

Status: Needs work » Needs review

Hey Bojhan:

This patch mimics the current vocabulary admin form's handling of node types but from the opposite direction in terms of UI context. The latest patch on #412518: Convert taxonomy_node_* related code to use field API + upgrade path shows how I've tried to use the current vocab admin form to trigger creation of field instances, though I admit it is a bit out of date. As soon as #491190: Provide a taxonomy term field type lands, this patch will be easy to rewrite. The submit handler will only need to create or delete field instances instead of saving vocabulary data. That's not important now, but (I hope) it will be important very soon.

We chatted in IRC, so I wanted to reiterate that I appreciate the usability goals of this issue. I'm not raising these other issues to say "this is a bad idea" but rather to say "there are other issues that are immediately relevant." I would be dismayed if term fields landed and Drupal's UX experts and contributors were caught by surprise by the changes it brings.

In the meantime, taxonomy_get_vocabularies() takes a node type argument and returns an identically formatted array. I think this patch could be shorter and avoid some of these local variables if it did something like this:

function taxonomy_form_node_type_form_alter(&$form, $form_state) {
  if (isset($form_state['args'][0]->type)) {
    $node_type = $form_state['args'][0]->type;
    $vocabularies = taxonomy_get_vocabularies();
    // Only show vocabulary fieldset, when vocabularies exist.
    if (count($vocabularies)) {
      $options = array();
      foreach ($vocabularies as $vocabulary) {
        $options[$vocabulary->vid] = $vocabulary->name;
      }
      $form['taxonomy'] = array(
        '#title' => t('Taxonomy'),
        '#type' => 'fieldset',
        '#collapsible' => TRUE,
        '#collapsed' => TRUE,
        '#tree' => TRUE,
      );
      $form['taxonomy']['vocabularies'] = array(
        '#title' => t('Vocabularies enabled on content creation'),
        '#type' => 'checkboxes',
        '#multiple' => TRUE,
        '#default_value' => array_keys(taxonomy_get_vocabularies($node_type)),
        '#options' => $options,
      );
      $form['#submit'][] = 'taxonomy_node_type_form_submit';
    }
  }
}
Anonymous’s picture

Status: Needs review » Needs work
tic2000’s picture

Status: Needs review » Needs work

@Bojhan it's 1 minute if you have a clean HEAD, I didn't have one so I just posted my review.

Bojhan’s picture

@tic2000 It's oke, just personally got annoyed by the 1 word nitpicking reviews without a patch. No problem. But I think @bangpound is suggesting a completely different direction. Do you have a screenshot bangpound?

Anonymous’s picture

Bojhan:

It's not a completely different direction at all. There are just contingencies.

I had two points:

  1. When taxonomy vocabularies are fields (called term fields) on nodes instead of a vague 'taxonomy' property that nodes pick up through nodeapi, the taxonomy_vocabulary_node_type table goes on the chopping block. Field API will become responsible for knowing which vocabularies (expressed as term fields) connect to which node types. We can still implement this usability goal using field API functions which are actually easier to write than these vocabulary object loops and taxonomy_vocabulary_save calls. I linked to some code I've written that already does this with the current Vocab admin UI, and it's even easier to "invert" it for the content type admin form.
  2. Your code can be streamlined. See my use of '#default_values' => array_keys(...).

(one point is unfortunately bigger and wordier than the other, which is why i'm probably not a usability guy.)

Bojhan’s picture

So how would this look?

derhasi’s picture

@bangpound:
as the whole vocabularyies are allready loaded via taxonomy_get_vocabularie() and there is allready a foreach, I'd avoid a second loop.

general:
when using taxonomy term via field there could be mutlipe fields using in one content type, that use the same vocabulary ... -is that right?- so we can assign one vocabulary multiple times to a content type, and cannot determine which existing field shall be used or a new field has to be created. So I guess there would not be a opportunity to determine how to link "vocabulary to content type".
Is there allready an approach for that?

Anonymous’s picture

derhasi:

That's an important question. We will have the opportunity to make multiple term fields of the same vocabulary on the same node type. However, each new vocabulary will trigger the creation of a new term field, and this "automatic" term field will be the one whose values are used to generated taxonomy/term/[tid] pages. For now, we're looking at using these "automatic" term fields as the well-lit path for "Drupal 6 taxonomy in Drupal 7." These fields provide the familiar "classification" feature of Drupal taxonomy.module.

Like all fields, we can't have multiple term fields instances of the same term field on a node type. Users will have to create new fields for the same vocabulary if they need to use the same vocabulary twice on the same node. Other term fields like that would not/could not be managed by this array of checkboxes.

Anonymous’s picture

Status: Needs work » Postponed

Let's postpone this for a few days until Term module is committed. Then we can talk about concrete problems.

I think this problem is an important one to think about because it complicates the way fields are/could be used in Drupal as content, as functions and as architecture.

yoroy’s picture

bangpound: please post a link to the issue you're postponing this on so we may track it's status here as well.

Anonymous’s picture

Bojhan’s picture

Status: Postponed » Active

Obviously this is active, anyone tried adding a vocabulary? Its pretty complex.

derhasi’s picture

Assigned: derhasi » Unassigned

I'm sorry I could not contribute to this post anymore. At the moment I'm running out of time. I will return in a few weeks, but meanwhile, maybe someone else will assign this issue.

xjm’s picture

Version: 7.x-dev » 8.x-dev
jibran’s picture

Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update

The workflow is completely changed in D8 so IMHO this is not an issue anymore. But I might be wrong so moving it postpone (maintainer needs more info) and issue summary could use some love.

xjm’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

I think this should be a wontfix; this is just a specific subset of the usability issue that users might not understand how to move on to adding fields after they create a content type. It would be strange to suddenly couple content type creation to taxonomy again. The expectation changed between D6 and D7, but it's now been this way for many years in D7, and the patch has also not seen activity for six years either.

I think a better solution would be general usability improvements for the content creation and field adding workflow -- tours, UI fixes, etc. -- as well as possibly information on the Entity reference form about how to add new bundles. So let's file new issues for those things instead if this comes up again in usability testing with D8.