When updating a node with assigned taxonomy marker which has existing translation, the entry for the translated node in table gmap_taxonomy_node will be deleted. The result is that only either of the nodes from the translation set has the desired gmap marker, the other gets the default marker.

I tried to track down where this is caused and came to function gmap_taxonomy_nodeapi (op=update). Right at the beginning, the available record is deleted (vid) from gmap_taxonomy_node, it should be re-added later. This works fine for the node that is updated, but when this functions gets executed the 2nd time (with the translated node), it won't re-add the marker to the term. The reason is that the $node->taxonomy array for the translation does not contain the vid as key. See below for examples of the taxonomy array.

That's the 1st run (originally updated node) and its $node->taxonomy array (multidimensional array with vid on 1st level and tid on 2nd level):

Array
(
    [1] => Array
        (
            [2] => 2
            [10746] => 10746
        )

    [5] => Array
        (
            [15903] => 15903
            [2415] => 2415
            [223] => 223
        )

)

This is the $node->taxonomy array of the 2nd run (node translation; one-dimension array with tid only on 1st level, no vid):

Array
(
    [2] => 2
    [10746] => 10746
    [15903] => 15903
    [2415] => 2415
    [223] => 223
    [14035] => 14035
)

The following foreach loop in the code sorts out by vid (verification if vocabulary gmap is enabled) and only then by tid (table gmap_taxonomy_term). That won't work for the node translation run due to missing vid, hence the marker won't be re-added into table gmap_taxonomy_node.

I'm using module i18nsync for translation synchronization. Maybe it's their issue, as the $node->taxonomy array gets translated and filled there for the node translation (2nd run of gmap_taxonomy_nodeapi).

CommentFileSizeAuthor
#17 gmap-fixgmaptaxonomybugwithi18nsync-907276-17.patch2.17 KBedxxu

Comments

deverman’s picture

deverman commented

subscribing.

oceanos’s picture

oceanos commented

subscribing - when Synchronize Translations module (i18n) is enabled and saving a node, the taxonomy marker of the translation of the node gets wrong.

Similar happens when using the "save post" function of Views Bulk Operations module - then the gmap taxonomy marker of the saved node(s) gets messed up. This happens even without having the Synchronize Translations module enabled.

simosacchi’s picture

simosacchi commented
Priority: Normal » Critical

subscribing

jiakomo’s picture

jiakomo commented

I've got this problem, too.

summit’s picture

summit commented

subscribing, having the same, greetings, Martijn

suffering drupal’s picture

suffering drupal commented

Same problem here too (again). We already suffered and waisted months on trying to solve this and in fact for a period it DID seem to work.

Now after some silly basic Drupal operation (flush caches, update or something the like) the marker settings get messed up again (actually seem to disappear) after saving in 1 language. This last language ends up with the correct marker, but the other languages use the fall back marker.
Will we have to waist some more months again on a previously "solved" problem? (of course we should have known it was only an ilusion)

So much for the multilanguage functionallity of Drupal (modules)...

suffering drupal’s picture

suffering drupal commented

It is to be understood that this should take care of what we all need, shouldn't it???

Synchronize translations
Select which fields to synchronize for all translations of this content type.

suffering drupal’s picture

suffering drupal commented

Moreover, after editing and saving one language some module even has the guts to state:

All 5 node translations have been synchronized.

although don't know which one anymore, this is where I start getting completely lost.
Is the problem caused by taxonomy, i18n, gmap or the simple fact that one "dares" to combine more than one module?

suffering drupal’s picture

suffering drupal commented

By the way if you go in to one of the other languages of which the marker "got lost" you do see that it's vocabulary setting is still correct.
If you save this node again, even without any change, then that language gets the correct marker again, but... the others loose them again. They literally fall back to the fallback marker.

suffering drupal’s picture

suffering drupal commented

If you uncheck Synchronize translations --> Taxonomy Terms then you get the right markers back! That is, after manually saving each language again (6x in our case)... Still better than the false promise of All 5 node translations have been synchronized (it's almost like politics...).
We would be happy to maintain this setting and forget about any syncronization, were it not that hundreds of markers that last week were correct, now are completely messed up.

Most frustrating is the fact that the right taxonomy term shows up under edit. That means they ARE THERE somewhere in the Database correctly, so who (which module) is the one that doesn't take them in account???

suffering drupal’s picture

suffering drupal commented

Don't know if it has anything to do, but looking in the database under gmap-taxonomy-node, I find that
the NIDs of the nodes with the correct markes DO appear in the table, and the NIDs of the nodes with the fallback marker do NOT appear in that table.
So the question is WHO the hell goes and whipes out that table without asking? Or, actually, without doing it correctly. Someone seems to wipe out and then forgets to substitute with new correct values.

Anyway it's not of our business anymore, since we just decided to go back to plain manual and forget about the misleading syncronization promise, disabling it. (One step further and we'd be back to good old stable and trustworthy HTML!)

suffering drupal’s picture

suffering drupal commented

By the way we are not using module i18nsync for translation synchronization like Sitiveni, so it's not their issue.

suffering drupal’s picture

suffering drupal commented

I just discovered the situation is even worse than we thought.
Now it turns out that translations are being synchronized even if you turn off the synchronize option for translations in the content type...

podarok’s picture

podarok
🇺🇦 he/him/his
Primary language Ukrainian
Location Ukraine
commented
Version: 6.x-1.1 » 7.x-1.x-dev
Priority: Critical » Major
Status: Active » Needs work

can anyone test this workaroubd for latest 7.x ?
good to see any fixes here

edxxu’s picture

edxxu commented

subscribing

edxxu’s picture

edxxu commented

For now, this module records markers for each node in table 'gmap_taxonomy_node'. I think this is not an effecient way to do this job. I think we should drop table 'gmap_taxonomy_node', just use table 'gmap_taxonomy_term' to do this job.

edxxu’s picture

edxxu commented
Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Needs work » Needs review
StatusFileSize
new gmap-fixgmaptaxonomybugwithi18nsync-907276-17.patch2.17 KB

Because of Gmap is in CodeFreeze stage for 7.x-2.x, so let us fix this bug first. Please review the patch.

podarok’s picture

podarok
🇺🇦 he/him/his
Primary language Ukrainian
Location Ukraine
commented
Status: Needs review » Fixed

Commited and pushed to 7.x-2.x #17

+++ b/gmap_taxonomy.module
@@ -103,26 +103,32 @@ function gmap_taxonomy_taxonomy_term_insert($term) {
+    //If Synchronize translations module is enabled, and the term reference field ¶

trailing whitespaces errors fixed

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.