WordPress als CMS: Auf dem Weg zum Web-Baukasten

WordPress ist derzeit mit einem Anteil von über 50 Prozent das marktbeherrschende CMS für Webseiten. Das im Jahr 2003 als Blog-Software gestartete Open-Source-Projekt ist inzwischen zu einem flexiblen und erweiterbaren Content-Management-System gereift und soll sich künftig zu einem echten Website-Builder weiterentwickeln. Nicht nur Millionen von Blogs werden mit WordPress betrieben, sondern auch unzählige Corporate Websites und viele ausgereifte Publishing-Projekte etablierter Verlage. Allerdings befindet sich WordPress derzeit in einem grundlegenden Transformations-Prozess und steht damit möglicherweise an einem Scheideweg.

Screenshot der WordPress Startseite

Die initiale Version von WordPress ist von seinem Gründer Matt Mullenweg im Mai 2003 veröffentlicht worden. Im Jahr 2005 gründete Mullenweg das Unternehmen Automattic und launchte mit WordPress.com ein SaaS-Angebot auf Basis der Open-Source-Software. In den folgenden Jahren hat sich WordPress zu der dominierenden Blog-Software entwickelt und konnte auch von späteren Alternativen wie Habari, Anchor oder Ghost nicht mehr vom Thron gestoßen werden.

WordPress: Die Flexibilität und ihr Preis

Ein Geheimnis des Erfolges von WordPress: Im Gegensatz zu vielen anderen Open Source Projekten hat sich WordPress nicht so sehr an den Bedürfnissen der Entwickler orientiert, sondern vielmehr die Perspektive der Anwender übernommen. Durch die hohe Popularität bei den Anwendern hat sich ein großer Markt für Plugins und Themes etabliert, der wiederum Chancen für Entwickler bietet. Inzwischen ist dieser Markt auf knapp 60.000 Plugins und über 8.000 Themes angewachsen, was WordPress seinen legendären Ruf des flexiblen Alles-Könners verschafft hat. Kaum ein anderes System lässt sich ohne Code-Kenntnisse so weitreichend anpassen.

WordPress hat jedoch auch mit zahlreichen Schwächen zu kämpfen. Die Qualität des Codes wird häufig kritisiert. Immer wieder werden große Sicherheitslücken entdeckt. Und die eher chaotisch gewachsene Komplexität machen WordPress teilweise inkonsistent und recht träge.

Als größte Hürde stellte sich für WordPress jedoch das unflexible Content-Modell heraus. Im Zentrum stand bei WordPress viele Jahre lang ein einfacher HTML-Editor, mit dem die Inhalte von Pages und Posts erstellt wurden. Eine flexible Content-Modellierung über einen Formular-Manager, wie ihn viele andere Systeme kennen, gibt es bei WordPress in der Form nicht. Dadurch mussten alle zusätzlichen oder abweichenden Inhalte mit Widgets, Plugins und ähnlichen Erweiterungen oder Zusatz-Konstrukten realisiert werden, was ganz wesentlich zu dem ausufernden Plugin-Markt geführt hat.

Für die Weiterentwicklung von WordPress stellte diese Unflexibilität des Core-Systems durchaus ein Problem dar. Denn wohin die Reise bei der Weiterentwicklung gehen sollte, zeichneten populäre Page-Builder wie Elementor oder GeneratePress bereits früh vor: Weg vom ursprünglichen Blog-System und hin zu einem selbstgehosteten Baukastensystem für Webseiten. Für diese Entwicklung ist jedoch ein flexiblerer Umgang mit Inhalten zwingend notwendig. Als Lösung präsentierte WordPress im Jahr 2018 den neuen Block-Editor Gutenberg. Mit dem Block-Editor ist die erforderliche Flexibilität nun in das Core-System von WordPress gewandert. Allerdings erhöht der neue Editor auch die Anforderungen an die Entwickler und greift tief in die Arbeitsgewohnheiten von Autoren ein.

Gutenberg: WordPress und der Block-Editor

Der Block-Editor "Gutenberg" ist im Dezember 2018 mit der Version 5 von WordPress als Standard-Editor integriert worden. Er löste den klassischen HTML-Editor (TinyMCE) ab, der seitdem als Plugin weiter zur Verfügung steht. Der Gutenberg-Editor folgt der bekannten Idee, dass eine Seite aus einer Vielzahl flexibler Content-Blöcke besteht. In der Handhabung ähnelt er modernen Editor-Tools, wie man sie von Squarespace, Slack oder auch anderen Content Management Systemen kennt. Unter WordPress.org findet man eine Online-Demo, die einen ersten Eindruck vermittelt.

Screenshot WordPress Gutenberg Editor

In den folgenden Versionen von WordPress sind viele Kinderkrankheiten überwunden worden, sodass der Gutenberg-Editor heute für Autoren recht gut bedienbar ist. Größere Neuheiten waren beispielsweise eine Pattern-Library, mit der Mustervorlagen für den Block-Editor übertragen werden konnten. Auch neue Block-Elemente wie Cover, Buttons und Spalten haben viel zur Flexibilisierung beigetragen.

Einen recht großen Schritt hat WordPress mit der Version 5.8 eingeleitet, die am 20. Juli 2021 mit dem Namen "Tatum" erschienen ist. Mit Tatum wurden unter anderem Query-Blocks eingeführt, mit denen sich beispielsweise eine Liste von Posts in eine Seite integrieren lassen. Weitere Neuheiten sind ein Template-Editor, automatische Pattern Vorschläge und vor allem ein Block Widget Editor, mit dem sich Blocks in Widget-Areas und auch im Customizer einfügen lassen. Version 5.8 ist ein großer Schritt hin zum Full-Site-Editing (FSE), mit dem WordPress seine Entwicklung hin zum Webbaukasten realisieren will.

Auf dem Weg zum Full-Site-Editing (FSE)

Derzeit wirkt der Gutenberg-Editor noch wie ein moderner Femdkörper in einer ansonsten gleichgebliebenen Administrations-Oberfläche. Diese Oberfläche hält unter anderem Bereiche für die Plugin-Verwaltung, die Medien-Verwaltung, die Nutzer-Verwaltung und die Design-Anpassung bereit.

Screenshot des WordPress Dashboards

Den unvermittelten Bruch in der Nutzeroberfläche beim Gutenberg-Editor kennt man bei WordPress bereits über den "Customizer", den man unter dem Menüpunkt "Appearance" findet. Mit dem Customizer wechselt man in eine Frontend-Ansicht, die auf der linken Seite zahlreiche Optionen zur Anpassung der Webseite bereithält. Auch dieser Customizer wirkte immer schon wie ein Fremdkörper und wie ein Versuch, Funktionen eines Website-Builders in WordPress zu integrieren.

Screenshot WordPress Customizer

Mit dem geplanten Full-Site-Editing soll sich in Zukunft alles ändern. Denn mit FSE werden Autoren die neue Gutenberg-Oberfläche auch für alle Inhalte nutzen können, die nicht unmittelbar zu einem Post oder einer Page gehören. Dazu zählen zum Beispiel der Footer, der Header oder auch andere Elemente wie Sidebars. Mit dem Full-Site-Editor wird der Customizer abgelöst, ebenso wie zahlreiche Features, die derzeit noch unter den Widgets und Plugins zu finden sind. Damit soll WordPress dann endlich eine einheitliche Benutzeroberfläche ohne große Brüche erhalten.

Screenshot Full-Site-Editor

Einen recht guten Einblick in die Pläne bietet der Video-Vortrag zum Full-Site-Editing von Anne McCarthy, einer Entwicklerin bei Automattic. Empfehlenswert ist außerdem die Einführung zum Gutenberg-Editor von Jan Tißler im Upload-Magazin.

Der Weg, den WordPress mit Gutenberg und dem Full-Site-Editing einschlägt, ist für WordPress-Nutzer ausgesprochen einschneidend und revolutionär. Tatsächlich sind solche Oberflächen in der CMS-Welt jedoch nicht neu. Im Enterprise-Bereich fühlt man sich vor allem an den Marktführer Adobe AEM erinnert. AEM hat schon immer auf flexible Blöcke ("Komponenten") gesetzt und bereits vor vielen Jahren eine Oberfläche geschaffen, mit der Autoren eine Webseite aus Komponenten prinzipiell beliebig zusammenbauen können. Es ist vielleicht kein Zufall, dass sich WordPress als Marktführer für kleinere Webseiten dem Marktführer im Enterprise-Bereich annähert. Die Transformation von WordPress ist dabei für bestehende Nutzer allerdings so radikal, dass es in Zukunft sicherlich noch mehr Raum für WordPress-Alternativen geben wird.

WordPress für Entwickler

WordPress startete als PHP-System mit einem prozeduralen Code-Stil, ist mit der Zeit jedoch in weiten Teilen auf den objektorientierten Stil umgestiegen. Die etwas chaotische Code-Basis hat dem CMS in der Vergangenheit viel Kritik eingebracht, allerdings auch die Einstiegshürden für Anfänger niedrig gehalten. Mit der Einführung des Gutenberg-Editors auf Basis von React.js haben sich die Anforderungen an Entwickler allerdings deutlich erhöht.

WordPress ist dank der berühmten 5-Minuten-Installation schnell und einfach lauffähig. Man muss lediglich den WordPress-Ordner herunterladen, eine Datenbank erstellen (MySQL oder MariaDB), dann die WordPress-Datei wp-config-sample.php in wp-config.php umbenennen und die Datenbank-Zugänge in die wp-config.php eintragen. Zum Schluss besucht man seine-domain.com und füllt die Formulare für die Installations-Routine aus. Viele Webhoster bieten bei ihren Paketen bereits eine Installation per Knopfdruck an, sodass man sich selbst diese Routine sparen kann.

Vorsicht ist allerdings bei einer Migration von WordPress geboten, zum Beispiel von der lokalen Umgebung in die Live-Umgebung. Denn WordPress speichert zahlreiche Referenzen des Domain-Namens in der Datenbank, was sicherlich zu den unschöneren Details des Systems gehört. In solchen Fällen hilft eine Anleitung für Migrationen.

Bei der Erstellung von Themes kommt gewöhnliches PHP und HTML zum Einsatz, eine eigene Template-Sprache wie beispielsweise Twig wird nicht verwendet. Auch bei den Themes ist der Code-Stil wieder überwiegend prozedural. Der typische WordPress-Loop sieht wie folgt aus:

<?php if ( have_posts() ) : ?>
    <div class="hfeed">
        <?php while ( have_posts() ) : the_post(); ?>
            <article id="post-<?php the_ID() ?>" class="<?php post_class() ?>">
               <h3><?php the_title(); ?></h3>
            </article>
        <?php endwhile; ?>
    </div>
<?php endif; ?>

Es gibt einen endlosen Katalog an Template-Tags und Funktionen, die ein Entwickler bei der Erstellung eines Themes nutzen kann. Die Überschneidungen können dabei durchaus verwirrend sein, so gibt es eine Funktion für die Ausspielung von Tags:

$tags = get_tags();
foreach ( $tags as $tag ) {
    $tag_link = get_tag_link( $tag->term_id );
    $html = "<a href='{$tag_link}' title='{$tag->name} Tag' class='{$tag->slug}'>{$tag->name}</a>";
}

Und auch ein Template-Tag, das eine fertige HTML-Liste mit Schlagwörtern ausspucken:

<?php the_tags( '<ul><li>', '</li><li>', '</li></ul>' ); ?>

Plugins werden bei WordPress wie in fast allen Content Management Systemen über ein Event-System realisiert, allerdings ist auch das Event-System von WordPress prozedural aufgebaut. Es läuft bei WordPress unter dem Begriff Hooks, wobei zwischen "Action-Hooks" und "Filter-Hooks" unterschieden wird. Die Arbeit mit einem Event-System im prozeduralen Stil sieht zum Beispiel so aus:

function email_friends($post_ID) {
    $friends = 'bob@example.org,susie@example.org';
    mail($friends, "sally's blog updated", 
      'I just put something on my blog: http://blog.example.com');
    return $post_ID;
}
add_action( 'publish_post', 'email_friends' );

Mit der Funktion add_action wird das Plugin im Event-System registriert, als erstes Argument wird der Event-Name (bzw. Hook-Name) angegeben, anschließend folgt der Name der Plugin-Funktion.

Mit der Einführung von Gutenberg wurde das bekannte Plugin-System um Gutenberg- bzw. Block-Plugins erweitert. Bei der Erstellung eines neuen Block-Plugins beginnt der Entwickler wie gewohnt mit einem PHP-Plugin:

<?php
/*
Plugin Name: Gutenberg examples 01
*/
function gutenberg_examples_01_register_block() {
    // automatically load dependencies and version
    $asset_file = include( plugin_dir_path( __FILE__ ) . 'build/index.asset.php');
    wp_register_script(
        'gutenberg-examples-01-esnext',
        plugins_url( 'build/index.js', __FILE__ ),
        $asset_file['dependencies'],
        $asset_file['version']
    );
    register_block_type( 'gutenberg-examples/example-01-basic-esnext', array(
        'api_version' => 2,
        'editor_script' => 'gutenberg-examples-01-esnext',
    ) );
}
add_action( 'init', 'gutenberg_examples_01_register_block' );

Das eigentliche Gutenberg-Plugin wird dann in JavaScript erstellt. WordPress hat sich dabei bemüht, den Stil der üblichen WordPress-Plugins auf React zu übertragen. Dennoch wird man nicht darum herumkommen, sich mit der Funktionsweise von React wie Methoden oder Props auseinanderzusetzen. Ein Grundgerüst für ein Plugin kann zum Beispiel so aussehen:

import { registerBlockType } from '@wordpress/blocks';
import { useBlockProps } from '@wordpress/block-editor';
const blockStyle = {
    backgroundColor: '#900',
    color: '#fff',
    padding: '20px',
};
registerBlockType( 'gutenberg-examples/example-01-basic-esnext', {
    apiVersion: 2,
    title: 'Example: Basic (esnext)',
    icon: 'universal-access-alt',
    category: 'design',
    example: {},
    edit() {
        const blockProps = useBlockProps( { style: blockStyle } );
        return (
            <div { ...blockProps }>Hello World, step 1 (from the editor).</div>
        );
    },
    save() {
        const blockProps = useBlockProps.save( { style: blockStyle } );
        return (
            <div { ...blockProps }>
                Hello World, step 1 (from the frontend).
            </div>
        );
    },
} );

Ein Einstieg in die Gutenberg-Entwicklung sprengt hier den Rahmen. Ein guter Startpunkt ist jedoch das Gutenberg-Handbuch, das künftig wohl jeder WordPress-Entwickler kennen sollte.

Alternativen zu WordPress

Mit Gutenberg und dem Full-Site-Editing durchläuft WordPress einen tiefgreifenden Wandel, der nicht unumstritten ist. Die Probleme, die eine solche Arbeitsweise bei Autoren hervorruft, sind hinlänglich von Web-Baukästen und anderen Content Management Systemen bekannt. Die enorme Flexibilität bedeutet in vielen Situationen leider auch ein Verlust an Effektivität. Gerade Autoren, die geringe Ansprüche an die Gestaltungsfreiheit stellen und dafür möglichst schnell und effektiv Inhalte publizieren wollen, haben bei dem Projekt Gutenberg eher das Nachsehen.

Dementsprechend ist bei etwa fünf Millionen WordPress-Seiten der klassische Editor im Einsatz, der allerdings nur noch als Editor-Plugin zur Verfügung steht. Das Plugin wird jedoch möglicherweise schon ab dem Jahr 2022 nicht mehr weiter unterstützt. Man kann annehmen, dass in naher Zukunft zahlreiche Anwender auf die Suche nach Alternativen gehen werden. Und andere Lösungen gibt es durchaus, wie unser Gastartikel zu WordPress-Alternativen im Upload-Magazin zeigt.

Für Anwender gilt dabei: Es gibt kein anderes CMS, das eine derart hohe Flexibilität ohne Code-Kenntnisse ermöglicht. Allerdings gibt es einige Systeme, die einfachere Anforderungen bedienen. Und diese Einfachheit dürfte für die meisten Wechselwilligen den Ausschlag geben. Im Bereich der Flat-File-CMS sind Bludit, Grav und gegebenenfalls auch HTMLy einen Versuch wert. Eine hervorragende Alternative für Journalisten und Publisher ist das Node-System Ghost mit seinen eingebauten Features für Communities und Subscriptions. Auch Publii ist ein interessanter Kandidat für Anwender, die die Vorteile einer statischen Auslieferung von Webseiten für sich nutzen möchten.

Auf Seiten der Entwickler und Dienstleister dürften Alternativen zu WordPress ebenfalls Auftrieb bekommen. Denn WordPress war bislang vor allem aufgrund des riesigen Plugin- und Theme-Marktes interessant. Dieser Markt wird durch die Webbaukasten-Strategie von WordPress in Zukunft jedoch eher schrumpfen. Gleichzeitig hat der Entwicklungsprozess von WordPress vor allem die erfahrenen Entwickler wohl noch nie sonderlich begeistert, wenn man sich die entwicklerfreundlichen Ansätze moderner Systeme anschaut.

Für Entwickler und Dienstleister gibt es auch heute schon ein riesiges Angebot an Alternativen. Die Entwickler-Szene greift für Webseiten zu Tech-Themen bereits seit Jahren lieber zu den Static Site Generatoren und lässt WordPress bzw. andere Content Management Systeme generell weg. Auch der Trend hin zu einfachen Headless-Systemen ist ungebrochen und für Entwickler ausgesprochen attraktiv. Unter den PHP-Systemen haben vor allem moderne CMS wie Craft Karriere gemacht. Mit dem Relaunch des Spiegels hat auch das Flat-File-CMS Statamic eine breitere Aufmerksamkeit gefunden. Genauso hat das Flat-File-CMS Kirby eine rasante und sehr positive Entwicklung durchgemacht. All diese modernen Systeme nutzen im Kern einen Formular-Manager für die Content-Modellierung und kennen somit die Probleme von WordPress nicht. Allerdings richten sich all diese Systeme hauptsächlich an Entwickler und Dienstleister.

Wenn es um einen Einsatz im komplexeren Unternehmens-Umfeld geht, dann zählen zum Beispiel Drupal oder TYPO3 zu den klassischen Alternativen. Unter den jüngeren Systemen kommen zum Beispiel Neos oder Sulu in Frage. Bei der Umstellung auf ein neues CMS ist jedoch auch ein Wechsel auf eine andere Architektur oder ein Upgrade auf ein komplexes Enterprise-CMS denkbar. All das hängt vom konkreten Einsatz-Szenario im Unternehmen ab. CMSstash kann einen ersten Markt-Überblick liefern. Für einen erfolgreichen Auswahl-Prozess ist jedoch eine individuelle Analyse nötig. Wer dabei auf eine externe Unterstützung zurückgreifen will, der kann sich an unseren Kooperationspartner SUTSCHE wenden. SUTSCHE gehört zu den wenigen Dienstleistern, die nicht implementieren und so die CMS-Auswahl unabhängig im Interesse des Kunden begleiten können.

Kosten

WordPress ist Open-Source und komplett kostenfrei. Zusätzlich gibt es natürlich einen riesigen Markt für Plugins, Themes und Dienstleistungen. Viele davon sind ebenfalls kostenlos, andere sind kostenpflichtig, wieder andere folgen dem Freemium-Modell: Man bekommt die Basis-Version kostenlos und zahlt dann für fortgeschrittene Funktionen.

Empfehlung: Wann macht WordPress Sinn?

In der Praxis wird mit WordPress nahezu alles gebaut: Vom simplen One-Pager über Shops bis hin zu kompletten Magazin-Projekten von etablierten Verlagen. Die marktbeherrschende Stellung, die enorme Flexibiltät und das breite Dienstleister-Angebot sind überzeugende Argumente. Hinzu kommt, dass sich viele Anwender und sogar Entwickler kaum mit Alternativen beschäftigen und schon aus Gewohnheit auf WordPress zurückgreifen.

Sinnvoll ist der Einsatz von WordPress bei dynamischen Publishing-Projekten wie Blogs und Magazinen, in vielen Fällen auch bei mittelkomplexen Business-Auftritten. Außerdem bietet WordPress genug Flexibilität, um auf einem vergleichsweise niedrigen Level verschiedene Konzepte auszuprobieren und nach Marktlücken zu suchen. Man kann mit einem Blog starten, im Erfolgsfall (mit viel Arbeit) einen Shop hinzufügen oder es mit einer Community versuchen. Hat man ein tragfähiges Konzept gefunden, kann man immer noch einen Technologie-Wechsel in Erwägung ziehen. Wer allerdings schon ein klares und funktionierendes Konzept hat und sich ohnehin auf Entwicklungs-Kosten einstellt, der dürfte in vielen Fällen mit anderen Systemen besser fahren.

© by Sebastian Schürmanns, 2017 - 2021. All Rights Reserved. Built with Typemill.