Als „Cowboy Coding“ bezeichnet man das Vorgehen, wenn man Änderungen an seiner WordPress Website (also typischerweise via „functions.php“ und „style.css“ Datei) lokal macht, und diese dann via FTP direkt auf den Live Webserver hochlädt.
Also man arbeitet im Prinzip ohne Sicherheitsnetz (oder anders gesagt: Man lebt eben wie ein Cowboy im Wilden Westen, ohne Gesetze und mit viel Risiko 😉 ).
Wenn etwas schief geht (was natürlich nie passiert 😉 ), dann ist die öffentliche Live-Website kurzfristig nicht mehr erreichbar (bis man den Fehler lokal korrigiert und wieder via FTP hochgeladen hat).
Damit wir uns richtig verstehen:
Wahrscheinlich arbeiten 99% aller WordPress Webdesigner als Cowboys.
Und:
Für die allermeisten Websites reicht dieses Cowboy Coding Vorgehen auch völlig aus.
Weil das „richtige“ Vorgehen im Vergleich zum Cowboy Coding deutlich mehr Schritte, Ressourcen, Zeit und auch Wissen erfordert. Und eben, für die meisten Website Projekte wäre es schlicht mit Kanonen auf Spatzen schiessen.
Übrigens: In meinem WordPress Online Kurs zeige ich eine Lösung, mit der ausschliesslich im WordPress Adminbereich gearbeitet werden kann, also eben ohne dass man lokal in einem Editor wie Notepad++ und mit FTP-Programm arbeiten muss (bis auf die initiale Installation von WordPress auf dem Webhosting).
Vom Prinzip her ist das zwar immer noch „Cowboy Coding“, weil man direkt an der Live-Website arbeitet, aber es ist ein etwas eleganterer und einfacherer Ansatz.
Als Vergleich:
Cowboy Coding braucht:
- Einen simplen Texteditor (z.B. Notepad++), um Änderungen an der functions.php und style.css machen zu können.
- Ein FTP-Programm (z.B. Filezilla), um diese Änderungen auf den Webserver hochzuladen.
Das ist alles.
Eine professionelle Entwicklungsumgebung hingegen umfasst typischerweise zusätzlich:
- Anstatt Änderungen via FTP direkt an der Live-Website zu machen, arbeitet man in einer lokalen Test- bzw. Entwicklungsumgebung.
- Anstatt einem simplen Text-Editor nutzt man eine sogenannte IDE (Integrated Development Environment), wie z.B. Visual Studio Code.
- Man nutzt ein Versionsverwaltungssystem (Version Control System), wo sich Git bzw. GitHub als Standard etabliert hat.
- Ev. die Nutzung eines Paketmanagers (Dependency Manager), was in unserem Fall für PHP (da wir das auf PHP basierende WordPress nutzen) Composer wäre.
Ein paar persönliche Anmerkungen/Einschätzungen zu diesen 4 Punkten:
- Diese 4 Systeme/Konzepte bauen aufeinander auf. Du startest also typischerweise bei #1.
- #1 (also die lokale Entwicklungsumgebung) ist gleichzeitig auch das einzige „Must-have“, um nicht mehr als Cowboy zu gelten. Alles andere kannst Du vorzu und nach Bedarf in Deinen Workflow einbauen.
- #2 (Visual Studio Code) ist grundsätzlich Geschmackssache, wird aber in Kombination mit #3 auf jeden Fall empfehlenswert.
- #3 (die Versionsverwaltung mit Git/GitHub) ist schon sehr fortgeschritten und wird erst bei wirklich sehr komplexen Projekten zum Must-have, wenn tatsächlich sehr viel individuelle Programmierarbeit nötig wird (und insbesondere wenn mehrere Personen gleichzeitig am gleichen Projekt arbeiten).
- #4 (Composer) wirst Du höchstwahrscheinlich nie wirklich brauchen.
Das Ziel von diesem Artikel ist nicht, all diese Themen im Detail zu erklären (ich bin kein Experte in all diesen Themen, und jedes dieser Themen braucht zu Beginn durchaus einige Stunden, bis man alles eingerichtet und die Grundlagen verstanden hat).
Dieser Artikel soll lediglich eine simple und praktische Übersicht speziell aus Sicht von WordPress sein (mit Links zu weiteren, von mir als nützlich empfundenen Ressourcen), um Dir beim Einstieg und umsatteln vom Cowboy zum Coder zu helfen 🙂
Legen wir los:
#1: Lokale Test- / Entwicklungsumgebung für WordPress einrichten
Zuerst einmal:
Ja, Du kannst natürlich auch direkt auf Deinem Webhosting eine Kopie Deiner Website als Testumgebung einrichten. Der Nachteil dabei ist aber, dass Du weiterhin jede Änderung zuerst via FTP hochladen musst. In einer lokalen Entwicklungsumgebung musst Du nur noch die Datei speichern, und kannst die Änderung sofort sehen.
Ausserdem: Spätestens wenn Du die Versionsverwaltung Git/GitHub nutzen möchtest, musst Du das sowieso mit einer lokalen Entwicklungsumgebung machen.
Damit Du eine WordPress Website lokal auf Deinem PC laufen lassen kannst, brauchst Du die entsprechende Software dazu (die ansonsten der Webhoster auf dem Server bereits installiert zur Verfügung stellt):
- Die Webserver Software selbst, was typischerweise Apache ist (oder Nginx).
- Die Programmiersprache PHP.
- Die Datenbank, was MySQL bzw. MariaDB ist.
Wenn Du dann in Google nach den verschiedenen Möglichkeiten recherchierst, wirst Du über 4 verschiedene Lösungen stolpern, die ich Dir hier kurz zusammenfasse:
- Die Klassiker: XAMPP oder MAMP. Nicht speziell für WordPress ausgerichtet, aber bieten genau das, was WordPress braucht (eben Apache, PHP und Datenbank).
- Wie angedeutet gibt es mit LocalWP eine für WordPress spezialisierte Alternative, die ähnlich wie XAMPP oder MAMP die benötigte Software lokal installiert, plus eben zusätzlich auch direkt WordPress installiert. Ausserdem ist die Bedienung deutlich moderner und einfacher.
- Hinweis: Du wirst bei der Recherche wahrscheinlich auch über Empfehlungen für DesktopPress / ServerPress stolpern. Ebenfalls eine für WordPress spezialisierte Lösung, die aber nicht mehr weiterentwickelt wird.
- Eine etwas weniger bekannte, aber modernere Alternative zu XAMPP/MAMP ist Laragon (nur für Windows). Praktisch alle Entwickler die Laragon ausprobiert haben, sind davon begeistert. Anscheinend ist Laragon spürbar schneller als XAMPP/MAMP und LocalWP. Und obwohl Laragon nicht speziell auf WordPress ausgerichtet ist, bietet es eine „1-click“ WordPress Installation an.
- Der Vollständigkeitshalber als Hinweis: Du wirst wahrscheinlich auch über Docker sowie Vagrant stolpern. Das sind deutlich umfangreichere („Corporate“) Lösungen für grosse Teams, die für unsere Bedürfnisse mit WordPress schlicht überdimensioniert sind (wäre jetzt zumindest meine Einschätzung, kann ich mich natürlich auch täuschen 😉 ).
Meine Empfehlung:
Nutze entweder LocalWP oder Laragon. LocalWP wenn Du es möglichst einfach möchtest, und Laragon wenn Du mehr Kontrolle, Möglichkeiten und Performance möchtest.
Ich persönlich nutze aktuell Laragon. Aber wenn Du zum ersten Mal nach einer lokalen Entwicklungsumgebung suchst, würde ich Dir tendenziell wohl eher LocalWP empfehlen 🙂
#2: Vom Texteditor zur IDE: Visual Studio Code
Zuerst einmal: Was ist der Unterschied zwischen einem Texteditor und einer IDE (Integrated Development Environment)?
Vereinfacht gesagt: Eine IDE umfasst: Texteditor + Compiler + Debugger + Versionsverwaltung
Hier gleich noch ein allgemeiner Hinweis: Der Übergang von Texteditor zu IDE ist fliessend (sprich Texteditoren können teilweise um Funktionen erweitert werden, welche typischerweise eine IDE bietet).
Und natürlich gibt es neben Visual Studio Code noch vielen andere IDEs, viele davon auch spezialisiert auf verschiedene Programmiersprachen, z.B. PhpStorm für (wie der Name schon vermuten lässt) PHP.
Ohne einen grossen Vergleich oder Analyse zu starten:
Visual Studio Code ist eine moderne und bei vielen Entwicklern sehr beliebte (und kostenlose) IDE, die ich Dir darum wärmstens empfehlen kann.
Für weitere Infos wie Visual Studio Code mit WordPress zusammen genutzt/eingerichtet werden kann, hier ein guter Artikel: Set Up Visual Studio Code and xDebug as the Ultimate Editor for WordPress Development
Und auch auf YouTube findest Du viele Tutorial Videos zu Visual Studio Code:
#3: Versionsverwaltung (Version Control) mit Git & GitHub
Falls Dir das Thema Versionsverwaltung / Version Control ganz grundsätzlich kein Begriff ist, dann würde ich z.B. mit diesen „Git Basics“ Videos starten (wie schon erwähnt ist Git der de facto Standard in der Versionsverwaltung).
Dann kurz zur Unterscheidung zwischen Git und GitHub:
- Git ist das eigentliche (Open Source) Versionsverwaltungssystem / Software, das Du lokal auf Deinem PC installieren kannst.
- GitHub ist die bekannteste Plattform bzw. Cloud Lösung, die auf Git basiert. Viele Open Source Projekte arbeiten mit GitHub und kannst Du direkt online den Quellcode anschauen und auch selber daran mitarbeiten. Es ist auch eine Art Social Network für Entwickler.
Ich empfehle dieses Video als Schnelleinstieg in Git:
Und dann gleich dazu als Ergänzung dieses Video zu GitHub:
Wie Du siehst basiert Git auf Kommandozeilenbefehlen (und auch die meisten Tutorials erklären das Ganze mit diesen Befehlen).
Falls Du wie ich zu wenig oft damit arbeitest, kann man Git dank Visual Studio Code und GitHub aber auch praktisch ohne die Kommandozeile nutzen.
Trotzdem muss man auch dann natürlich die Grundbegriffe und Konzepte von Branch / Push / Pull / Merge kennen, um mit Git arbeiten zu können.
Es gibt unzählige Anleitungen zu Git/GitHub (auch in Kombination mit Visual Studio Code) und ich will hier jetzt definitiv keine ausführliche Anleitung machen.
Aber vielleicht hilft Dir meine persönliche kurze Zusammenfassung und Workflow mit Visual Studio Code:
Git Projekt erstellen
Zuerst musst Du Git herunterladen und lokal auf Deinem PC installieren.
Jetzt kannst Du in Visual Studio Code im Reiter „Source Control“ ganz einfach per Knopfdruck ein neues Git Projekt initialisieren (eben ganz ohne Kommandozeile). Und dieses (jetzt erst lokale) Git Projekt kannst Du mit Visual Studio Code auch ganz einfach per Knopfdruck in ein GitHub Projekt hochladen.
Hier in diesem Artikel ist dieser Ablauf sehr gut erklärt (wie Du siehst gibt es 2 Wege: Einmal Projekt in Visual Studio Code anlegen und auf GitHub „pushen“, oder eben umgekehrt, das Projekt zuerst in GitHub anlegen, und dann in Visual Studio Code „pullen“): Create Your First Github Project in VSCode
GitHub Workflow
Zuerst einmal musst Du Dir grundsätzlich überlegen, wie Du mit Branches in Git arbeiten möchtest. Dieser Artikel gibt eine gute Übersicht über die verschiedenen „Branching Workflows“ (mein Tipp: Halte es simpel und nutze „GitHub Flow“): 4 branching workflows for Git
Hier ein Artikel, der ein konkretes simples Beispiel mit Visual Studio durchspielt: How to Create a Pull Request on GitHub using VS Code
Wirklich ganz, ganz kurz und simpel zusammengefasst und erklärt, wie Du im Prinzip mit Visual Studio Code und GitHub arbeitest:
- Pull (in Visual Studio Code): Du lädst die aktuelle Version des „main“ Branch des Projekts von GitHub auf Deinen PC herunter. Ja, wenn Du alleine arbeitest, dann fühlt sich das im Prinzip wie ein überflüssiger Schritt an. Wenn Du in einem Team arbeitest, erhältst Du damit aber eben die aktuellste Version mit allen Änderungen Deiner Kollegen. Deshalb ist es empfehlenswert, sich an diesen grundlegenden GitHub Workflow zu gewöhnen.
- Branch: Du erstellst basierend auf dem „main“ Branch einen neuen Branch (z.B. „feature-xyz“). In diesem Branch machst Du jetzt die Änderungen (also lokal in Deiner Entwicklungsumgebung).
- Commit: Mit dem Commit speicherst Du die aktuelle Version Deiner Änderungen in Git (immer noch lokal und in Deinem „feature-xyz“ Branch).
- Push: Mit einem Push kannst Du Deine Änderungen jetzt nach GitHub hochladen (Du bist immer noch in Deinem „feature-xyz“ Branch). Der „main“ Branch ist davon also immer noch völlig unberührt. Jetzt können aber andere in Deinem Team Deinen „feature-xyz“ Branch online in GitHub sehen (und selber wieder herunterladen / „pullen“) und Feedback geben oder daran weiterarbeiten.
- Pull Request (hier wechselst Du auf die GitHub Website): Mit dem Pull Request beantragst Du, dass die Änderungen in Deinem „feature-xyz“ Branch in den „main“ Branch zusammengeführt werden sollen (zusammenführen = „merge“).
- Hinweis: Es gibt eine Erweiterung für Visual Studio Code, damit Du das direkt in VSC machen kannst. Für das bessere Verständnis ist es aber einfacher nach GitHub zu wechseln.
- Merge: Wenn Du alleine im Projekt arbeitest, dann kannst Du jetzt den Merge automatisch und per Knopfdruck durchführen lassen. In einem Team macht das unter Umständen eine andere Person. In diesem Fall kann es auch vorkommen, dass verschiedene Leute an gleichen Stellen im Code Änderungen vorgenommen haben. In diesem Fall müssen diese Merge-Konflikte manuell aufgelöst werden (also eben manuell entschieden werden, welche von 2 Änderungen definitiv übernommen werden soll. Der „feature-xyz“ Branch wird jetzt nach dem Merge nicht mehr benötigt und gelöscht.
Jetzt bist Du bereit für das nächste Update oder Feature, bei dem Du wieder bei Punkt 1. startest 🙂
Git & GitHub für WordPress
Jetzt zur Anwendung von Git/GitHub speziell für WordPress:
Kurz zusammengefasst als grundsätzliche Regel gilt: Du willst lediglich Deinen eigenen Code (sprich Dein Child Theme, und allfällige selber programmierte Plugins) mit Git/GitHub verwalten. Nicht den Code von WordPress selber oder von fremden Themes/Plugins.
Hier kommt die .gitignore Datei ins Spiel.
Mit dieser .gitignore Datei kannst Du angeben, welche Dateien Du in Deinem Ordner (lokal in Deiner Entwicklungsumgebung) tatsächlich in Git verwalten möchtest, und welche eben von Git ignoriert werden sollen.
Hier eine typische Beispiel .gitignore Datei für WordPress, die eben alles ausser dem explizit angegebenen Child Theme und Plugin Ordnern ignoriert:
# ignore everything in the root except the "wp-content" directory.
/*
!wp-content/
# ignore everything in the "wp-content" directory, except:
wp-content/*
!wp-content/mu-plugins/
!wp-content/plugins/
!wp-content/themes/
# ignore everything in the "mu-plugins" directory, except:
wp-content/mu-plugins/*
!wp-content/mu-plugins/my-plugin/
# ignore everything in the "plugins" directory, except:
wp-content/plugins/*
!wp-content/plugins/my-plugin/
# ignore everything in the "themes" directory, except:
wp-content/themes/*
!wp-content/themes/generatepress-child/
# ignore log files and databases
*.log
*.sql
*.sqliteDie beste und umfassendste WordPress spezifische Anleitung die ich gefunden habe, ist dieser Artikel hier: Managing Your WordPress Site With Git and Composer
Hier wird wirklich von A bis Z und spezifisch für WordPress alles erklärt.
Hinweis: In dem Artikel wird auch die Verwendung der Paketverwaltung Composer beschrieben. Wie schon eingangs im Artikel erwähnt, ist das für die meisten Projekte schlicht übertrieben. Trotzdem denke ich, ist es interessant für das Verständnis.
#4: Paketverwaltung / Dependency Manager: Composer
Da das für die meisten Projekte nicht nötig bzw. übertrieben wäre, halte ich es hier kurz, und verweise für Interessierte auf den unter #3 bereits verlinkten Artikel, der das Konzept sehr detailliert erklärt: Managing Your WordPress Site With Git and Composer
Wie gesagt, mein Artikel soll nur eine Grobübersicht bieten 🙂