The downsides: the UX is a little janky (for example, Subscribers > Unsubscription and Subscription > Unsubscription both lead to the same fairly useless page which lets you customize the unsubscribe message. Subscribers > Statistics > By Time shows two confusing line graphs… apparently the “by day” is subscribers added each day non-cumulatively, and “by month” is the same info cumulatively? Seems like there could be better statistics.) We got 20 unsubscriptions and ALL 20 show the EXACT same time and date for when they unsubscribed… is that a bug or did Newsletter’s unsub link get auto-clicked by the mail client? And the documentation isn’t always great; I used trial-and-error to figure out which variable name to use for subscriber firstname because the docs were no help. Lastly, the mail tester at aboutmy.email says that the Newsletter list-unsubscribe header is outdated. “List-Unsubscribe header has been MIME encoded. This may work at some mailbox providers but is not valid.”

That said, these are minor gripes compared to the overall positive: this does the job well, it supports unsubscribe headers and list mail merge, and it creates a legit unsubscribe page on my WordPress site for full Google/Yahoo compliance.

This would mean I have to re-upload all ttf fonts.

The Hide font files from Media Library setting is off.

Any ideas?

But I have already added the support to .wma file type as below:

   // Add this filter to allow mime file uploads
   add_filter('upload_mimes', array($this, 'allow_mime_uploads')); 

    public function allow_mime_uploads($mimes) {
        $mimes['epub'] = 'application/epub+zip';
        $mimes['djvu'] = 'image/vnd.djvu';
        $mimes['jfif'] = 'image/jpeg';
        $mimes['htm'] = 'text/html';
        $mimes['html'] = 'text/html';
        $mimes['svg'] = 'image/svg+xml';
        $mimes['eps'] = 'application/postscript';
                $mimes['psd'] = 'image/vnd.adobe.photoshop';
                $mimes['mobi'] = 'application/x-mobipocket-ebook';
                $mimes['vob'] = 'video/dvd';
                $mimes['dwg'] = 'image/vnd.dwg';
                $mimes['wma'] = 'audio/x-ms-wma';

        return $mimes;
    }  

The other file types, such as .dwg can be uploaded after adding the mime type, but .wma does not work.

Refused to apply style from ” because its MIME type (‘text/html’) is not a supported stylesheet MIME type, and strict MIME checking is enabled. Can anyone shed any light on a fix for this?

XML 1.0 document or

ASCII text,

I have tried both of these and it shows as:

docx file’s type is invalid.

Is anyone familiar with WP forms plugin “File upload types” ?

Surely, getting WordPress to allow Word documents can’t be that unusual?

Any help appreciated.

The resource from “/wp-content/litespeed/js/fad5a5209149c25cf94bb164ee74224f.js?ver=894d8” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff)

The resource from “/wp-content/litespeed/css/a7fce63fe22174b3ad57c6bd0a5c8102.css?ver=894d8” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).

When we follow these links, the server returns a 404. So, is there a problem with the cache update?

After logging into the admin panel and clearing the cache, this problem disappears.

Can you advise me what this problem can be related to in your opinion?

In the LiteSpeed plugin settings, combining styles and scripts is enabled.

Refused to apply style from ‘https://wordpress-575834-3536436.cloudwaysapps.com/#’ because its MIME type (‘text/html’) is not a supported stylesheet MIME type, and strict MIME checking is enabled.

When deactivating either the header security or cookie plugin – the error disappears.

I’ve found that this line in the HTACCESS clashes with Complianz:

Header always set X-Content-Type-Options “nosniff”

I’ve currently deactivated the Header Security plugin and using the other htaccess settings it writes (manually written in the htaccess).

Is this something you can fix? Or is there a better workaround than what I did?

Thanks

1. Content-Type: text/plain;
2. Content-Type: text/html;

Background: Not all email clients can view html (and, indeed, some users prefer to disable HTML in their email clients), so it’s normal practice for mass emails to be sent in the two above formats.

When you send an email with *both* content types, it allows the user’s mail client to display the email in whichever format they choose.

On my fresh install of WooCommerce, it only sends the emails in html format, which makes reading the email contents nearly impossible in my email client. I could change it to “plaintext”, but then it wouldn’t display in html for users who choose to view html emails.

How can I configure WooCommerce to send emails in *both* plaintext *and* html?