WordPress-Entwicklung

Am Anfang steht die Frage, welche Inhaltstypen ein Projekt wirklich braucht. Seiten und Beiträge decken selten alles ab, was ein Unternehmen veröffentlicht. Wir legen deshalb zuerst Custom Post Types und eigene Felder an: Referenzen, Standorte, Stellenangebote, Ansprechpartner, Produktdaten. Dazu kommen Taxonomien, über die sich Inhalte filtern und an mehreren Stellen automatisch ausspielen lassen. Erst wenn dieses Modell steht, entsteht das Theme.

Themes bauen wir selbst, statt eine gekaufte Vorlage umzufärben. Das Markup folgt dem Design und nicht dem Funktionsumfang eines fremden Page Builders. Für die Redaktion richten wir den Block-Editor gezielt ein: eigene Blöcke für wiederkehrende Elemente, Block-Patterns für ganze Abschnitte, gesperrte Bereiche dort, wo das Layout nicht verrutschen darf. Wer Inhalte pflegt, sieht nur die Bausteine, die zum Design gehören.

Funktionen, die der Standard nicht abdeckt, landen in einem eigenen Plugin und nicht in der functions.php des Themes. So bleibt die Logik erhalten, wenn das Design später ausgetauscht wird. Mehrsprachigkeit, Formulare, Caching und die Suchmaschinen-Grundlagen ergänzen wir mit etablierten Erweiterungen, bewusst sparsam, weil jedes zusätzliche Plugin dauerhaft mitgepflegt werden muss.

WordPress lohnt sich, wenn Inhalte regelmäßig und von mehreren Personen gepflegt werden und niemand für eine Textänderung die Agentur anrufen soll. Rollen und Rechte, Vorschau, Revisionen und ein Backend, das man ohne Schulungswoche versteht, sind ab Werk vorhanden. Ebenso passt es, wenn Sie unabhängig bleiben wollen: Der Code liegt bei Ihnen, das System ist quelloffen, Hoster und Dienstleister sind austauschbar.

Weniger sinnvoll ist WordPress, wenn ein Projekt im Kern kein Inhaltsproblem löst, sondern ein Prozessproblem. Konfiguratoren mit komplexer Rechenlogik, Portale mit vielen Benutzerrollen und Berechtigungsstufen oder Anwendungen mit Echtzeitdaten lassen sich zwar hineinbauen, arbeiten dann aber gegen die Architektur des Systems. In solchen Fällen ist eine eigenständige Anwendung die ruhigere Lösung, bei Bedarf mit WordPress als reiner Inhaltsquelle über die REST-API.

Typische Anlässe für ein Projekt sind ein Relaunch, der Wechsel von einem in die Jahre gekommenen System, ein zusätzlicher Shop auf Basis von WooCommerce oder eine Installation, die über Jahre gewachsen ist und die niemand mehr zuverlässig aktualisieren kann. Auch der Zusammenschluss mehrerer Einzelseiten in eine gemeinsame Installation kommt regelmäßig vor.

Die meisten kaputten WordPress-Installationen wurden nicht angegriffen, sie wurden jahrelang nicht aktualisiert. Kern, Themes und Plugins hängen voneinander ab, und je länger Updates liegen bleiben, desto größer wird der Sprung und desto wahrscheinlicher der Konflikt. Wir richten deshalb eine Staging-Umgebung ein, in der Aktualisierungen zuerst laufen und geprüft werden, bevor sie auf die Live-Seite gehen.

Backups gehören nicht auf denselben Server wie die Website. Datenbank und Upload-Verzeichnis werden getrennt gesichert, und eine Sicherung, die noch nie zurückgespielt wurde, ist keine. Der Rückweg muss einmal geprobt worden sein. Dasselbe gilt für die PHP-Version: Sie folgt dem, was der Kern und die eingesetzten Erweiterungen unterstützen, und wird nicht dem Hoster überlassen.

Zwei Entscheidungen fallen früh und wirken lange nach. Erstens: wie viele Plugins die Installation dauerhaft tragen soll. Zweitens: wie stark Inhalte an ein einzelnes Plugin gebunden werden. Wer Texte und Layouts in den proprietären Datenstrukturen eines Page Builders ablegt, kann das Theme später nicht ohne Datenmigration wechseln. Wir speichern Inhalte deshalb so weit wie möglich in Kernstrukturen: Blöcke, Taxonomien, Metafelder.