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.
It seems the example works ok on configuration form, but not on node add/ edit. In hierarchical_select_ajax() list($form, $form_state) = ajax_get_form();
isn't able to get the right form -- it seems the form_build_id is wrong.
Comment | File | Size | Author |
---|---|---|---|
#19 | Screen shot 2011-06-25 at 23.53.04 PM.png | 7.96 KB | hubScrappy |
#19 | Screen shot 2011-06-25 at 23.54.34 PM.png | 8.82 KB | hubScrappy |
#15 | hs-1069368-15.patch | 1.14 KB | fearlsgroove |
#10 | 1069368-10.patch | 1.1 KB | fietserwin |
#5 | 1069368.patch | 1.18 KB | Owen Barton |
Comments
Comment #1
Wim LeersHuh? How is it possible that the most basic thing is failing?
Can you reproduce this on a vanilla Drupal site?
Comment #2
amitaibuWith plain vanilla install (7.0 release, I'll soon try with dev as-well) and only HS-taxonomy installed -- it doesn't work.
Comment #3
amitaibuAlso with drupal 7-dev, it doesn't work. I've attached a dump of the DB
Comment #4
Wim LeersThanks for reporting back. That's very strange. I'll try to reproduce it.
Comment #5
Owen Barton CreditAttribution: Owen Barton commentedI had the same problem, the form is not actually in the cache_form table, so there is nothing to retrieve - the issue is that hierarchical select is not setting the form to cache, or including ajax.js (yet it does use this function). It currently only works if another module (for example a multiple value field module) has done this already, which may explain why this is a little hard to detect.
Initially I received first a Javascript error (since ajax.js was missing), and after I fixed that an blank AJAX response, with a watchdog log of "invalid POST data" due to ajax.inc being unable to retrieve the form cache (since it was not stored).
Attached patch fixes this for me.
Comment #6
Wim LeersAwtch. Quite stupid of me. I've always tested with a content type that has a File Field — to make sure I don't break it. I should also have tested without it, and then I'd have noticed this. Thanks, Owen! :)
Comment #7
bigsyke CreditAttribution: bigsyke commentedPatch #5 fixed it!
Comment #8
JVA-1 CreditAttribution: JVA-1 commentedPatch #5 worked for my D7 too. Good job guys.
Comment #9
JVA-1 CreditAttribution: JVA-1 commentedIt seems fine in editing and viewing, but gives the notice mentioned earlier when adding/editing a field to any content type.
admin/structure/types/manage//fields/body
Comment #10
fietserwinThese js files are libraries,so i think they should be included like this (see e.g. ajax.inc line 655/656):
Looking at ajax.inc, can't this be triggered by using the "#ajax' attribute on the element? (probably at the same time replacing some other lines of code with declarative settings) (http://api.drupal.org/api/drupal/developer--topics--forms_api_reference....)
Comment #11
Adam S CreditAttribution: Adam S commentedPatch on #10 works for me :)
Comment #12
Owen Barton CreditAttribution: Owen Barton commentedComment #13
silkscreen CreditAttribution: silkscreen commentedMany thanks to the author for getting this up and running in D7. It is an invaluable module.
Comment #14
slashrsm CreditAttribution: slashrsm commentedI can confirm that patch at #10 works.
Caution: patch at #5 also worked for Drupal 7.0, but it stoped working at 7.2.
Comment #15
fearlsgroove CreditAttribution: fearlsgroove commentedReroll of #10
Comment #16
fred0 CreditAttribution: fred0 commentedNot sure this is related, but even after this patch, I am getting an invalid response from server error on the page and this in my apache error.log:
File does not exist: /var/www/mysite/hierarchical_select_ajax, referer: http://10.211.55.11/mysite/?q=node%2Fadd%2Fasset&render=overlay
Comment #17
fearlsgroove CreditAttribution: fearlsgroove commented@fred: you need to enable clean URLs. Not sure if HS is supposed to require clean URLs or not -- it should work without. But it should be a separate issue.
Comment #18
fred0 CreditAttribution: fred0 commented@fearlsgroove: Thanks!
Comment #19
hubScrappy CreditAttribution: hubScrappy commentedStill a bug somewhere here, after Patch/Line #15 ... I have a content type that has two Select Lists ... one for Location (Country -> Province / State -> City) and the other for Category ...
When I go to 'Add Content', as can be seen in the first attachment, both select lists show up fine ...
If I select Country, though, the view changes to what is seen in the second screen shot ...
Ignoring that problem, and choosing yet another time, one of the select lists then disappears, and, choosing another with just the remaining select list, I can actually now start choosing items ...
So, I guess the first question is: should I be able to do this twice on the same 'Add Content' form, or is that my mistake right there ...
Assuming that I am correct in how I'm trying to use it ... what more information can I provide towards debugging it?
I am running Drupal 7.2, with Hierarchical Select 7.x-3.0-alpha1 ...
Thx ...
Comment #20
fearlsgroove CreditAttribution: fearlsgroove commented@hubscrappy: Sounds like a different bug. Please open a new issue.
Comment #21
artatac CreditAttribution: artatac commentedwhen I pplace this patch in the module folder and add the following in terminal I get
will this be added to the dev version soon?
Comment #22
fietserwinApparently, your file is not in the directory where patch is run. Try to place it in the hierarchical_select directory under modules. The patch expects this as the directory hierarchical_select is not part of the filename.
Comment #23
univate CreditAttribution: univate commentedThanks, this issue was bugging me as it was working on an admin account but not for normal users. The difference in my case was that I had a filefield that shows up for admin's and not normal users.
Comment #24
Wim LeersFixed: http://drupalcode.org/project/hierarchical_select.git/commit/2953d9b.