UnleashWP – Band 1 E-Book

Benjamin Zekavica

• Herausgeber: Kreo Pulse
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch

Veröffentlichungsjahr: 2025

Beschreibung

Viele WordPress-Projekte verlieren genau dort an Fahrt, wo es am meisten zählt: im Alltag. Stundenlange Deployments, chaotische Umgebungen, fehlende Standards – Fehler häufen sich, Budgets laufen aus dem Ruder, und irgendwann fehlt die Motivation, weiterzumachen. Genau an diesem Punkt stand auch ich.

Über 16 Jahre habe ich als Entwickler Projekte in Agenturen und Unternehmen begleitet – und direkt im WordPress-Core-Team mit den besten Köpfen der Community gearbeitet. Dort habe ich gesehen, welche Fehler Teams immer wieder ausbremsen – und welche Methoden Projekte stabil machen.

UnleashWP – Band 1 ist die Essenz dieser Erfahrungen. Kein Grundlagenbuch, kein endloser Theorieteil, sondern ein Werkzeugkasten für Profis: erprobte Workflows, Automatisierungen und Entwicklungsumgebungen, die dir Struktur, Sicherheit und Geschwindigkeit geben.

Das erwartet dich in Band 1:

• Workflows, die Ordnung und Klarheit schaffen
• Automatisierungen, die Zeit sparen und Fehler vermeiden
• Entwicklungsumgebungen: lokal, Container, Cloud
• Git, CI/CD und reibungslose Deployments
• Releases, die sicher ablaufen – vom kleinen Update bis zum großen Rollout
• Testing-Strategien, die Vertrauen in deinen Code bringen
• Lösungen für Theme- und Plugin-Updates, ohne Projekte zu gefährden
• Strategien für den Verkauf und die Pflege eigener Themes & Plugins
• Enterprise-Ansätze für große Plattformen und Teams

Und mehr noch: Jeder Leser erhält zusätzlich ein exklusives Geschenk zum Download – ein Extra, das das Buch über seine Seiten hinaus erweitert.

UnleashWP – Band 1 richtet sich an Entwickler, Freelancer und Teamleiter, die genug von halben Lösungen haben. Es ist nicht der einzige Weg – aber es ist der Weg, der mich nach vorne gebracht hat. Und vielleicht auch dein Schlüssel, WordPress-Projekte souverän, effizient und mit neuer Sicherheit umzusetzen.

Leseprobe

Band 1

Workflows. Automatisierung. Umgebungen.

Von Benjamin Zekavica

Besuche für mehr Informationen:www.unleash-wp.com

1. Auflage 2025 Band 1 |  Deutsch

Impressum

Kreo Pulse Publishing & Media by Benjamin Zekavica c/o Autorenglück #31329 Albert-Einstein-Straße 47 02977 Hoyerswerda, Deutschland

Postanschrift über den Dienstleister Autorenglück. Eine private Adresse wird auf Anfrage offengelegt.

E-Mail:[email protected]:www.kreo-pulse.com

Verantwortlich gemäß § 5 TMG und § 55 Abs. 2 RStV:

Benjamin Zekavica Umsatzsteuer-ID (§ 27a UStG): DE 358 256 337 Inhaber: Benjamin Zekavica

Veröffentlichung

ISBN 978-3-692-25002-1 eBook [EPUB], German-Edition

Urheberrecht

© 2025 Benjamin Zekavica / Kreo Pulse. Alle Rechte vorbehalten. Dieses Werk ist urheberrechtlich geschützt. Jede Vervielfältigung, Verbreitung, öffentliche Zugänglichmachung oder sonstige Nutzung – in gedruckter oder digitaler Form, als Kopie, Scan, Audio- oder E-Book-Datei – ist ohne vorherige schriftliche Genehmigung des Autors nicht gestattet. Zuwiderhandlungen werden zivil- und strafrechtlich verfolgt. Zulässig sind lediglich kurze Zitate unter Angabe der Quelle im Rahmen von Rezensionen oder wissenschaftlicher Arbeiten.

Mitwirkende

Autor & Buch Design, Layout: Benjamin Zekavica Lektorat & Korrektorat: Brigitte Nickel

Markenhinweis

WordPress ist eine eingetragene Marke der WordPress Foundation. Dieses Buch steht in keinerlei geschäftlicher, organisatorischer oder rechtlicher Verbindung zur WordPress Foundation oder zu Automattic Inc. Die Bezeichnung „WordPress“ wird ausschließlich als beschreibender Hinweis auf die gleichnamige Open-Source-Software verwendet und erfolgt im Einklang mit den offiziellen Markenrichtlinien. UnleashWP ist ein unabhängiger Anbieter und steht in keiner geschäftlichen oder rechtlichen Beziehung zur WordPress Foundation oder zu Automattic Inc.

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind online abrufbar unter: http://dnb.d-nb.de abrufbar.

Hinweis zur KI-Unterstützung

Die in diesem Buch enthaltenen Inhalte und Texte wurden vollständig vom Autor Benjamin Zekavica verfasst. Zur Unterstützung beim Lektorat, Korrektorat, stilistischen Feinschliff und zur Strukturprüfung wurde punktuell die KI-Software ChatGPT (OpenAI) eingesetzt. Sämtliche Texte wurden inhaltlich vom Autor erstellt, geprüft und in finaler Form eigenverantwortlich freigegeben. Die Verwendung von KI erfolgte ausschließlich als redaktionelle Hilfestellung und nicht zur Generierung eigenständiger Inhalte.

Einzelne Illustrationen und Grafiken wurden unter Einsatz von KI-gestützten Bildgenerierungs-Tools (ChatGPT / DALL·E, OpenAI) erstellt. Auch hier gilt: Alle final verwendeten Bilder wurden durch den Autor ausgewählt, geprüft, angepasst und freigegeben.

Bild- und Quellennachweise

Alle im Buch verwendeten Bilder, Illustrationen, Icons, Screenshots, Codebeispiele und weiteren Materialien wurden rechtmäßig lizenziert oder unter zulässigen Schranken (z. B. Bildzitat, Open-Source-Lizenzen, Creative Commons) verwendet.

Eine vollständige, detaillierte Übersicht aller Quellen, Urheber, Lizenzarten und Rechtehinweise befindet sich im abschließenden Kapitel „Bildnachweise & Lizenzen“ am Ende dieses Buches.

Rechtlicher Hinweis & Haftungsausschluss

Alle genannten Marken, Produkt- und Firmennamen sind Eigentum der jeweiligen Rechteinhaber. Die Nennung erfolgt ausschließlich zur Identifikation und sachlichen Beschreibung. Dieses Buch steht in keiner geschäftlichen oder vertraglichen Beziehung zu den genannten Unternehmen, Markeninhabern oder Organisationen.

Alle Informationen, Codebeispiele und Konfigurationen wurden mit größter Sorgfalt erstellt, erfolgen jedoch ohne Gewähr. Der Autor übernimmt keine Haftung für direkte oder indirekte Schäden, die aus der Anwendung der Inhalte entstehen könnten.

Hinweis zu Codebeispielen und Toolkit

Alle im Buch sowie im Toolkit Vol. 1 enthaltenen Code-Beispiele, Skripte und Vorlagen wurden sorgfältig geprüft. Dennoch erfolgen Einsatz, Anpassung und produktive Nutzung ausschließlich auf eigene Verantwortung. Eine Haftung für Schäden, die aus deren Anwendung entstehen, ist ausgeschlossen. Support oder Updates werden nicht bereitgestellt.

Inhalte

Start

Impressum

Vorwort

Wie du dieses Buch am besten nutzt

Wenn Workflows fehlen, bricht’s irgendwann

Eine saubere Projektstruktur

Lokale Entwicklungsumgebungen

Composer und Dependency Management

Bedrock vs. klassische WordPress-Struktur

Automatisiertes Scaffolding mit WP-CLI

Assets und Releases

Git Advanced und Branch-Concepts

Inhalte spiegeln: Von Live zu Lokal

Staging statt Stress

Continuous Integration Pipelines

Umgebungen und Secrets

Testing in der Praxis

End-to-End-Tests mit Playwright

Visuelles Regression-Testing mit Playwright

Testdaten mit Faker, WP-CLI und Factories

Tests in der CI

Deployment - Strategien und Tools

Monitoring, Performance und Sicherheit

Unter der Haube

Infrastruktur und Hosting

Automatisierung mit WP-CLI und Scheduled Tasks

Secrets-Management Best Practices

Enterprise und Skalierungsstrategien

Release-Management für Themes und Plugins

Monorepo vs. Multirepo und Private Registry

Enterprise und Agency Best Practices

MU-Plugins – das unsichtbare Fundament

Themes und Plugins – Ordnung statt Chaos

Content-Operations und Workflows im Team

Krisenmanagement für WordPress-Projekte

Change-Management und Rollouts

Teamorganisation und Prozesse

Dokumentation und Wissenssicherung

Schlusswort

Mein WordPress-Werkzeugkasten

Glossar

Quellenverzeichnis

Bildnachweise und Lizenzen

Guide

Start of Content

„WordPress ist ein Instrument. Nur wer es bewusst spielt, erschafft Harmonie statt Lärm.“

Benjamin Zekavica

1 

Vorwort

Es ist oft spät in der Nacht, wenn ich noch am Rechner sitze. Während die meisten schon schlafen, bin ich noch wach. Nicht, weil ich muss, sondern weil ich nicht anders kann. Weil mich Ideen nicht loslassen. Weil ich verstehen will, warum Systeme so laufen, wie sie laufen. Weil ich WordPress nicht einfach nur benutzen, sondern weiterbringen will. Und ganz ehrlich: auch, weil es mich manchmal ärgert, wie oft WordPress falsch oder halbherzig eingesetzt wird.

Mein Weg mit WordPress

Vor über 16 Jahren habe ich WordPress zum ersten Mal aufgesetzt. Damals war es nur ein Mittel zum Zweck – ich brauchte ein CMS für ein kleines Projekt. Ich hatte keine großen Erwartungen. Doch schon nach kurzer Zeit hat mich etwas daran gepackt. WordPress war offen, schnell, flexibel. Ich hatte plötzlich das Gefühl, ein Werkzeug in den Händen zu halten, das nicht einschränkt, sondern Freiraum schafft.

Aus dieser ersten Begegnung ist eine Reise geworden, die bis heute anhält. Ich habe Blogs gestartet, Multisites aufgebaut, Plattformen entwickelt. Ich habe mit Freelancern gearbeitet, mit kleinen Teams, mit großen Agenturen. Ich habe an winzigen Details gefeilt und an Projekten gearbeitet, die Millionen Nutzer erreichen. Und irgendwann kam der Moment, an dem ich nicht mehr nur für mich entwickelt habe. Ich wollte mich einbringen. Ich wollte der Community, die mir so viel gegeben hatte, etwas zurückgeben.

Die Community – mein Herzstück

Mein erster Contributor Day hat mein Denken verändert. Menschen aus aller Welt saßen einen Tag lang mit dem gleichen Ziel zusammen: WordPress ein Stück besser zu machen. Es war chaotisch, es war laut, es war voller Energie. Ich fühlte mich sofort als Teil von etwas Größerem.

Seitdem habe ich viele Stunden in die Community gesteckt: in Diskussionen, in Patches, in Slack-Channels, in Release-Teams. Ich war nervös, als ich zum ersten Mal Feedback auf einen meiner Core-Beiträge bekam. Ich habe Nächte damit verbracht, Bugs zu jagen, und stundenlange Diskussionen darüber geführt, wie eine Commit-Message am besten aussieht. Klingt verrückt? Vielleicht. Aber genau das ist es, was Open Source ausmacht: Wir machen es nicht allein. Wir machen es gemeinsam. Und es macht mich bis heute stolz, dass meine Arbeit dort geschätzt wird.

Mit gerade einmal 27 Jahren wurde ich einer von nur drei WordPress Core Team Representatives weltweit. Für mich ist das nicht einfach ein Titel. Es ist ein Ausdruck von Vertrauen. Ein Zeichen, dass die Community meine Arbeit sieht und anerkennt. Und genau deshalb möchte ich etwas zurückgeben. UnleashWP ist mein Beitrag. Es ist aus Jahren der Erfahrung entstanden – aus Erfolgen, aus Fehlern, aus Experimenten. Und ja: mit viel Herzblut.

Warum dieses Buch entstanden ist

In all den Jahren habe ich beide Seiten erlebt. Ich habe gesehen, wie großartige Ideen an chaotischen Workflows gescheitert sind. Wie Teams voller Talent ins Straucheln geraten sind, weil Standards und Strukturen gefehlt haben. Ich habe Deployments erlebt, bei denen niemand genau wusste, was eigentlich live ging. Und ich habe Code gesehen, den man nach ein paar Monaten kaum noch anfassen konnte. Aber ich habe auch die andere Seite gesehen. 

Projekte, die durch klare Prozesse plötzlich Ruhe und Stabilität bekamen. Teams, die entspannter zusammenarbeiteten. Kunden, die Vertrauen gefasst haben, weil Professionalität spürbar war. Den Unterschied machte nie Talent. Den Unterschied machte ein System. Und genau da setzt dieses Buch an.

Worum es in diesem Buch geht

Dieses Buch ist kein Einsteigerhandbuch. Ich erkläre dir nicht, wie man WordPress installiert oder was ein Plugin ist – dafür gibt es genug Tutorials. Ich zeige dir, wie du deine Projekte so aufsetzt, dass sie halten:

mit

DDEV

und

Docker

, damit deine

Umgebung überall gleich funktioniert,

mit

Git

, um deinem Projekt ein stabiles Rückgrat zu geben,

mit

Composer

, um Abhängigkeiten zu ordnen,

mit

Tests

, die dir Sicherheit geben,

mit

Automatisierungen

, die dir Arbeit abnehmen und

mit

Strukturen

, die auch in

Jahren noch nachvollziehbar sind.

Das ist kein theoretischer Kram. Alles, was du hier liest, nutze ich selbst jeden Tag – in echten Projekten, mit echten Kunden, in echten Teams.

Natürlich wird das nicht immer leicht. Manche Dinge werden dich herausfordern. Manche werden dich vielleicht nerven. Aber wenn du einmal erlebt hast, wie befreiend ein reproduzierbares, getestetes, automatisiertes Projekt sein kann, willst du nicht mehr zurück.

UnleashWP – mehr als ein Buch

Dieses Buch ist nur der Anfang. UnleashWP soll ein Grundstein für die Community werden. Ein Projekt, das wächst – mit weiteren Büchern, aber auch mit Tools, Plugins, Themes und Kursen. Alles mit demselben Anspruch: höchste Qualität, schlanker Code, echte Performance. Keine überladenen Baukästen, keine Lösungen von der Stange. Sondern Werkzeuge, die Entwicklern und Firmen wirklich helfen.

Ich will, dass wir aufhören, WordPress mit beliebigen Plugins „zuzuballern“. Ich will, dass wir es endlich so nutzen, wie es gedacht ist: als solides Fundament.

Nachhaltigkeit als Haltung

Ein Wort noch zur Produktion. Dieses Buch wird on demand gedruckt. Das bedeutet: Jedes Exemplar entsteht erst dann, wenn du es bestellst. Es gibt keine Überproduktion. Keine Lagerhallen voller unverkaufter Bücher. Keine unnötigen Transportwege.

Für mich ist das mehr als eine Druckmethode. Es ist eine Haltung. Mir ist wichtig, dass wir Verantwortung übernehmen – nicht nur im Code, sondern auch in unserem echten Leben. Jede Seite wird ressourcenschonend produziert, so lokal wie möglich, mit kurzen Wegen. Das ist nachhaltiger, und ja, es macht die Printversion teurer als ein Massenprodukt eines Großverlags. Aber es ist die ehrlichere Lösung. 

Und ich möchte, dass UnleashWP nicht nur WordPress besser macht, sondern auch einen kleinen Beitrag dazu leistet, unsere Erde zu schützen.

Danke, dass du hier bist.

Dass du dieses Buch gekauft hast, bedeutet mir sehr viel. Es zeigt, dass du Qualität schätzt. In einer Welt, in der Inhalte ständig kostenlos und beliebig verfügbar sind, ist das keine Selbstverständlichkeit. Mit deinem Kauf unterstützt du meine Arbeit – und die Idee, dass Wissen seinen Wert hat. Danke dafür.

Zum Schluss nur noch eins: Dieses Buch endet nicht einfach mit der letzten Seite. Ich habe etwas für dich vorbereitet, das dich beim Umsetzen unterstützen wird. Am Ende wartet ein kleines Geschenk auf dich. Mehr verrate ich nicht – aber ich verspreche dir: Es wird dir den Einstieg leichter machen.

Lass uns anfangen!

Dein Benjamin Zekavica

2 

Wie du dieses Buch am besten nutzt

Ein Leitfaden für alle, die es wirklich ernst meinen

Dieses Buch ist kein Schnellstart-Guide. Es ist auch keine Ideensammlung zum Durchblättern. Es ist ein Werkzeug. Ein System. Und vor allem: ein Einstieg in eine strukturierte, nachhaltige Art, mit WordPress zu arbeiten.

Du musst dieses Buch nicht von vorne bis hinten lesen. Aber du solltest es nicht einfach nur lesen. Denn wenn du wirklich etwas verändern willst – in deinen Projekten, in deinem Workflow, in deiner Denkweise –, dann reicht Lesen allein nicht.

Für wen dieses Buch geschrieben wurde

Dieses Buch richtet sich an Entwickler, die WordPress bereits einsetzen – und es künftig bewusster, klarer und professioneller nutzen möchten.

Ganz egal, ob du:

alleine arbeitest oder im Team,

schon viele Jahre mit WordPress entwickelst

oder gerade tiefer einsteigst,

freie Projekte umsetzt oder in einer festen Struktur arbeitest …

... entscheidend ist, dass du bereit bist, deinen Workflow zu hinterfragen und zu verbessern. Es geht nicht um Perfektion. Es geht um Haltung. Und darum, eine Grundlage zu schaffen, auf der man sauber entwickeln kann – unabhängig von Projekt, Kunde oder Teamgröße.

Was dich erwartet – und was nicht

Dieses Buch erklärt dir nicht, wie man WordPress installiert. Es geht nicht um Themes, Page-Builder oder einfache Hacks.

Stattdessen geht es um die technische Basis – darum,

wie du deine Projekte lokal mit DDEV aufsetzt – reproduzierbar, unabhängig vom System;

wie du mit Composer ein sauberes Abhängigkeitsmanagement etablierst;

wie du Inhalte aus der Live-Umgebung lokal

spiegelst – ohne Wildwuchs und Versionschaos;

wie du Staging und Deployments automatisierst – mit Git, Skripten und CI/CD;

wie du deine Projektstruktur so aufbaust, dass sie wartbar bleibt.

Der Fokus liegt auf Klarheit. Auf Effizienz. Auf Verständlichkeit. Nicht auf Spielereien.

Das Begleit-Repository

Zum Einstieg gibt es ein öffentliches Repository mit allen technischen Beispielen aus diesem Buch. Du kannst es hier öffnen:

u-wp.com/code

Dort findest du:

alle Codebeispiele aus dem Buch,

Bash-Skripte für Setup und

CI/CD-Workflows mit GitHub Actions.

Im Buch erkennst du relevante Abschnitte an diesem Symbol:

Code-Beispiele: So kannst du direkt loslegen, ohne alles selbst zu schreiben.

So verwendest du das Buch am effektivsten

Mein Vorschlag:

Lies das Buch kapitelweise – am besten mit offenem Terminal und Editor.

Teste jeden Schritt direkt – mit dem mitgelieferten Projekt oder an einem deiner eigenen Projekte.

Nutze das Repository nicht als Bonusmaterial, sondern als Grundlage.

Passe es an deine Umgebung an. Erweitere es. Mach es zu deinem Standard.

Was du daraus machst, bleibt dir überlassen – aber ich gebe dir alles an die Hand, damit du nicht bei null anfangen musst.

Und jetzt?

Wenn du deine Projekte künftig stabiler aufsetzen möchtest, wenn du dir wiederholbare Abläufe wünschst, wenn du bereit bist, deine Herangehensweise zu professionalisieren – dann ist dieses Buch der richtige Startpunkt. 

Ich zeige dir, wie du WordPress so strukturierst, dass du es nicht nur bedienen, sondern wirklich entwickeln kannst.

Ganz ruhig. Ganz klar. Schritt für Schritt.

3 

Wenn Workflows fehlen, bricht’s irgendwann

Ich hab WordPress-Projekte gesehen, da war der Code nicht mal das größte Problem. Sondern das, was drumherum gefehlt hat: ein Ablauf. Eine Struktur. Eine gemeinsame Sprache für „Wie arbeiten wir hier eigentlich?“.

Die Seiten liefen. Die Kunden waren sogar erstmal zufrieden. Aber sobald etwas geändert werden musste, kam das böse Erwachen.

Niemand wusste, welcher Stand gerade live ist. Änderungen wurden einfach drübergeschrieben, oft direkt auf dem Server. 

Git? Gab’s irgendwo – aber niemand wusste, wie aktuell es war. Fehler tauchten auf, und niemand konnte mehr sagen, woher sie kamen. So entstehen Projekte, die von außen „fertig“ wirken, aber bei jedem neuen Feature zur Zeitbombe werden.

Ich hab selbst mal so gearbeitet

Ich erzähl dir das nicht von oben herab. Ich hab genau so angefangen. Ich hab FTP benutzt, weil’s halt schnell ging. Hab mal eben was in derfunctions.php ergänzt – live. Ohne Testing, ohne Review, ohne Deploy-Prozess. Ging oft gut. Manchmal nicht.

Einmal hab ich in einem laufenden Shop einen kleinen CSS-Fix gemacht. Lokal getestet, schien zu passen. Hochgeladen – und aus Versehen dabei eine alte JS-Datei mitgeschoben. Checkout gebrochen. Fehler gemerkt, korrigiert – aber die zwei Bestellungen, die in der Zwischenzeit reinkamen, waren unvollständig. Und das Tracking war weg. 

Das war der Moment, an dem ich beschlossen hab: Nie wieder. Ich bau mir einen Ablauf, der solche Fehler gar nicht erst zulässt. Nicht, weil ich perfekt bin. Sondern weil ich weiß, dass ich es nicht bin.

Warum viele Teams auf Struktur verzichten

Was ich oft sehe: Entwickler haben gute Ideen, können sauber coden – aber der Rahmen fehlt. Nicht, weil sie’s nicht könnten. Sondern weil WordPress ihnen keine Struktur aufzwingt. Du kannst einfach loslegen. Es funktioniert. Bis es das nicht mehr tut. Und dann wird’s teuer. Oder peinlich. Oder beides.  Der Workflow ist das, was dich schützt. Nicht vor Fehlern – die passieren sowieso. Sondern davor, dass du sie erst dann merkst, wenn der Kunde dich anruft.

Was ein Workflow wirklich ist – und was er nicht sein darf

Ein guter Workflow ist kein starres Gerüst. Es geht nicht darum, irgendwas „richtig“ zu machen. Es geht darum, Verlässlichkeit in deinen Alltag zu bringen.

Das heißt:

Jede Änderung

hat ihren eigenen Branch.

Keine Änderungen direkt auf

main

.

Kein Deployment

per Hand. Niemals.

Der Code wird reviewt

, bevor er live geht. Nicht danach.

Fehler werden getestet

, bevor der Kunde sie findet.

Alle arbeiten mit der gleichen Umgebung

,

egal ob lokal oder im Team.

Das klingt nach mehr Aufwand. Ist es aber nicht. Es spart dir mit jedem Tag mehr Zeit – einfach weil du seltener Dinge flicken musst, die eigentlich klar gewesen wären.

Das Gegenteil siehst du täglich

Ich sag dir, wie es aussieht, wenn kein Workflow da ist. Du kennst das vielleicht:

WordPress liegt direkt im Projekt-Root, zusammen mit

screenshot.psd

, einem OLD-Ordner und

backup.zip

.

In

functions.php

steht Custom-Code zwischen

Tracking, Shortcodes und vier if-Abfragen.

Git? Gibt’s. Ein Repo, drei Commits:

„initial“, „final“, „final-final“.

Deployments passieren mit FileZilla.

Inklusive Tippfehlern im Dateinamen.

Und dann wundert man sich, warum Dinge nicht mehr funktionieren.

Und wenn du alleine arbeitest?

Dann erst recht. Du bist Dev, QA, Admin und Projektmanager in einer Person. Du kannst dir kein Chaos leisten. Eine Git-History ist dein Gedächtnis. Ein sauberer Ablauf, dein Schutzschild.

So beginnst du sauber – ganz ohne Overhead

Du brauchst kein Jira-Board, kein Tool-Overkill. Aber du brauchst einen klaren Ablauf. Der sieht z. B. so aus:

Wenn du das ein paar Mal durchziehst, willst du nie wieder anders arbeiten. Weil du merkst: Du brauchst weniger Meetings, weniger Rückfragen – und kannst dich endlich auf den Code konzentrieren.

Du musst nicht alles sofort perfekt machen. Aber du musst anfangen, überhaupt damit anzufangen. Ein funktionierender Workflow ist kein Luxus. Es ist das Mindeste, was ein Projekt verdient. Nicht, weil du damit glänzen willst. Sondern weil du ernst genommen werden willst – als Entwickler, als Team, als Dienstleister.

Im nächsten Kapitel steigen wir ein: Wie du dir eine lokale Entwicklungsumgebung aufbaust, die überall gleich funktioniert. Kein XAMPP, kein „geht nur bei mir“. Sondern ein Setup, auf das du dich verlassen kannst.

4 

Eine saubere Projektstruktur

Warum deine Projektstruktur entscheidet, wie lange dein Code überlebt

Ordner-Konventionen und Patterns

Ich habe viele Projekte gesehen, die technisch funktioniert haben – aber komplett unwartbar waren. Nicht, weil der Code schlecht war. Sondern weil niemand wusste, wo was liegt. Es gab kein klares Schema. Keine Struktur. Keine Trennung von Logik, Präsentation, Konfiguration. 

Was am Anfang noch funktioniert, bricht spätestens dann auseinander, wenn ein Teammitglied dazukommt – oder du nach sechs Monaten selbst wieder reingehst. Und genau das passiert ständig. Denn WordPress gibt dir keine Regeln vor. Du kannst Themes bauen, wie du willst. Plugins schreiben, wie du willst.

Ob du deine API-Endpoints in die functions.php oder in ein sauberes Modul schreibst – das System macht dazu keine Vorgaben. Und das hat zur Folge, dass es überall anders aussieht. Und in den meisten Fällen: unstrukturiert.

Was passiert, wenn Struktur fehlt?

Du schreibst einen Code, der doppelt vorhanden ist – weil du den alten nicht mehr findest.

Du debuggst Features, die kaputtgehen, nur weil jemand eine

helper.php

geändert hat, die drei andere Dinge mitzieht.

Du verlierst Zeit bei jedem Einstieg – weil du dich jedes Mal wieder orientieren musst.

Du traust dich nicht, aufzuräumen – aus Angst, etwas zu zerstören.

Du wirst langsamer – obwohl du eigentlich immer schneller sein wolltest.

Was eine Projektstruktur leisten muss

Sie muss dir helfen, Entscheidungen schneller zu treffen. Sie muss Ordnung schaffen – nicht Komplexität. Und sie muss von selbst erklärbar sein. Nicht, weil alles dokumentiert ist – sondern weil die Logik sofort sichtbar wird.

Ein gutes Projekt erkennt man daran, dass man nach fünf Minuten im Repo grob weiß, was wie funktioniert – auch ohne Doku.

Realität vs. Struktur

Nehmen wir ein typisches Projekt als Beispiel.

Was du hier siehst:

Der Code liegt kreuz und quer – nach technischem Zweck, nicht nach fachlicher Funktion.

Alles hängt voneinander ab – aber niemand weiß wie.

Keine Namespaces, kein Autoloading, kein Plan.

Kein Composer, kein Testing, kein CI, keine externe Struktur.

Das läuft, bis etwas geändert werden muss ...  Jetzt vergleichen wir das mit einer strukturierten Variante.

Was du immer brauchst

Egal ob du an einem kleinen Projekt arbeitest oder an einem großen Enterprise-Projekt, du brauchst immer diese Bausteine:

Ordner / Datei

Zweck

app/ oderwp-content/            

Deine echte Codebasis – nicht WordPress-Core

mu-plugins/

Logik, die konstant geladen werden muss – z. B. Setup, Sicherheit

vendor/

Autoloaded, extern verwaltet – keine eigenen Änderungen!

config/

Konfig-Dateien, ENVs, Server-Pfade, Domain-Angaben etc.

tests/

Testbare Strukturen, damit du sicher deployen kannst

bin/

Eigene Scripts, Setup-Routinen, CLI-Tools

.gitignore

Damit du nur das versionierst, was auch relevant ist

.env.example

Konfig-Beispiel für neue Entwickler oder Setups

README.md

Einstiegspunkt – nicht optional, sondern Pflicht

Was du hier siehst:

Trennung nach Zweck, nicht nach Technik.

Einen klaren Einstiegspunkt:

README.md

,

.env

,

composer install

,

ddev start

.

Du weißt sofort: Wo ist das Theme, wo ist die Logik, wo ist das Setup?

Das Onboarding dauert

30 Minuten statt 3 Tage.

Und du kannst das auf jedes neue Projekt übertragen.

Best Practices aus echten Projekten

Achte auf immer gleichbleibende Pfade. Wenn du drei Projekte gleichzeitig betreust, willst du nicht dreimal überlegen, ob jetzt

assets/js

oder

js/

oder

static/js

richtig ist.

Nutze mu-plugins für das Setup – nie für Logik, die abgeschaltet werden soll. Das ist dein Fundament – nicht dein Spielfeld.

Dokumentiere Konventionen in der

README.md

. Welche Branches gibt es? Wo liegen Plugins? Wie heißt der Theme-Slug?

Nutze das Autoloading über Composer. Das spart dir zahlreiche require_once und macht deinen Code wartbar.

Gleiche Regeln, egal welches Projekt 

„Das ist ja nur ein kleines Ding.“„Hier geht’s nur um Landingpages.“„Ich bin eh der Einzige, der dran arbeitet.“„Die Seite geht sowieso bald offline.“

Und genau darin liegt der Fehler.

Denn das kleine Ding wächst, die Landingpage wird zur Plattform, der Kunde will auf einmal Erweiterungen. Und dann sitzt du wieder da – und denkst dir: „Hätte ich doch …“

Du brauchst ein System – kein Bauchgefühl

Du brauchst ein Setup, das du kopieren kannst.

Einen Einstieg, der immer gleich funktioniert.

Einen Standard, der dich schneller macht – nicht langsamer.

Struktur ist kein Luxus. Sie entscheidet, ob dein Projekt wächst – oder in der Bedeutungslosigkeit verschwindet.

5 Lokale Entwicklungsumgebungen

Und ab sofort hast du keine Ausreden

Ich hab zu viele Projekte gesehen, bei denen „lokal“ in Wahrheit bedeutete: Jeder bastelt sich irgendwas. Einer arbeitet mit XAMPP, der nächste mit MAMP, der dritte hat sich WSL lokal eingerichtet und hofft, dass es irgendwie so läuft wie auf dem Server. Das tut es nie.

Und genau da fängt das Problem an:

Wenn du nicht die gleiche Umgebung hast wie dein Kollege, dein Server oder dein CI-System, testest du im Blindflug. Und dann fragst du dich irgendwann wieder, warum dein Code auf Staging plötzlich nicht mehr funktioniert, obwohl „bei dir alles lief“.

Lokal bedeutet heute nicht mehr „einfach WordPress irgendwo starten“. Lokal bedeutet: eine identische, kontrollierte, wiederholbare Umgebung. Ohne Wenn und Aber.

„Ich will doch nur schnell testen.“ Nein! 

Wenn du ernsthaft entwickelst – egal ob ein Plugin, Theme oder eine komplette Plattform –, dann ist dein Setup genauso wichtig wie dein Code.

Warum? Ganz einfach: Weil du sonst Bugs jagst, die keine sind. Weil du Funktionen debuggen musst, die nur in deiner Umgebung auftreten. Weil du Konfigurationsleichen mitschleppst, die auf dem Live-System nie vorhanden sind. Ich hatte mal ein Projekt, bei dem auf Staging plötzlich Custom Post Types nicht mehr angezeigt wurden. Lokal lief alles. Sauber, validiert, ohne Fehler.

Nach zwei Tagen Suche war klar: Der Kollege hatte lokal PHP 8.2 mit einem anderen Error-Reporting-Level, auf Staging lief 7.4, und ein kleinerundefined index hatte den ganzen Loop abgeschossen. Kein Fehler, kein Log – einfach weg. Seitdem arbeite ich ankeinem Projekt mehr ohne eine standardisierte Umgebung.

Warum DDEV und nicht „XYZ“?

Ich hab Docker gehasst. Lange. Zu viel Setup, zu viel Frickelei, zu viel Kram, der auf macOS nicht ging, auf Windows wieder anders – du kennst das. Dann kam DDEV. Und hat Docker nicht ersetzt, sondern gezähmt. Denn ja: DDEV baut auf Docker auf. Aber du musst Docker nicht mehr verstehen, um es zu benutzen. Du musst dir keine docker-compose.yml mehr basteln, keine Netzwerke konfigurieren, keine Ports jonglieren. DDEV nimmt dir diesen ganzen Overhead ab. 

Es packt dir eine komplette Entwicklungsumgebung – PHP, MySQL, Mail, Composer, Node, was du willst – in ein paar simple Befehle. 

Du brauchst kein Setup-Wiki mehr. Es gibt kein „Bei mir geht’s nicht“ oder „Warte, ich muss erst noch die richtige PHP-Version installieren“ mehr.

Kurz: DDEV ist Docker – aber endlich einfach benutzbar.

Warum ich heute auf DDEV setze:

Es kümmert sich um alles, was nervt: Host-Dateien, Domains, Ports, Volumes.

Es läuft unter macOS, Windows, Linux – gleich.

Es ist CLI-first, aber verständlich.

Du bekommst PHP, MySQL, Mailhog und Redis – direkt, ohne Suchen.

Die Config ist projektbasiert. Das heißt: Du checkst ein Projekt aus, machst

ddev start

– und es läuft.

So sieht ein brauchbares Projekt aus

Hier siehst du einen typischen Aufbau – schlank, klar, nachvollziehbar:

Wichtig dabei:

.ddev/config.yaml

definiert deine ganze Umgebung: PHP-Version, Webserver, DB und zusätzliche Dienste.

WordPress liegt im Unterverzeichnis (

wp/

) oder (

app/)

, damit du nicht alles durcheinanderwirfst.

Abhängigkeiten steuerst du mit Composer – ohne manuelle Downloads.

Deine Konfiguration (z. B. DB-Zugang) wird über

.env

oder DDEV-Umgebungsvariablen geregelt.

Ohne Passwörter im Code. Nie.

DDEV installieren und loslegen

Falls du DDEV noch nicht installiert hast, ist hier ein schneller Einstieg ohne Schnickschnack.

Voraussetzungen:

Docker Desktop oder Docker Engine

Homebrew (macOS) oder

apt/yum/choco

für dein System

Installation (macOS oder Linux):

brew install drud/ddev/ddev

Oder für Windows (mit Chocolatey):

choco install ddev -y

Projekt initialisieren:

Erstelle einen neuen Ordner und wechsle hinein.

mkdir my-wp-project && cd my-wp-project

ddev config

Folge dem Prompt:

Projekttyp: WordPress Name der Datenbank: DDEV legt den DB-Namen automatisch fest Webroot: z. B. wp

Danach:

ddev start ddev launch