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.
Using the Twitter Bootstrap theme on a page that includes ajax.js results in the following error message
Uncaught TypeError: Cannot read property 'form' of undefined (ajax.js - line 137)
if (this.element.form) {
this.form = $(this.element.form);
}
As a result, users are unable to submit content via ajax. This seems to be specific to the theme, as the error disappears when using jQuery 1.7.1 + a different theme.
Comments
Comment #1
einpol CreditAttribution: einpol commentedi get the same error message. at first glance it seems to be related to the views ajax-options. when i disable the ajax view, the error is gone.
Comment #2
natted CreditAttribution: natted commentedThe problem is that views doesn't look for
<button>
for triggering an ajax control.#1551534: Submit buttons themed as <button> element fail to trigger ajax in Views exposed forms
So unfortunately, I think for this one you need to patch views.
Comment #3
zmove CreditAttribution: zmove commented+1, I can confirm that the ajax is broken on views exposed filter search.
For me, this is an issue related to twitter bootstrap, not views. The goal of twitter bootstrap is to make drupal works with HTML5/boostrap libraries, views included (as we can consider that it's pratically a core module).
What about a form_alter to let the views button as it is with view core ?
Comment #4
natted CreditAttribution: natted commentedWe could do a patch, I will look into this. I agree with your comment but at some point we need to draw a line, as we can't patch all contrib.
In the mean time, the patch outlined in #2 definitely works.
I feel it is really something views should look at fixing though. I would advise you to +1 the issue in #2. Views should be able to support both input and buttons by default and not restrict themes into only using one or the other.
Comment #5
zmove CreditAttribution: zmove commentedI can confirm that the patch works and it's more logical to fix it directly in view. By waiting that, maybe we could let the exposed filters submit as to keep compatibility.
Comment #6
andregriffin CreditAttribution: andregriffin commentedComment #7
andregriffin CreditAttribution: andregriffin commentedComment #8
andregriffin CreditAttribution: andregriffin commentedComment #9
natted CreditAttribution: natted commentedComment #10
andregriffin CreditAttribution: andregriffin commentedIs it that imperative that we have the theme use
<button>
instead of<input>
? Initially, it was a nice idea to use more HTML5 friendly semantics, but it may be causing more problems than it's worth. And the Bootstrap library should be element-independent, so the styling should apply just as well to an<input>
type button.Comment #11
natted CreditAttribution: natted commentedIt's a good point you raise.
I personally think it's good to try make other modules aware that
<input>
may not be a given and<button>
should also be supported...It's probably something Drupal should abstract at a low level in core (in an ideal world). Anyway, I'm using this functionality, so will work on a patch for this today.
Longer term, maybe in 3.x we provide as optional...
Comment #12
andregriffin CreditAttribution: andregriffin commentedAgreed about 3.x, or maybe for the future D8 branch only... as i think this is an issue that has been brought up for D8. But actually, I'd support rolling back these
<button>
instances for 2.x if we run to to more problems, and just wait until either 3.x or D8 to re-implement.Comment #13
frankbaele CreditAttribution: frankbaele commentedits a pity but practicality > progress i guess. Maybe D8 will bring us some more html5 support.
Comment #14
cpliakas CreditAttribution: cpliakas commentedConfirming that the the Views patch at #1551534: Submit buttons themed as <button> element fail to trigger ajax in Views exposed forms fixes this issue. My $0.02 is that this is indeed a Views bug because the module assumes input elements and not buttons, and buttons are perfectly acceptable markup for this implementation. Since Twitter Bootstrap uses the button element in it's examples, I wouldn't want to see this theme revert back to input elements to fix another module's assumption.
Comment #15
frankbaele CreditAttribution: frankbaele commentedso can we lable this as wont fix?
Comment #16
natted CreditAttribution: natted commentedHi Frank,
Perhaps we can just keep this active for now. It probably helps people find the solution. At least until we can document the solution (or until views fix the issue).
Comment #17
Fabianx CreditAttribution: Fabianx commentedAdd active_tags and autocomplete_deluxe to the non-supported modules ...
I am gonna revert this locally - or rather override the button -> input change in the theme - if possible.
Comment #18
Fabianx CreditAttribution: Fabianx commentedYup, easily possible, for those that do not want this solution nor the hardcoded white list:
Comment #19
boban_dj CreditAttribution: boban_dj commented@ Fabianx,
When you patch it like that, I needed to remove the complete $whitelist from the form.inc
, It worked for me when I had problems with Views-Quicksand module.
It is quite simple to use the $whitelist, but I agree that this is not sustainable.
I haven't tested the whitelisted elements so far, so I go with the solution to just add my Views exposed button #id filters to the $whitelist, so Views-Quicksand works.
Comment #20
gushil CreditAttribution: gushil commentedI'm using the solution posted in #18 but it doesnt work for form created using form api.
It seem the element doesnt contain class ajax-processed.
Any idea to solve this issue?
Comment #21
markhalliwellAs stated in #2120849-3: Decrease Panels IPE CSS & JS specificity to allow "button" elements:
These types of issues occur when modules specifically use
input
in their module's JS jQuery selectors. This kind of conflict should be filed with the module that is causing them. That being said, I don't think this is really an issue any longer and seems to be working in 7.x-3.x. If not, please file an issue with Views.Comment #22
stephenplatz CreditAttribution: stephenplatz commentedviews 7.x-3.7
jQuery 1.8.2
Still getting the same offending statement in ajax.js. The element triggering the ajax is a select list, an exposed filter. I can get this to work without ajax, of course; it would just be nicer if it worked without a page refresh.