Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#14 | vocabulary_node_type_form-394482_3.patch | 2.94 KB | Bojhan |
#11 | vocabulary_node_type_form-394482_2.patch | 2.66 KB | derhasi |
#11 | vocabulary_on_content_type_edit_2.png | 21.97 KB | derhasi |
#6 | before_vocabulary_on_node_type_form.png | 38.01 KB | derhasi |
#6 | vocabulary_on_content_type_edit.png | 58.54 KB | derhasi |
Comments
Comment #1
derhasi CreditAttribution: derhasi commentedAdded this functionallity with attached patch.
* additional taxonomy fieldset via
taxonomy_form_alter
* additional #submit function saving vocabulary data
Comment #2
tic2000 CreditAttribution: tic2000 commentedWhat 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.
Comment #3
derhasi CreditAttribution: derhasi commentedtic2000, 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.
Comment #4
Dries CreditAttribution: Dries commentedBefore and after screenshot for our non-technical friends?
Comment #5
tic2000 CreditAttribution: tic2000 commentedOne minor problem. The documentation standard (at least for now) says that it should be "Implement" not "Implementation of"
Comment #6
derhasi CreditAttribution: derhasi commentedSome screens...
Comment #7
Bojhan CreditAttribution: Bojhan commentedYes - I think we can make the label better, so that we don't need the description.
Comment #8
derhasi CreditAttribution: derhasi commentedSo instead of simply "Vocabularies", something like...
* Vocabularies for node terms.
* Vocabularies for node tagging.
* Active vocabularies for node term selection.
?
Comment #9
Bojhan CreditAttribution: Bojhan commentedWhat 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
Comment #10
Bojhan CreditAttribution: Bojhan commented*Vocabularies enabled on content creation.
Let's go with this one for now.
Comment #11
derhasi CreditAttribution: derhasi commented* Changed to "Vocabularies enabled on content creation"
* removed #description
* Corrected documentation to "Implement ..."
Patch and new screen attached
Comment #12
derhasi CreditAttribution: derhasi commentedComment #13
tic2000 CreditAttribution: tic2000 commentedThe only nitpicking I would have is to change $voc to $vocabulary.
Comment #14
Bojhan CreditAttribution: Bojhan commentedOk, changed it.
Comment #15
tic2000 CreditAttribution: tic2000 commentedNow $vocabularies became $vocabularyabularies.
Comment #16
Bojhan CreditAttribution: Bojhan commentedJeez, 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.
Comment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedHey 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:
Comment #18
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #19
tic2000 CreditAttribution: tic2000 commented@Bojhan it's 1 minute if you have a clean HEAD, I didn't have one so I just posted my review.
Comment #20
Bojhan CreditAttribution: Bojhan commented@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?
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedBojhan:
It's not a completely different direction at all. There are just contingencies.
I had two points:
(one point is unfortunately bigger and wordier than the other, which is why i'm probably not a usability guy.)
Comment #22
Bojhan CreditAttribution: Bojhan commentedSo how would this look?
Comment #23
derhasi CreditAttribution: derhasi commented@bangpound:
as the whole vocabularyies are allready loaded via
taxonomy_get_vocabularie()
and there is allready aforeach
, 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?
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedderhasi:
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.
Comment #25
Anonymous (not verified) CreditAttribution: Anonymous commentedLet'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.
Comment #26
yoroy CreditAttribution: yoroy commentedbangpound: please post a link to the issue you're postponing this on so we may track it's status here as well.
Comment #27
Anonymous (not verified) CreditAttribution: Anonymous commented#491190: Provide a taxonomy term field type
Comment #28
Bojhan CreditAttribution: Bojhan commentedObviously this is active, anyone tried adding a vocabulary? Its pretty complex.
Comment #29
derhasi CreditAttribution: derhasi commentedI'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.
Comment #30
xjmComment #31
jibranThe 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.
Comment #32
xjmI 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.