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"}]
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nchicong’s picture

I faced this same problem. Even if I unstalled all other unneccessary extra Views modules including Views Hack. The error message still keeps poppping up.

grasmash’s picture

I'm getting a similar error. It looks like BEF is just packing too many variables into Drupal's 'settings' JSON array.

semei’s picture

Am 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.

mikeker’s picture

Priority: Major » Normal
Status: Active » Closed (cannot reproduce)

I'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.

DuaelFr’s picture

Status: Closed (cannot reproduce) » Active

I am.

 Views    Better Exposed Filters (better_exposed_filters)                  Module  Enabled    7.x-3.0-beta3+29-dev  
 Views    Views Selective Exposed Filters (views_filters_selective)    Module  Enabled    7.x-1.0-alpha2+1-dev
cafuego’s picture

Version: 7.x-3.x-dev » 7.x-3.0-beta3
Status: Needs review » Active

I'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.

cafuego’s picture

Version: 7.x-3.0-beta3 » 7.x-3.x-dev
Status: Active » Needs review
FileSize
4.34 KB

Attached patch should make the settings form work again if you hit this issue. To explicitly include token info, enable the checkbox.

mikeker’s picture

Version: 7.x-3.0-beta3 » 7.x-3.x-dev
Status: Active » Needs work

Ug... 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!

kenorb’s picture

The same issue here.
Increased max_input_vars in php.ini as workaround.

jennypanighetti’s picture

Is the #7 patch included in any dev release? Is there a timeline for it?

s427’s picture

Same 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.

mikeker’s picture

Assigned: Unassigned » mikeker

@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!

  • mikeker committed 5c880fd on 7.x-3.x
    Issue #1891612 by mikeker, cafuego: Better Exposed Filters in...
mikeker’s picture

Assigned: mikeker » Unassigned
Status: Needs work » Fixed

Updated 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

masher’s picture

I 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.

alesr’s picture

Status: Closed (fixed) » Needs work

I'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.

kenorb’s picture

Happened again, increased even to 2000, didn't help.

Warning: Unknown: Input variables exceeded 2000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0

Path: http://local/admin/structure/views/ajax/display/events/page/exposed_form...

JSON response:

Warning: Unknown: Input variables exceeded 2000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
[{"command":"settings","settings":{"basePath":"\/","pathPrefix":"","ajaxPageState":{"theme":"ember","theme_token":

...

"data":"\u003Cdiv id=\u0022edit-display-settings-details\u0022\u003E\u003Cdiv id=\u0022edit-display-settings-top\u0022 class=\u0022views-ui-display-tab-actions views-ui-display-tab-bucket clearfix\u0022\u003E\u003Cdiv class=\u0022ctools-no-js ctools-button ctools-dropbutton\u0022\u003E\u003Cdiv class=\u0022ctools-link\u0022\u003E\u003Ca href=\u0022#\u0022 class=\u0022ctools-twisty ctools-text\u0022\u003Eopen\u003C\/a\u003E\u003C\/div\u003E\u003Cdiv class=\u0022ctools-content\u0022\u003E\u003Cul class=\u0022horizontal right actions\u0022\u003E\u003Cli class=\u0022view\u0022\u003E\u003Ca href=\u0022\/upcoming-events\u0022\u003Eview Page\u003C\/a\u003E\u003C ... (very long)

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.

Warning: Unknown: Input variables exceeded 5000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0

Submit form data:

override[dropdown]:default
exposed_form_options[submit_button]:Apply
exposed_form_options[reset_button_label]:Reset
exposed_form_options[exposed_sorts_label]:Sort by
exposed_form_options[expose_sort_order]:1
exposed_form_options[sort_asc_label]:Asc
exposed_form_options[sort_desc_label]:Desc
exposed_form_options[autosubmit_hide]:1
text_input_required[value]:Select any filter and click on Apply to see results
text_input_required[format]:filtered_html
exposed_form_options[bef][general][secondary_label]:Advanced options

Btw. Patch doesn't seems to be in dev if that's the expected thing.

Workaround, increased to 10000, seems to work for now.

mastoll’s picture

I'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?

Beezer75’s picture

The workaround in #16 allowed me to get past the errors and make configuration changes in BEF.

alanom’s picture

Title: Better Exposed Filters in combination with Views Selective Filters (Views Hacks module) causes Views UI to crash » Better Exposed Filters can cause Views UI AJAX to crash - Input variables exceeded 1000
Priority: Normal » Major

I'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.

alanom’s picture

I'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

mikeker’s picture

Status: Needs work » Postponed (maintainer needs more info)

re: @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.

Samuran’s picture

I am experiencing the same problem, can not apply the settings, even max_input_vars be set as 100000......

mikeker’s picture

@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.

Samuran’s picture

@mikeker, Very sorry I am not able to do that....

mikeker’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

Putting this back to fixed as there haven't been updates on this in ages.

crutch’s picture

This will fix this common problem with large token tree and BEF https://www.drupal.org/project/better_exposed_filters/issues/2786849