SOLUTION: For everyone interested: turned out the solution was moving all files that use DoJo beneath the jQuery UI files, so that jQuery UI is fully loaded before any DoJo stuff loads. Moved them all in the footer in that order (jQuery, then jQuery UI and then alle DoJo related files).

Edit: to keep things organized:

I'm running a Wordpress website which uses both jQuery and DoJo (part of the ArcGIS JS API, loaded from http://js.arcgis.com/3/12/). After recently upgrading from Wordpress 4.0.1 to 4.1, things broke. Dojo is returning multiple Error: multipleDefine errors.

Basically it looks like DoJo tries to load a new instance of jQuery, which it shouldn't, since WordPress has loaded jQuery already and there isn't a jQuery module available in the DoJo map. Furthermore, this issues seems to only exists in WordPress, not in a jsfiddle I made including exactly the same scripts.

For debugging purposes I first disabled all WordPress plugins, without any result; the problem kept existing. I went on and found a couple of interesting things. But I'm really stuck in the further debugging proccess. I know the scope of this question is rather broad.

What I know so far/that i'm wondering about:

-Things stopped working after upgrading to WordPress 4.1

-In the info of the multipleDefine error it states https://js.arcgis.com/3.11/jquery.js, which is weird: it shouldn't be looking for jQuery there, since it's already included in Wordpress

-Things break as soon as I included the ArcGIS Javascript API, which includes DoJO, but only in WordPress; on a jsfiddle things work fine http://jsfiddle.net/dhunink/mry5vn3s/7/

  var dojoConfig = { 
    isDebug: true,
    async: false

<script src="http://js.arcgis.com/3.12/"></script>

enter image description hereenter image description here The things mentioned above leads me to the conclusion that something changed in the last WordPress release that effects my script, although I can't find anything in the release notes that could be linked to my issue.

Feel free to see all in action at https://tpgrf.nl/testserver/alpha/topotrainer/provincies/.

  • Since this occurred after your WordPress upgrade, would you be better served by this question being posted on the WordPress SE site? Commented Dec 23, 2014 at 16:50
  • I saw a similar error when I once tried to use the ArcGIS JS API in combination with RequireJS. I believe the error means that the define and require functions are already defined when the API (including Dojo) tries to load. If this is the case then Wordpress is probably using its own AMD manager and you're probably going to have a hard time. Comment-out the ArcGIS reference and then in console try typeof window.define
    – tomfumb
    Commented Dec 23, 2014 at 22:39
  • @ChadCooper I did post it down there, thanks for the suggestion. Unfortunately it came down to an argument if WordPress is to blame or not.... Although the comments over there were constructive, it didn't let to a solution. For now I've managed to downgrade to WordPress 4.0.1. I've included new links to a WordPress 4.0.1 and 4.1 version in my original post. Commented Dec 23, 2014 at 22:55
  • @tomfumb thanks! I'm pretty sure WordPress isn't using RequireJS (yet) but do believe now that the problem is somewhere in that particular direction; something is declaring define and require before the ArcGIS JS API is. Next up: figure out what is doing that. Any thoughts on that? Commented Dec 23, 2014 at 22:56
  • it's a bit of a hammer but I would suggest routing traffic through Fiddler or equivalent and searching HTTP responses for the text 'define' or 'require'
    – tomfumb
    Commented Dec 23, 2014 at 23:06

3 Answers 3


I removed the Jquery UI scripts at the end of the page in https://tpgrf.nl/testserver/alpha/topotrainer/provincies/.

All those scripts start with the base URL https://tpgrf.nl/testserver/alpha/wp-includes/js/jquery/ui.

Moving them up just before the variable translObj fixed it.

JQuery UI is trying to define the global function define when it already exists, creating a conflict.

  • Hi Aamir! Thanks for all the effort, really appreciate it! I believe you'r right: when I use W3 Total Cache and minify the shortcakes.js before the jQuery UI files, everything works like a charm. Unfortunately I can't replicate this solution without the caching plugin by setting jQuery-ui-core as a decency (wp_register_script('shortcodes-jquery', $scriptdir.'/js/tpgrf_shortcodes_jquery.js', 'jquery-ui-core');). This isn't working; the jQuery-ui script is still loaded AFTER the shortcakes script. How would you handle it? Commented Dec 26, 2014 at 12:33
  • Not 100% sure but I believe i've narrowed it down to jquery-ui-core, jquery-ui-progressbar and jquery-effects-slide. When I deregister those three files, all seems to work perfect. Whoever, when I include any of those files, I get the error I've got before. So far so good. But I'm really unsure about the next steps to take. Any thoughts on how to proceed? Commented Dec 27, 2014 at 0:17
  • Hi @Aamir! Building forward upon your brilliant answer, I finally solved it. You were right, including jQuery UI before the JS that contains DOJO is the solution. However, instead of moving jQuery UI up, I went the other way and moved all the other stuff beneath jQuery UI. Works like A charm, so I just marked you're answer as the solution. Thanks again! Commented Dec 29, 2014 at 11:47

SOLUTION: For everyone interested: turned out the solution was moving all files that use DoJo beneath the jQuery UI files, so that jQuery UI is fully loaded before any DoJo stuff loads. Moved them all in the footer in that order (jQuery, then jQuery UI and then alle DoJo related files).

Still wondering though why this has been an issue in WP 4.1, while it worked perfectly without the fix in WP 4.0.

  • I don't know WP that well. But in the 4.0 page I didn't see Jquery UI files being referenced. Commented Dec 29, 2014 at 18:03

I recently ran into this issue on a Wordpress site where the Dojo Loader was conflicting with WPForms (plugin) that was loading in jQuery UI. Because I couldn't define the loading order of WPForms's scripts (which loaded last in the footer no matter what I did), I instead used the 'defer' attribute of the tag that I was loading the ArcGIS SDK through. This fixed the issue without having to worry about load order.

<link rel="stylesheet" href="https://js.arcgis.com/4.15/esri/themes/light/main.css">
<script defer src="https://js.arcgis.com/4.15/"></script>

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.