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.
I am running Views 7.x-3.5 together with Better Exposed Filters 7.x-3.0-beta3 and Views Hacks 7.x-1.0-alpha1. The view whose user interface constantly crashes contains a selective exposed filter and has "Better Exposed Filters" as its exposed form style.
Whenever I click on "Use AJAX" in the user interface of my view (no matter if AJAX is set on "yes" or "no"), the interface crashes into a white screen giving me the following error. If I disable either Better Exposed Filters or Views Hacks then the error does not occur anymore.
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: myurl/admin/structure/views/view/myview/preview/page/ajax
StatusText: OK
ResponseText:
Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
[{"command":"settings","settings":{"basePath":"\/","pathPrefix":"","ajaxPageState":{"theme":"seven","theme_token":"nvKvA0ZSovvE1dNTelQP509E8Mx56jRbk922JY0DIOM"},"googleAnalyticsReportsAjaxUrl":"\/google-analytics-reports\/ajax"},"merge":true},{"command":"viewsSetForm","output":"\u003Cform action=\u0022\/admin\/structure\/views\/ajax\/display\/meetings\/page\/use_ajax\u0022 method=\u0022post\u0022 id=\u0022views-ui-edit-display-form\u0022 accept-charset=\u0022UTF-8\u0022\u003E\u003Cdiv\u003E\u003Cdiv class=\u0022views-override clearfix container-inline\u0022\u003E\u003Cdiv class=\u0022form-item form-type-select form-item-override-dropdown\u0022\u003E\n \u003Clabel for=\u0022edit-override-dropdown\u0022\u003EFor \u003C\/label\u003E\n \u003Cselect id=\u0022edit-override-dropdown\u0022 name=\u0022override[dropdown]\u0022 class=\u0022form-select\u0022\u003E\u003Coption value=\u0022default\u0022\u003EAll displays\u003C\/option\u003E\u003Coption value=\u0022page\u0022\u003EThis page (override)\u003C\/option\u003E\u003C\/select\u003E\n\u003C\/div\u003E\n\u003C\/div\u003E\u003Cdiv class=\u0022scroll form-wrapper\u0022 id=\u0022edit-options\u0022\u003E\u003Cdiv class=\u0022description form-item\u0022\u003EIf set, this view will use an AJAX mechanism for paging, table sorting and exposed filters. This means the entire page will not refresh. It is not recommended that you use this if this view is the main content of the page as it will prevent deep linking to specific pages, but it is very useful for side content.\u003C\/div\u003E\u003Cdiv id=\u0022edit-use-ajax\u0022 class=\u0022form-radios\u0022\u003E\u003Cdiv class=\u0022form-item form-type-radio form-item-use-ajax\u0022\u003E\n \u003Cinput type=\u0022radio\u0022 id=\u0022edit-use-ajax-1\u0022 name=\u0022use_ajax\u0022 value=\u00221\u0022 checked=\u0022checked\u0022 class=\u0022form-radio\u0022 \/\u003E \u003Clabel class=\u0022option\u0022 for=\u0022edit-use-ajax-1\u0022\u003EYes \u003C\/label\u003E\n\n\u003C\/div\u003E\n\u003Cdiv class=\u0022form-item form-type-radio form-item-use-ajax\u0022\u003E\n \u003Cinput type=\u0022radio\u0022 id=\u0022edit-use-ajax-0\u0022 name=\u0022use_ajax\u0022 value=\u00220\u0022 class=\u0022form-radio\u0022 \/\u003E \u003Clabel class=\u0022option\u0022 for=\u0022edit-use-ajax-0\u0022\u003ENo \u003C\/label\u003E\n\n\u003C\/div\u003E\n\u003C\/div\u003E\u003C\/div\u003E\u003Cdiv class=\u0022clearfix\u0022\u003E\u003Cdiv class=\u0022form-buttons\u0022\u003E\u003Cinput type=\u0022submit\u0022 id=\u0022edit-submit\u0022 name=\u0022op\u0022 value=\u0022Apply\u0022 class=\u0022form-submit\u0022 \/\u003E\u003Cinput type=\u0022submit\u0022 id=\u0022edit-cancel\u0022 name=\u0022op\u0022 value=\u0022Cancel\u0022 class=\u0022form-submit\u0022 \/\u003E\u003C\/div\u003E\u003C\/div\u003E\u003Cinput type=\u0022hidden\u0022 name=\u0022form_build_id\u0022 value=\u0022form-Sd9dNHQ8_Xr4XlHixcSNI3mVv0dZ1_c8rb7UbCj6MK0\u0022 \/\u003E\n\u003Cinput type=\u0022hidden\u0022 name=\u0022form_token\u0022 value=\u0022xvueODe7F7mEy-IOKRQfJbF-KzDQHlC9ZdFcixwBYHg\u0022 \/\u003E\n\u003Cinput type=\u0022hidden\u0022 name=\u0022form_id\u0022 value=\u0022views_ui_edit_display_form\u0022 \/\u003E\n\u003C\/div\u003E\u003C\/form\u003E","title":"Page: Use AJAX when available to load this view","url":"http:\/\/MYURL\/admin\/structure\/views\/ajax\/display\/MYVIEW\/page\/use_ajax"}]
Comment | File | Size | Author |
---|---|---|---|
#18 | Screen Shot 2015-10-29 at 22.43.00.png | 728.19 KB | kenorb |
#7 | better_exposed_filters-max_input_vars-1891612-7.patch | 4.34 KB | cafuego |
Comments
Comment #1
nchicong CreditAttribution: nchicong commentedI faced this same problem. Even if I unstalled all other unneccessary extra Views modules including Views Hack. The error message still keeps poppping up.
Comment #2
grasmash CreditAttribution: grasmash commentedI'm getting a similar error. It looks like BEF is just packing too many variables into Drupal's 'settings' JSON array.
Comment #3
semei CreditAttribution: semei commentedAm I supposed to declare this a critical error? I mean, it practically makes the module unusable in our cases! It would be really great if one of the maintainers could have a look at this issue.
Comment #4
mikeker CreditAttribution: mikeker commentedI'm unable to get VFS working with or without BEF enabled. If you are seeing this issue only with BOTH VFS and BEF enabled, please reopen. Otherwise, I believe this is a VFS issue.
Comment #5
DuaelFrI am.
Comment #6
cafuego CreditAttribution: cafuego commentedI'm getting the same problem as well when submitting the settings form and loading it is extremely slow. I'm not using Views Hacks, only Better Exposed Filters.
When I access BEF settings on a view with 6 exposed filters, the generated JSON blob comes to 5.8MB and pretty much *all* of that is token substitution information.
I expect that because every single token is wrapped in [] brackets, PHP tries to parse it as if it were an array variable, thus causing the max_input_vars problem. Nice one!
If I add an extra checkbox that is disabled by default and requires to be checked before including token substitution information, the module settings form loads instantaneously and saves as expected, no max_input_vars warnings. The JSOB blob comes to 49K without the token substitution info.
Since this token info is (as far as I know) identical for each of the fields, maybe it should be a single fieldset at the bottom of a form, rather than included for each field.
Comment #7
cafuego CreditAttribution: cafuego commentedAttached patch should make the settings form work again if you hit this issue. To explicitly include token info, enable the checkbox.
Comment #8
mikeker CreditAttribution: mikeker commentedUg... Token replacements and CTools modal windows!
@cafuego, thank you for finding the root cause and your proposed solution. My only concern is that the only way to uncheck the "Show token substitution" option is through the form that may not be accessible if a user is experiencing this issue. However, I can't think of another solution at the moment. (just got back from vacation! :)
Let me know if there is another way to turn off the "Show token substitution" option that I'm not seeing. Thanks!
Comment #9
kenorb CreditAttribution: kenorb commentedThe same issue here.
Increased max_input_vars in php.ini as workaround.
Comment #10
jennypanighetti CreditAttribution: jennypanighetti commentedIs the #7 patch included in any dev release? Is there a timeline for it?
Comment #11
s427 CreditAttribution: s427 commentedSame problem here. I have a view with five exposed filters, and because of this error message, it's impossible for me to configure BEF, rendering it completely useless. I'd say this bug should be marked as "critical".
Same question as fenstechs: is this patch included in any release? I tried v. 3.0 and 3.x-dev but both had the same problem.
Simple suggestion regarding comment #8: why not revert the logic? Disable the checkbox by default, to make sure that nobody experiences this problem, and let people who need it enable it (maybe with a warning message?). My guess is that most people who uses BEF don't actually work with the tokens anyway.
Note: increasing php.ini's max_input_vars to 2000 didn't solve the issue for me. Neither did increasing it to 10'000. Increasing it to 100'000 (!) did the trick.
Comment #12
mikeker CreditAttribution: mikeker commented@s427: No it has not been committed because the issue is set to "Needs work" due to the concerns in #8.
I can take a look at this. Raising PHP's max_input_vars to stratospheric heights is clearly not a decent solution!
Comment #14
mikeker CreditAttribution: mikeker commentedUpdated the settings page so that the global tokens are only displayed once (at the bottom fo the dialog) and filter-specific tokens are displayed in the "More options" fieldset for each filter.
Since the global tokens are the biggest chunk, I believe this should fix the underlying issue as they are only passed once instead of once-per-filter.
Thank you, @cafuego, for your work on this. And to everyone for your patience.
Comment #16
masher CreditAttribution: masher commentedI was experiencing this issue on a view with four exposed filters.
Checking "Disable JavaScript with Views" in /admin/structure/views/settings/advanced while setting up my exposed filters enabled me to work around this one and get the view finished.
Comment #17
alesr CreditAttribution: alesr commentedI'm getting this issue too.
It's weird that it happens only when I enable Reset button in BEF Settings.
With Reset button enabled I get WSOD with max_input_vars error in apache log.
Without Reset button enabled the view loads without a problem.
Update to the latest -dev didn't help, neither did Disable Javascript with Views as proposed in #16.
Comment #18
kenorb CreditAttribution: kenorb commentedHappened again, increased even to 2000, didn't help.
Path: http://local/admin/structure/views/ajax/display/events/page/exposed_form...
JSON response:
Content-Length:472183 (0.5MB)
version = "7.x-3.2", re-tested and the same with 7.x-3.x-dev
Increased to 5000, didn't help either.
Submit form data:
Btw. Patch doesn't seems to be in dev if that's the expected thing.
Workaround, increased to 10000, seems to work for now.
Comment #19
mastoll CreditAttribution: mastoll as a volunteer commentedI'm experiencing this problem as well. BEF version 3.2+48-dev; Views version 3.13.
Ajax error occurs when trying to save the BEF settings or switch Ajax on/off.
If I disable Javascript with Views as proposed in #16, I am able to adjust and save settings, then re-enable Javascript. In the display, the datapicker doesn't show; the default dropdown appears instead. On a second filter of taxonomy terms, the list is formatted with radio buttons but it does not appear collapsed. Are these behaviors related to the Ajax error?
Comment #20
Beezer75 CreditAttribution: Beezer75 as a volunteer commentedThe workaround in #16 allowed me to get past the errors and make configuration changes in BEF.
Comment #21
alanom CreditAttribution: alanom commentedI'm updating the title of this issue since we've established it's not caused by the above mentioned modules. I don't use any of those yet I'm seeing this exact same error.
Sometimes if I just refresh the Views edit page it keeps the changes and saves the form, but this issue needs a proper fix. If some people can't do this, surely that's a major problem?
It seems like a good plan to commit #7 now, and document that, if you need to enable tokens but can't do so due to this issue, you should disable views JS. got to be better than just leaving this as is.
Comment #22
alanom CreditAttribution: alanom commentedI've found a better workaround, so you don't need to disable Javascript on all views:
- Before editing Better Exposed Filter settings, save any other changes
- To edit Better Exposed Filter settings, open Better Exposed Filter settings in a new tab. This gives you the standalone page which saves as a non-JS form submit
- Save changes immediately after submitting the Better Exposed Filter settings form
Comment #23
mikeker CreditAttribution: mikeker as a volunteer commentedre: @alanom in #17: The patch in #7 was committed about a year ago (see #13). If you are still seeing this error using the latest dev release, please update the issue summary with steps to reproduce and set the status back to Need Work. With my test views, I'm not getting any errors with
max_input_vars
at the default 1000.Thanks.
Comment #24
Samuran CreditAttribution: Samuran commentedI am experiencing the same problem, can not apply the settings, even max_input_vars be set as 100000......
Comment #25
mikeker CreditAttribution: mikeker as a volunteer commented@Samuran, can you provide steps to reproduce or a Features-generated module that includes the content types and views needed to repro this issue?
Thanks.
Comment #26
Samuran CreditAttribution: Samuran commented@mikeker, Very sorry I am not able to do that....
Comment #27
mikeker CreditAttribution: mikeker as a volunteer commentedPutting this back to fixed as there haven't been updates on this in ages.
Comment #28
crutch CreditAttribution: crutch commentedThis will fix this common problem with large token tree and BEF https://www.drupal.org/project/better_exposed_filters/issues/2786849