Our Great Posts

An Example of Legacy Code Broken by SharePoint 2013’s Minimal Download Strategy

  • July 25, 2014
  • by David Lohnes
  • Gotchas, SharePoint 2013, Under the Hood,
  • Leave a comment

Several months ago we ran into an odd issue while testing the 2013 version of a suite of third-party web parts which we frequently incorporate into our solutions. The gist of the issue (as I put it in the bug report to the developer) was, “Many buttons throughout the site do not work.”

Digging into the page elements, all of the buttons looked to be implemented correctly: the links were all correct and in place, they all worked if navigated to directly, and the JavaScript looked right. My first thought was it might be a browser issue related to IE11’s well-known incompatibility with SharePoint 2013. But fiddling with compatibility settings didn’t fix the issue, and all other browsers were equally afflicted. So I decided to wait for the developer to get back to me. They would need to fix the issue anyways.

Three days later I got their feedback:  

I was directed to line 100 in one of their JS files in the 15 hive and told to wrap the function call


as follows

EnsureScript("inplview", typeof InitAllClvps, function() {SP.UI.ModalDialog.showModalDialog(options); });

This was the information I needed.

EnsureScript() is a JavaScript function defined in the SharePoint core JS (you can find it in 15TEMPLATELAYOUTSINIT.debug.js) that checks to see if the JavaScript that defines the function being called (in this case SP’s showModalDialog function) has been loaded by the browser, and if it hasn’t, it gets it from the server.

The reason the buttons weren’t working was because each of them was trying to open a modal dialog (the pop-up windows SP often uses), and the JavaScript defining how to make a modal dialog hadn’t been sent to the browser yet. The EnsureScript() wrapper was a workaround from the developer designed to fix that problem.
The EnsureScript() wrapper didn’t work (because the INIT.debug.js file hadn’t been sent to the browser either), but I was able to create my own wrapper using SP’s Script on Demand (which is probably a better way to do this than EnsureScript() anyways.)

SP.SOD.execute('sp.ui.dialog.js', 'SP.UI.ModalDialog.showModalDialog', options);

Once this wrapper was in place, all the buttons started working properly.

So Why Did This Happen?

SharePoint 2013 introduced a new feature called the Minimal Download Strategy that is designed to optimize performance by not sending information to the browser unless it’s really necessary. So in this case, instead of unnecessarily preloading bunches of JavaScript that may not be used, SharePoint was trying to load only the JavaScript that would be necessary.

However, since the web part code was written before the Minimal Download Strategy existed, it did not communicate properly which JavaScript files would be needed. The SP.SOD wrapper is one way to do that. There are others. The bottom line is the code worked in the past because all the JavaScript was loaded automatically.

So why didn’t the developers find the issue before it got to me?

Well, the SP2013 MDS is implemented as a Site Feature and can be turned on or off at will in the Site Settings.

SP2013 MDS



Some site templates (like Publishing) include it automatically. Some don’t. The web parts I was using are usually deployed to the root of a site collection as a custom site template created by the vendor. I had deployed them to a subsite under an existing Publishing site collection and adjusted the template. In the process, the MDS feature was Activated, and the issue was discovered.

The immediate lesson I took was to be more careful about how I modified the vendor’s template, but this is also an interesting example of how the new MDS (which is nice) can break legacy code that wasn’t written with its limitations in mind.


Leave a Reply