Willkommen im STRATO Blog. Hier gibt es News und Tipps rund ums Hosting.

 

Menu

Veröffentlicht am: 06. Januar 2016

Mit ein paar Handgriffen bekommst du mehr WYSIWYG im Wordpress-Editor

Echtes WYSIWYG im WordPress-Editor

Willst Du direkt im WordPress-Editor sehen, wie Dein Blog-Post für die Leser aussieht? Mit ein paar Tricks bringst Du WordPress dazu, Text und Formatierungen schon beim Schreiben weitgehend authentisch anzuzeigen.

Die meisten WordPress-Themes verwenden besondere Formatierungen, zum Beispiel für den ersten Absatz eines Beitrags, hervorgehobene Zitate oder attraktiv gestaltete Aufzählungen. Von all dem siehst Du aber beim Schreiben und Bearbeiten Deiner Beiträge nichts.

Im WordPress-Editor (links) sieht Dein Beitrag ganz anders aus als für Deine Leser (rechts).

Im WordPress-Editor (links) sieht Dein Beitrag ganz anders aus als für Deine Leser (rechts).

Um das zu ändern, musst Du lediglich ein paar Kleinigkeiten in Deinem WordPress-Theme anpassen: Dann siehst Du schon beim Schreiben beinahe perfekt, wie der Beitrag für den Leser aussehen wird – also „WYSIWYG“, what you see is what you get.

Bei solchen Anpassungen ist es sinnvoll, Änderungen nicht im Original-Theme vorzunehmen, sondern dafür ein Child-Theme zu nutzen.

1. CSS-Definitionen aus dem Theme übernehmen

Zuerst übernimmst Du alle Formatierungen Deines Themes für die Darstellung im WordPress-Editor. Meist stehen diese Formatierungen in der Datei style.css Deines Themes. Für die Übernahme ergänzt Du die functions.php Deines (Child-)Themes um folgende Zeilen:

function custom_editor_styles() {
  add_editor_style(’style.css‘);
}
add_action( ‚admin_init‘, ‚custom_editor_styles‘ );

Code für WordPress

Ein paar Zeilen in der functions.php genügen, um CSS-Definitionen fürs Backend zu übernehmen.

Liegt die style.css bei Deinem Theme in einem anderen Verzeichnis als die functions.php oder heißt die Datei anders, musst Du den Dateipfad im Code entsprechend anpassen.

2. CSS-Definitionen speziell fürs Backend

Allerdings werden damit nicht zwangsläufig alle Formatierungen auf den Beitragstext im Editor angewendet. Denn der Editor zeigt nicht die komplette Website an, sondern lediglich den Teilbereich des eigentlichen Beitragsinhalts. Deshalb fehlen im Editor alle Formatierungen aus übergeordneten Elementen, also beispielsweise dem DIV-Element, das den gesamten Content-Bereich umschließt.

Deshalb musst Du solche Formatierungen über eine zusätzliche CSS-Datei ergänzen. Diese Datei legst Du mit beliebigem Namen im gleichen Verzeichnis an wie die style.css Deines Themes. Für unser Beispiel nennen wir die Datei backend.css und binden sie – wie zuvor die style.css – über die functions.php mit ein. Du erweiterst also lediglich den eben schon eingefügten Code:

function custom_editor_styles() {
  add_editor_style(’style.css‘);
  add_editor_style(‚backend.css‘);
}
add_action( ‚admin_init‘, ‚custom_editor_styles‘ );

Code für WordPress

Zusätzliche Formatierungen bindest Du über eine eigene CSS-Datei fürs Backend ein.

3. Grund-Formatierung für die backend.css

Über die backend.css entfernst Du zunächst den standardmäßig grauen Hintergrund im WordPress-Editor und definierst für die bessere Optik einen Abstand des Inhalts zum Rand. Die folgenden CSS-Definitionen kommen in die backend.css, so wie auch alle weiteren CSS-Definitionen in den folgenden Schritten.

/** Hintergrundfarbe und Randabstand */
#tinymce {
  background: none;
  margin: 10px;
}

Code für WordPress

Damit es ordentlich aussieht:10 Pixel Randabstand und weg mit dem grauen Hintergrund.

Jetzt hast Du schon einmal einen Teilerfolg und der Beitrag in unserem Beispiel sieht im Editor so aus:

Zwischenergebnis: Teile der Formatierungen werden bereits angezeigt.

Zwischenergebnis: Teile der Formatierungen werden bereits angezeigt.

4. Grundsätzliches zum WordPress-Editor

Um das weitere Vorgehen besser zu verstehen, ist es wichtig zu wissen, wie der WordPress-Editor funktioniert. Der Editor holt sich den inhaltlichen Teil Deines Blog-Beitrags aus der Datenbank und stellt ihn im Editor quasi als eigene Webseite dar – nämlich in einem Iframe (Inlineframe). Das ist nichts anderes als eine eigenständige HTML-Datei, die in eine andere HTML-Datei (nämlich der Editor-Bereich in WordPress) eingebettet wird.

Mit Schritt 1 und 2 hast Du zwar alle Formatierungen in dieses Iframe übernommen. Ins Leere laufen aber Formatierungen, die von übergeordneten Elementen vererbt wurden. Da diese Elemente in dem Iframe nicht vorkommen, können sie ihre Formatierungen aber auch nicht vererben.

Anschaulicher wird das in unserem Beispiel: Der Content-Bereich ist hier von einem DIV-Container mit der Klasse .article-content umrahmt. Dort sind Schriftgröße, Farbe und Textbreite festgelegt, was im Editor keine Auswirkung hat, weil dort eben nur der reine Content übernommen wird, aber nicht der übergeordnete DIV-Container mit der Klasse .article-content.

Browser-Erweiterungen wie beispielsweise Google Chromes Entwicklertools machen sichtbar, wie der Editor von WordPress den Inhalt eines Beitrags mit Hilfe eines Iframes einbettet.

Browser-Erweiterungen wie beispielsweise Google Chromes Entwicklertools machen sichtbar, wie der Editor von WordPress den Inhalt eines Beitrags mit Hilfe eines Iframes einbettet.

Wie der Screenshot zeigt, ist das übergeordnete Element des Blog-Beitrags, den Du bearbeiten willst, nicht mit dem DIV-Container mit der Klasse .article-content umgeben, sondern mit einem body-Tag mit der ID #tinymce.

Das wird in Schritt 6 noch wichtig. Dort ergänzen wir nämlich in der backend.css diejenigen Formatierungen aus der style.css, die aus dem eben genannten Grund nicht greifen.

5. Exkurs: Die Entwicklertools Deines Webbrowsers

Dafür ist nun Deine Spürnase gefragt. Denn je nach Theme musst Du unterschiedlich viele Formatierungsanweisungen in der backend.css einfügen. Vergleiche dazu erst einmal optisch auf der Webseite und im Editor, welche Formatierungen im Editor noch fehlen.

Mit Hilfe der Entwicklertools Deines Browsers kannst Du identifizieren, woher die jeweilige Formatierung stammt, um sie dann gezielt in der style.css zu suchen und angepasst in die backend.css zu übernehmen. Wie geht das konkret?

Im Beispiel arbeiten wir mit den Entwicklertools von Google Chrome, aberbeispielsweise auch in Firefox und anderen Browsern gibt es vergleichbare Hilfsmittel.

Rufe in Chrome den Code-Inspektor mit der Tastenkombination Steuerung – Umschalt – C auf (oder per Klick auf das Symbol mit dem Pfeil im Quadrat). Sobald Du nun mit der Maus über einen Bereich der Webseite fährst, wird dieser Bereich farbig markiert. Klickst Du darauf, wird rechts der zugehörige HTML-Code angezeigt. Im Bereich Styles kannst Du nun sehen, welche Formatierungsanweisungen für diesen Bereich relevant sind. Umgekehrt wird auch auf der Website der jeweilige Bereich farbig hinterlegt, wenn Du rechts in der Code-Ansicht mit dem Mauszeiger über den zugehörigen Code fährst.

Die Entwicklertools von Google Chrome im Einsatz.

Die Entwicklertools von Google Chrome im Einsatz.

6. Suche nach fehlenden Formatierungen

Mit diesem Hilfsmittel ausgerüstet, musst Du nun einen Blogbeitrag im Editor und auf Deinem Blog vergleichen, um die im Editor unwirksamen Formatierungen zu finden. In unserem relativ typischen Beispiel-Theme (ColorMag) stellen wir fest, dass der Content-Bereich von einem DIV-Container mit der der Klasse .article-content umschlossen wird und viele Formatierungen in der style.css von genau dieser Klasse auf den Inhaltsbereich vererbt werden.

Beispielsweise wird in der style.css für Aufzählungen der Stil square zugewiesen:

.entry-content ul { list-style: square;  }

Da der DIV-Container mit der Klasse .entry-content aber im WordPress-Editor nicht vorhanden ist, wird diese Formatierung auch nicht auf die Aufzählungen im Editor angewendet.

In die backend.css tragen wir deshalb diese CSS-Formatierung ein und ersetzen die Klasse .entry-content mit der ID #tinymce – denn der body-Tag des Editor-Iframes ist genau mit dieser ID ausgezeichnet:

#tinymce ul { list-style: square;  }

Steht diese Zeile in der backend.css, werden die Aufzählungen in unserem Beispiel richtig angezeigt.

Auf die gleiche Weise identifizierst Du nun alle Formatierungen, die ebenfalls im Editor angezeigt werden sollen. In unserem Beispiel haben wir einfach sämtliche Anweisungen für die Klasse .entry-content  aus der style.css übernommen und entsprechend modifiziert. Dazu gehören in diesem Beispiel auch die Spaltenbreite und die andersfarbige Formatierung des ersten Absatzes.

Aus den in der style.css zusammengesuchten Formatierungen (links) werden die entsprechend modifizierten Einträge in der backend.css (rechts).

Aus den in der style.css zusammengesuchten Formatierungen (links) werden die entsprechend modifizierten Einträge in der backend.css (rechts).

Jetzt sind wir schon fast am Ziel, der Beitrag sieht im Editor so aus:

Fast am Ziel: Nur noch das Anführungszeichen im Zitat-Kasten fehlt.

Fast am Ziel: Nur noch das Anführungszeichen im Zitat-Kasten fehlt.

7. Schriftarten einbinden

Das Geheimnis hinter dem fehlenden Anführungszeichen im Zitate-Kasten: Relativ häufig verwenden Themes besondere Schriftarten. In unserem Beispiel-Theme kommt FontAwesome zum Einsatz.

Das ist ein lösbares Problem, denn auch Schriften kannst Du über die backend.css einbinden. In unserem Beispiel liegt die Schrift-Datei lokal in einem Verzeichnis des Themes, aber natürlich kannst Du auf die gleiche Weise auch Schriften aus anderen Quellen integrieren, beispielsweise von Google.

In unserem Beispiel bringt der folgende Eintrag in der backend.css den gewünschten Erfolg:

@font-face {
font-family: FontAwesome;
 src: url(http://bloggertricks.de/wp-content/themes/colormag/fontawesome/fonts/fontawesome-webfont.ttf);
}

8. Anpassungen sind Theme-spezifisch

Wichtig: Die Klasse .entry-content ist ebenso spezifisch für das in diesem Beispiel verwendete Theme wie etwa der Pfad zu der eben eingebundenen Schriftdatei. In anderen Themes heißt die Klasse sehr wahrscheinlich anders oder die ganze CSS-Struktur ist eine andere. Letztlich musst Du für Dein Theme mit den Entwicklertools des Browsers und ein wenig Spürsinn selbst ermitteln, welche CSS-Definitionen in der backend.css nötig sind, um eine möglichst authentische WYSIWYG-Ansicht zu bekommen.

Identisch ist im WordPress-Editor dagegen immer der body-Tag mit der ID #tinymce – sofern Du mit dem Standard-Editor von WordPress arbeitest und kein anderes Editor-Plugin installiert hast.

Mit ein wenig Glück musst Du bei Deinem Theme nur wenige Anpassungen machen oder Du beschränkst Dich auf einige wichtige Elemente, die für die optische Beurteilung Deines Beitrags schon beim Schreiben relevant sind.

Denn eines ist natürlich klar: Absolut identisch wird die Ansicht im Editor und im Frontend nie sein. Die abschließende Überprüfung musst Du immer mit Hilfe der Vorschau-Funktion machen. Aber bis dahin kann die selbst gebaute WYSIWYG-Ansicht viel Zeit und Nerven sparen.

Nach einigen Anpassungen fast identisch: Editor-Ansicht (links) und Vorschau (rechts).

Nach einigen Anpassungen fast identisch: Editor-Ansicht (links) und Vorschau (rechts).

Tags: WordPress

Der Autor:

Autor: Franz Neumeier

Ich bin Franz Neumeier, war jahrelang Chefredakteur bei IT-Zeitschriften wie PC Professionell, Internet Professionell und Internet Magazin. Inzwischen habe ich mich als freier Autor vor allem auf Kreuzfahrt-Themen spezialisiert, betreibe mehrere Websites und schreibe für STRATO über verschiedene Themen, vor allem über WordPress und übers Bloggen.

11 Kommentare

  1. hans wurst sagte am 30. März 2016 um 6:17:

    euer code für die functions.php ist, wenn kopiert, unbrauchbar…statt den einzel-apostrophen zum einbinden der backend.css stehen dort kommas. >> add_editor_style(‚backend.css‘); >>

    im screenshot ist es richtig geschrieben. musste ewig nach dem fehler suchen. bitte ändern!

    Antworten
    • Philipp Wolf sagte am 1. April 2016 um 17:33:

      Hallo Hans Wurst,

      das bedauern wir, dass Du so lange nach dem Fehler suchen musstest. Wir arbeiten daran, Code demnächst besser darstellen zu können. Bis dahin bitte ich Dich noch um ein wenig Geduld.

      Viele Grüße
      Philipp

      Antworten
  2. Frank E. sagte am 29. Juni 2016 um 17:21:

    So weit ist mir alles klar geworden und es funktioniert, zumal ich ebenfalls das ColorMag-Theme verwende 🙂 . Danke also für den Artikel.

    Was ich allerdings nicht hinbekomme, ist die Standard-Schriftgröße, also die ganz normale Formatierung „Absatz“. Die Schriftart/Größe ist im Editor recht klein geworden und irgendwie blicke ich nicht so ganz durch, was da nun in die backend.css rein muss, damit der „Absatz“ wieder auf die normale Schriftgröße gesetzt wird…

    Antworten
  3. Franz Neumeier sagte am 29. Juni 2016 um 19:57:

    Hallo Frank,

    das funktioniert äquivalent wie in Absatz „6. Suche nach fehlenden Formatierungen“ beschrieben:

    #tinymce p { font-size: 5em; }

    Ich hab‘ mal mit 5em eine etwas übertriebene Schriftgröße gewählt, um den Effekt deutlich zu demonstrieren, aber natürlich kannst Du da beliebige Werte verwenden, um die Größe auf ein angenehmes Maß zu bringen …

    Herzliche Grüße
    Franz

    Antworten
  4. Dieter Langer sagte am 23. August 2016 um 20:44:

    Hallo Franz,
    alles was Du geschrieben hast kann ich verstehen, ist mir aber zu umständlich. Könnte ich das Plug-in https://de.wordpress.org/plugins/beaver-builder-lite-version/ verwenden und damit all die Korrekturen vermeiden? Meine bisherige Webseite bei Strato ist von einem Fachmann erstellt aber ich möchte nun persönlich eine neue Webseite mit einem echten WYSIWYG Programm erstellen, a la iWeb vor 5 Jahren. Da ich bei Strato bleiben möchte, und deren Baukasten-Themes unveränderbar sind, hatte ich die Hoffnung mit WordPress frei gestalten zu können. Gelingt mir aber nicht. Daher der Beaver-Builder.
    Für eine kurze Nachricht wäre ich dankbar.
    Mit freundlichen Grüßen Dieter

    Antworten
    • Franz Neumeier sagte am 24. August 2016 um 13:37:

      Hallo Dieter,

      ich ganz persönlich würde ein solches Plugin nicht nutzen, um ganz ehrlich zu sein. Mir wäre die Abhängigkeit davon zu groß – sprich: die komplette Website hängt ab dem Moment daran, dass die Entwickler das Plugin ständig weiter entwickeln und an WordPress-Updates anpassen. Sollte das einmal nicht mehr der Fall sein, steht man im Zweifel im Regen.

      WordPress ist nicht wirklich als Wysiwyg-Website-Applikation konzipiert sondern eben als Blog, insofern wäre vielleicht eher die Überlegung, über eine komplett andere Software bzw. ein CMS nachzudenken, dass besser zu den Anforderungen passt. Oder ein WordPress-Theme suchen, das genau das kann, was Du suchst (wobei, wenn das zu viel eigene Funktionalität mitbringt, hast Du natürlich fast das gleiche Abhängigkeitsproblem wie mit einem Plugin).

      Das angesprochene Plugin kenne ich aber nicht aus eigener Erfahrung und es ist auch zu komplex, um es mal auf die Schnelle durchzutesten. Insofern würde ich empfehlen, es vor dem Einsatz genau zu testen und insbesondere zu schauen was passiert, wenn man einige Seiten damit eingerichtet hat und dann das Plugin deaktiviert – bleibt alles erhalten? Dann wäre ein Einsatz vermutlich unkritisch. Bleiben die Seiten nicht erhalten, dann ist man eben komplett abhängig vom Plugin. Ob Du dieses Risiko eingehen willst, musst Du selbst entscheiden 😉

      Herzliche Grüße,
      Franz

      Antworten
  5. Manuela sagte am 31. Januar 2018 um 13:14:

    Ich hab soweit verstanden, dass man Klassennamen (.xxx) einfach durch #tinymce ersetzt. Was ist aber, wenn in meinem css praktisch alles nur IDs mit Klassen sind?

    Wie könnte ich dann z. B. sowas im backend wysiwygen?

    #content .row {
    float: left;
    width: 48%;
    margin-top: 50px;
    }

    #content kann ich ja vermutlich nicht einfach durch #tinymce ersetzen – vorallem weil im css noch eine andere ID eine gleichlautende Klasse verwendet.

    Antworten
    • Franz Neumeier sagte am 31. Januar 2018 um 14:49:

      Hallo Manuela,

      der Editor arbeitet so, dass er den Inhalt Deines Blogbeitrags, also das, was im Eingabefeld des Editors steht, in ein iFrame packt, also quasi in eine eigene HTML-Datei. der -Tag dieser „HTML-Datei“ hat die ID „tinymce“. Das ist also hierarchisch die übergeordnete ID auf dieser „Seite“ (sprich innerhalb des Blogpost-Eingabefelds).

      Wenn Du Dir, wie oben beschrieben, mit den Entwicklertools den HTML-Code anschaust und dort nach der Zeile suchst, die mit <body id="tinymce" … beginnt, dann kannst Du hierarchisch unterhalb dieses Body-Tags sehen, welche IDs und Klassen Du adressieren musst, um entsprechende Formatierungen vorzunehmen.

      Ohne Dein Blog zu kennen, kann ich Dir dazu nichts Präziseres schreiben; aber ich vermute, dass die ID "content" im Theme übergreifend eingesetzt wird und deshalb im Editor gar keine Rolle spielt. Ist das der Fall, würdest Du tatsächlich #content durch #tinymce ersetzen.

      Im Zweifel auch einfach mal ausprobieren und schauen, was passiert 😉

      Ich hoffe, das hilft Dir weiter.

      Herzliche Grüße,
      Franz

      Antworten
  6. Herbert sagte am 2. Juli 2018 um 10:05:

    Ich weiß, dass dies etwas weit darüber hinausgeht, auf was WordPress aufgebaut ist. Aber können wir Python ausführen oder verwenden, um das Backend zu bearbeiten?

    Antworten
    • Thomas Ritter sagte am 3. Juli 2018 um 11:40:

      Hallo Herbert,

      ich muss gestehen, ich verstehe nicht so ganz, was Du mit Backend bearbeiten genau meinst. Kannst Du das bitte noch etwas weiter ausführen?

      Danke & schöne Grüße
      Thomas

      Antworten

Hinterlasse eine Antwort

Bitte beachte, dass sich Dein Kommentar auf den Artikel beziehen sollte. Wenn Du ein persönliches Kundenanliegen besprechen möchtest, wende Dich bitte an unseren Kundenservice auf Facebook, Twitter oder über Hilfe & Kontakt.
Wir freuen uns, wenn Du uns Deinen Namen hinterlässt. So wissen wir, wie wir Dich bei unserer Antwort ansprechen können.
Wenn Du Deine E-Mail-Adresse einträgst, wirst Du per Mail über unsere Antwort informiert. Sie wird zum Schutz Deiner Daten aber nicht veröffentlicht. Beide Angaben sind freiwillig.

Hier bloggen

Lisa Kopelmann
Ist Ansprechpartnerin für den Blog und berichtet über aktuelle STRATO Themen

Oliver Meiners
Schreibt über alles, was für Dich als STRATO Kunde wichtig ist

Michael Poguntke
Schreibt über den Online-Speicher HiDrive, den Homepage-Baukasten, Webshops und Server

Thomas Ritter
Berichtet über Neuigkeiten aus dem Unternehmen

Bianca Restorff-Adrion
Schreibt über Karriere & die Menschen bei STRATO

Christian Lingnau
Bloggt über WordPress & andere CMS

Franz Neumeier
Gibt Tipps zum erfolgreichen Bloggen

Sven Hähle
Kennt sich bei Domains hervorragend aus

Patrick Schroeder
Erzählt die Stories unserer Kunden

Ann-Christin Schmitt
Schreibt über HiDrive, den Homepage-Baukasten und guten Websitecontent