Problem/Motivation
In certain large and/or complex forms (entity) or other, which involve a number of elements etc it is sometimes the case that ajax_html_ids causes the number of variables in the ajax postback to exceed 1000 resulting in partial loss of postback data. In some scenarios this can cause the ajax postback in admin forms to fail validation of the theme / theme token resulting in additional processing being run on the form where mandated via the non-admin theme and potentially causing WSOD / calls to functions not loaded.
Proposed resolution
The core function drupal_html_id will look for the ajax_html_ids attribute of the post-back, and already has a case to validate if there is a ',' and to explode the entered string - I propose making this the standard operating procedure.
If the misc/ajax.js were to always flatten the values into a comma delimetered string, there is a very large number (in some cases) of input variables that will not be run:
Current callback:
ajax_html_ids[]=id_one
ajax_html_ids[]=id_two
ajax_html_ids[]=id_three
vs.
ajax_html_ids=id_one,id_two,id_three
Comment | File | Size | Author |
---|---|---|---|
#17 | drupal-ajax-max_input_vars-2541722-17.patch | 2.31 KB | RoSk0 |
#7 | drupal-ajax-max_input_vars-2541722-6.patch | 2.3 KB | pookmish |
Comments
Comment #1
dan.munn CreditAttribution: dan.munn commentedHave attached a patch based on the proposed resolution above.
Comment #2
geoffreyr CreditAttribution: geoffreyr commentedI've seen a couple of contrib modules that have this problem handle this in a different way, such as with WYSIWYG here. https://www.drupal.org/node/2493443
Nevertheless, this is a really useful patch, thanks for putting it together.
Comment #3
josejayesh CreditAttribution: josejayesh as a volunteer commentedThanks @dan.munn you have saved my day !. Patch works ! .
Comment #4
josejayesh CreditAttribution: josejayesh as a volunteer commentedComment #5
jenlamptontagging
Comment #6
pookmish CreditAttribution: pookmish commentedThe patch in #1 failed on my tests. It worked for one page with a custom form API made form, but then broke when i tried to attach an image in a media field for a node. Perhaps someone might have a similar issue as me. Here's my version of the patch. Very similar.
Comment #7
pookmish CreditAttribution: pookmish commentedForgot to remove my root directory for the above patch.
Comment #9
pookmish CreditAttribution: pookmish commentedComment #11
troybthompson CreditAttribution: troybthompson commented#7 Solved my problems using Field Collection!
Comment #12
troybthompson CreditAttribution: troybthompson commentedI spoke too soon, it helped in one case, but it's happening on another node now. What information can I give that would help determine the difference between the two nodes?
Comment #13
wranvaud CreditAttribution: wranvaud commentedI tried patch #7 as well without success
Comment #14
troybthompson CreditAttribution: troybthompson commentedAny progress on this? The patch and upping my max_input_vars hasn't helped this time around.
Downgrading from jQuery 1.7 to 1.4 temporarily lets me add new entries for my problem with Field Collection.
Comment #15
shravan1794 CreditAttribution: shravan1794 commentedWe are getting the below error when trying to upload an image to an image field :
Warning: explode() expects parameter 2 to be string, array given in drupal_html_id() (line 3966 of common.inc).
Warning: Invalid argument supplied for foreach() in drupal_html_id() (line 3968 of common.inc).
Comment #16
shravan1794 CreditAttribution: shravan1794 commentedComment #17
RoSk0Patch in #7 is good and fixes the problem of POST polluted with ajax_html_ids.
This is re-roll against HEAD.
Comment #18
aaron.ferris CreditAttribution: aaron.ferris commented+1 for the patch in #17.
Comment #19
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI seem to remember we didn't want to make $_POST['ajax_html_ids'] a string before (see https://www.drupal.org/node/1575060#comment-6565854). So this probably needs more review.
If we absolutely have to, then I would think we should convert it back to an array as early in the page request as possible, rather than inside drupal_html_id() like the current patch does?
Comment #20
stefan.r CreditAttribution: stefan.r commentedComment #21
kerrycurtain CreditAttribution: kerrycurtain commentedpatch in #17 worked for me, thanks very much :)
Comment #22
anrikun CreditAttribution: anrikun commentedBumping
Comment #23
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedRegarding the comments #19, #13 and #12, I think that probably this: #3253601: Make sending ajax_html_ids optional could be a more feasible approach in this D7 stage (though it is not a fix, only workaround).