Die Seite wurde über HTTPS geladen, aber eine unsichere Schriftart angefordert – aber alle Links sind HTTPS

Ich habe eine WP-Site, die einige benutzerdefinierte Schriftarten aus einem Verzeichnis auf derselben Seite lädt. Es gab bisher keine Probleme damit. Ich vermute, es könnte ein Plugin sein, das etwas mit der .htaccess gemacht hat.

Mixed Content: The page at 'https://www.mypage.net/' was loaded over HTTPS, but requested an insecure font 'http://www.mypage.net/'. This request has been blocked; the content must be served over HTTPS.

Normalerweise können Sie dies einfach durch Hinzufügen beheben s am Ende von HTTP, aber alle Links sind HTTPS – aber es sagt, dass es nicht so ist. Ich habe die überprüft <link> zum Schrift-Stylesheet. Ich habe dann das Stylesheet überprüft und alle Links sind HTTPS und absoluter Pfad.

Die Seite erzwingt eine HTTPS-Weiterleitung, und in den Einstellungen des WP ist die Seite so definiert, dass sie eine URL mit HTTPS hat.

UPDATE: Nach langem Testen und Basteln endlich gelöst.

Zuerst; Mein Schriftartenordner hatte eine .htaccess Regel, um das Herunterladen (Lizenz erforderlich) von einem anderen Ursprung als der Website selbst zu verhindern. Einer der RewriteRule hatte HTTP statt HTTPS:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mypage\.net/ [NC]
RewriteCond %{REQUEST_URI} !hotlink\.(ttf|otf|woff|woff2|eot) [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in.*$ [NC]
RewriteRule .*\.(ttf|otf|woff|woff2|eot)$ http://www.mypage.net/ [NC]
                                          ^^^^^

Ich habe das auf HTTPS korrigiert und dann zu einem anderen Fehler geändert:

Failed to decode downloaded font: https://mypage.net/fonts/font.woff
OTS parsing error: invalid version tag

Um dies zu beheben, musste ich sicherstellen, dass meine Schriftarten dies hatten Unterstützung für tiefe Schriftartendie es hatte, und dann habe ich irgendwo gelesen, dass es durch Hinzufügen der Version zum Link (?v=x) gelöst werden könnte, z.

src: url('https://mypage.net/fonts/font.woff?v=1') format('woff');

Dies funktionierte mit .woff, .woff2 und .eot, aber aus irgendeinem Grund nicht mit .ttf. Das Hinzufügen der Versionserweiterung zu .ttf würde mir 404 geben. Ich habe tatsächlich auch einmal festgestellt, dass es mir einfach 404 ohne die Erweiterung gegeben hat. Ich ging auf die Beine und bewegte die src: url('…'); mit dem .ttf von unten nach oben und das hat beide Fehler irgendwie gelöst.

An diesem Punkt gab es mir keine Fehler, aber jetzt wurde die Schriftart einfach nicht geladen. Es wurde auf den Fallback umgestellt. Nach zufälliger Suche stellte ich fest, dass die über das Plug-in hochgeladenen benutzerdefinierten Schriftarten (ProPhoto6 – sie erlauben nur X hochgeladene benutzerdefinierte Schriftarten, was dumm ist) eine andere Lese-/Schreibberechtigung hatten. Ich habe die Berechtigungen auf den Wert geändert, den alle von mir verwendeten Schriftarten hatten (Schriftarten, die von ProPhoto hochgeladen wurden und verwendet wurden); 0666 (hatte 0644). Dadurch wurde es endlich fehlerfrei geladen.

Sie können versuchen, ein Plugin namens hinzuzufügen Wirklich einfaches SSL um zu prüfen, ob das dein Problem löst