Jump to:
| Project: | Taxonomy Defaults |
| Version: | master |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | bradweikel |
| Status: | postponed (maintainer needs more info) |
Issue Summary
In Drupal 7, taxonomy uses the Fields API, which means that taxonomy behaves more or less like a CCK field did in Drupal 6. This has huge implications for the Taxonomy Defaults module, because all Fields already come with the ability to designate default values on a per-content type basis. That's the core function of this module, and its now being done in Drupal core, which really undercuts the value of this module. The only other major feature of Taxonomy Defaults is the ability to force terms onto a content type by hiding the select box in the node/add form, but this is also easily replicated with the taxonomy access module, or whatever field access module will fill that niche in D7.
There are edge cases, of course, and I'm sure I'm overlooking some things, but overall my sense is that the Taxonomy Defaults module's end is near, and that I shouldn't bother with a D7 release. However, please use this issue to discuss any concerns.
Comments
#1
Oh, man, i hope you're right... i don't wanna upgrade to find later that i can't replicate all of the functionalities i have today in 6.x because of these core/contributed questions. I'm sure people are waiting for the release of Drupal 7 to test such functionalities, so they wont bother 'til then.
#2
This functionality is needed in Drupal 7 in a simplified form:
Select a vocabulary -> term on the content type edit page.
The core field default term doesn't work reliably and does not work on multilanguage sites.
The term should be set on a per Content type basis not per node.
Can we get this on 7.x in a barebone version?
#3
Jeffm,
Can you clarify what you mean when you say core defaults don't work "reliably"? Is there something that isn't functioning, and if so is there a bug reported for it yet?
Note: I just saw that you posted a related support request, #1155334: Default term for content type?, and I answered your question there, but I suspect you found that answer on your own already, since your question here is more detailed.
Regarding multilingual support: taxonomy_defaults does not support multilingual sites either, though it does just happen to mesh nicely with some multilingual configurations (but not others).
-----
A general update for Taxonomy Defaults users:
I do not plan to port this module to Drupal 7, because it's primary functionality is now included in Drupal core, and all related subsystems have changed dramatically.
If there is demand for a helper module to assist with D6->D7 I'm open to working on that, but so far I haven't seen any demand.
#4
#5
Well the way it should be is a helper module that allows you to associate a term with a whole content type, regardless of language.
It's very annoying now since you can easily set a term reference like you said, i already did that. However it does not update the already created nodes with the default term value!
And also, internationalization module does not have a working version of field translate, even if it did, i don't think it lets you set a default value per language.
Ontop of that, if you would ignore the issues mentioned above, you will be presented with all available values of a term reference, even if you set the default value. There is no way to limit the amount of terms the end user can choose from.
So you would have to hide the field in the edit form.
It would be much better if we can somehow set up a reference to a single term on the content type edit page that is automatically embedded in all the nodes so to speak.
Maybe it can be done with the node api,
Thanks,
Jeff
#6
it does not update the already created nodes with the default term value
correct, but this is not something that Taxonomy Defaults module has ever done either, nor is it related to differences between Drupal 6 and Drupal 7 taxonomies. Taxonomy Defaults module has always worked by modifying the node/add form or hook_nook_alter for individual nodes as they were created or edited, and has never done bulk editing of existing nodes. For that sort of bulk editing you should look at the Views Bulk Operation module (http://drupal.org/project/views_bulk_operations)
There is no way to limit the amount of terms the end user can choose from - and - So you would have to hide the field in the edit form.
You can easily hide a vocabulary from specific roles with the Field Permissions module (http://drupal.org/project/field_permissions). Taxonomy Defaults for Drupal 6 allows vocabulary hiding, but I always thought it was an ugly solution to begin with so I'm glad that vocabularies are now fields so that code can die off. But that's all at the per-vocabulary level... it kind of sounds like you want per-term control, which is a much different problem. I've never thought about it, but I know it doesn't belong in this module.
internationalization module does not have a working version of field translate
It will...
even if it did, i don't think it lets you set a default value per language.
I'd suggest you take that up in the i18n issue queue or start a new contrib module just for that feature -- it's self-contained and seems solvable, but it has no place in Taxonomy_Defaults -- it should be solved at a more general level for fields, not just taxonomy.
----
Point is, there is nothing that the Taxonomy Defaults module already does that isn't more effectively done in D7 through core or other (stronger) contrib modules. Not to be negative, but a laundry list of limitations of other modules isn't going to change the fact that the Taxonomy Defaults module's primary purpose has been absorbed by core, and all its secondary purposes are solvable in other ways.
#7
OK Brad,
Thanks alot for the information. I will see if there is a suitable work around for my problems.
Good luck to you.