Skip to main content


The MWF Team maintains a content delivery network (CDN) to deliver complete MWF code distributions to users based on their geographic locations. For example, if you are using the default theme in the US, you would use:

Using versions

MWF is evolving rapidly and version control is the only way to stay organized so you are using the right version. Each version is deployed so you can point to a specific version and deliberately upgrade on your own schedule. This allows you to not wake up one morning and find your site is down because a new version of MWF was disployed overnight.

The intention is to delete old versions after 6 weeks. This gives you a window in which to test the latest release and fix any site issues that might occur. However, the 6-week policy may change based on the business impact. There is no technical reason why these versions cannot persist forever, but there is a strong business desire to force partners to upgrade to the latest version, thus enforcing a consistent design across all MWF domains. Deleting old versions guarantees that consistency.

You should be prepared to participate in User Acceptance Test (UAT) passes to assure that the new version works for your site. The MWF team is ready to assist however possible. If you are not prepared to participate, you should notify the MWF team by emailing

Sometimes there are special needs. In rare cases a path might include the names "long" and "short" which relate to their intended expiration timeframe. The files in the "short" path will have a TTL of 15 minutes. The files in the "long" path will have a TTL of 1 year. Remember that these are exceptional cases.

Manifest file

All users need to become familiar with the content of the manifest file. The manifest file is used to manage how MWF CSS and JavaScript libraries are versioned, deployed, and cached. It contains the current version path information and is stored on the CDN. Ideally, though not required, you would automate the process of reading the manifest file. When a new release is available, the manifest file will have all of the information needed to update your site to get the latest release.

Get the manifest

The current manifest can be downloaded from here:

Using the manifest

The manifest provides 4 paths for both CSS and JavaScript:

  1. vNext: During the UAT period, this is the path to statics that are about to ship and should be tested. Outside of the UAT period, this path will be identical to vCurrent.
  2. vCurrent: This is the most current path for statics and that your Production site should reference.
  3. vPrior: This points to the previous version of statics. In the event of a live site issue, you may want to rollback to this version of statics.
  4. ci: Not for production. This is the Continuous Integration path and contains the latest build currently in development. It may not be stable or ready to ship, but your developer environment may want to reference this path to get the very latest version.

Sample manifest file:


     "regionMap" : "",
     "css" :   {
            "vNext": "",
            "vCurrent": "",
            "vPrior": "",
            "ci": ""
     "js" :   {
            "vNext": "",
            "vCurrent": "",
            "vPrior": "",
            "ci": ""

Matching CSS file names

Please note that the paths in the manifest provide the paths you need to use in your code, but not the actual CSS file names. You have to construct the file name to meet the needs of your site based on the following filename pattern:



  • {region} — Specifies the CSS to use for that region. Each region has custom CSS that follows industry standards and allows quicker implementation as newer markets are made available. A full list of regions can be found in the regionMap as referenced in the manifest.
  • {theme} — Currently supports two options: "default" or "alt".
  • {ie8|ie9} — Support for IE8 is obtained using the option "ie8". Support for IE9 is obtained using the option "ie9".
  • min — Specifies the minified version for faster load times and higher performance. If not specified, then the you will receive the un-minified version.

Matching JavaScript file names

There is no equivalent of "regional" JavaScript library filenames. You can find a list of available JavaScript library filenames on the Scripting page.

For example:


MWF does require some additional libraries that are classified as dependencies. Not all of these dependency libraries are not necessarily required. This section examines these dependencies and where they are needed. At this time there are 4 dependency files:

MWF dependencies
Filename Description Included in distrobutions?
normalize.css A modern HTML5 ready alternative to CSS resets Yes
html5shiv.js Resolves calls to HTML5 sectioning elements No1
modernizr.js A browser feature detection library Most2
picturefill.js Controls responsive images based on a variety of screen sizes, viewports, size, resolutions, and more Most2
  1. Use of this library is fully your responsibility to host and integrate the library into your code.
  2. Included in all distributions except where the term "no-vendor" is included in the library name (e.g. mwf-main-no-vendor.amd.min.js).


Those distributions including the "no-vendor" in the library filename do not include the JavaScript dependency libraries. This is a marginal case where there might be an issue such as a namespace conflict with the dependency libraries and your site's code. For those who use this version of the MWF distribution, there are no provisions for providing the dependency libraries through CDN. You must obtain them from their respective public distributions and all integration responsibilities are assumed by you.

Avoiding versions

It is not recommended to use the statics in the "latest" path because:

  • The client is forced into a cold start (PLT1) because the CDN cache needs to be sufficiently small (currently estimate is 15 minutes).
  • The continued downloading from the CDN to the client reduces the page load performance unnecessarily.
  • The CDN has to re-hydrate its cache which increases the costs that Akamai charges.
  • The load on the origin server is greatly increased, potentially in bursts which could potentially cause failed responses.
  • There is no quick rollback plan for just one partner, while keeping other partners moving forward.

The most important thihng to remember is that you won't be able to upgrade on your own terms. The files in the "latest" path will update without notice. And the Live Site Support provided by MWF for the "latest" path is much slower because it would require investigation, fixing, testing and redeployment. It is much better for a site to quickly revert to an earlier version.

However, if you find that the "latest" version meets your needs better, and you're ready to take on the risk of unannounced issues, you can chose to use it.

For example, the latest location: