Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I am using D7.12 and HS 7.x-3.x-dev (2012-Apr-19).
1. Created new vocabulary.
2. Added first term without changing anything.
3. While adding second term I set the first term as parent and removed "" from parent list.
4. When I hit submit I get the message "Parents field is required" and the parent list is empty.
Any clues?
Comment | File | Size | Author |
---|---|---|---|
#22 | hs_issue_1566878.patch | 841 bytes | SimeonKesmev |
#17 | 1566878-17-fix-double-remove-on-term-edit.patch | 6.16 KB | hanoii |
Comments
Comment #1
wiifmHaving exactly the same issue, steps to reproduce:
Edit a taxonomy term (with no parent), notice that the hierarcy is currently:
I add another parent
I then remove 'root', leaving
Clicking Save reveals
Parents field is required.
Does anyone have a fix for this. This is extremely frustrating especially when you need to re-parent 50+ terms
Comment #2
iMiksuExperiencing the same thing.. Very annoying bug :/
Comment #3
chingis CreditAttribution: chingis commentedPatch attached. Same logic as in taxonomy module.
Comment #4
claudinec CreditAttribution: claudinec commentedPatch in #3 had incorrect paths. New patch attached with correct paths.
Comment #5
kle CreditAttribution: kle commentedPatch #4 works fine for me !
Thanx a lot
Comment #6
jackbravo CreditAttribution: jackbravo commentedOn latest dev for hierarchical_select those lines already appear fixed, but I still have this error.
This is how it's currently on dev-7.x-3.x
Comment #7
Gold@jackbravo, the patch in #4 is checking $parent, not $parent_tid. If the error is still there though...
I'll add my +1 to the patch in #4. I'm not confident changing the status to reviewed & tested though. I'm applying the patch against contrib, not -dev.
Comment #8
J V CreditAttribution: J V commentedJust ran into this bug in alpha5, patch at #4 worked like a treat, but only if the root term is deleted before the custom term is added, if the custom term is added and the root term is deleted it still gives you an error.
This also happens when moving terms from a to b and deleting b after adding a.
Why is HS used for parent terms anyway? IIRC there should only be one parent. (Or better yet let us turn it off for term editing but keep it for field editing)
Edit: Actually testing shows patch #4 doesn't work any more - it's entirely dependant on the order of delete/adding terms.
Comment #9
Wim LeersPlease test with alpha 6 now.
Comment #10
martins.bertins CreditAttribution: martins.bertins commentedThe problem still exists in alpha 6.
Here's a screencast. http://screencast.com/t/pB9rDmfhe0X
Comment #11
k.skarlatos CreditAttribution: k.skarlatos commentedi have got the exact same problem. Is there any other module that can replace the default widget in the term_add page?
Comment #12
hanoiiI think I found the culprit of this issue. All the reproducible cases here are OK, but I found that the issue was basically a double-removal. Once you remove one item from dropbox, the newly rendered dropbox comes with a checked checkbox for the position of the previous removal.
If you have:
Item 1
Item 2
Item 3
Item 4
If you remove Item 2,
The newly created table will be:
Item 1
Item 3
Item 4
However, Item 3 will have the remove checkbox checked (you don't see it because it's hidden by JS), so once you submit it, you will lose Item 3 as well.
Attach is a patch that solves this by removing the reference on the form_state array of the removed checkbox. I am not 100% sure this won't cause other issues, but I think fairly sure that it won't on JS behavior. Non-JS behavior doesn't work properly anyway, as far as my tests went, so this is a good enough fix IMHO. It was a hard one to fix.
Patch is against latest dev.
Also, I am not sure why or how patch #4 worked, but that's on the current dev code anyway, I just don't think the fix was related to this issue.
Comment #13
hanoiiPushing this for review now there's some activity on the module.
Comment #14
stefan.r CreditAttribution: stefan.r commentedIf anyone else can review I'll be happy to commit this...
Comment #15
Georgique CreditAttribution: Georgique commentedPatch is nice. Here is patch rerolled against latest alpha12.
Comment #16
stefan.r CreditAttribution: stefan.r commentedComment "Remove the input reference this checkbox so that any rebuilt doesn't force it to be again" is unclear and over 80 characters. Please can you clarify?
Comment #17
hanoiiOK, it's been a while, attempting to explain it better.
Also removing some whitespaces from the file. Let me know if you prefer a cleaner patch.
Comment #18
hanoiiComment #19
stefan.r CreditAttribution: stefan.r commentedcommitted
Comment #22
SimeonKesmev CreditAttribution: SimeonKesmev commentedI cant see how the latest patch is going to work. For me it at least it doesn't as I don't see any $form_state['input']['parent'] out there.
Here is what I did to fix the issue.
Comment #23
SimeonKesmev CreditAttribution: SimeonKesmev commentedPlease review.
Comment #24
prns CreditAttribution: prns commentedCan confirm that #22 works.
Comment #26
stefan.r CreditAttribution: stefan.r commentedCommitted, thanks!