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
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"}]

#7 better_exposed_filters-max_input_vars-1891612-7.patch4.34 KBcafuego
Test request sent.
[ View ]


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

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.

jenstechs’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.