Ausgabe von Schriftart-Feld funktioniert nicht mit bestimmter Font
SOLVE
Hallo,
Ich wurde vom Support hierher verwiesen und gebe das Ticket einfach mal 1 zu 1 hier weiter.
Ich habe folgendes Problem festgestellt. Das Beispiel befindet sich auf der Landingpage "GladiatorPLUS - LP TEST". Ich habe beim "Headline" Element die Möglichkeit hinzugefügt die Schriftart jeweils für Desktop und Mobil zu überschreiben. Das Ganze dann via CSS. Dies funktioniert ansich auch. Jedoch explizit nicht für die Font "PT Sans". Wenn diese Schriftart ausgewählt ist, ist das gerenderte CSS immer leer. Andere Fonts funktionieren. Wenn ich das CSS Inline direkt aufs Element setzte funktioniert allerdings auch "PT Sans", also das Problem besteht nur, wenn versucht wird es per CSS zu setzen. Das gilt für alle Fonts mit Leerzeichen im Namen.
Inline überschreiben ist allerdings keine Option mehr, da ich ja nun zwei Viewports getrennt überschreiben möchte.
Ich hoffe die Screenshots sind verständlich.
Die KI Antwort hat bereits vorgeschlagen "escape_css_string" zu verwenden. Beispiel:
In meinem Beispiel gibt {{name}} den Namen des Moduls aus. Indem ich es also als Div des übergeordneten Divs "id" festlege und es dann in meinem CSS wie #{{name}} aufrufe, erreiche ich dasselbe wie scope_css, da {{name}} für die Instanz des Moduls auf der Seite eindeutig ist.
In my example {{name}} prints the name of the module, so by setting it as the div of the parent div and then calling it like #{{name}} in my css, it achieves the same thing as scope_css as the {{name}} is unque to the instance of the module on the page
in HubL gibt es leider kein escape_css_string filter.
Fonts sollten auch optimalerweise nicht im Modul, sondern im Theme definiert werden. Du möchtest ja nicht, auf jeder Seite, pro Modul die Schrift einstellen. Die Definition der Font mittels Theme fields.json ist hierfür optimal.
Darüber hinaus finde ich die "upload custom font" option des Font fields zwar benutzerfreundlich, wenn du jedoch komplett Cordporate Design konform und ohne Kopfschmerzen arbeiten möchtest, empfehle ich einen der folgenden Wege.
Um für die verschiedenen breakpoints etwas anderes zu definieren, nutze sogenannte media-queries. Ich empfehle von klein zu groß zu gehen, da dies zu einem saubereren Code führt.
Beispiel:
{# Greift immer / mobile #}
body{
font-family: 'PTSans', Arial, sans-serif;
font-size:16px;
font-weight:400;
}
h1,h2,h3,h4,h5,h6{
font-family: 'PTSans', Arial, sans-serif;
font-weight:600;
}
h1{
font-size:28px;
}
h2{
font-size:24px
}
...
@media screen and (min-width:1024px){
{# Für Bildschirme ab 1024px Breite #}
h1{
font-size:40px;
}
h2{
font-size:32px;
}
...
}
@media screen and (min-width:1400px){
{# Für Bildschirme ab 1400px Breite #}
h1{
font-size:48px;
}
h2{
font-size:36px;
}
...
}
2. Custom Fonts die du selber hochlädst bzw. hostest und die keinen @import oder style-link tag verfügen
Du kannst deine TTFs, OTFs, WOFF etc. files entweder in den File-Manager oder Design-Manager hochladen und sie mittels Font-Face rules in der CSS Datei wie im vorherigen Code definieren.
Bindest du die Fonts entsprechend global ein, musst du dir keine Gedanken um die individuelle Definition in Modulen machen. Möchtest du dies trotztdem haben, so empfehle ich es mittels CSS Klassen und bspw. Choice Fields zu machen.
Möchtest du noch mehr Kontrolle, so kannst du im Prinzip alles machen. Für Schriftgrößen nutze ich meist Number fields. Du musst sie nur entsprechend definieren und gruppieren. Mein persönlicher Aufbau in Themes (nicht Module) ist folgender:
===== English translation (using DeepL because I don't want to type the whole thing twice 🙂 ) ====
Unfortunately there is no escape_css_string filter in HubL.
Fonts should ideally not be defined in the module, but in the theme as you don't want to set the font for each module on each page.
Defining the font using theme fields.json is ideal for this.
In addition, I find the “upload custom font” option of the font field user-friendly, but if you want to work completely Cordporate Design compliant and without headaches, I recommend one of the following ways.
To define something different for the different breakpoints, use so-called media-queries. I recommend going from small to large, as this leads to cleaner code.
Example:
{# works always / mobile #}
body{
font-family: 'PTSans', Arial, sans-serif;
font-size:16px;
font-weight:400;
}
h1,h2,h3,h4,h5,h6{
font-family: 'PTSans', Arial, sans-serif;
font-weight:600;
}
h1{
font-size:28px;
}
h2{
font-size:24px
}
...
@media screen and (min-width:1024px){
{# For screens larger than 1024px width #}
h1{
font-size:40px;
}
h2{
font-size:32px;
}
...
}
@media screen and (min-width:1400px){
{# For screens larger than 1400px width #}
h1{
font-size:48px;
}
h2{
font-size:36px;
}
...
}
2. custom fonts that you upload or host yourself and that do not have an @import or style-link tag
You can upload your TTFs, OTFs, WOFF etc. files either to the File Manager or Design Manager and define them using font face rules in the CSS file as in the previous code.
If you integrate the fonts globally, you don't have to worry about the individual definition in modules. If you still want to do this, I recommend using CSS classes and, for example, choice fields.
Möchtest du noch mehr Kontrolle, so kannst du im Prinzip alles machen. Für Schriftgrößen nutze ich meist Number fields. Du musst sie nur entsprechend definieren und gruppieren. Mein persönlicher Aufbau in Themes (nicht Module) ist folgender:
===== English translation (using DeepL because I don't want to type the whole thing twice 🙂 ) ====
Unfortunately there is no escape_css_string filter in HubL.
Fonts should ideally not be defined in the module, but in the theme as you don't want to set the font for each module on each page.
Defining the font using theme fields.json is ideal for this.
In addition, I find the “upload custom font” option of the font field user-friendly, but if you want to work completely Cordporate Design compliant and without headaches, I recommend one of the following ways.
To define something different for the different breakpoints, use so-called media-queries. I recommend going from small to large, as this leads to cleaner code.
Example:
{# works always / mobile #}
body{
font-family: 'PTSans', Arial, sans-serif;
font-size:16px;
font-weight:400;
}
h1,h2,h3,h4,h5,h6{
font-family: 'PTSans', Arial, sans-serif;
font-weight:600;
}
h1{
font-size:28px;
}
h2{
font-size:24px
}
...
@media screen and (min-width:1024px){
{# For screens larger than 1024px width #}
h1{
font-size:40px;
}
h2{
font-size:32px;
}
...
}
@media screen and (min-width:1400px){
{# For screens larger than 1400px width #}
h1{
font-size:48px;
}
h2{
font-size:36px;
}
...
}
2. custom fonts that you upload or host yourself and that do not have an @import or style-link tag
You can upload your TTFs, OTFs, WOFF etc. files either to the File Manager or Design Manager and define them using font face rules in the CSS file as in the previous code.
If you integrate the fonts globally, you don't have to worry about the individual definition in modules. If you still want to do this, I recommend using CSS classes and, for example, choice fields.
If you want even more control, you can basically do anything. I usually use number fields for font sizes. You just have to define and group them accordingly. My personal structure in themes (not modules) is as follows:
In meinem Beispiel gibt {{name}} den Namen des Moduls aus. Indem ich es also als Div des übergeordneten Divs "id" festlege und es dann in meinem CSS wie #{{name}} aufrufe, erreiche ich dasselbe wie scope_css, da {{name}} für die Instanz des Moduls auf der Seite eindeutig ist.
In my example {{name}} prints the name of the module, so by setting it as the div of the parent div and then calling it like #{{name}} in my css, it achieves the same thing as scope_css as the {{name}} is unque to the instance of the module on the page
in HubL gibt es leider kein escape_css_string filter.
Fonts sollten auch optimalerweise nicht im Modul, sondern im Theme definiert werden. Du möchtest ja nicht, auf jeder Seite, pro Modul die Schrift einstellen. Die Definition der Font mittels Theme fields.json ist hierfür optimal.
Darüber hinaus finde ich die "upload custom font" option des Font fields zwar benutzerfreundlich, wenn du jedoch komplett Cordporate Design konform und ohne Kopfschmerzen arbeiten möchtest, empfehle ich einen der folgenden Wege.
Um für die verschiedenen breakpoints etwas anderes zu definieren, nutze sogenannte media-queries. Ich empfehle von klein zu groß zu gehen, da dies zu einem saubereren Code führt.
Beispiel:
{# Greift immer / mobile #}
body{
font-family: 'PTSans', Arial, sans-serif;
font-size:16px;
font-weight:400;
}
h1,h2,h3,h4,h5,h6{
font-family: 'PTSans', Arial, sans-serif;
font-weight:600;
}
h1{
font-size:28px;
}
h2{
font-size:24px
}
...
@media screen and (min-width:1024px){
{# Für Bildschirme ab 1024px Breite #}
h1{
font-size:40px;
}
h2{
font-size:32px;
}
...
}
@media screen and (min-width:1400px){
{# Für Bildschirme ab 1400px Breite #}
h1{
font-size:48px;
}
h2{
font-size:36px;
}
...
}
2. Custom Fonts die du selber hochlädst bzw. hostest und die keinen @import oder style-link tag verfügen
Du kannst deine TTFs, OTFs, WOFF etc. files entweder in den File-Manager oder Design-Manager hochladen und sie mittels Font-Face rules in der CSS Datei wie im vorherigen Code definieren.
Bindest du die Fonts entsprechend global ein, musst du dir keine Gedanken um die individuelle Definition in Modulen machen. Möchtest du dies trotztdem haben, so empfehle ich es mittels CSS Klassen und bspw. Choice Fields zu machen.
Möchtest du noch mehr Kontrolle, so kannst du im Prinzip alles machen. Für Schriftgrößen nutze ich meist Number fields. Du musst sie nur entsprechend definieren und gruppieren. Mein persönlicher Aufbau in Themes (nicht Module) ist folgender:
===== English translation (using DeepL because I don't want to type the whole thing twice 🙂 ) ====
Unfortunately there is no escape_css_string filter in HubL.
Fonts should ideally not be defined in the module, but in the theme as you don't want to set the font for each module on each page.
Defining the font using theme fields.json is ideal for this.
In addition, I find the “upload custom font” option of the font field user-friendly, but if you want to work completely Cordporate Design compliant and without headaches, I recommend one of the following ways.
To define something different for the different breakpoints, use so-called media-queries. I recommend going from small to large, as this leads to cleaner code.
Example:
{# works always / mobile #}
body{
font-family: 'PTSans', Arial, sans-serif;
font-size:16px;
font-weight:400;
}
h1,h2,h3,h4,h5,h6{
font-family: 'PTSans', Arial, sans-serif;
font-weight:600;
}
h1{
font-size:28px;
}
h2{
font-size:24px
}
...
@media screen and (min-width:1024px){
{# For screens larger than 1024px width #}
h1{
font-size:40px;
}
h2{
font-size:32px;
}
...
}
@media screen and (min-width:1400px){
{# For screens larger than 1400px width #}
h1{
font-size:48px;
}
h2{
font-size:36px;
}
...
}
2. custom fonts that you upload or host yourself and that do not have an @import or style-link tag
You can upload your TTFs, OTFs, WOFF etc. files either to the File Manager or Design Manager and define them using font face rules in the CSS file as in the previous code.
If you integrate the fonts globally, you don't have to worry about the individual definition in modules. If you still want to do this, I recommend using CSS classes and, for example, choice fields.
Möchtest du noch mehr Kontrolle, so kannst du im Prinzip alles machen. Für Schriftgrößen nutze ich meist Number fields. Du musst sie nur entsprechend definieren und gruppieren. Mein persönlicher Aufbau in Themes (nicht Module) ist folgender:
===== English translation (using DeepL because I don't want to type the whole thing twice 🙂 ) ====
Unfortunately there is no escape_css_string filter in HubL.
Fonts should ideally not be defined in the module, but in the theme as you don't want to set the font for each module on each page.
Defining the font using theme fields.json is ideal for this.
In addition, I find the “upload custom font” option of the font field user-friendly, but if you want to work completely Cordporate Design compliant and without headaches, I recommend one of the following ways.
To define something different for the different breakpoints, use so-called media-queries. I recommend going from small to large, as this leads to cleaner code.
Example:
{# works always / mobile #}
body{
font-family: 'PTSans', Arial, sans-serif;
font-size:16px;
font-weight:400;
}
h1,h2,h3,h4,h5,h6{
font-family: 'PTSans', Arial, sans-serif;
font-weight:600;
}
h1{
font-size:28px;
}
h2{
font-size:24px
}
...
@media screen and (min-width:1024px){
{# For screens larger than 1024px width #}
h1{
font-size:40px;
}
h2{
font-size:32px;
}
...
}
@media screen and (min-width:1400px){
{# For screens larger than 1400px width #}
h1{
font-size:48px;
}
h2{
font-size:36px;
}
...
}
2. custom fonts that you upload or host yourself and that do not have an @import or style-link tag
You can upload your TTFs, OTFs, WOFF etc. files either to the File Manager or Design Manager and define them using font face rules in the CSS file as in the previous code.
If you integrate the fonts globally, you don't have to worry about the individual definition in modules. If you still want to do this, I recommend using CSS classes and, for example, choice fields.
If you want even more control, you can basically do anything. I usually use number fields for font sizes. You just have to define and group them accordingly. My personal structure in themes (not modules) is as follows: