When saving term lineage turn on, it seems that the selection fails to load correctly.
This is appearing on first load of a node edit form. I can see that the terms are being saved.
I have a 2 level taxonomy.
I've stepped through the code and can see that where the hierarchy is generated, it seems to select the wrong term as the selected term for the parent level.
Probably somewhere here where it's doing the funky taxonomy tid ordering.
$hierarchy = _hierarchical_select_hierarchy_generate($config, $hs_selection, $element['#required'], $dropbox);
i.e. 1450 is the tid, yet doesn't appear in the levels array, because 1450 is the selected term from the children level.
$hierarchy = Object of: stdClass
levels = Array [1]
0 = Array [72]
...
lineage = Array [1]
0 = (int) 1450
Hope this makes sense.
Michael
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 258708.patch | 1.19 KB | wim leers |
| #5 | Settings.gif | 26.92 KB | pingers |
Comments
Comment #1
wim leersIs this a node that was created when save_lineage was still disabled? Because then this is normal behavior: no valid lineage can be reconstructed, because not enough items are selected.
E.g. suppose you selected "7 series" before save_lineage was enabled. If you then turn on save_lineage and edit the node, no terms will be listed, because the parent term ("bmw") was not selected, and because of that, no lineage could be reconstructed.
Comment #2
wim leersIs this a node that was created when save_lineage was still disabled? Because then this is normal behavior: no valid lineage can be reconstructed, because not enough items are selected.
E.g. suppose you selected "7 series" before save_lineage was enabled. If you then turn on save_lineage and edit the node, no terms will be listed, because the parent term ("bmw") was not selected, and because of that, no lineage could be reconstructed.
Comment #3
pingers commentedI think you're right. I'll try it when I get a chance tonight - on a fresh node.
Cheers,
Michael
Comment #4
wim leersJust for the record: it's of course possible to support these transitions. But it can give unexpected results. So it's better to make the right choice from the beginning, so take your time while deciding on that!
Comment #5
pingers commentedStill experiencing the same behaviour after creating a few new nodes.
Please see settings attached.
Okay, when I debugged this time, before executing the line of code in my first post, I switched the values of the following array:
Original
Switched
Then it loaded the hs element perfectly.
Hopefully this is enough info to get you on the right track :)
EDIT: Attach the image.... sigh. Must be Friday.
Comment #6
wim leersHm, that should not happen. Seems like a bug indeed then.
I've got very little time, so it'd help if you could provide me with FTP/SSH access to this web site, so I don't have to set up a testing environment.
Comment #7
pingers commentedI'll see what I can do - under an NDA for the site - but it's going public very soon - as in few days.
I'll do my best to provide access to what you need.
Regards,
Michael
Comment #8
wim leersWell, if you want me to sign an NDA to access it, no problem for me (had to do that before). But I'm not sure if that's your call.
Comment #9
wim leersReproduced. Happens when:
- save_lineage = 1
- dropbox is disabled
Guess at the cause: multiple values is not being enabled automatically for the vocabulary.
Comment #10
wim leersFound it. The cause was that I was validating the hierarchy *before* it was reconstructed. That's why this did *not* happen when tid1 < tid2 < tid3, which is often the case.
Comment #11
pingers commentedLovely work!
Comment #12
wim leersSo it works? :)
Comment #13
esllou commentedit essentially works but as I reported here:#259903: When using "Save Term Lineage", term data not saved on node/edit, it seems to be having an odd side effect. As always, happy to help in further testing if tweaks are needed.
Comment #14
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.