Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.For some reason the multipage next-button is an input button, whereas the previous-button is link(?).
During initialization and navigation, the multipage.js produces an un-caught exception in jQuery("...next-button...").appendChild().
IE<9 apparantly doesnt support appending to an input button (which btw doesnt make much sense ;-).
Fix, in multipage.js, make next-button a link:
controls.item.append(controls.nextLink = $('<input type="button" class="form-submit multipage-link-next" value="" />').val(controls.nextTitle = Drupal.t('Next page')));
controls.item.append(controls.nextLink = $('<a class="multipage-link-next" href="#">' + Drupal.t('Next page') + '</a>'));
Comments
Comment #1
Stalski commentedCan you create a patch for this against dev release? This way it can be handled really quick.
Thx in advance
Comment #2
jacobfriis commented@Stalski
Yep, of course, patch attached, for the dev version.
But not tested, because I dont use the dev version, sorry.
Now both next and previous buttons are links, not input buttons.
And the controls.nextTitle and .previousTitle do not exist anymore - they don't seem be used(?).
This will however ruin styling of the two buttons.
But s.... IE<9 browsers will be pleased ;-)
Comment #3
peteruithoven commentedI can confirm that this is an issue on IE 8. The error will cause all the javascript to cease.
Is there any way I can help to get this in the module? I don't want to alter the js in a module, because it will just break again when someone updates it. Or is there any other way to override this?
Comment #4
peteruithoven commentedComment #5
peteruithoven commentedI've added a patch against the latest dev version. Let me know if it's okay.
I added a new patch because jacobfriis's patch seemed to contain to much changes.
(I also noticed that the current dev (7.x-2.x-dev) isn't different from the 7.x-1.1 version)
Comment #6
Stalski commentedAfter a talk with zuuperman today and with Bojhan on IRC, the conclusion is that it should be buttons or links.
So there are 2 tasks here:
1) Make it configurable (just delegating a js variable)
2) Still patch this issue for a fix for IE9 so buttons work properly as well.
Comment #7
peteruithoven commentedHi Stalski,
I'm not sure I follow.
What do you want to make configurable? If it adds a button or link?
You mean implementing my patch or finding a way to add a actual button instead of a link?
I'd like to help out. I would like to make sure I can add this module without hacking it so my client can update normally.
Comment #8
Stalski commentedHi,
First of all, I'd like every improvement to go into this module, but some things just take time. Even if you need a patch for a while. I'd like to add that we just decided to use buttons since it "would" be better.
so about the work that needs to be done, it needs to be configurable as you said: just let the webmaster decide to use a button or a link.
As an implication of that decision, the button approach still needs to work. So that's why this patch will include two things.
Result:
From configuration: buttons: the issue needs to be fixed so it works out of the box (with buttons in ID9)
From configuration: links: it works out of the box
Comment #9
jacobfriis commentedNot an issue in development version (7.x-1.x)
Multipage next-button Javascript error in IE<9 only occurs when using stable release 7.x-1.1.
It is already fixed in the dev version.
Solution when using 7.x-1.1
Update to the dev version, or fix it manually in your 7.x-1.1's multipage/multipage.js file:
controls.item.append(controls.nextLink = $('<input type="button" class="form-submit multipage-link-next" value="" />').val(controls.nextTitle = Drupal.t('Next page')));controls.item.append(controls.nextLink = $('<a class="multipage-link-next" href="#">' + Drupal.t('Next page') + '</a>'));Notes
In the dev version, next and previous are both input buttons, and neither result in error in IE7/IE8.
P.S.: How do you create a patch against a stable release?
Comment #10
Stalski commentedthe same way as normal :-), don't see a difference, except that you have the stable checked out ofcourse.
Comment #11
jacobfriis commented@Stalski
I know this a newbie thing, sorry ;-)
But what's the name of the stable branch?
There is no "7.x-1.1" branch, 7.x-1.1 is just a tag.
And checking out no specific branch results in head, which turns out to be the 7.x-1.x branch.
And master - I know, we don't use master - gives me something which looks like the very initial version of the module.
So ? ;-)
I guess we all can live without that patch (if 7.x-1.x is fairly stable). But it might be relevant in other cases.
Comment #12
Stalski commentedWell first of all, I am still asking what still needs to be patched in this issue then? you could patch against 7.x-1.1 to help people with that version. Ofcourse you can wait until a new stable release is ready.
So a patch can be against anything you want. If you checkout the tag 7.x-1.1, do your changes and then git diff will be correct for that version ...
Comment #13
jacobfriis commentedPatch against stable release 7.x-1.1 (current dev version does not have this issue).
Does
Doesnt
Contrary to my earlier patch, this patch
Tested
Against IE7 and IE8 (the browsers affected by the issue), plus FIrefox and IE9.
This should finally close this matter.
And thanks a lot for your help and patience, Stalski ;-)