GenerateBlocks: Text bricht im Frontend anders um als im Editor

Ein typisches GenerateBlocks-Problem: Im WordPress-Editor steht ein kurzer Text bequem in einer Zeile. Auf der veröffentlichten Seite bricht derselbe Text plötzlich in zwei Zeilen um. Im ursprünglichen Gemini-Chat war genau das die Beobachtung – und die Breite musste scheinbar „extrem vergrößert“ werden, damit der Umbruch verschwand.

Die Ursache liegt fast nie im Text selbst. Meist unterscheiden sich verfügbare Breite, Flexbox-Verhalten, Schrift oder CSS zwischen Editor und Frontend.

1. Zuerst klären: Ist der Umbruch wirklich ein Fehler?

Ein Browser bricht Text automatisch um, sobald die verfügbare Breite nicht mehr reicht. Wenn der Block im Editor 700 Pixel Platz hat, im Frontend aber nur 420 Pixel, ist ein zusätzlicher Zeilenumbruch völlig normal.

Die richtige Frage lautet deshalb nicht „Wie verhindere ich jeden Umbruch?“, sondern zunächst: Warum ist der Bereich im Frontend schmaler?

2. Den äußeren Container prüfen

Der Textblock kann selbst auf 100 Prozent Breite stehen und trotzdem zu schmal sein, wenn sein Eltern-Container begrenzt wird.

Prüfe nacheinander:

  • Width des Textblocks
  • Max-Width des Textblocks
  • Width des Eltern-Containers
  • Max-Width des Eltern-Containers
  • Padding links/rechts
  • Gap zwischen Flex- oder Grid-Elementen

Ein Container mit 500 Pixel Breite und jeweils 40 Pixel Padding lässt seinem Inhalt nur noch 420 Pixel.

3. Max-Width ist oft der versteckte Verursacher

Besonders häufig wird nur width: 100% kontrolliert. Eine gleichzeitig gesetzte max-width begrenzt den Block trotzdem.

Beispiel:

width: 100%;
max-width: 360px;

Der Block darf dann nie breiter als 360 Pixel werden, selbst wenn der Container viel mehr Platz bietet.

4. Flexbox kann den Textblock zusammendrücken

Der ursprüngliche Gemini-Chat wies zu Recht auf Flexbox hin. Wenn mehrere Elemente nebeneinander in einem Flex-Container liegen, dürfen Flex-Items standardmäßig schrumpfen.

Dadurch kann ein Textblock schmaler werden, als du anhand seiner Width-Einstellung erwartest.

Ein möglicher Test ist:

flex-shrink: 0;

Das sollte aber nur eingesetzt werden, wenn der Block tatsächlich nicht schrumpfen darf. Sonst kann die Gesamtzeile auf kleineren Bildschirmen überlaufen.

5. Besser als flex-shrink: Layout logisch aufbauen

Wenn beispielsweise Icon und Text nebeneinander stehen, ist oft sinnvoll:

  • Icon: feste oder minimale Breite
  • Text: flex: 1

Dann bekommt der Text automatisch den verbleibenden Platz, statt mit willkürlichen Pixelbreiten zu arbeiten.

6. Editor und Frontend haben nicht dieselbe Breite

Der Gutenberg-Editor bildet das Frontend nicht immer pixelgenau ab. Gründe können sein:

  • andere Editor-Canvas-Breite
  • fehlende Frontend-Paddings
  • Sidebar im Editor geöffnet/geschlossen
  • Theme-Styles nur im Frontend
  • unterschiedliche Breakpoints

Darum sollte bei einem Umbruchproblem immer die reale Frontend-Breite im Browser geprüft werden.

7. Unterschiedliche Schrift kann den Umbruch verursachen

Wenn im Editor eine Fallback-Schrift verwendet wird, im Frontend aber die eigentliche Webfont geladen wird, kann derselbe Satz unterschiedlich breit sein. Manche Schriften benötigen deutlich mehr Platz pro Zeichen.

Kontrolliere im Browser unter „Computed“, welche font-family tatsächlich aktiv ist.

8. Schriftgröße und Letter-Spacing vergleichen

Neben der Font-Family beeinflussen auch diese Werte die benötigte Zeilenbreite:

  • font-size
  • font-weight
  • letter-spacing
  • Großschreibung

Schon ein leicht erhöhtes Letter-Spacing kann bei kurzen Button- oder Menütexten den Umbruch auslösen.

9. Padding im Textblock selbst

Ein Textblock mit Breite 300 Pixel und 30 Pixel Padding links plus rechts hat je nach Box-Sizing deutlich weniger Platz für den eigentlichen Text.

Prüfe deshalb nicht nur die nominelle Breite, sondern die tatsächlich berechnete Inhaltsbreite im Browser-Inspektor.

10. White-Space: nowrap nur gezielt verwenden

Im ursprünglichen Chat wurde als schnelle Lösung vorgeschlagen:

.no-wrap {
    white-space: nowrap;
}

Das funktioniert technisch. Der Text darf dann nicht mehr automatisch umbrechen.

Aber: Auf kleinen Displays kann die Zeile aus dem Container herauslaufen. Deshalb ist nowrap ideal für kurze Elemente wie:

  • Telefonnummern
  • kurze Labels
  • kleine Buttons
  • bestimmte Navigationspunkte

Für längere Fließtexte ist es meist die falsche Lösung.

11. No-Wrap nur auf Desktop

Wenn ein kurzer Text auf dem Desktop unbedingt einzeilig bleiben soll, auf Mobil aber umbrechen darf:

@media (min-width: 769px) {
  .no-wrap-desktop {
    white-space: nowrap;
  }
}

So verhinderst du horizontales Überlaufen auf schmalen Bildschirmen.

12. Grid-Spalten kontrollieren

Bei CSS Grid können feste oder prozentuale Spaltenbreiten den Text unerwartet einschränken.

Beispiel:

grid-template-columns: 30% 30% 30%;

Zusammen mit Gaps bleiben womöglich weniger Pixel übrig als gedacht. Flexible Definitionen wie 1fr 1fr 1fr verteilen den verfügbaren Raum oft sauberer.

13. min-width: 0 bei Flex- und Grid-Kindern

Ein fortgeschrittener, aber wichtiger Punkt: In Flex- und Grid-Layouts kann min-width das Schrumpfverhalten beeinflussen. In manchen Layouts hilft:

min-width: 0;

Dadurch darf ein Kind-Element tatsächlich innerhalb des verfügbaren Bereichs schrumpfen. Das löst eher Überlaufprobleme als unerwünschte Umbrüche, gehört aber in dieselbe Diagnosefamilie.

14. Explizite Zeilenumbrüche ausschließen

Prüfe den HTML-Inhalt, wenn der Umbruch immer exakt an derselben Stelle erscheint. Möglicherweise befindet sich dort:

  • ein <br>
  • ein separater Span/Block
  • ein geschützter Bereich

Dann bringt eine größere Width zwar optisch manchmal etwas, behebt aber nicht die eigentliche Ursache.

15. Browser-Inspektor als schnellstes Werkzeug

Öffne das Frontend und markiere den Text im Inspektor. Prüfe:

  • berechnete Breite
  • max-width
  • padding
  • display
  • flex-grow / flex-shrink / flex-basis
  • font-family
  • font-size
  • white-space

Vergleiche dann die Werte mit dem Eltern-Container. Meist ist die Ursache innerhalb weniger Minuten sichtbar.

16. Beispiel: Text neben Icon

Eine robuste Struktur kann so aussehen:

.info-row {
  display: flex;
  align-items: center;
  gap: 12px;
}

.info-row .icon {
  flex: 0 0 auto;
}

.info-row .text {
  flex: 1 1 auto;
  min-width: 0;
}

Der Text erhält den verfügbaren Restplatz und bleibt trotzdem responsiv.

17. Warum „Width extrem vergrößern“ kein guter Dauerfix ist

Wenn du die Width nur immer weiter erhöhst, bis der Text nicht mehr umbricht, behandelst du das Symptom. Auf einem anderen Bildschirm oder nach einer Schriftänderung taucht das Problem wieder auf.

Besser ist:

  1. echte verfügbare Breite feststellen,
  2. unnötige Max-Width/Paddings beseitigen,
  3. Flex-/Grid-Verhalten korrigieren,
  4. erst bei bewusst einzeiligen UI-Elementen nowrap einsetzen.

18. Responsive Breakpoints prüfen

GenerateBlocks erlaubt unterschiedliche Werte für Desktop, Tablet und Mobil. Kontrolliere deshalb, ob für Tablet oder Mobil versehentlich eine kleine Width oder Max-Width gespeichert wurde, die bereits früher greift als erwartet.

Fazit

Wenn Text in GenerateBlocks im Editor einzeilig und im Frontend zweizeilig erscheint, ist die Ursache fast immer eine reale Layout-Differenz. Prüfe zuerst Containerbreite, Max-Width, Padding und Flex-/Grid-Verhalten und danach Schriftwerte. white-space: nowrap ist eine nützliche gezielte Lösung für kurze UI-Texte, aber kein Ersatz für ein sauberes responsives Layout.