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.
Hi,
I've added a new vocabulary and term reference field on a content type. I can't select the vocabulary, the select list looks disabled with the first vocabulary selected (first vocabulary in the vocabulary list ordered alphabetically).
The select list when adding a new node is empty.
Using latest dev version of mongodb module and drupal 7.2
Comments
Comment #1
ronsnow CreditAttribution: ronsnow commented...operator error....
Comment #2
lurkingbeast CreditAttribution: lurkingbeast commentedI see this too, it has something to do with field_has_data function. I'm not sure whether it's mongodb field storage module which should return something else on this query or what, I didn't have time to look into this further.
I resorted to an annoying hack, when I want to add or edit a taxonomy term reference field, I edit the modules/field_ui/field_ui.admin.inc in two places:
// $has_data = field_has_data($field);
$has_data = FALSE;
and then after choosing the vocabulary I revert the code.
Would be great if someone would point in the right direction where the problem lies.
Comment #3
MiSc CreditAttribution: MiSc commentedThis is still an issue, I changed status to critical - because this issue make mongodb not usable for storing taxomomy entities.
Comment #4
lurkingbeast CreditAttribution: lurkingbeast commentedOn a related note, I made a small change to core taxonomy.module to allow taxonomy index to be updated correctly when using mongodb for taxonomy entities (just quick advice, no patch):
in
function taxonomy_field_insert($entity_type, $entity, $field, $instance, $langcode, &$items) {
and
function taxonomy_field_update($entity_type, $entity, $field, $instance, $langcode, &$items) {
replace first line with
Comment #5
MiSc CreditAttribution: MiSc commentedGood point lurkingbeast, just stumbled over that problem. Added patch for your fix. By the way - do you store the index in mysql or mongodb?
Comment #6
MiSc CreditAttribution: MiSc commentedThe path was not generic, adding a new.
Comment #7
MiSc CreditAttribution: MiSc commentedSorry, again, hopefulle this one would work more correct
Comment #8
lurkingbeast CreditAttribution: lurkingbeast commentedIn my case the index is stored in mysql.
Comment #9
drupik CreditAttribution: drupik commentedWhat about Drupal 7.12?
Based on this patch, I changed line 1773 from taxonomy.module
if ($field['module'] == 'taxonomy' && $field['storage']['type'] == 'field_sql_storage') {
to
if ($field['module'] == 'taxonomy' && $field['storage']['type'] == 'field_sql_storage' || $field['storage']['type'] == 'mongodb_field_storage') {
but error in SQL
So I changed also line 1788:
$tid_all[$item['tid']] = $item['tid'];
to
$tid_all[$item['tid']->tid] = $item['tid'];
Now terms saving, but still have error:
Comment #10
drupik CreditAttribution: drupik commentedTake taxonomy.module from D7.10, patched and voila :)
Comment #11
MiSc CreditAttribution: MiSc commentedHm, I do not think that you should hack so much that you use old versions of modules ;-). We have to look into this issue.
Comment #12
kalmarzs CreditAttribution: kalmarzs commentedUnfortunately I have the latest modules and core, however I have the same issue. I will try the patch and report back with the results.
Comment #13
lurkingbeast CreditAttribution: lurkingbeast commentedSeems that for 7.12 they have reorganized the taxonomy code a bit, I did this:
In
function taxonomy_build_node_index($node)
if ($field['module'] == 'taxonomy' && ($field['storage']['type'] == 'field_sql_storage' || $field['storage']['type'] == 'mongodb_field_storage')) {
Appears to work. It's good to see work going on with this module.
Comment #14
MiSc CreditAttribution: MiSc commentedPatch for solution for d7 in comment #13 attached
Comment #15
MiSc CreditAttribution: MiSc commentedComment #16
MiSc CreditAttribution: MiSc commentedI started work on putting the taxonomy_build_node_index stuff inside mongodb_module so we do not have to patch a core module when we want to have that with the Mongodb backend - a couple of questions:
* Should this index be stored in Mysql or Mongodb?
* Should it be in the field_storage_module, seperate or somewhere else?
For the original issue here, solved in comment #2 with patch of core module, I will start work to try to get this inside the Mongodb module also.
Comment #17
MiSc CreditAttribution: MiSc commentedFirst patch of implementing index in the Mongodb module - this is stored in Mysql.
Comment #18
Janne Salo CreditAttribution: Janne Salo commentedI've been using the taxonomy index patch (in #17) for a while now. It seems to work ok for new nodes, but node updates delete data from the taxonomy_index table. This is because taxonomy.module runs taxonomy_delete_node_index() and taxonomy_build_node_index() on node updates. The former (obviously succeeds) but the latter doesn't, since the storage type of my node's field isn't field_sql_storage. Now, this is exactly the problem the above patch is for, but it falls a bit short since taxonomy.module's node_update hook is run after mongodb_field_storage's node_update. Which is inconvenient because it deletes the rows mongodb_field_storage just inserted but doesn't insert anything on its own (because of the storage type check).
An easy solution would be to just increase mongodb_field_storage's weight by 1.
a) Do you feel this is the best possible solution (or at least good enough)?
b) If yes, should we automatically increase the weight of the module in, say, hook_install() or hook_enable()?
Other than this, the patch seems to work just fine.
Comment #19
MiSc CreditAttribution: MiSc commentedFor the original issue raised in this issue, solution is committed to latest dev, see #1547198: field_has_data() will always return TRUE.
Comment #20
MiSc CreditAttribution: MiSc commentedRenamed, because of two different issues raised here, the first one, is solved, see comment #19, the second one (comment #4 - latest patch in comment #17) is still waiting to be fixed..
Comment #21
firebird CreditAttribution: firebird commentedJanne, the current best practices call for the use of hook_module_implements_alter() instead of juggling weights. See http://api.drupal.org/api/drupal/modules!system!system.api.php/function/... .
Comment #22
sarhugo CreditAttribution: sarhugo commentedModified version of #17 implementing hook_module_implements_alter(). Also removed the deletion from taxonomy_index table. It should be made by the taxonomy module, so if there are some fields with sql storage then these are preserved.
Comment #23
sarhugo CreditAttribution: sarhugo commentedSorry, just found a bug at the previous patch. I removed the hook_node_delete implementation without removing from the hook_module_implements_alter.
Attached a fixed version
Comment #24
MiSc CreditAttribution: MiSc commentedThanks @sarhugo, patch works as it should, but the coding standards are not followed, could you please update the patch with the current coding standards?
Comment #25
sarhugo CreditAttribution: sarhugo commentedFixed the wrong indenting
Comment #26
chx CreditAttribution: chx commentedI need to know why this is critical and why do we even want to populate an SQL table when all work is done to move away from any SQL storage? Where is this table used that you see it as useful? Please consider the entity controller code lying around which marks my intention to entirely remove entities from SQL.
Comment #27
MiSc CreditAttribution: MiSc commentedI do not think this is critical (but the possibility to choose a vocabulary was), but this just make the core indexing of taxonomy terms work - my first patch suggestion is just a quick fix for that. I mark this as normal.
Comment #28
fgm@chx: The patch itself may or may not be the best implementation, but filling "something like" {taxonomy_index} enables taxonomy pages to point back to any nodes containing a term reference to the chosen term, whichever the field. This is something that is not implemented in core is taxonomy_index, nor with entityreference pages, with which any backlink from a taxonomy term is via a specific field, not across all fields and instances pointing to that term.
So there /is/ a use case. But there are other ways to implement it.
Comment #29
chx CreditAttribution: chx commentedWhat about providing the taxonomy pages via efq_views? I suspect it's easy by now.
Comment #30
MiSc CreditAttribution: MiSc commentedI think it should be important to have so much functionality as possible from core that works the same when we have mongodb field storage, so modules that uses the same functionality does not brake when it uses another backend.
Comment #31
fgmMaybe I'm missing something, but EFQ (and hence) EFQ_Views will still need manual selection of the fields used to build the references, or code to build the view dynamically based on current field_info_fields(), so this introduces both more code to build the EFQ and a dependency on EFQ_Views. Or maybe EFQ_Views could have a handler to agregate term references across field instances. Just thinking loud.
Comment #32
chx CreditAttribution: chx commentedWe are getting to #31 slowly , I pushed taxonomy term reference field filters to efq_views just now.
Comment #33
chx CreditAttribution: chx commentedIs it a valid use case to have several term reference fields using the same vocab? The typical pattern seems to be
$field_name = 'taxonomy_' . $vocabulary->machine_name;
and then instantiate that so I truly wonder whether once the argument (contextual filter) handler is added to efq_views this could be closed down.Comment #34
fgmTypically, many sites will prefer to use multiple fields with almost identical definitions instead of creating multiples instances of a given field, so this will likely also apply to taxonomy term references.
Comment #35
chx CreditAttribution: chx commentedWhy on earth would anyone do that? I am genuinely curious.
Comment #36
MiSc CreditAttribution: MiSc commented@chx: I have to agree with fgm, I have seen that in many places.
Comment #37
fgmOne problem with instances is views integration, which is typically limited to per-field settings, not per-instance. This is something we run into constantly with entityreference plugins.
Comment #38
Janne Salo CreditAttribution: Janne Salo commentedI don't know if the use of the patch in #25 is encouraged or not, but I need it and you can't patch the latest dev version (Jul 27) with it, so I created a new version of the patch in case someone else needs it too. It's the exact same code, but it should work with the current dev version.
Comment #39
chx CreditAttribution: chx commentedIf you would reroll it with a mongodb collection insert I would consider but db_insert is a flat-out no.
Comment #40
mgiffordI might be able to re-roll this, but need to get a bit more direction @chx as to what you're needing to be improved in this patch.
We applied MongoDB and had a bunch of problems with the taxonomy and are still trying to figure out what the problem was.
Comment #41
chx CreditAttribution: chx commentedWhat I meant is that if you want to keep the taxonomy-node denormalized data around, do it in MongoDB not in SQL.
Comment #42
Summit CreditAttribution: Summit commentedHi, referring to this issue about taxonomy, can I now use Taxonomy_menu etc...taxonomy driven modules with storing the taxonomy entities in Mongo? If you want me to place another issue for this, sorry then.
greetings,
Martijn
Comment #43
marcingy CreditAttribution: marcingy commentedAs per #41 the mongodb module should be doing no operations on MySQL.
Comment #44
protools CreditAttribution: protools commentedincorrect work with taxonomy breaks all reasons to use mongo
Comment #45
sunnykasera3107 CreditAttribution: sunnykasera3107 commentedI was also facing this issue and just added a hack using custom module. I check for data exist for the field in mongodb on form alter of field settings. I am sure it is not right way but it works for me.
Here is code