Embedded mode unable to load Frontity module JS due to disallowed MIME type

I’ve been a Frontity developer for about a year now and I was just trying out the embedded mode for the first time. I know it’s still a work-in-progress but it looks like a lot of progress has been made on it.

You can see my problem by going to https://wpadmin.toursmv.com. There you will see a sort of buggy looking rendering of the site and in the console you’ll get the following error:

Loading module from “https://wpadmin.toursmv.com/static/gfmv-frontity-theme.module.6f3ef41e602345908489.js” was blocked because of a disallowed MIME type (“text/js”).

Here’s the repository (we are on the development branch) and the Vercel hosted link is at https://gfmv-frontity.vercel.app/. I’ve installed WP Fastest Cache based on the documentation and enabled it but it complains that I’m using Cloudflare and that I need to set that up. I don’t really want to do that until I’m ready to deploy so that may be an important issue I need to address. I believe the back end is on GoDaddy and the REST API URL would be at wpadmin.toursmv.com in case that’s a contributing factor.

Is there a work-around for this? I know embedded mode maybe isn’t production-ready but it fixes 2-3 big issues on this project.

you’re getting a file not found on both files in the footer (and other js files on the server)


what is your host? it’s theoretically possible they don’t see filename.hash.js as a .js file but see it as a .hash.js file and doesn’t interpret the mime type correctly

try purging your cache at cloudflare end

Hey @codemonkeynorth, thanks for the tips. I see that those files are not found as well.

My host is GoDaddy. I saw that the “text/javascript” and “application/javascript” MIME types were enabled for .js files but not “text/js”. I added it to the .htaccess in cPanel but I’m still getting the issue. I’ll try throughout the day in case it needs some time to propagate.

I also purged the WP Fastest Cache and Cloudflare caches plus I paused Cloudflare for the time being and nothing has helped. I also wondered if Wordfence could be contributing to this issue so I disabled it and messed around with the site but I’m still getting the error. Actually I went through and disabled all plugins that weren’t necessary to the function of the site and I still got the error (mostly Yoast and Akismet related stuff).

In the end, I realized that I didn’t modify the build task in Vercel to use the correct --public-path so I changed it to npx frontity build --public-path https://gfmv-frontity.vercel.app/static using the override in Vercel. I tried a couple re-builds on production but it still didn’t work. So I remembered we are using a vercel.json that probably overrides whatever is set up in Vercel so I made the change in package.json and that did the trick!

I’d love to see this idiosyncrasy better-documented here. Basically stating that it should be changed in the package.json and the Vercel override won’t work.


Hi @david1

Glad to know you were able to fix your issue :+1:

I’d like to understand better the issue you had and how you solved it to evaluate if there’s some additional explanation that should be added in the Embedded Mode docs, in the generic Deployment section, or in the specific Deploying to Vercel section

Can you provide more details of the issue and how you solved it?

Sure @juanma. Let me preface this by saying I don’t read documentation thoroughly enough the first time; I skim to see if that gets me what I’m looking for. I feel as if I can’t spend all day reading documentation and I’ve gotten away with this approach in the past, but I know it doesn’t always work. I’m probably not alone in this methodology so I have a couple suggestions to make the docs more “skimmable”.

First of all, the actual issue I had was that when I followed the three steps in the Installation section of the documentation, it didn’t work. As a documentation skimmer, I’ll go straight to that section, read the three steps, understand that the process is simple, and hope that it’s going to work after that. Sometimes there’s another section called “Setup” that I’ll also read and see if it gets me where I need to go, returning to the documentation if something is unclear.

Secondly, the error message was pretty unhelpful in this case. Loading module from “https://wpadmin.toursmv.com/static/gfmv-frontity-theme.module.6f3ef41e602345908489.js” was blocked because of a disallowed MIME type (“text/js”) made me think that the .htaccess is incorrectly configured, that X-Content-Type-Options need to be configured (the error linked to X-Content-Type-Options - HTTP | MDN), or that I’m having permissions issues with the webhost. It took me 2-3 googles and @codemonkeynorth’s response to figure out that the files was missing. The error could be clearer and not point me down these tricky roads to debug.

Regarding the documentation for embedded mode, I have three main issues. My first issue is that under “Settings”, it has this line:

The only configuration necessary for this Frontity Embedded Mode plugin is to set the URL of the Frontity server. This can be configured in a variety of ways.

That “only” is misleading because I had to do the “Static Assets” setup to get the embedded mode working.

My second issue is that the section “Static Assets” doesn’t seem like a necessary step when it is. It should be a part of “Setup” because when I read “Static Assets”, I interpret it as where the favicon or Frontity-referenced images go (which you even mention in the section) when the JS linked by configuring the --public-path is crucial to loading the Frontity code.

Lastly, what’s truly missing is that I tried to change the --public-path by editing the Deployment Settings in Vercel:

That didn’t work for me. I had to go into my package.json and modify it there (which I would guess is because of the local vercel.json file overriding server settings?):

  "name": "gfmv-frontity",
  "scripts": {
    "build": "frontity build --public-path https://gfmv-frontity.vercel.app/static",

One minor suggestion for the docs is I would start with instructions for setting the Static Assets for local development first, then for an externally deployed site, and lastly if you are deploying Frontity on the WordPress server. In my opinion, if someone is interested in embedded mode, they might first try to set it up on a local environment. Then, since Vercel and other headless solutions are easier than installing Node yourself on a server with WordPress, I would show the external server methodology. Lastly, if someone is already in the mood to configure WordPress and Node on the same machine, they’ll be reading until they hit that last item.

At the end of the day, the problem was mine for not reading the entire page. However, here is my suggestion for rewriting the documentation so it’s more “skimmable”:


  1. Download the zip file from here.
  2. Install the plugin by uploading it to WordPress
  3. Activate the plugin by locating it in the Plugins list and clicking on ‘Activate’.


  1. Configure the Frontity Embedded Mode plugin by setting the URL of the Frontity server in any of the following ways:
  2. Set the static assets public path of your Frontity deployment.

As far as the Vercel deployment documentation, my only problem recently was forgetting to set up the vercel.json file. In every case, I love the idea of numbered or bulleted instructions with more detail before getting into paragraphs and detail. So the deployment instructions would similarly be:


  1. Signup for Vercel.
  2. Log into Vercel via command line.
  3. Create a vercel.json file.
  4. Run deployment.

It just reads to me like here are the definitive steps and then each item would link to a more detailed explanation. That way people who need a refresher read the list and think “Ohhhh that’s right” whereas for people learning or evaluating Frontity, they see 4 steps, maybe 1 & 2 they’ve already done so it reads like 2 steps, then they click on those items, read more and think Frontity is dead easy to use. The long paragraphs (like I’m writing now) are (as you know at the end of this response) a little overwhelming to see when learning a new framework and get in the way of someone who is just referencing something they learned before.

Let me know if I can clarify it further and thanks for following up with me!

1 Like

Here’s an update on the issue that I hope helps someone in the future; although, it isn’t totally related to the issue with the documentation:

I was using a URL for the WordPress site like wpadmin.toursmv.com and tried embedded mode on that installation. Once I figured out the issue I was having, it worked great; however, that’s not a great domain for launching. So I thought I’d just clone the site and set it up under toursmv.com (without the subdomain)…

DO NOT DO THIS! In the process of doing this, my server went haywire and used up all of it’s bandwidth and memory. Probably the best practice is to disable embedded mode first, then clone the site and make sure that the following are all pointed to the right place:

  1. Always make a backup of everything before you do this stuff. uploads folder, database, and current theme if you haven’t.
  2. Disable the “Frontity Embedded Mode” plugin.
  3. Make sure that the domain you will be deploying your back end and front end in embedded mode is pointing to the server serving the files.
  4. Now you could probably clone the site and start setting up embedded mode again.
  5. Make sure you’ve set your --public-path correctly in the build task of package.json in your Frontity project.
  6. Re-activate the “Frontity Embedded Mode” plugin and make sure the URL in its settings is correct.
  7. Clear the cache if you have one (might as well since things are changing).

I don’t think I missed anything but just be thorough because the website was very unresponsive to me for like 30-40 minutes while I was trying to figure out what was going on. Had I followed these steps, it probably wouldn’t have been an issue.

1 Like

Thanks, @david1 for all this feedback and the detailed explanation!
It has a lot of value. It will be taken into account for re-writing the documentation page of the Embedded Mode plugin :+1:

Hi @david1

Thanks for your feedback on the embedded mode docs. This is just a reminder (to anyone that has ideas or suggestions that could improve our docs) that all our docs are on GitHub and you can suggest changes in a pull request.

Although the Frontity team works with the framework all the time, we’re not really building real-world projects in the way that users of the framework are. So contributions to the docs from developers encountering real-world experiences and real-world issues while building real-world projects would be extremely valuable.


@david1 We’ve updated the following docs pages

…using your valuable feedback. Thanks a lot again for it.

Feel free to open a PR in the docs for more suggestions to improve the docs as @mburridge suggests above

@juanma thanks a lot for taking my suggestions into consideration; it looks great! I have it on my radar to contribute to Frontity more in the future as well as Vue Storefront as I am quite actively working with both libraries but with a full-time job, I find it a bit tricky. I will try to carve out some time in the future.