Dieser Beitrag ist eigentlich offen. Ich räume die style.css Datei in meinem Block Theme auf. Das hier ist ein Lernen oder Gespräch mit chatgpt. Weil sonst niemand da ist, der mit mir soetwas macht. Es geht hier um body und p.

Meine style.css Datei

Ich habe früh mit Block Themes angefangen. Aber ich habe die style.css Datei gelassen. Es gab so viel anderes zum Lernen bei der Erstellung von Custom Block Themes.

Und es gab am Anfang ja noch kein Create Block Theme.

Mein Block Theme

Im Prinzip schleppe ich die style.css Datei so ähnlich wie hier auf mediendesign-quer.com ( auch ein Custom Block Theme ) schon länger mit mir herum. Ich habe zwar eine theme.json und dort die Grundeinstellungen , wie

• Layout
• Schriften eingebunden
• Template Parts
• Grundeinstellungen

👉💡Achtung ! Das ist kein Hybrid Theme mehr, das ist ein reines Block Theme. Einziges Manko, ich verwende sehr viel CSS.

Jo und jetzt räume ich die style.css Datei auf.

Viel mit geschleppt

WordPress: Wechsel auf ein FSE Block Theme – meine ersten Schritte

Wenn man so an einer Theme Umstellung arbeitet vom Classic Theme zu einem Block Theme , es sammelt sich irgendwie viel an.

.wp-block-content .. und die Klassen

Am Anfang war ja nur der Block Editor. Und ich habe mir alle WordPress Klassen einmal angesehen und dann angefangen die einzelnen Blöcke mit CSS zu stylen.

Das hat mir gut gefallen. Ich habe mir am Anfang – im Editor habe ich es bis heute – lauter Ränder und Hintergrundfarben für die einzelnen Blöcke erstellt, um mit dem Block Editor mich besser anzufreunden.

Block Editor – bis heute nur weiß

Mir hat das nie gefallen, einfach nur Weiß. im Block Editor. Bis heute hat man keine Ahnung, in welchem Block man ist. Man braucht ständig die linke Sidebar dafür .

Synchronisation von Block Editor und Front End

Allerdings, was ich ja lange nicht wußte, vielleicht weil ich so späte mit der theme.json Datei anfing. Nämlich

💡 Man braucht keine editor-style.css Datei mehr, weil mit der theme.json Datei Frontend und Editor dieselben Styles haben. Wenn denn styles da sind. Meistens halt immer noch nur weiß. 🤭

Meine Ausgangs Situation

• Voll funktionstüchtiges Custom Block Theme
• theme.json
• style.css Datei – übernimmt die styles
• editor-style.css Datei – für ein cooles custom Backend

Und jetzt muss ich für mich eine Lösung finden. Das Backend mit meinen Hintergründen und Rändern für die verschiedenen Blöcke werde ich niemals aufgeben.

Sonst macht das Schreiben für mich keinen Spaß. Das ist sozusagen Mein ZuHause. Allerdings verstehe ich auch, dass man nicht für jede Website und unterschiedliche Styles eine eigene editor-style.css Datei erstellen möche.

Wir leben in einer Zeit, mit KI , wo alles nur schnell gehen muss. Und so was ist halt einfach echte Handarbeit. Na gut.

Neues Custom Block Theme – angepasst

Aus dem Grund – allein zur Übung für mich – möchte ich jetzt ein neues Custom Block Theme erstellen, wo ich zumindest mal die style.css Datei aufräume.

Dabei werde ich alles, was ich nicht mehr brauche auskommentieren. Und was nicht mit theme.json geht, das lasse ich drinnen. Und diese Sachen möchte ich hier dokumentieren.

Vielleicht kann es auch jemand anderes brauchen. Letztlich habe ich noch nie gesehen, dass irgendjemand über so etwas etwas geschrieben hat.

body

overflow-x:hidden; /*  hidden → verhindert horizontales Scrollen,  bei fehlerhaftem Layout oder negativen Margins.*/
	 
	 -webkit-hyphens: auto;
	   -moz-hyphens: auto;
	    -ms-hyphens: auto;
			hyphens: auto;/* sorgt dafür, dass Wörter bei kleinen Displays automatisch getrennt werden dürfen (Silbentrennung).*/

			

👉 Diese beiden Sachen müssen drin bleiben in der style.css. Das geht nicht mit theme.json.

p – der Absatz

.wp-block-post-content p
   {color:#1c1c1c;
    line-height:1.6;

   }

p {
	margin-bottom: 0px;
	 color:#464646;
	 font-family: Lora,serif;
	 line-heigth:1.2;
} /*pass color contrast*/

.wp-block-post-content, daraus wird in der theme.json: core/post-content.

Diese Klasse braucht man im Prinzip ja nicht, es ist nur ein Container, es sei denn man möchte wissen, wie der aussieht.

Die theme.json für den Absatz wird bei mir so aussehen:

"core/paragraph": {
  "border": {
    "width": "1px",
    "color": "#ddd",
    "style": "solid"
  },
  "spacing": {
    "padding": {
      "top": "10px",
      "bottom": "10px",
      "left": "15px",
      "right": "15px"
    }
  },
  "color": {
    "background": "#f9f9f9"
  },
  "typography": {
    "lineHeight": "1.6"
  }
}

Warum ? Weil ich bei der Umstellung sehen möche, was passiert. Ich will nicht nur weiß haben, ich möchte den Absatz Block auch im Frontend mit einem Hintergrund und einem Rand haben.

Ha Ha es hat nicht funktioniert 😜😂😂😂

Abstände in der theme.json

Es ist nämlich so, die Abstände zwischen den einzelnen Blöcken in der theme.json wird über block Gap gesteuert. Früher hatte man die Abstände über die CSS Klassen zum Beispiel bei der Überschrift H1-H6 hinzugefügt.

Da ich das aber ja noch so in der style.css Datei stehen habe, lasse ich das block Gap daweil weg. Sonst bekomme ich den doppelten Abstand.

Wie testen das Ganze?

Neue WordPress Installation, lokal. Mit Create Block Theme Plugin und den Theme Test Data. Ohne Gutenberg oder Beta Versionen.

Diskussion mit chatgpt

So, es ist nicht wirklich einfach, ein CSS Style in eine theme.json zu übersetzten. Zunächst muss man sich nämlich damit auseinandersetzen, das theme.json anders funktioniert.

Ich wollte einfach ein p Absatz, und den body Teil in die theme.json rein. Das hat aber so nicht funktioniert. Es kam folgendes heraus:

😔 Nur die Absätze waren dann von der Schrift her viel kleiner als 1.3 rem, wie ich das haben wollte. Dann war diese zu kleine Absatz Schrift auch in meiner Navigation im Footer und ja halt im Fließtext .

So war das nicht gewollt. Gut alles wieder zurück. Dann ist mir klar geworden, dass in der theme.json ja die Schriftgrössen mit small, large , xx, usw. gekennzeichnet sind.

Diese kann ich dann ja auch direkt im Editor so sehen und verwenden.

Ich erstelle ein Custom Block Theme. Ich baue das einmal nur für mich. Somit brauche ich auch keine X Schriftgrößen, wenn ich auf der ganzen Website nur ein p definiert habe mit 1.3 rem.

Mein Problem ist, die Vorstellung, ich habe einen header und footer, im footer ist nur ein Absatz drinnen, aber der war auch kleiner dann, im header ist auch nur p, alles was ich mit p in die theme.json reingeschreiben ahbe oder das body war dann kleiner auch die schrift ind er navigation, und wenn ich schreibe small usw. ich habe überhaupt kein Gefhül, es sagt mir nix, ich habe bei mir nur Absatz ist auf der gesamten Website auch in der navigation 1.3rem, das gefällt mir diese grösse, aber wie deifniere ich das mit small und medium usw. im prinzip egal welcher Block es ist eh immer nur die Absatz schrifgrösse und die wäre bei mir 1.3 rem,

Nur so nebenbei, ich mache ziemlich viele Tippfehler, habe eine neue externe Tastatur, mit der komme ich nicht so klar, daweil. Aber dieses Gschreibsel von da oben konnte chatgpt total lesen und hat es verstanden. WOW 

ChatGPT:

Ja, jetzt hast du den entscheidenden Punkt glasklar benannt – und du hast vollkommen recht:
👉 Du brauchst genau eine klare Absatz-Schriftgröße (1.3rem) – und die soll überall gelten, egal ob im Footer, in der Navigation oder im normalen Content.

Das heißt: Du brauchst nur eine benutzerdefinierte Schriftgröße, die du konsequent überall einsetzt.

✅ Lösung: So definierst du eine Schriftgröße (z. B. 1.3rem)

1. Definiere in der settings.typography.fontSizes deinen festen Wert

"settings": {
  "typography": {
    "defaultFontSizes": false,
    "fontSizes": [
      {
        "name": "Standard",
        "slug": "standard",
        "size": "1.3rem"
      }
    ]
  }
}

🔸 name: wie sie im Editor heißt
🔸 slug: für die CSS-Variable → ergibt --wp--preset--font-size--standard
🔸 size: deine Wunschgröße → 1.3rem

---

2. Wende die Schriftgröße global an

"styles": {
  "typography": {
    "fontSize": "var(--wp--preset--font-size--standard)"
  }
}

Damit sagst du: Das ist die globale Standardschriftgröße. Sie wird verwendet, wenn kein einzelner Block etwas anderes vorgibt.

---

3. Optional: Sicherstellen, dass core/paragraph das auch bekommt

Falls du sicherstellen willst, dass Absätze wirklich immer dieselbe Größe haben, kannst du zusätzlich schreiben:

"styles": {
  "blocks": {
    "core/paragraph": {
      "typography": {
        "fontSize": "var(--wp--preset--font-size--standard)"
      }
    }
  }
}

➡️ Das ist aber oft gar nicht nötig, wenn du es oben global gesetzt hast. Die Vererbung funktioniert ziemlich gut.

---

📌 Und was ist mit Navigation oder Footer?

Die Navigation (core/navigation) und der Footer sind ebenfalls Blöcke. Wenn du im Editor dort einen Absatzblock (p) benutzt, greifen die globalen Stile auch dort – es sei denn, du hast im CSS oder Template eine andere Größe gesetzt.

Wenn du noch CSS drin hast (z. B. body { font-size: 1.3rem; }), dann kann das mit theme.json in Konflikt kommen. Deshalb:

👉 Schrittweise CSS abbauen
👉 Testweise den body-Eintrag entfernen oder auskommentieren und prüfen, ob die theme.json richtig greift.

---

🧠 Merksatz

Du brauchst keine 5 Schriftgrößen, wenn du nur eine brauchst.
Definiere genau eine – nenn sie „standard“ oder „absatz“ – und nutze sie konsequent.

---

Wenn du willst, kann ich dir auch eine Mini-theme.json erstellen, die nur genau das macht: 1 Schriftgröße global definiert und zugewiesen – ohne alles andere. Sag einfach Bescheid.

Du:

Das hört sich jetzt gut an. Ich glaube, so könnte es gehen. Nur weißt du was, das was du als standard beschreibst, wie meinst du das ?

ChatGPT:

Super Frage – das klären wir ganz genau, denn das ist das Herzstück der neuen theme.json-Denkweise.

---

🔍 Was bedeutet „standard“ in diesem Zusammenhang?

In deinem CSS hattest du bisher:

body {
  font-size: 1.3rem;
  line-height: 1.6;
}

Das heißt:
Du hast manuell gesagt, dass die Standardschriftgröße auf der Seite 1.3rem ist.

---

In theme.json macht man das nicht mehr im CSS, sondern so:

Schritt 1: Man gibt dieser Standard-Schriftgröße einen Namen und einen „Slug“

(z. B. standard, absatz, base, text, … – der Name ist frei wählbar)

"settings": {
  "typography": {
    "defaultFontSizes": false,
    "fontSizes": [
      {
        "name": "Standard",          // so wird sie im Editor angezeigt
        "slug": "standard",          // daraus wird die CSS-Variable
        "size": "1.3rem"             // deine tatsächliche Schriftgröße
      }
    ]
  }
}

→ Daraus wird automatisch die CSS-Variable:

--wp--preset--font-size--standard: 1.3rem;

---

Schritt 2: Du wendest diese Schriftgröße global an

"styles": {
  "typography": {
    "fontSize": "var(--wp--preset--font-size--standard)",
    "lineHeight": "1.6"
  }
}

Jetzt sagt die theme.json:

Verwende für den Fließtext (also überall, auch Navigation, Footer, Paragraphen …) diese eine Schriftgröße.

---

💡 Fazit

• standard ist nur ein selbstgewählter Name für deine Basis-Schriftgröße
• Sie ersetzt das frühere CSS body { font-size: 1.3rem; }
• Du kannst sie auch absatz, text, base, body nennen – völlig egal
• Wichtig ist, dass du sie einmal definierst und dann überall nutzt

Und so funktioniert’s 😅

Chatgpt weiß auch nicht alles sofort. Aber es ist doch eine große Hilfe. Warum ? Es nimmt sich einmal Zeit für mich. Es hat Geduld. Wir können immer wieder von vorne anfangen. Er muntert mich auf, wenn es mir schon zu blöd wird.
👍😍

So, das mit dem Stadard Namen hat nicht funktioniert. Ich zeige euch jetzt was funktioniert hat, und wie ich das body p und das p , also den Absatz extra in p in CSS und die Schriftgröße im body rübergebracht habe nach theme.json.

Was habe ich erreicht ?

1 Alle Absätze also Absatz Blöcke sind jetzt mit 1.3rem Schriftgröße in der theme.json definiert.

2 sowohl die Blogbeiträge, Startseite, Seiten, Absätze in Footer, Navigation und Blog Sidebar sind in 1.3 rem Schrifgröße

3 p und body in CSS habe ich auskommentiert, also es greift nicht mehr.

👉 Achtung ! CSS ist am Stärksten. Es überschreibt immer die theme.json.

So sieht’aus:

🎯 Ziel

Die globale Schriftgröße für Absätze (p) soll einheitlich 1.3rem betragen – und zwar ohne CSS, nur über die theme.json. Sie soll überall gelten: auf Seiten, Blogbeiträgen, in der Navigation, im Footer etc.

✅ Schritt 1: Schriftgröße als Preset definieren

In theme.json unter settings.typography.fontSizes:

"settings": {
  "typography": {
    "defaultFontSizes": false,
    "fontSizes": [
      {
        "name": "Medium",
        "slug": "medium",
        "size": "1.3rem"
      },
      {
        "name": "Small",
        "slug": "small",
        "size": "1rem"
      },
      {
        "name": "Large",
        "slug": "large",
        "size": "2rem"
      }
    ]
  }
}

Damit steht „Medium“ als auswählbare Option im Editor zur Verfügung – mit 1.3rem.

✅ Schritt 2: Globale Anwendung der Schriftgröße

In theme.json unter styles.typography:

"styles": {
  "typography": {
    "fontSize": "var(--wp--preset--font-size--medium)"
  }
}

Das sorgt dafür, dass 1.3rem überall als Standardgröße verwendet wird – auch bei Absätzen in Templates (Blogübersicht, Footer, Navigation, Archivseiten …).

✏️ Wichtig

• In der CSS-Datei muss font-size entfernt oder überschrieben sein – sonst übersteuert es die theme.json.
• Im Editor kann weiterhin jede Blockschriftgröße angepasst werden, aber der Standard bleibt bei 1.3rem.
• Wenn man mehr Größen brauchst (z. B. für Überschriften, Buttons usw.), kannst du einfach zusätzliche Presets hinzufügen.

Mein Fazit:

Ich bin von notepad++ jetzt auf Visual Studio Code umgestiegen. Warum ? Weil man Code dort einfacher schreiben kann. Gerade die theme.json mit diesen vielen Klammern usw. geht in notepad++ nicht mehr.

Außerdem zeigt Visual Studio Code die Fehler nicht nur an, es springt sofort zu der Stelle, wo etwas falsch ist. Also, ja, hätte mir das nicht gedacht, dass ich mal in einer theme.json Datei so einfach schreiben kann. 👍😜

Ich habe etwas erreicht, was ich mir fast nicht gedacht habe. Chatgpt hat mir den Unterschied zwischen CSS und der theme.json erklärt. Das war mir so irgendwie gar nicht bewusst.

Dieser folgende Text hat mir Chatgpt geschrieben. Er erklärt hier nochmal den Unterschied zwischen CSS und der theme.json:

Der Unterschied zwischen CSS und theme.json in WordPress

🧾 Was ist die theme.json?

Die theme.json ist eine Konfigurationsdatei, die seit WordPress 5.8 eingeführt wurde. Sie ermöglicht es, das Verhalten und Design eines Themes zentral und strukturiert zu steuern, ohne (oder mit sehr wenig) klassischem CSS.

Sie ist speziell für den Block-Editor (Gutenberg) gemacht – also für Full Site Editing (FSE) und Block-Themes. Alles, was du dort definierst, wirkt sich nicht nur auf das Frontend, sondern auch auf den Editor im WordPress-Backend aus.

---

🧱 Was kann theme.json?

• Design-Vorgaben global festlegen, z. B. Farben, Schriften, Abstände
• Editor-Einstellungen steuern – z. B. ob Benutzer Schriftgrößen ändern dürfen
• Blöcke gezielt stylen (z. B. core/paragraph)
• Globale Styles definieren, die früher in der style.css standen
• Custom Presets anlegen, z. B. eigene Farbnamen, Schriftgrößen oder Fonts

---

🆚 CSS vs. theme.json

Feature	CSS	theme.json
Wird im Editor angezeigt	❌ Nein	✅ Ja (Editor sieht sofort die Farben, Schriften usw.)
Global einsetzbar	🔶 Nur mit Aufwand	✅ Sehr einfach über Presets und globale Styles
Benutzerfreundlichkeit	❌ Nur für Entwickler	✅ Auch für Designer im Editor zugänglich
Stiländerung im Editor	❌ Muss händisch gemacht werden	✅ Automatisch im Editor sichtbar
Theme-Anpassung mit GUI	❌ Nicht möglich	✅ Funktioniert mit dem Site Editor
Wartbarkeit	❌ Schnell unübersichtlich	✅ Klar strukturiert (JSON-Format)

---

📝 Wann du noch CSS brauchst

Auch wenn theme.json sehr viel ersetzt, komplett ohne CSS geht es nicht immer:

• Für komplexe Layouts (z. B. Grid, Media Queries)
• Für Hover- oder Fokus-Zustände, die der Editor nicht abbildet
• Für ältere Themes oder Plugins, die kein FSE nutzen

---

📌 Fazit

• theme.json = zentrale Steuerung + saubere Kontrolle im Editor
• CSS = für Feinschliff oder Spezialfälle
• Für moderne Block-Themes ist theme.json der neue Standardweg.