WordPress: Revolution Slider Interval anpassen (Visual Composer Element)

Eine Antwort

Sehr praktisch: viele WordPress Premium Themes werden mit mächtigen Plugins aufgeliefert, die man nicht extra bezahlen muss. Allerdings kann die Anpassung dieser Plugins ein wenig schwierig sein – und beim Support fühlt sich plötzlich niemand zuständig.

Kauft man beispielsweise eine Lizenz des beliebten Themes Stockholm, dann gibt es unter anderem gleich noch den Visual Composer und den Revolution Slider dazu. Somit kann man einfach per Drag’n’Drop eine Slideshow / einen Slider in beliebige Seiten einbauen – und über das mitgelieferter Interface auch bedingt anpassen.

Der Interval, in dem die Bilder wechseln lässt sich allerdings nur in 4 Stufen regeln. Das Dropdown Menu „auto rotate“ bietet lediglich die Auswahl 3 Sekunden, 5 Sekunden, 10 Sekunden und 15 Sekunden an – alternativ kann man die Funktion „auto rotate“ auch ausschalten.

In den meisten Fällen ist diese Auswahl siecherlich ausreichend – aber manchmal kommt es eben doch auf die Feinheiten an. Und wer es zB von jQuery-Slidern gewöhnt ist, den Bilderwechsel-Interval auf die Tausendstel Sekunde genau einstellen zu können, der kommt sich bei der beschränken Auswahl doch ein wenig ‚ausgebremst‘ vor, um es einmal milde auszudrücken.

Wordpress Slider auto rotate Bildwechsel Interval anpassen Ich habe mich also zunächst an den Support des Themes Stockholm gewandt – aber eigentlich wäre das Sache des Visual Composers. Dort sagte man mir, ich solle mir doch mal die API ansehen – ausserdem hätte der Visual Composer ja nur indirekt mit dem Revolution Slider zu tun. Langer Rede kurzer Sinn: so kam ich nicht weiter. Also ab in den Quellcode.

Um den Code des eigentlichen Sliders herum ist ein div zu finden, das ungefähr so aussieht:

<div class="wpb_gallery_slides wpb_flexslider flexslider_fade flexslider" data-flex_fx="fade" data-interval="10">

Wenn ich als Wert für „auto rotate“ 5 auswähle, steht bei „data-interval“ eine „5“ – der Bilderwechsel-Interval wird also vom Visual Composer Interface in das div – und aus dem div heraus an den Slider übergeben.

Anstatt das Interface des Visual Composer zu hacken kann man nun einfach in die Quellcode-Ansicht wechseln und den Wert dort manuell anpassen.

Zunächst also über die blaue VC-Schaltfäche den „Klassischen Modus“ aufrufen – dann über den Reiter „Text“ in den textmodus wechseln. (Geht vermutlich auch in der regulären Ansicht – mir ist aber persönlich lieber, wenn ich Shortcodes im Quellcode ändere.)

Anschliessend bekommt man unter Umständen eine sehr umfangreiche Sammlung verschiedener Shortcodes zu sehen – je nachdem, wieviele und welche Elemente man bereits über den Visual Composer in die Seite eingebaut hat. Die entscheidende Stelle sieht dann so aus:

[vc_gallery interval="10" images="22390,23006" img_size="full"]

Hier einfach den Wert für den Interval anpassen – zum Beispiel auf 7 Sekunden – und schon wechseln die Bilder im 7-Sekunden-Takt.

[vc_gallery interval="7" images="22390,23006" img_size="full"]

Der Revolution Slider bzw. das Visual Composer Interface zum Revolution Slider kann mit diesem Wert leider nichts anfangen. Wenn man zu einem späteren zeitpunkt also Bilder hinzufügt kann es passieren, dass das Interface den Wert erstmal wieder auf 3 Sekunden zurücksetzt. Dann muss man *einfach* noch einmal in den Quellcode und den Interval entsprechend anpassen.

Webseite langsam? Geschwindigkeit von PHP Skripten testen

Schreibe eine Antwort

Die Webseite lädt langsam? Es könnte an einem Skript liegen… Aber welches?

Wenn Sie zum Beispiel das Gefühl haben, dass eine bestimmte Funktion, eine spezielle Datenbankabfrage oder vielleicht ganz konkret ein bestimmtes WordPress Plugin zu langsam läuft, dann kann es durchaus mal sein, dass das an einem ungünstigen Loop liegt und/oder dass vielleicht zu viele (unnötige) Datenbankanfragen an den Webserver gestellt werden.

Bevor man aber loszieht und den vermeintlich langsamen Skripte mit dem Feuerschwert begegnet sollte man zunächst versuchen, die Ursache – die Bremse zu finden. Häufig reicht es dafür, einfach mal die Zeit zu stoppen, die ein bestimmtes Skript benötigt.

Dazu muss man lediglich vor Ausführung des verdächtigen Skripts eine Art Stoppuhr starten – wenn dann das Skript oder die Datenbankabfrage durchgelaufen ist schaut man einfach nach, wieviel Zeit vergangen ist. Und mit PHP ist es zum Glück auch relativ einfach, eine solche SToppuhr zu bauen und diese quasi um einen verdächtigen Code zu klammern – solange es sich eben um PHP Code handelt. Microtime ist Dein Freund!

Zunächst brauchen wir eine Variable für den Timer, der vor Ausführung des zu untersuchendes Codes gestartet wird:

$start_timer = microtime(true); // TIMER START

Dann wird der Timer gestoppt, sobald der Code durchgelaufen ist. Genau genommen wird hier einfach die Differenz zwischen START und STOPPin der Variable $time_passed gespeichert:

$time_passed = microtime(true) - $start_timer; // TIMER STOP

Man könnte den so errechneten Wert – also die Dauer über ein einfaches echo anzeigen lassen:

echo("Das Skript hat ".$time_passed." Sekunden benötigt.");

Wenn man dann noch den Wert auf zwei Kommastellen runden möchte, setzt man einfach die PHP Anweisung round davor:

echo("Das Skript hat ".round($time_passed, 2)." Sekunden benötigt");

Alles zusammen genommen könnte am Ende dann ungefähr so aussehen:

$start_timer = microtime(true);

// hier folgt der verdächtige Code
while … {

}

$time_passed = microtime(true) - $start_timer;

echo("Das Skript hat ".round($time_passed, 2)." Sekunden benötigt.");

Nachtrag: Ob sich der Aufwand lohnt? Ist die Ladezeit überhaupt SEO-relevant? ist eine langsam ladende Seite schlecht für SEO? Und/oder ist eine langsame Webseite schlecht für UX? Alle diese Fragen können ganz klar mit JA beantwortet werden:

Ladezeit ist SEO-relevant
Spätestens seit 2010 ist es offiziell: die Ladezeit einer Webseite beeinflusst neben vielen anderen Faktoren die Suchergebnisse-Position einer Webseite. Bereits 2009 hatte google ein Experiment durchgeführt, bei dem die Ladezeit der Suchergebnisseite künstlich verlangsamt wurde – und das Ergebnis war eindeutig: Ladezeit ist SEO-relevant.
Ladezeit ist UX-relevant
Die oben genannten Untersuchung war im Prinzip ’natürlich‘ eine Untersuchung der User Experience. Wenn die Suchergebnisseite nur 100ms bis 400ms langsamer lädt, reduziert sich die Zahl der Suchanfragen um 0,2% bis 0,6% – die Nutzer verlieren mit abnehmender Geschwindigkeit die offenbar die Lust, die Seite zu benutzen.
Lohnt sich der Aufwand?
Ich habe kürzlich für einen Kunden eine Seite optimiert, die man auch schon als WebApp bezeichnen kann. Kurz beschrieben: aus unterschiedlichen Datenbankabfragen wird je nach gesetzten Präferenzen und Optionen eine komplexe Tabelle generiert. Vor der Optimierung wurde jede Tabellenzelle bzw. die Ausgabe jeder Tabellenzelle über einen Loop einzeln generiert. Nach der Optimierung genügte eine einzige Datenbankabfrage. Wir darüberhinaus an verschiedenen Stellen im Skript die Zeit gemessen, die zum Beispiel zur Ausführung einer bestimmten Funktion benötigt wurde und anschliessend verschiedene Alternativen getestet. So konnten wir letztendlich die Zeit, die benötigt wird, um die Daten für die Tabelle zusammenzustellen von 5 – 10 Sekunden auf unter 0,5 Sekunden reduzieren. Ja: der Aufwand lohnt sich. Manchmal.

WordPress Child Theme erstellen – ganz einfach

Schreibe eine Antwort

Wenn man eine WordPress Webseite erstellen möchte, sollte man am besten gleich auch ein WordPress Child Theme erstellen. Es gibt natürlich eine Fülle fertiger WordPress Themes – und viele kostenpflichtige Premium Themes bieten bereits umfangreiche Anpassungsmöglichkeiten: über diverse Optionen lassen sich häufig ‚ganz einfach‘ Design-Details wie Schriftart und Farben anpassen. Und auch bei kostenlosen Themes lässt sich häufig immerhin die Schriftfarbe oder andere Design-Elemente über eingebaute Optionen ändern. Egal für welches Theme man sich am Ende entscheidet – hier und da möchte man gegebenenfalls Design–Anpssungen machen, sodass das Deisgn den eigenen Wünschen bzw. den Kundenwünschen entspricht und sich vonanderen Webseiten abhebt.

Der einfachste Weg ist sicherlich, direkt in den entsprechenden Templates und Stylesheets Änderungen vorzunehmen. Dies ist allerdings auch der ‚drechigste‘ Weg – ein alter Grundsatz lautet: never hack the core! Beim nächsten Update kann das sonst zu bösen Überraschungen führen: die mühsam eingearbeiteten Anpassungen werden beim Update unter Umständen direkt überschrieben, Design-Anpassungen gehen verloren und dann sieht plötzlch alles wieder genau so aus, wie am Anfang.

Der wirklich einfachste Weg, um schnell individuelle Anpassungen an einem WordPress Theme vorzunehmen ist, ein eigenes Child Theme einzurichten.

WordPress Child Theme erstellen – ganz einfach

Vor einigen Jahren war es noch etwas umständlich, schnell mal ein eigenes WordPress Child Theme zu erstellen. Inzwischen ist das aber sehr viel einfacher geworden. Im Prinzip muss man nur zwei Dateien anlegen – schon kann man mit den eigenen Style-Anweisungen die voreingestellten Theme-Styles überschreiben. Genug der Vorrede – so geht’s:

Zunächst legt man im Themes-Verzeichnis ein neues leeren Verzeichnis an. Dieses Verzeichnis wird dann alle Dateien beinhalten, die unser Child Theme benötigt. Das Verzeichnis sollte daher schon so benannt sein, wie das Child Theme heissen soll. In diesem Falle nennen wir das Child Theme einfach mal „Mein Theme“ und das Verzeichnis dementsprechend „mein-theme“.

1) Child Theme Stylesheet style.css einrichten

In dem neuen Verzeichnis legt man dann ein Stylesheet an, das folgenden Code enthalten sollte:

/*
 Theme Name:   Mein Theme
 Theme URI:    http://cpu20.de/mein-theme/
 Description:  Twenty Fifteen Child Theme
 Author:       Vorname Nachname
 Author URI:   http://cpu20.de
 Template:     twentyfifteen
 Version:      1.0.0
 License:      GNU General Public License v2 or later
 License URI:  http://www.gnu.org/licenses/gpl-2.0.html
 Tags:         light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
 Text Domain:  mein-theme
*/

Wozu sind die einzelnen Angaben notwendig? Naja – die meisten Angaben sind nicht wirklich notwenig, damit das Child Theme auch funktioniert. Es ist aber gut, sich an die verabredeten Strukturen zu halten, damit später mal jemand nachvollziehen kann, womit er es hier eigentlich zu tun hat. Ausserdem werden einige der Angaben des sogn. Stylesheet-Headers später im Administrationsbereich von WordPress angezeigt.

Ich habe mir angewöhnt, das Child Theme nach dem jeweiligen Projekt bzw. dem Kunden zu benennen. Damit ist dann allen beteiligten klar, dass es sich hier um Anpassungen handelt, die speziell für diesen Kunden vorgenommen wurden. Das kann aber natürlich jeder so machen, wie er möchte. Kurz ein paar Details zu den Angaben:

Theme Name ist der Name des Themes in diesem Falle des Child Themes.
Theme URI ist die Web-Adresse, unter der man mehr über dieses Theme erfährt.
Unter Description sollte eine kurze Beschreibung des Themes zu finden sein.
Der Author ist natürlich der Autor des Child Themes und über die Author URI sollte der Autor zu finden sein.
Bei Template muss das Verzeichnis des Parent Themes eingetragen werden, das überschrieben bzw. ergänzt werden soll (wichtig!). In diesem Falle wäre also twentyfifteen das Parent Theme.
Version sollte selbsterklärend sein – die Version des Themes.
Unter Licence und Licence URI ist die Nutzerlizenz des Themes hinterlegt. In des meisten Fällen sollte das die GNU General Public License sein.
Mit Tags lässt sich das Theme beschreiben – das erleichtert ggf. ein späteres Auffinden in Themes-Verzeichnissen.
Und die Text Domain ist wiederum wichtig, damit das Theme auch in andere Sprachen übersetzt werden kann. Sie muss eindeutig sein und sollte sich am Namen des Themes orientieren.

Der erste Schritt zum WordPress Child Theme ist gemacht – jetzt müssen wir nur noch Child Theme und Parent Theme miteienander verbinden – und das passiert in der Datei functions.php…

2) Child Theme functions.php einrichten

Die zweite Datei im Child Theme Verzeichnis ist die functions.php, die wenigstens den Code enthalten muss, der das Child Theme mit dem Parent Theme verbindet. Das Child Theme würde zwar theoretisch auch ohne diese Verbindung funktionieren – es würden aber keine Style-Anweisungen und keine Funktionen des Parent Themes übernommen werden – somit wäre das Child Theme kein Child mehr, sondern ein eigentständiges Theme.

Hier also der Code:

<?php
function theme_enqueue_styles() {

    $parent_style = 'parent-style';

    wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( $parent_style )
    );
}
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
?>

Was dieser Code-Schnippsel macht: zunächst wird das Stylesheet des Parent Themes geladen, dann das Stylesheet des Child Themes. Damit ist gewährleistet, dass zunächst alle Style-Anweisung ‚reguler‘ befolgt werden. Anschliessend werden die individuellen Anpassungen berücksichtigt.

In einem letzten Schritt muss das neue Theme nun noch aktiviert werden. Sobald das Verzeichnis auf den Webserver geladen wurde sollte es im Administrationsbereich unter Design > Themes zu finden sein. Nachdem es aktiviert wurde greifen alle Anpassungen, die man im Stylesheet hinterlegt hat. Ausserdem lassen sich der functions.php nun auch beliebige Funktionen hinzufügen, die das Theme ggf. bereichern können.

Wer möchte, kann nun auch noch ein paar Schritte weiter gehen. Grundsätzlich lässt sich in weinem WordPress Child Theme alles das anpassen, was ein WordPress Theme zu bieten hat. Dazu aber mehr in einem anderen Tutorial. Zunächst würde ich mal empfehlen, einen Screenshot des Child Themes zu hinterlegen. Dazu legt man einfach ein entsprechendes png-Bild im Theme-Verzeichnis an und benennt es screenshot.png – damit sieht das Theme auch im Administrationsbereich dann ‚ordentlich‘ aus.

Email mit „Domain availability notice“ – was tun?

Schreibe eine Antwort

Wenn man ein paar Domains besitzt, bekommt man hin und wieder Emails mit der Betreffzeile „Domain X availability notice“. Manchmal steht auch einfach nur der Domainname „Domain X“ in der Betreffzeile, und der Absender lautet zum Beispiel „Domain Available Info“. Und manchmal bekommt man sogar gleich von mehreren Diensten ähnlcihe Emails zugeschickt.

Dabei bezieht sich „Domain X“ meistens auf einen Domainnamen, der einem irgendwie bekannt vorkommt – der einem Domainnamen ähnelt, den man selbst in der Sammlung hat. Häufig Domains mit alternativer Endung angeboten. Zum Beispiel wird einem nahegelegt, dass doch „cpu20.com“ gut zu „cpu20.de“ passen würde. Was tun?

“ I just wanted to let you know that domain CPU20.COM is now available again and we are brokering the sale. Since you have a related domain name we thought you might have some interest in this one? „

Bei diesen Diensten handelt es sich in der Regel um professionelle Domain-Händler, die gerne auch mal als „Domain-Grabber“ bezeichnet werden.

Was machen Domain-Grabber? Dürfen die das?

Grundsätzlich sollten Domains eigentlich nur von Personen und Firmen registriert werden, die ein direktes Interesse an der jeweiligen Domain haben. So steht es zumindest in den Richtlinien des Internic – der zentralen Registrierungsstelle für Domainnamen. Trotzdem reservieren Domain-Grabber und Domain-Händler gerne manchmal hunderte oder sogar tausende Domains, um diese eventuell gewinnbringend zu veräßern. Rechtlich bewegen sie sich damit meines Wissens nach in einer Grauzone. Praktisch kann man dagegen aber kaum etwas tun.

Häufig fangen Domain-Grabber abgelaufene Domains auf. Wenn eine Domain aufgegeben und somit wieder frei wird, kann sie theoretisch jeder neu registrieren. In der Praxis wird aber ein Großteil der freiwerdenden Domains inzwischen von solchen Domain-Grabbern abgegriffen.

Was kann man tun?

Es ergeben sich eigentlich die folgenden drei Möglichkeiten:

Domain-Grabber beauftragen
Man möchte die angebotene Domain übernehmen und beauftragt einen solchen Dienst mit der Übernahme. Je nach Dienst und je nach Domain wird dann eine bestimme Gebühr fällig. In der Regel bewegen sich die Kosten zwischen 100 und 200 Dollar – es kann aber auch teurer werden.
Domain selber registrieren
Man kann natürlich darauf hoffen, dass man schneller ist, als die Domain-Grabber. Das wird technisch aber kaum möglich sein. Insofern bleibt eigentlich nur die Hoffnung, dass die Domain-Grabber die Domain zwar anbieten, aber ohne feste Zusage nicht tätig werden und die Domain somit fallengelassen und letztendlich frei registrierbar wird. Das kann klappen, aber man sollte sich nicht darauf verlassen.
Alternative Domain registrieren
Man sucht sich einfach eine alternative Domain und registriet diese. Zunächst kann das etwas frustrierend sein, da sich der angebotene Domainname vielleicht schon als ‚Gute Wahl‘ ins Gedächtnis gebrannt hat. Aber letztendlich ist die Registrierung einer alternativen Domain nicht wirklich von Nachteil. Schließlich kommt es beim Erfolg einer Webseite am Ende auf sehr viel mehr an, als *nur* auf den optimalen Domainnamen. Und man kann sich rühmen, die Domain-Grabber nicht gefüttert zu haben. Schließlich funktioniert dieses etwas fragwürdige Business nur dann, wenn immer wieder genug Leute bereit sind, für deren Dienste zu bezahlen.

Update: In einem aktuellen Fall hat sich die Geduld bezahlt gemacht. Ich habe einfach stillgehalten, nicht auf die Emails reagiert, keinen Link angeklickt. Stattdessen habe ich regelmäßig nachgesehen, ob die Domain frei ist – und schließlich war sie frei und ich konnte sie ohne zusätzliche Kosten und ohne Zwischenhändler registrieren.

WordPress WooCommerce Shop Titel „Produkte Archiv“ ändern

WooCommerce: Seitentitel "Produkte Archiv" anpassen - Foto: T.Bortels/cpu20.de

4 Antworten

WordPress mag vielen vor allem als Blog Tool bekannt sein. Mit WordPress lassen sich inzwischen aber auch ganz andere Sachen bauen – zum Beispiel lassen sich mithilfe des kostenlosen WordPress Plugins WooCommerce Online Shops erstellen. Die Kombination aus WordPress und WooCommerce steckt mittlerweile sogar sogar hinter ca. einem Drittel aller Online Shops. Das WooCommerce Plugin ist zunächst einmal kostenlos – und lässt sich relativ einfach installieren. Wenn es dann an Detailfragen geht, kann es schnell etwas kompliziert werden. Wir picken uns mal ein Detail heraus: den Seitentitel der Shop Seite.

Bei einem neu eingerichteten WooCommerce-Shop wird als Seitentitel der ‚Startseite‘ des Shops häufig zunächst der Standardtitel „Produkte Archiv“ angezeigt. Das fällt dem ambitionierten Webshop-Betreiber vielleicht erstmal gar nicht weiter auf – immerhin lässt sich der Titel der Seite, der auf der Seite angezeigt wird, direkt anpassen. Der Seitentitel, der später in den Suchergebnissen zum Beispiel bei Google oder DuckDuckGo zu sehen ist, wird häufig erstmal übersehen. Vielleicht wissen auch viele Shop Betreiber gar nicht, dass sie den Seitentitel relativ einfach ändern können – und das der Seitentitel ein ganz wichtiges Detail sein kann, das über Erfolg oder Misserfolg eines Online Shops entscheiden kann? Langfristig ist der generische Seitentitel „Produkte Archiv“ jedenfalls keine gute Wahl. Vermutlich gibt es hunderte oder sogar tausende Standard WooCommerce Installationen mit genau demselben Titel, der absolut nichts über den Shop aussagt. Das hat einerseits einen negativen Einfluss auf das SEO-Ranking – und andererseits hilft es potentiellen Kunden nicht, wenn sie die Seite in den Suchergebnissen sehen. Wer den Seitentitel nicht anpasst, verschenkt SEO-Potential.

WooCommerce Shop Titel „Produkte Archiv“ mit Yoast ändern

Grundsätzlich sollte sich jeder Shop-Betreiber früher oder später Gedanken über Suchmaschinenoptimierung machen. Wer seinen Shop in der Kombination WordPress+WooCommerce betreibt ist mit dem SEO-Plugin Yoast auf jeden Fall schon mal ganz gut beraten. Und mithilfe von Yoast lässt sich der Seitentitel eines WooCommerce Shops zum Glück auch relativ einfach so anpassen, dass er zum Shop bzw. zu den angebotenen Produkten passt. Gut für die Kunden, gut für SEO, gut für den Shop.

WordPress WooCommerce Shop Titel Produkte Archiv mit Yoast aendern

Screenshot: Shop Titel „Produkte Archiv“ mit Yoast aendern

Um den Seitentitel nun zu bearbeiten geht man wie folgt vor:

Zunächst in der Menuleiste (links) über den Link „SEO > Titel & Metas“ die Seite mit den Voreinstellungen für Seitentitel und Meta-Tags aufrufen.
Dann wählt man oben den Seitenreiter „Artikeltypen“ aus. Ganz unten sollte dann der Bereich „Archive von Artikeltypen“ zu sehen sein.
Hier kann man dann den gewünschten Shop-Titel direkt in das Feld „Titel“ eintragen. Und fertig ist die Laube.

Update: Manche WP-Themes scheinen sich dem oben aufgeführten Trick zu widersetzen. Beim WP-Theme Explore zum lässt sich zum Beispiel zwar der Seitentitel anpassen, oben in der Browserleiste zu sehen ist – die Überschrift der Shop-Seite bleibt aber hartnäckig bei dem Begriff „Archiv„. Aber auch dieses Detail lässt sich mit einem Griff in die Plugin-Trickkiste anpassen: mit dem kostenlosen Übersetzungs-Plugin „Loco Translate“ lassen sich im Prinizip alle vom Theme verwendeten Begriffe übersetzen – und vorhandene Übersetzungen ändern. Und so kann man dann auch der Shop-Seite einen eigenen Titel bzw. eine eigene Überschrift geben, die zum Shop und zu den angebotenen Produkten passt.

siehe auch:

WordPress Übersetzungen ändern, einzelne Begriffe anpassen – ohne Plugin

WordPress als CMS: Seiten-Management (CPT)

WordPress CMS - Seiten Management Plugins - Photo/Montage: T.Bortels/cpu20.de

3 Antworten

Es ist durchaus möglich und sinnvoll, WordPress als CMS zu betreiben. Früher oder später muß man allerdings feststellen, dass WordPress ursprünglich leider nicht wirklich dafür vorgesehen war, als Content Management System betrieben zu werden. Ein Problem bei der Sache können die statisches Seiten (Pages) sein – insbesondere, wenn man es mit vielen in ineinander verschachtelten Seiten zu tun hat. Manchmal muss man hunderte oder sogar tausende Seiten verwalten – häufig über Parent-Child-Verknüpfungen zu ganzen Seiten-Bäumen verknüpft. Für viele Webseiten macht es zudem Sinn, neben den Standard-Seiten noch eigene Seitentypen einzurichten, die sogenannten Custom Post Types (CPT). Dann wird die Sache noch interessanter.

WordPress CMS Härtetest: über 1000 CPT Seiten verwalten

Wenn man WordPress als CMS betreiben will hat man es wie gesagt häufig mit statischen Seiten zu tun. Oft spielt die Blog-Funktion dann eher eine Nebenrolle und die Pages spielen stattdessen die Hauptrolle. Je mehr Seiten oder sogar Seitenbäume man anlegt, desto schwieriger wird die Verwaltung. Das Seiten-Management läßt in vielen Punkten zu wünschen übrig.

Spätestens, wenn man es mit hunderten oder sogar tausenden Seiten zu tun hat, stößt man mit den Default-Funktionalitäten an seine Grenzen – die Bedienung wird einfach unhandlich. Kommen dann noch Hierarchien dazu, also verschachtelte Seiten, Hauptseiten und Unterseiten (Parent-Pages / Child-Pages) dann ist das Chaos buchstäblich vorprogrammiert.

In den letzten Jahren haben sich verschiedene WordPress-Entwickler dieses Themas angenommen und eine Reihe von Plugins entwickelt, die beim Seiten-Management helfen sollen. Einige machen ihren Job ganz gut, andere leider nicht. Ich habe mir 5 der besten bzw. beliebtesten und offenbar bekanntesten Plugin einmal näher angesehen, getestet und habe eine für meine Bedürfnisse passende Kombination gefunden. Hier der Überblick:

Plugin #1: Admin Collapse Subpages

Das Plugin Admin Collapse Subpages bringt mir leider keinen Mehrwert. Das Plugin fügt lediglich der Standard-Seitenansicht die Option „collapse“ hinzu, mit der sich verschachtelte Seiten etwas übersichtlicher darstellen lassen. Allerdings werden immer nur die Seiten eingeklappt, die in der gerade aktuellen Listenanischt aufgeführt werden.

Plugin #2: Advanced Page Manager

Das Plugin Advanced Page Manager sieht erstmal sehr vielversprechend aus. Allerdings stellt sich schnell heraus, dass das Plugin zurzeit leider keine eigenen Seitentypen (CPT) unterstützt. Daher kommt das Plugin zurzeit für mich nicht in Frage. Ansonsten scheint es aber recht komfortabel zu sein. Wenn man also ausschliesslich mit Ur-Seiten zu tun hat, kann man sich den Arbeitsalltag mithilfe des Advanced Page Manager vermutlich etwas leichter machen.

Plugin #3: Swifty Page Manager

Auf den ersten Blick macht der Swifty Page Manager einen sehr guten Eindruck. Die Organisation von Seiten erscheint übersichtlich. Hierarchisch geordnete Seiten/ Unterseiten lassen sich einfach ausklappen, neue Unterseiten lassen sich direkt erstellen. Und auch das Page-Template läßt sich direkt beim Erstellen wählen.

Für meine Anwendung ist das Plugin aber leider zurzeit nicht geeignet Es lassen sich im Moment offenbar nur für Standard-Seiten organisieren – eigene Seitentypen (CPT) lassen sich über Swifty Page Manager weder verwalten, noch bearbeiten. Und dies scheint erstmal auch nicht vorgesehen zu sein. Laut Entwicklern bestehen keine Pläne, Custom Post Types zu berücksichtigen „there are no plans for adding custom post types at this point“.

Ein schwacher Trost und Grund zu Hoffnung: das Plugin wird unter Open Source Lizenz vertrieben – es steht also theretisch jedem Entwickler offen, fehlende Funktionalitäten selbst einzubauen.

Plugin #4: CMS Tree Page View

Mithilfe des Plugins CMS Tree Page View lassen sich auch komplexe Seiten-Bäume abbilden.

Auch bei über tausend Seiten lädt die Übersicht schnell – die Unterseiten werden offenbar über eine entsprechende AJAX-Anfrage immer erst dann geladen, wenn die übergeordnete Seite „ausgeklappt“ wird.

Die Seiten-Übersicht erscheint insgesamt sehr reduziert und erinnert vielleicht ein wenig an Anwendungen aus den Neunzigern, wie zum Beispiel „Windows Explorer“ mit dem man relativ einfach die Baustruktur von Verzeichnissen auf einem PC überblicken und organisieren konnte.

Das Plugin unterstützt Custom Post Types – ein Punkt, der mir sehr wichtig war.

Die Sortierung von Seiten und Unterseiten per Drah’n’Drop kann ein bischen schwierig sein. Will man eine Seite verschieben, werden unter Umständen andere Seiten in der Nähe der „Abwurfstelle“ aufgeklappt. Gegebebenenfalls muss ein ein bisschen vorsichtig sein und nachträglich kontrollieren, wohin man die betroffene Seite nun wirklich gerade verschoben hat.

Plugin #5: Nested Pages

Die Benutzeroberfläche von Nested Pages ist vorbildlich übersichtlich. Und mit dem Plugin lassen sich auch CPT-Seiten verwalten. Das sind zwei Pluspunkte, die mich zunächst dieses Plugin nutzen ließen.

Ausserdem zeigt Nested Pages das SEO-Ranking des Plugins Yoast direkt in der Übersicht an – ein Feature, das ich gerne nutzen würde.

Allerdings hat Nested Pages einen entscheidenden Nachteil: die Seiten-Übersicht wird von vornherein komplett geladen, es werden aber nur die Parent-Seiten angezeigt. Bei über 1000 Seiten kann die Seiten-Übersicht daher entsprechend langsam laden. Ein Verschieben per Drag’n’Drop ist zwar auch dann noch möglich, aber sehr zäh.

WordPress als CMS – Seiten-Management Plugins Zusammenfassung

Wenn Nested Pages die Unterseiten über AJAX laden würde, wäre es für mich vermutlich das perfekte Plugin zum Verwalten von komplexen Seiten-Bäumen. In der aktuellen Version wird es mit zunehmender Seitenzahl aber leider immer unbrauchbarer.

Zur Verwaltung meines CPT-Seitenbaums verwende ich nun das Plugin CMS Tree Page View. Beide Plugins lassen sich offenbar aber auch parallel betreiben. Also werde ich erstmal auch Nested Pages noch weiter nutzen, um mir hin und wieder einen Überblick über den SEO-Status der Seiten machen zu können.

Abschliessend noch ein Hinweis: alle Plugins ließen sich beliebig aktivieren und deaktivieren. Im Zweifelsfalls kann man also die hier aufgeführten Plugins einfach mal selbst ausprobieren.