Meine lokale Entwicklungsumgebung und wie ich in der Produktion Updates durchführe

Ich bin Mac-Nutzer und obwohl ich mich gut mit Docker auskenne, habe ich aus Bequemlichkeitsgründen immer lokale Entwicklungssoftware verwendet. In den letzten Monaten bin ich jedoch von MAMP auf LocalWp umgestiegen. Diese Software macht es sehr einfach, eine einsatzbereite und zuverlässige Entwicklungsumgebung einzurichten, und verfügt über eine sehr praktische Funktion zum Klonen von Projekten.

Da ich für kleine Agenturen und Einzelkunden arbeite, verwende ich oft dieselben Plugins, dasselbe Starter-Theme und dieselben Konfigurationen. Mit LocalWp kann ich eine Starter-Website erstellen, auf der bereits alles Notwendige vorbereitet und konfiguriert ist, und diese mit einem Klick klonen, um mit einem neuen Projekt zu beginnen. LocalWp bietet außerdem weitere sehr nützliche Funktionen wie wp-cli, Backups und Bildoptimierungen, die mir viel Zeit sparen.

In einem zukünftigen Beitrag werde ich die von mir verwendeten Plugins, Konfigurationen und weitere Details zur Erstellung meiner monolithischen Showcase- und E-Commerce-Websites ausführlich erläutern. Nehmen wir nun aber einmal an, wir hätten die Website fertiggestellt und mit einem einfachen Duplikator in die Produktion überführt, damit wir zu weiteren Informationen übergehen können, die ich euch in diesem Artikel mitteilen möchte.

In den meisten meiner Projekte schreibe ich – abgesehen von bestimmten Funktionen, die ich in mehreren Projekten wiederverwenden möchte – den gesamten Code für websitespezifische Funktionen, Stile und benutzerdefinierte Elemente (ich nenne sie „Elemente“, da ich ein Premium-Theme verwende, das WPBakery nutzt) innerhalb eines Child-Themes.

Schauen wir uns nun an, wie ich dieses Child-Theme organisiere und wie ich die Synchronisation zwischen lokaler Umgebung und Produktionsumgebung
aufrechterhalte. In dieses Repository habe ich mein Starter-Theme hochgeladen, bei dem es sich um ein Child-Theme handelt, das „Salient“ als Parent-Theme verwendet. In diesem Projekt finden Sie die Standardelemente eines Child-Themes, wie beispielsweise die Dateien „style.css“ und „functions.php“, aber ich habe mich entschieden, „Parcel“ für die Verwaltung von .scss-Dateien hinzuzufügen, was ich sehr praktisch finde, sowie eine GitHub-Action für die direkte Veröffentlichung per FTP bei jedem Push. Schauen wir uns die beiden Konfigurationen im Detail an.

Parcel
Ich habe mich für Parcel entschieden, da es sich um ein Build-Tool ohne Konfigurationsaufwand handelt. In meinem Fall musste ich, wie du am Projekt sehen kannst, lediglich die Abhängigkeit „parcel-namer-custom“ hinzufügen, um statt variabler Ausgabedateinamen feste Namen zu erhalten, die ich über functions.php in die Warteschlange stellen kann.

GitHub-Action
Unter folgendem Pfad .github/workflows/main.yml findest du einen sehr interessanten Job für die Veröffentlichung des Themes in der Produktionsumgebung bei jedem Push, ergänzt durch die `.gitignore`-Datei, die es GitHub ermöglicht, einen Großteil des Codes zu ignorieren, der nur in der Entwicklungsumgebung benötigt wird. Diese beiden Dateien zusammen ermöglichen es uns, nur die notwendigen `.php`- und `.css`-Dateien zu veröffentlichen. Ein besserer Ansatz wäre natürlich, das Committen des gesamten Codes zuzulassen und in diesem Job in der `exclude`-Anweisung die Veröffentlichung der Entwicklungsdateien auszuschließen oder ihn nur bei einem Commit auf dem `main`-Branch zu starten und einen `development`-Branch zu verwenden.

Wie ich oben bereits geschrieben habe, gibt es ein zweites Szenario: Plugins, bei denen ich Code schreibe, der nicht nur auf einer Website veröffentlicht werden muss, sondern für viele weitere Projekte relevant ist. Meine Lösung für ein privates Repository und automatische WordPress-Updates werde ich in einem zukünftigen Artikel mit euch teilen.

Falls die Informationen in diesem Artikel für Sie hilfreich waren, empfehle ich Ihnen, mit dem nächsten Artikel dieser Reihe fortzufahren: https://blog.riccardodicurti.it/my-thoughts-on-css