Page MenuHomePhabricator

Uncaught ReferenceError: jQuery is not defined with action=formedit on MW 1.26
Closed, ResolvedPublic


After upgrading a Wiki running MediaWiki 1.24.4 to 1.26 I am getting:

Uncaught ReferenceError: jQuery is not defined with action=formedit on MW 1.26

in the browser's developer console (Chrome 47 on Win 8.1)

This error points to the following line in the HTML:


It seems that jQuery is not loaded here at this point, probably because of T107399: Make top queue fully asynchronous (therefore related to T115692).

Not sure what is the right component to file this.

Event Timeline

saper raised the priority of this task from to Needs Triage.
saper updated the task description. (Show Details)
saper added subscribers: saper, Schreibhan.

The site runs Semantic MediaWiki 2.3, Semantic Forms 3.3.2, Semantic Result Formats 2.3 loaded via composer.

MediaWiki 1.26.0 and the bundled extensions like WikiEditor come from the release tarball.

Change 258680 had a related patch set uploaded (by Paladox):
Fix Uncaught ReferenceError: jQuery is not defined


This is a problem... It indicates that RL is being bypassed somehow. Scripts have been inserted using direct dom manipulation, document.write or other problems.
Basically any <script> block not starting with mw.RLQ or mw.loader.implement (other than the startup module and the jquery module itself), are suspicious.

I see usage of addHeadItem() and addScript() in multiple files of mediawiki-extensions-SemanticForms. Those all bypass RL, and thus won't guarantee any load order and/or dependency management...


What should I replace in


		if ( isset( $result[ 'formJS' ] ) ) {
			$out->addScript( '		<script type="text/javascript">' . "\n$result[formJS]\n" . '</script>' . "\n" );

since I carn't find any way to find out where that is linked to what js code.

is it using SemanticForms.js or ext.sf.js or is it using its own js code.

saper claimed this task.

This is fixed in the Semantic Forms 3.4.1 (and maybe even earlier).

saper reopened this task as Open.EditedDec 13 2015, 5:40 PM

Reopening. This is still present in git master, SF_FormInput.php:

// create calls to JS initialization and validation
// TODO: This data should be transferred as a JSON blob and then be evaluated from a dedicated JS file
if ( $input->getJsInitFunctionData() || $input->getJsValidationFunctionData() ) {

    $jstext = '';
    $input_id = $input_name == 'sf_free_text' ? 'sf_free_text' : "input_$sfgFieldNum";

    foreach ( $input->getJsInitFunctionData() as $jsInitFunctionData ) {
        $jstext .= "jQuery('#$input_id').SemanticForms_registerInputInit({$jsInitFunctionData['name']}, {$jsInitFunctionData['param']} );";

    foreach ( $input->getJsValidationFunctionData() as $jsValidationFunctionData ) {
        $jstext .= "jQuery('#$input_id').SemanticForms_registerInputValidation( {$jsValidationFunctionData['name']}, {$jsValidationFunctionData['param']});";

Where is the file that has that code. Because I have this patch

This is from

@Yaron_Koren What do you think would be the best strategy to fix this?

A quick and dirty way to make it 'just work' with 1.26 would be to stop using anything related to jQuery in this little snippet as well as in some functions in (SemanticForms_registerInputValidation etc.).

Is there any way to create modules that produce per-form validation scripts that could be saved as RL modules? It seems that such a form script could be then cached.

Last question: why are all those methods static?

@saper - Paladox has a patch he's working on, which moves a lot of inline JS into its own files and modules, which might fix this issue. We'll see, I suppose.

Making those specific methods static made sense to me; I don't know if I can give a better answer than that.

@Yaron_Koren I have reviewed Paladox patches' and this thing is going beyond their scope.

Btw. I have just found this:, an effort to have 1.26 compatibility.

Yes, that's true... I finally looked into this, and indeed the problem is with the JS input registration (not validation).

I'm adding Foxtrott, since this is his code. @Foxtrott - do you have any time to look into this?

Also, @saper - what makes you think that fork is intended to add MW 1.26 compatibility? (Maybe it is; I have no idea what it's for.)


Arbitrary inline scripts cannot rely on jQuery being loaded. Always use ResourceLoader::makeInlineScript() instead of manually wrapping. This ensures that:

  1. The script fails silently and gracefully if network problems caused prerequisites (e.g. mw or jQuery) to not have been loaded.
  2. The script is deferred until jQuery and mw have loaded. Or, if they loaded already, the script will run immediately.

Which file is that done in @Krinkle and what line please.

Change 262368 had a related patch set uploaded (by Paladox):
Use $wgResourceModules directly for module ext.semanticforms.wikieditor

Change 262371 had a related patch set uploaded (by Paladox):
Use ResourceLoader::makeInlineScript instead of Html::inlineScript

Change 262368 abandoned by Paladox:
Use $wgResourceModules directly for module ext.semanticforms.wikieditor

@saper does this work now. Could you try the master branch on mediawiki 1.26 and mediawiki 1.27 alpha please.

Change 258680 abandoned by Paladox:
Fix Uncaught ReferenceError: jQuery is not defined

Change 262371 abandoned by Paladox:
Use ResourceLoader::makeInlineScript inside of Html::inlineScript

Marking this as "Resolved". Feel free to re-open if it's still an issue.