Nachdem ich aktuell dabei bin meine eigenen Themes zu entwickeln und zu verkaufen, möchte ich hier einmal kurz vorstellen, wie ich dabei vorgehe. Damit das Tutorial verständlich ist, sollte man folgende Themen grundlegend beherrschen und sein eigen nennen:
- git
- Unix / Mac OS X
- Webserver mit SSH-Zugang (für git)
Zusätzlich setze ich noch phpStorm als IDE ein – aber das ist eher unerheblich und sorgt nur für etwas Komfort. Als erstes Problem steht man vor der Dateistruktur. Am Ende ist ein Theme dann doch mehr als ein einzelnes Theme-Verzeichnis. Daher habe ich mir folgende Struktur überlegt.
. ├── dev │ └── themes │ └── kwando │ ├── Documentation │ ├── License │ ├── Ressources │ ├── SampleData │ ├── kwando │ └── kwando-child ├── media ├── wp-content │ ├── themes │ │ └── kwando -> /Volumes/DEV/sites/wordpress/dev/themes/kwando/kwando/ │ └── upgrade
Wie man sieht, liegt innerhalb meiner WordPress-Entwicklungs-Instanz ein dev-Verzeichnis. Darunter folgt der Typ des zu entwickelnden Stück Software (plugins, themes, …). Dann ein allgemeiner Name, welcher den Inhalt beschreibt und als git-Repo angelegt wird.
Im Themes-Verzecihnis selbst liegt dann nur noch ein Symlink auf das eigentliche Theme-Verzeichnis. So kann ich zusätzlich zum eigentlichen Theme noch weitere Dateien wie Dokumentationen, Beispieldaten oder Bilder in das Repo legen und bin innerhalb von WordPress immer auf dem aktuellsten Stand des Repos. So spart man sich das hin und her kopieren und kann auch innerhalb des Repos ganz entspannt Branches wechseln etc.
Da bei einer Veröffentlichung eines Theme-Updates immer genau der eine Stand zur Verfügung gestellt wird, arbeite ich hier mit git-Tags. Diese sind dann auch immer identisch mit der Version des Themes. Generell arbeite ich also in einem develop-branch bis eine Version fertig gestellt ist. Diese wird dann mit einem Tag versehen. Der Vorteil daran ist, dass ich auch in meiner Demo-Installation (online) git nutzen kann. Dazu lege ich einfach die selbe Struktur an wie lokal und kann einfach den nächst-höchsten Tag auschecken. Schon ist die neue Version zur Vorschau freigeschaltet.
Falls irgendwann jemand eine Frage zu dem Theme hat, muss er mir nur die Versionsnummer nennen und ich kann viel besser nachvollziehen was dort falsch laufen könnte.
Wie man sieht, ist das alles nichts besonderes und eigentlich nur klassisches git mit einem Symlink und etwas System und Disziplin beim Entwickeln. So beugt man extrem viel Chaos vor und kann alles genaustens nachvollziehen.
Meine Repos liegen als privat auf Bitbucket. Wer eh schon Geld für GitHub ausgibt kann diese natürlich auch hier ablegen. Hauptsache alle Server haben dort Zugriff. So hat man auch gleichzeitig ein Backup der sensiblen Daten.