Wenn ihr WordPress für Kundenprojekte einsetzt, werdet ihr schnell merken, dass einige Kunden Schwierigkeiten mit dem WordPress-Editor haben. Insbesondere wenn ein komplexer Inhaltsbereich gefüllt werden soll – beispielsweise ein mehrspaltiges Layout – sind viele Kunden überfordert. Und wir wollen den Kunden ja auch nicht mit der HTML-Variante quälen.
Ihr könnt den Editor ganz einfach mit Standard-Inhalten füllen und mit einer eigenen CSS-Datei stylen. Und das sogar für verschiedene post_types individuell. Es bietet sich u.U. also an, vorab eine HTML-Struktur festzulegen und für den Kunden benutzerfreundlich darzustellen.

WordPress-Editor mit Standard-Inhalten füllen

Über die functions.php des Themes könnt ihr den Editor mit Default-Content füllen. Häufig wird als Einsatzbeispiel ein wiederkehrender Absatz am Ende von Artikeln genannt den ich persönlich allerdings direkt ins Template schreiben würde.
Ich möchte in diesem Beispiel ein HTML-Grundgerüst für verschiedene Seitentypen anlegen, und anschließend so gestalten, dass der Kunde sich leicht zurechtfindet. Aber beginnen wir erst einmal mit der grundsätzlichen Funktionsweise.

Folgender Code gehört in die functions.php und fügt Standard-Inhalt in den Editor verschiedener Beitragstypen ein. Zunächst erstellen wir den Inhalt für statische Seiten und Custom Post Types. Anschließend den Inhalt für alle verbliebenen Beitragstypen wie die Artikel.


// Standard-Inhalte für verschiedene Beitragstypen
function kb_custom_editor_content( $kb_default_content ) {
   global $current_screen;
   
   // Für statische Seiten
   if ( $current_screen->post_type == 'page') {
	  $kb_default_content = 'Dieser Inhalt erscheint bei statischen Seiten.';
   }
   
   // Für Custom Post Types
   elseif ( $current_screen->post_type == 'POSTTYPE') /* POSTTYPE durch den Namen des Post Types ersetzen! */ {
	  $kb_default_content = 'Dieser Inhalt erscheint bei Custom post Types.';
   }
   
   // Alle weiteren Beitragstypen wie Artikel etc. 
   else {
	  $kb_default_content = 'Dieser Inhalt erscheint bei Artikeln und allen Beitragsarten, die nicht zuvor definiert wurden.';
   }
   
   return $kb_default_content;
 }
 
 add_filter( 'default_content', 'kb_custom_editor_content' );

Wenn ihr anschließend einen neuen Inhalt erstellt, wird automatisch der Default-Content eingefügt. Auf bereits erstellte Beiträge hat die Funktion keinerlei Auswirkungen.

Der hier abgebildete Code lädt nur eine Textzeile in den entsprechenden Editor. Ihr könnt auch komplexe HTML-Strukturen festlegen. Wie das funktioniert und welche Vorteile es hat zeige ich später.

Ein eigenes Stylesheet für den Editor: editor-style.css

Ihr habt den Editor mit Default-Content gefüllt, jetzt fehlt noch eine CSS-Datei um die Inhalte des Editors – sei es nun Default-Content oder nachträglich erstelle Elemente – ansprechend zu gestalten.

Fügt den nachfolgenden Code in die functions.php eures Themes ein. Anschließend sucht der WordPress-Editor im Stammordner des Themes (dort wo auch die style.css abgelegt ist), nach einem CSS-Dokument namens editor-style.css. Mit diesem Stylesheet könnt ihr den Inhalt des Editors dann gestalten.


// Individuelles Stylesheet für den Editor
function kb_custom_editor_stylesheet() {
   add_editor_style(
	   array('editor-style.css')
   );
}

add_action( 'admin_head', 'kb_custom_editor_stylesheet' ); 

Alternativ könnt ihr auch dieses verkürzte Snippet verwenden. In diesem Fall wird nach einer CSS-Datei namens editor-style.css im Stammverzeichnis des Themes gesucht.


// Aktivierung der editor-style.css im Root
add_editor_style();

Eigene Stylesheets für Custom Post Types

Das zuvor gezeigte Snippet gilt immer für alle Editor-Bereiche und für alle Arten von Inhalten. Wenn ihr allerdings mit Custom Post Types arbeitet, kann es Sinn machen für verschiedene Custom Post Types verschiedene Stylesheets anzulegen.
Das folgende Snippet ist eine kleine Erweiterung des vorherigen. Nun wird für jeden Custom Post Type nach einem eigenen Dokument gesucht. Die Namenstruktur ist immer editor-style-NAME DES POST TYPES.css.


// Individuelle Stylesheets für den Editor (je nach Post Type)
function kb_custom_editor_stylesheet() {
   global $current_screen;
   
   add_editor_style(
	   array(
		  'editor-style.css',
		  'editor-style-'.$current_screen->post_type.'.css'
		)
   );
 }

 add_action( 'admin_head', 'kb_custom_editor_stylesheet' );

Und so sieht’s in der Praxis aus

Ihr habt nun alle Basics gelernt, um den Editor für eure Kunden ansprechend zu gestalten. Ich möchte euch mit einem einfachen Praxisbeispiel noch zeigen, wie das Ganze dann aussehen könnte.

Über den Default-Content wurden nur div-Container erstellt. Der beschreibende Text über den Textbereichen wird über das Pseudoelement :before per CSS generiert. Der Vorteil an :before ist, dass der Inhalt nur im Editor – nicht aber im Frontend sichtbar ist.

In der functions.php habe ich folgenden Inhalt voreingestellt.

[...]

$kb_default_content = '
  	  <div class="entry"></div> 
	  <div class="contentMain"></div>
	  <div class="contentAside"> </div>
	  ';
[...]

Die editor-styles.css habe ich anschließend mit diesem Inhalt gefüllt.

* {font-family:Arial, Helvetica, sans-serif;}

.wp-editor {width:800px;}

.entry:before {
	content:'Einleitungstext';
	color:silver;
	font-size:11px;	
	position:absolute;
	top:-20px;
	left:0;
}

.entry, 
.contentMain,
.contentAside {
	float:left;
	padding:15px;
	margin:30px 10px 10px 10px;
	border:1px dashed silver;
	position:relative;
}

.contentMain:before {
	clear:both;
	float:none;
}

.entry {width:750px;}

.contentMain {width:550px;}

.contentMain:before {
	content:'Haupt-Inhalt';
	color:silver;
	font-size:11px;	
	position:absolute;
	top:-20px;
	left:0;
}

.contentAside {width:150px; margin-right:0;}

.contentAside:before {
	content:'Ergänzender Inhalt';
	color:silver;
	font-size:11px;	
	position:absolute;
	top:-20px;
	left:0;
}

Ich habe übrigens bewusst mit festen Pixelgrößen gearbeitet, damit der Kunde besser einschätzen kann wo später auf der Website ein Zeilenumbruch entsteht. Das ist zwar meist ein wenig Gefummel bis es wirklich so klappt wie auf der Website, dann ist es allerdings ein echter Mehrwert.

Caching-Probleme mit der editor-style.css beheben

Wenn beim Reload des Editors keine Änderungen sichtbar werden kann dies am Cache des TinyMCE liegen. Fügt in diesem Fall folgenden Code anstelle des o.g. Codes ein.

add_editor_style('editor-style.css?' . time());

Geschrieben von Jonas

Benutzerbild

Jonas ist Gründer der Agentur kulturbanause und des kulturbanause Blogs. Er arbeitet an der Schnittstelle zwischen UX/UI Design, Frontend und Redaktion und hat zahlreiche Fachbücher und Video-Trainings veröffentlicht. Jonas Hellwig ist regelmäßig als Sprecher auf Fachveranstaltungen anzutreffen und unterstützt mit Seminaren und Workshops Agenturen und Unternehmen bei der Planung, der Gestaltung und der technischen Umsetzung von Web-Projekten.

Jonas Hellwig bei Xing

Feedback & Ergänzungen – 15 Kommentare

  1. tskraft
    schrieb am 19.06.2016 um 14:26 Uhr:

    Ich möchte diese Lösung gern einsetzen (Es ist viel einfacher als komplexe Seitenstrukturen in Typo3), aber in der Praxis gibt es Schwierigkeiten (Jahr ist mittlerweile 2016, ich benutze WordPress 4.5.2), und zwar:
    Ich schreibe einen Absatz im Bereich Haupt-Inhalt, drücke Enter, und dann verdoppelt sich der Bereich Haupt-Inhalt. Hat jemand vielleicht eine Lösung dafür?

    Antworten
    • Jonas Hellwig
      schrieb am 19.06.2016 um 15:43 Uhr:

      Probiere mal Shift + Enter.

      Antworten
  2. Sabine
    schrieb am 10.07.2013 um 10:56 Uhr:

    Super, gefällt mir gut.

    Habs gleich mal ausprobiert. Zeilenumbrüche funktionieren aber leider garnicht. Wird die Entertaste benutzt, wird ein neues Feld eingefügt. Ein sanfter Umbruch wird beim speichern ganz entfernt – mmh?

    Antworten
  3. Jonas
    schrieb am 18.04.2012 um 10:21 Uhr:

    Ähm, ja. Also ich meinte nbsp;-Ergänzungen und das nbsp;-Problem :-)
    Und überhaupt: vielen Dank für den Beitrag, er bringt mich meinem WordPress-Ideal Lichtjahre näher :-)

    Antworten
  4. Jonas
    schrieb am 18.04.2012 um 10:16 Uhr:

    Leider werden HTML5-Elemente in der TinyMCE-Version, die in WP-Version 3.3.1 verbaut ist, noch nicht so schön unterstützt, was lästige  -Ergänzungen zur Folge hat. In der aktuellsten TinyMCE-Version wurden diese Fehler behoben. Leider funktionierte die aber noch nicht mit dem TinyMCE-Templates-Plugin, nargh :-) Oder gibt es für das  -Problem noch eine andere Lösung?

    Viele Grüße,

    Antworten
  5. Philipp
    schrieb am 27.01.2012 um 01:22 Uhr:

    Wow, sehr cool. Danke!

    Antworten
  6. Links 49 » WoWa-Webdesign Friedrichshafen, Bodensee
    schrieb am 12.12.2011 um 11:07 Uhr:

    […] WordPress-Editor: Komplexe Inhaltsstrukturen benutzerfreundlich pflegen […]

    Antworten
  7. Tobi
    schrieb am 10.12.2011 um 22:10 Uhr:

    Man lernt nie aus, danke!

    Antworten
  8. Thomas
    schrieb am 10.12.2011 um 19:04 Uhr:

    Danke für die schnelle Antwort.

    Was ich eben auch noch festgestellt habe, dass wenn eines der „Felder“ ohne Inhalt ist und die Seite abgespeichert wird, dieses Feld aus dem Editor verschwindet. Schade, denn vielleicht will der Anwender es ja später füllen.

    Hast Du dazu ’ne Idee?

    Antworten
  9. Thomas
    schrieb am 10.12.2011 um 18:15 Uhr:

    Danke für die tolle Erklärung.

    Wie könnte ich unterschiedliche Standardinhalte für verschiedene Seiten-Templates generieren?

    Um was müsste ich die Anfrage
    if ( $current_screen->post_type == 'page') {
    ergänzen, um abfragen zu können, welches Seiten-Template verwendet wird.

    Antworten
  10. Caspar
    schrieb am 08.12.2011 um 12:51 Uhr:

    Das mit :before und mit den extra Farben ist eine klasse Idee! Danke!

    Antworten
  11. Tocki
    schrieb am 08.12.2011 um 12:33 Uhr:

    Oha, danke!

    Antworten
  12. Stefan
    schrieb am 08.12.2011 um 09:29 Uhr:

    Aber ist das mit dem „Umbruch“ nicht hinfällig wenn man ein Responsives Layout hat?

    Antworten
    • Jonas Hellwig
      schrieb am 08.12.2011 um 09:37 Uhr:

      @Stefan: Absolut, dann war’s das natürlich mit dem Umbruch. Trotzdem hilft es den Kunden manchmal sich die Frontend-Desktop-Version besser vorzustellen. Am wichtigsten ist es eigentlich, dass der Kunde versteht wie er den Inhalt semantisch auszeichnet und nicht überall manuell Zeilenumbrüche etc. erstellt. Das ist allerdings manchmal gar nicht so einfach.

      Antworten

Kommentar zu dieser Seite

Wir freuen uns über Anregungen, Ergänzungen oder Hinweise zu Fehlern. Wir lesen jeden Eintrag, veröffentlichen aber nur, was den Inhalt sinnvoll ergänzt.

WordPress-Projekte mit kulturbanause

Wir wissen wovon wir reden. Wir setzen WordPress seit über 10 Jahren erfolgreich ein und realisieren maßgeschneiderte Websites auf Basis dieses großartigen CMS.

WordPress-Leistungsangebot →

Schulungen von kulturbanause

Wir bieten Seminare und Workshops zu den Themen Konzept, Design und Development. Immer up-to-date, praxisnah, kurzweilig und mit dem notwendigen Blick über den Tellerrand.

Übersicht Schulungsthemen →