CSS für den Dashboard-Editor

Es ist schon ärgerlich, wenn man im Wysiwyg-/TinyMCE-/Visuell-/Viewer-Editor des Dashboards eine mehr oder weniger stark vom endgültigen Frontend abweichende Darstellung bekommt. WordPress kennt auch hier Abhilfe, wenn diese auch nicht von allen Themes bereitgestellt wird. Wenn diese Möglichkeit vom Theme nicht angeboten wird, kann es nachgereicht werden, darauf komme ich sofort zurück.

Im Standard-Theme 2010 und auch bei seinen Nachfolgern steht die Datei editor-style.css bereit, mit der man die entsprechende Abgleichung zwischen Frontend und Editorsicht durchführen kann. Man sollte vielleicht meinen, dass die Abstimmung für 2010 bereits durchgeführt ist, dem ist aber nicht so. Da wohl kaum jemand das Standard-Theme 1:1 übernimmt, würde eine solche Abgleichung auch nach wenigen Schritten nichts mehr bringen.

Es gibt je nach Bedarf verschiedene Vorgehensweisen, den Editorstyle so zu entwickeln, dass die Sicht in annähernder Übereinstimmung mit der Frontendsicht ist.

  1. Wenn man erst nach Herstellung des Designs der Website die gewünschte Editorsicht benötigt – also im allgemeinen für den Kunden – kann man sich das ständige Nachziehen im editor-style.css nach erfolgter Änderung im style.css ersparen und die Arbeit mit einem Schlag erledigen.
  2. Gehen aber Design-Arbeit und möglichst komfortable Texterstellung Hand in Hand muss nach erfolgter Änderung der style.css geprüft werden, ob diese auch Auswirkungen auf die content-Darstellung hat und dann editor-style.css  entsprechend angepasst werden.

In beiden Fällen reicht es aber nicht aus, die entsprechenden Styles einfach zu kopieren, denn der Editor und das Style des Frontend haben unterschiedliche Selektoren. Im Theme 2010/11/12 wird der Selektor #content benutzt, um das Styling des Content vom Styling der Sidebars und Menüs zu unterscheiden, während im Dasboard-Editor der Klassenselektor .mceContentBody für den Content-Bereich zuständig ist.

Die bequemste Art, Dashboard-Sicht und Frontend-Sicht anzugleichen, ist also in beiden Fällen die Ersetzung von #content durch .mceContentBody, nachdem man entweder das ganze style.css in das editor-style.css kopiert hat (Fall 1) oder nachdem man die entsprechenden Statements aus style.css nach editor-style.css übertragen hat.  Im ersten Fall wird man natürlich viele überflüssige Style-Definitionen mitschleppen, aber da im Editor die Effizienz keine gr0ße Rolle spielt, kann man damit leben. Sauberer wäre es, das Styling des content-Bereichs klar abzugrenzen, evtl. sogar durch ein includierendes css, so dass nur die relevanten Styles übertragen werden müssen.

Was aber, wenn es kein editor-style.css gibt? WP bietet alle Mittel an, das nachzudefinieren:

Man füge in die functions.php folgende Funktion ein:

function theme-setup() {add_editor_css();}

Der Name theme-setup ist frei wählbar, deshalb kursiv geschrieben. Um diese Funktion zum Leben zu erwecken, d. h. dass das File beim Stylen der Editorsicht auch gesehen wird, muss sie natürlich zu einem geeigneten Zeitpunkt aufgerufen werden und das ist naheliegend nach der Aktivierung des Themes.

add_action( 'after_setup_theme', 'theme-setup' );

Statt einer eigenen Funktion ließe sich hier auch eine anonyme Funktion benutzen, aber wenn man vielleicht mehrere solche Statements zum setup eines Themes ausführen will, bleibt eine solche Vorgehensweise eher selbstdokumentierend. Natürlich muss das File editor-style.css noch erzeugt und auf Themeniveau eingebunden werden. WP sieht vor, dass der Name dieses Files frei wählbar ist, also nicht unbedingt editor-style.css lauten muss. Dafür muss der Funktion add_editor_css ein Argument mitgegeben werden, also z. B.

function theme-setup() 
 {add_editor_css('custom-editor-style');}

Es genügt also nicht, sich davon zu überzeugen, dass im Theme kein editor-style.css existiert, sondern man sollte sicherheitshalber in der functions.php nachschauen, ob nicht ein anderer Name gewählt wurde.

Nun noch 3 wichtige Hinweise.

1. Für einen normalen Blog reicht es in den meisten Fällen aus Schriftfamilie, Schriftgröße und content-Breite anzupassen. Für letzteres suche man z.  B. im editor-style.css von 2010 nach

.mceContentBody {   max-width: 625px;}

und ändere die Breite entsprechend. Für flexible Breite muss man natürlich einen Kompromiss wählen, hier kann ja auch jede Frontend-Sicht differieren.

2. Diese Breitenangabe hat aber keine Auswirkung auf die Breite der Vollbildsicht des Editors. Hierzu muss man wieder in die funktions.php eingreifen und folgendes Statement einsetzen, z. B. an das Ende des Files:

set_user_setting( 'dfw_width', 1000 );

Hier steht 1000 als Beispielbreite für 1000px.

3. Nun vielleicht der wichtigste Hinweis: WP hat die Macke, dass die Änderungen in editor-style.css sich nicht sofort auf das Erscheinungsbild im Editor auswirken. Das ist frustrierend, lässt sich aber beheben, wenn man im Browser nach der Änderung den Cash löscht.

In den Standard-Themes befindet sich auch noch die Datei editor-style-rtl.css. Hierbei steht rtl für right to left, also für die Schriftrichtung rechts nach links. Hiermit wird deutlich, wie sinnvoll es ist, add_editor_style parametrisieren zu können. Damit sind im gleichen Theme beide Schriftrichtung auch im Editor möglich. Welche der Dateien nun aktiviert wird, hängt von der voreingestellten Schriftrichtung ab.

Resourcen:

One thought on “CSS für den Dashboard-Editor

  1. Pingback: Review: 23.10.2012 | WP Meetup Potsdam

Comments are closed.