Google Webfonts einbinden klappt nicht mit Hausmitteln

Druckbare Version

09.03.2017, 12:40
tofo

Google Webfonts einbinden klappt nicht mit Hausmitteln

Hallo,

mir ist aufgefallen, dass wenn ich zwei Webfonts via Layout -> Webfonts einbinde, wird das Bar Zeichen "|" in einen normalen HTML Charakter umgewandelt:

HTML-Code:

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Oswald%7CQuattrocento">

Einbinden ging bei mir nur dann, wenn ich den Code als zusätzlichen <head>-Tag eingebunden habe:

HTML-Code:

<link href="https://fonts.googleapis.com/css?family=Oswald|Quattrocento" rel="stylesheet">

Ist das schon mal wem aufgefallen?

Gruß, Thomas
09.03.2017, 12:55
korlbeu

Ich binde webfonts eigentlich immer in meine css datei ein....

per:

HTML-Code:

@import url(https://fonts.googleapis.com/css?family=Open+Sans:400,300);
09.03.2017, 12:55
Stefko

Zitat:

Zitat von tofo

Hallo,

mir ist aufgefallen, dass wenn ich zwei Webfonts via Layout -> Webfonts einbinde, wird das Bar Zeichen "|" in einen normalen HTML Charakter umgewandelt:

HTML-Code:

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Oswald%7CQuattrocento">

Das | in der URL durch %7C encoded wird ist schon korrekt (siehe hier: https://www.w3schools.com/tags/ref_urlencode.asp).
Da kann der Fehler eigentlich nicht liegen, hast Du es mal mit anderen Browsern oder an einem anderen Rechner probiert?
Ich würde eher in der Richtung den Fehler vermuten.

Grüße,
Stefko
09.03.2017, 13:11
stefan-at-work

was spricht dagegen, die Anweisung direkt im Seitenlayout unter Webfonts einzutragen?

Code:

Open+Sans:400,700|Roboto:400,700
09.03.2017, 13:28
Stefko

Zitat:

Zitat von stefan-at-work

was spricht dagegen, die Anweisung direkt im Seitenlayout unter Webfonts einzutragen?

Code:

Open+Sans:400,700|Roboto:400,700

Meiner Meinung nach nix, mache ich genauso. Nur hat der Threadopener ja das Problem, dass es dann bei ihm wohl nicht korrekt funktioniert. Woran das liegt kann ich auch nicht sagen, aber das encodierte "|" (%7C) würde ich ausschließen.

Grüße,
Stefko
09.03.2017, 13:41
stefan-at-work

das Pipe-Problem besteht aber IMHO nur, wenn man es als HTML-Code einbindet.
09.03.2017, 13:46
Stefko

Zitat:

Zitat von stefan-at-work

das Pipe-Problem besteht aber IMHO nur, wenn man es als HTML-Code einbindet.

Aber er schrieb doch zu Beginn:
"... wenn ich zwei Webfonts via Layout -> Webfonts einbinde, wird das Bar Zeichen "|" in einen normalen HTML Charakter umgewandelt"
Das klingt für mich schon so, als ob er es eben genau wie von Dir beschrieben versucht hätte. Im Quellcode steht dann eben %7C anstatt der Pipe und dort vermutete er die Ursache, dass die ganze Geschichte bei ihm nicht funktioniert.
Vielleicht meldet sich tofo ja nochmal zu Wort und löst die Konfusion ein wenig auf :D
09.03.2017, 14:54
tofo

Liste der Anhänge anzeigen (Anzahl: 3)

Das Problem entsteht gerade dann, wenn ich es über Webfonts in Contao einbinde, aber NICHT, wenn ich es als zusätzlichen HEAD-Tag einbinde. Sprich, schreibe ich die Fonts in das Feld für Webfonts in Contao rein, wird das Pipe-Zeichen in ein HTML-Entity umgewandelt. Somit werden die Webfonts nicht geladen.

Ich habe zur Veranschaulichung Screenshots gemacht. _1 ist der Eintrag im normalen Contao-Feld, _2 der Eintrag in HEAD-Tags, _3 zeigt den Quellcode, den Contao produziert. Der oberee LINK-Tag ist der von Webfonts, der darunter aus der HEAD-Sektion.

Gruß, Thomas

Anhang 19008
Anhang 19009
Anhang 19010
09.03.2017, 15:09
stefan-at-work

okay, dann mach am besten mal ein Contao-Check und überprüfe, ob alles korrekt installiert ist. Bei uns funzt das auf diversen Instanzen ohne die geschilderten Probleme
09.03.2017, 15:11
tofo

Zitat:

Zitat von stefan-at-work

okay, dann mach am besten mal ein Contao-Check und überprüfe, ob alles korrekt installiert ist. Bei uns funzt das auf diversen Instanzen ohne die geschilderten Probleme

Fresh installation direkt out of the box. Check sagt: alles in Ordnung.

Gruß, Thomas
09.03.2017, 15:12
Spooky

Poste einen Link zur Seite.
09.03.2017, 15:39
tofo

http://contao.tomdoodle.com
09.03.2017, 15:53
Spooky

Zitat:

Zitat von tofo

http://contao.tomdoodle.com

Funktioniert alles problemlos dort.

Das einzige was auffällig ist:

Du hast diese Google Fonts zwar eingebunden, aber du benutzt sie nicht.
09.03.2017, 16:13
stefan-at-work

Versuche mal in den Anweisungen den Schnitt mitzugeben -> Oswald:400|Quattrocento:400
09.03.2017, 16:14
Spooky

Er muss nichts ändern, es funktioniert ja schon (außer er braucht bestimmte Schriftschnitte, dann müssen die natürlich angegeben werden).
09.03.2017, 20:03
tofo

Zitat:

Zitat von Spooky

Funktioniert alles problemlos dort.

Das einzige was auffällig ist:

Du hast diese Google Fonts zwar eingebunden, aber du benutzt sie nicht.

Die Seite ist ja noch nicht fertig, hab ja gerade erst angefangen, diese aufzusetzen. Wie meinst Du es funktioniert alles problemlos? Dass %7C im Quellcode steht, wenn die Google Fonts via Webfonts-Feld eingebunden werden, ist normal?

Gruß, Thomas
09.03.2017, 20:29
Spooky

Zitat:

Zitat von tofo

Wie meinst Du es funktioniert alles problemlos?

Wenn man per CSS bspw.

Code:

font-family:'Oswald';

setzt, wird auch diese Schriftart benutzt.

Zitat:

Zitat von tofo

Dass %7C im Quellcode steht, wenn die Google Fonts via Webfonts-Feld eingebunden werden, ist normal?

Ja, das ist normal, wurde ja auch schon mehrmals erwähnt.
24.04.2017, 08:02
Jens_

Umstellung Webfonts auf SSL

Hallo zusammen,

ich nutze in Contao 3.5.25 die Google Webfonts in einer Installation. Diese sind im Theme/Seitenlayout in das entsprechende Feld eingegeben. Vor https hat alles prima funktioniert. Nach Umstellung auf SSL werden die Webfonts weiterhin per http ausgeliefert und daher vom Browser als unsicher gebrandmarkt.

Im Template finde ich dies:
<?php /* http://www.smashingmagazine.com/2012...gle-web-fonts/ */ ?>


<link href="http://fonts.googleapis.com/css?family=Merriweather:400italic,700italic,400,70 0" rel="stylesheet" type="text/css">


Wenn ich das alles manuell auf https anpasse, wird die Seite ohne CSS geladen. Dafür bekomme ich keine Fehler mehr angezeigt. Hat jemand damit bereits Erfahrungen gesammelt?

Viele Grüße
Jens_
24.04.2017, 08:28
Spooky

Poste einen Link zur Seite.
24.04.2017, 08:37
do_while

Wenn Du eine https-Seite hast, musst Du alle Links zu den Fonts auch mit https aufrufen.
Das sollte bei Google-Fonts auch kein Problem sein, einfach aus http ein https machen.
24.04.2017, 17:17
Jens_

SSL und Webfonts von Google

Hallo Spooky und do_while,

vielen Dank für Eure Antworten. Eigenartig ist, dass ich das auf https umgestellt habe - und dann kein CSS mehr geladen wird. Für mich völlig unerklärlich. Wenn ich es auf http lasse, "beschwert" sich ein SSL-Check-Tool, nicht aber ein Firefox- oder Safari-Browser. Hier der Link zur Seite: https://www.studienreisen-polen.de/
Und dieser SSL-Check beschwert sich, obwohl in den 2 getesteten Browsern alles gut aussieht: https://www.jitbit.com/sslcheck/

Für mich nicht ganz logisch?

Grüße
Jens_
24.04.2017, 17:53
tab

Naja, für den Firefox und Safari ist das ein ganz normaler HTML-Kommentar, warum also meckern? Das Tool aber merkt, dass im IE das CSS unsicher geladen würde und meckert deshalb. Warum das als https nicht geladen werden sollte weiss ich aber auch nicht. Was innerhalb der conditional comments steht sollte ja eigentlich sowieso nur den IE betreffen.
24.04.2017, 18:06
Spooky

Zitat:

Zitat von Jens_

Hallo Spooky und do_while,

vielen Dank für Eure Antworten. Eigenartig ist, dass ich das auf https umgestellt habe - und dann kein CSS mehr geladen wird. Für mich völlig unerklärlich. Wenn ich es auf http lasse, "beschwert" sich ein SSL-Check-Tool, nicht aber ein Firefox- oder Safari-Browser. Hier der Link zur Seite: https://www.studienreisen-polen.de/
Und dieser SSL-Check beschwert sich, obwohl in den 2 getesteten Browsern alles gut aussieht: https://www.jitbit.com/sslcheck/

Für mich nicht ganz logisch?

Grüße
Jens_

Du musst es auf jeden Fall auf HTTPS setzen. Aktuell kann die Schriftart Merriweather so nicht benutzt werden.
24.04.2017, 20:39
Jens_

Schriftart

Hallo noch mal,

ich muss noch mal nachfragen: Merriweather geht generell nicht als Schriftart mit https, oder funktioniert es, wenn ich sie auf https setze? Dann aber sind meine Styles alle weg; dafür habe ich allerdings keine Erklärung.

Danke und Grüße
Jens_
24.04.2017, 21:04
do_while

Grundsätzlich geht die Schrift natürlich. Prinzip ist, alles externen Inhalte müssen auch auf https umgestellt werden.

Deine Styles kommen intern aus Contao. Der base-Tag und die internen Links im Quellcode scheinen aber richtig zu sein.
Manuell kann ich unter dem https-Link zu den Styles Deine Styles aus assets/css/e24a0c4c672f.css laden.
Hast Du schon mal die Caches im Browser und in Contao geleert?
Ansonsten scheint etwas in Deinem Contao nicht zu stimmen, prüfe das mit dem Contao-Check.
24.04.2017, 22:02
Spooky

Zitat:

Zitat von Jens_

Hallo noch mal,

ich muss noch mal nachfragen: Merriweather geht generell nicht als Schriftart mit https, oder funktioniert es, wenn ich sie auf https setze? Dann aber sind meine Styles alle weg; dafür habe ich allerdings keine Erklärung.

Danke und Grüße
Jens_

Stelle es auf HTTPS um und poste einen Link zur Seite, damit man analysieren kann, warum dann alle Styles weg sind.
25.04.2017, 10:09
PaddySD
Alles Quark... :D :D :D

Wenn Du Google-Webfonts einbindest, reicht es mittlerweilen völlig aus, diese normal (idealerweise direkt in Contao über das vorgesehene Feld dafür) einzubinden. Google bietet von sich aus schon Support für alle IE grösser IE6. Also raus mit diesen ganzen zusätzlichen Empfehlungen aus dem Jahr 2012, die sind alt und überholt.

Heisst für Dich:
1. Trage den Webfont in der Konfiguration von Contao ein
2. Stelle die Seite auf https um
3. Entferne all diesen zusätzlichen, furchtbaren Code im Template
4. Hab Spass
So, und jetzt sollte alles klappen. Warum es bislang nicht funktioniert ist: Du rufst eine css-datei auf, die so nicht mehr ausgeliefert wird von Google. Daher klemmt es dann in den weiteren Aufrufen der css-Dateien (eben Deiner eigenen aus Contao zB).
30.04.2017, 08:10
Jens_

Danke für die Tipps

Hallo Paddy, Spooky und do_while,

Danke für Eure Hinweise. Ich war zwischenzeitlich ziemlich verwirrt, weil ich viele von den Dingen getestet habe. Bereinigt habe ich die alten Anweisungen für den IE. Danach wurde es auch nicht besser; das Problem war, dass es immer ging, wenn ich mich einmal eingelogged habe. Erst nach dem Backend-Cache-Ende tauchte das Problem wieder auf. Das verwirrt mich noch immer ein bisschen.

Nun habe ich eine andere Stelle ausgemacht; und zwar im Piwik-Tracking-Code. Den habe ich auch noch einmal bereinigt, da war noch ein Bug im Piwik-Template. Ich hoffe mal, dass es das war.

Ich drücke mal die Daumen, dass es nun tut, und zwar auf allen Browsern... :-)

Beste Grüße
Jens_
04.05.2017, 07:03
Jens_

SSL

Hallo zusammen,

vielleicht kann mir irgend jemand noch einen Tipp geben: Die Schrift-Themen mit den Webfonts sind bereinigt, wie vorgeschlagen. Es ist nur noch im Contao-Backend eingetragen, dass die Googlefonts verwendet werden sollen. Immer, wenn ich nach Anpassungen teste, ist alles okay. Einen Tag später (passt zum Contao-Cache...) wird die Seite dann wieder als unsicher eingestuft und ohne CSS dargestellt, aber nur einzelne Seiten. Hat noch irgendjemand eine Idee?

Komisch ist, dass im Firebug auch eigentlich ganz klar von Contao ausgelieferte Elemente (CSS, Javascript-Teile von jquery etc.) als unsicher klassifiziert werden und damit die Ursache sein könnten. Aber warum lädt das System bei Aufruf per https diese Elemente per http?

Beste Grüße
Jens
04.05.2017, 07:09
Spooky

Poste einen Link zur Seite, wo bzw. wenn man das Problem sieht.
04.05.2017, 07:12
Jens_

Link

https://www.studienreisen-polen.de/
04.05.2017, 07:38
tab

Deine Seiten sind alle auch noch per http erreichbar. Damit gelangen so aufgerufene Seiten in den Contao-Seitencache und werden - auch bei nachfolgenden Aufrufen per https - aus dem Cache ausgeliefert. Da stehen dann natürlich die Links alle mit http drin. Als erste >Maßnahme solltest du per .htaccess dafür sorgen, dass alle Aufrufe über http auf https weitergeleitet werden. Danach dann den Seitencache löschen. Falls dann noch Probleme auftreten muss man weitersehen.
04.05.2017, 07:49
Spooky

Zitat:

Zitat von tab

Da stehen dann natürlich die Links alle mit http drin.

Links nicht unbedingt - dafür aber der <base href>
04.05.2017, 10:15
tab

Ja, so war es natürlich gemeint, dadurch wird eben jede URL, die nicht explizit absolut mit https angegeben ist, mit http aufgerufen.
04.05.2017, 16:20
Jens_

Danke!

Hallo an Euch alle,

nun habe ich das auch in einem anderen Thread hier gefunden; genau das war das Problem. Dadurch, dass ich zuerst https parallel zu http testen wollte, hat sich der Cache zum Teil mit http aufgebaut, zum Teil mit https. Komischerweise hatte ich das bei 20 anderen Seiten, die ich umstellte, nicht. Nur bei dieser. Nun habe ich fest auf https umgestellt und es sollte wohl klappen. Blöd, dass ich da nicht vorher drauf gekommen bin; ich hatte nach dem Unterschied zwischen dieser und den anderen Seiten gesucht, und das waren die Webfonts, die auch zunächst mit http eingebunden waren. Daher war die Ursachenvermutung schnell dort.

Danke noch mal, großen Danke!

Beste Grüße
Jens_

Alle Zeitangaben in WEZ +1. Es ist jetzt 15:30 Uhr.