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"}]
Files: 
CommentFileSizeAuthor
#7 better_exposed_filters-max_input_vars-1891612-7.patch4.34 KBcafuego
Test request sent.
[ View ]

Comments

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.

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

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.

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.

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

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.

Version:7.x-3.0-beta3» 7.x-3.x-dev
Status:Active» Needs review
StatusFileSize
new4.34 KB
Test request sent.
[ View ]

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

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!

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

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