Multisite – MIME type issue on JS file

@luckycabarlo – That is the first I’ve seen that error message. It indicates that there may be a permission issue in your wp-uploads folder where those files are stored.

To be clear we save the file by normal methods so something on your specific setup is changing the mimetype served. I just checked and by default the file should be served as Content-Type: application/javascript; charset=utf-8, for whatever reason yours is serving it as image/js.

I would check with your host and see if they can offer any insights.

@danieliser – When I checked your code, I think you’re using WP_FILESYSTEM to save the js setting on a multisite setup. Is there any way we can force the file being saved to use Content-Type: application/javascript?

If it’s a server issue, do you have any idea on what to change?

By the way we are also uaing the latest wp version.

@danieliser – Here is the link from our main site and subsite with popup maker.

https://agentmarketingcloud.com.au/real-estate-copywriting/ – Send Us A Brief button

https://tamaralee.agentmarketingcloud.com.au/property/house-qld-ashgrove-127272186/ – Send Enquiry or Map Button

You’ll see that from the main site that the link to js file is from the wp-uploads folder whereas the subsite has different filepath.

https://agentmarketingcloud.com.au/wp-content/uploads/pum/pum-site-scripts-1.js?defer&generated=1522795822&ver=1.7.14

https://tamaralee.agentmarketingcloud.com.au/files/pum/pum-site-scripts-40.js?defer&generated=1522821169&ver=1.7.14

@luckycabarlo – My first thought was that we weren’t specifying file type using WP_Filesystem, but from what I could see digging in this afternoon that function doesn’t offer anything related to writing file types. Also, nobody else has reported this issue which means its atypical and very rare conditions to produce in the first place.

Now that you have shown path differences that may indicate your site has modified the uploads directory for each subsite somehow. We use WP built-in functions to prepare those file paths, so if those folders don’t exist or there is a permission error in them it may be unrelated to our plugin and more related to the custom setup used & possibly server permissions. Might be worth chatting with your host.

Bt default from my experience subsites should be storing uploads in wp-content/uploads/ as there is no /files/ path by default. I’m leaning toward the /files/ folder having strict rules in nginx or something like that.

@danieliser – all we did was update the plugin, we haven’t touched the filepaths or directories at all. We are managing our own host and have access to the server.

You might also wanna test it on a multisite setup using a subdomian approach. We didn’t change anything from the Upload Path on our subsites, we’re using the default data coming from WordPress which is something like this: wp-content/blogs.dir/40/files

You’re saying that the it should store in wp-content/uploads/ on the subsite. I tried to echo the upload directory on your code located on this file:
/classes/Helpers.php – public static function upload_dir_url( $path = ” )

	public static function upload_dir_url( $path = '' ) {
		$upload_dir = wp_upload_dir();
		$upload_dir = $upload_dir['baseurl'];
		print_r($upload_dir);
		die();
		$upload_dir = preg_replace( '/^https?:/', '', $upload_dir );

		if ( ! empty ( $path ) ) {
			$upload_dir = trailingslashit( $upload_dir ) . $path;
		}

		return $upload_dir;
	}

The data showing on our end is like this: https://tamaralee.agentmarketingcloud.com.au/files

I’m seeing this issue as well. I’m running the latest plugin version on WP Multisite.

My site is here: https://twimlai.com/

If you visit the homepage and look at the JS console, you’ll see the error:

Refused to execute script from ‘https://twimlai.com/files/pum/pum-site-scripts-7.js?defer&generated=1536552723&ver=1.7.30’ because its MIME type (‘text/plain’) is not executable, and strict MIME type checking is enabled.

The file does load at that URL, it’s just the wrong mime type is sent.

Any ideas?

Disabling asset caching fixed this for me, but not sure the performance implications.