Last modified: 2014-11-14 23:52:16 UTC
At some point in MW 1.24 development - my guess is it may have been the jQuery update - the "Add another" feature for multiple-instance templates (all such button varieties) stopped working. With MW 1.24 and 1.25, nothing happens in a form upon clicking such buttons. Tested with currently latest SF from git (but the problem also affects older SF versions).
Hi Joel, I'm guessing that there's a Javascript error somewhere. Can you open the Javascript console in your browser (if you're using a non-IE browser) and see if there are any error messages there?
Joel: For error console instructions please see: * Firefox ≥24: https://developer.mozilla.org/en-US/docs/Tools/Web_Console * Internet Explorer: http://msdn.microsoft.com/en-us/library/ie/dn255006 * Google Chrome: https://developers.google.com/chrome-developer-tools/ * Apple Safari: https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/PrototypingYourWebsite/PrototypingYourWebsite.html
Okay - the following appears, and it seems my initial guess regarding the cause was wrong: "Exception thrown by user callback" load.php:150 "ReferenceError: wgWikiEditorEnabledModules is not defined" ReferenceError: wgWikiEditorEnabledModules is not defined Stack trace: init/</<@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=ext.semanticforms%7Cext.semanticforms.autogrow%2Cbrowser%2Cfancybox%2Cmain%2Cselect2%2Cwikieditor%7Cjquery.textSelection%7Cmediawiki.cldr%2CjqueryMsg%2Clanguage%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser&skin=vector&version=20141021T224256Z&*:153:686 jQuery.Callbacks/fire@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:44:925 jQuery.Callbacks/self.fireWith@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:46:258 .Deferred/</deferred[tuple[0]]@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:47:595 handlePending@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:158:760 runScript@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:160:474 execute/</checkCssHandles@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:160:863 execute@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:161:642 handlePending@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:159:1 runScript@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:160:474 execute/</checkCssHandles@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:160:863 execute/</cssHandle/<@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:160:993 jQuery.Callbacks/fire@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:44:925 jQuery.Callbacks/self.fireWith@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:46:258 jQuery.Callbacks/self.fire@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:46:301 addEmbeddedCSS@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:155:857 addEmbeddedCSS/<@http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141021T223859Z:155:319 load.php:150 In WikiEditor/WikiEditor.hooks.php, it seems it is still defined, though the WikiEditorHooks::makeGlobalVariablesScript method has a comment saying: "Build and export old-style wgWikiEditorEnabledModules object for back compat" Perhaps some other change made the way it is defined in WikiEditor and/or used in Semantic Forms no longer work.
If you add "&debug=true" (or "?debug=true") to the URL, it will probably give a more helpful message about the exact line number in which the problem is happening. Could you try that out? It could be that SF's handling of WikiEditor needs to be slightly updated.
Just tried it. The first line is load.php:10344 - which simply leads to a console.log() call in jQuery. The rest points to load.php:10350 - a related jQuery console.error() call. So unfortunately, doesn't seem to give much of a clue. The message appears in the log after the form has loaded, no clicking on anything being needed. However, another thing which seems more promising, and which I missed in writing the previous message, is: upon clicking an "Add another" button, the following line (at SemanticForms.js:785) appears in the Javascript console: ReferenceError: sfgShowOnSelect is not defined
Oh, okay. Are you using "show on select" within the form? If not, my guess is that the second error is just a result of the first error. If you are, could you try temporarily disabling the WikiEditor extension, and see if the problem persists?
It's not being used within the form, but I tried disabling WikiEditor anyway, and the "Add another" button problem persisted (along with the logged "sfgShowOnSelect is not defined"). The WikiEditor-related message went away as expected, though. In SemanticForms.js, line 785 is the beginning of the following if-statement: // TODO: Data in sfgShowOnSelect should probably be stored in // jQuery("#sfForm").data('SemanticForms') if ( sfgShowOnSelect[ old_id ] ) { sfgShowOnSelect[ this.id ] = sfgShowOnSelect[ old_id ]; } So it seems it fails upon just performing a check related to the feature. And I guess the WikiEditor-related problem turns out to be a separate bug of some kind (or, if related, then not being the cause of this issue).
Could you include your form definition here? (Assuming this only happens to you with one form.)
I only had one form using multiple instance templates, but I just made a greatly cut down test form. It still shows the problem and is included below. (The free text input can also be removed while still reproducing the "Add another ..." problem.) <noinclude> This is the "Test" form. To create a page with this form, enter the page name below; if a page with that name already exists, you will be sent to a form to edit that page. {{#forminput:form=Test}} </noinclude><includeonly> {{{for template|Resource links for topic}}} {{{field|Article link subobjects|holds template}}} {{{end template}}} <!-- Articles --> {{{for template|Article link subobject|multiple|embed in field=Resource links for topic[Article link subobjects]|label=Articles|add button text=Add another article link}}} '''Title:'''<br /> {{{field|Title|property=Title|input type=text|size=86}}} '''URL:'''<br /> {{{field|Main URL|property=Main URL|size=86}}} '''Brief description:'''<br /> {{{field|Description|property=Description|rows=1|cols=76|autogrow}}} {{{end template}}} {{{standard input|free text|rows=25|editor=wikieditor}}} </includeonly>
I can't reproduce that problem, unfortunately. I assume this is not a public wiki? If not, what I would try doing is to cut down the test wiki even further, until you get to a bare minimum where the problem still exists; that may help to diagnose the culprit.
Make that "test form", not "test wiki".
It seems that as soon as a field - any field - is included for a multiple instance template, the problem is triggered. If all fields are removed (in the above, "Title", "Main URL", and "Description"), the problem goes away. I'm currently doing this testing using MediaWiki-Vagrant. The "real" wiki (which is not currently public) is still running an older MW 1.24-alpha version from some time before the problem appeared. Here's a bare minimum second test to replace that in the form previously posted: {{{for template|Multitemplateholder}}} {{{field|Templateholder|holds template}}} {{{end template}}} {{{for template|Heldtemplate|multiple|embed in field=Multitemplateholder[Templateholder]}}} '''Test''' <!-- Uncomment to trigger the problem: {{{field|Something}}} --> {{{end template}}} {{{standard input|free text|rows=25|editor=wikieditor}}}
Hi - well, this doesn't seem quite like the bare minimum: my guess is that the JS error still happens if you remove "editor=wikieditor". (Though it would be good to know that for sure.) In any case - could you look at the HTML source for the page where the form is displayed, and look for the snippet there that looks like "sfgShowOnSelect":..., and let me know what it says (if it's there at all)?
Hi, the JS error still happens without "editor=wikieditor". That was also the case earlier (for the less bare form), as noted then, but I must've been a bit absent-minded in writing the update. To truly make the form a bare minimum, one can go even further and fully remove the line adding the free text input. This does not affect the error. Here's the snippet from the HTML source when using the form: "sfgShowOnSelect":[],
I don't know - I'm stumped as to why this would be happening, though I do it's in some way tied to your wiki's specific setup, given that I can't reproduce it and I haven't heard of the problem elsewhere. There's no way I can get access to your wiki, is there?
(do think)
Quite unexpectedly, it can now be considered resolved. There's two copies of the wiki. Only the local copy, using MediaWiki-Vagrant for testing, was running the most recent MediaWiki versions. After the problem appeared during such testing after an upgrade, I held off on upgrading the "real" wiki. Today I tried reducing the configuration for the local copy of the wiki, removing all extensions except SMW, SF, SRF, and their dependencies. (As for the skin, the wiki uses standard Vector.) The problem remained, and I got the suspicion that since there was nothing left in the configuration to cause the problem, perhaps it only appeared using the MediaWiki-Vagrant setup. So I finally upgraded the real wiki. Same versions, extensions, configuration as on the local test wiki - and the problem didn't appear! So it seems something weird is going on with the MediaWiki-Vagrant installation I have. I'm sorry for wasting your time.
Aha! No problem, and that's great to hear.
