WordPress-Editor: Komplexe Inhaltsstrukturen benutzerfreundlich pflegen
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());
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?
Probiere mal Shift + Enter.
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?
Ä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 :-)
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,
Wow, sehr cool. Danke!
[…] WordPress-Editor: Komplexe Inhaltsstrukturen benutzerfreundlich pflegen […]
Man lernt nie aus, danke!
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?
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.
@Thomas: Auf Anhieb habe ich keine Lösung – das muss ich in Ruhe ausprobieren. Aber vielleicht hilft dir dieser Beitrag hier weiter. Damit kannst du prüfen ob ein bestimmtes Page Template Aktiv ist. http://www.wprecipes.com/how-to-check-if-a-page-template-is-active
Das mit :before und mit den extra Farben ist eine klasse Idee! Danke!
Oha, danke!
Aber ist das mit dem „Umbruch“ nicht hinfällig wenn man ein Responsives Layout hat?
@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.