Moderner WordPress Entwicklungsworkflow mit dem Roots Stack

WordPress gibt es schon seit Ewigkeiten, zumindest nach Internetstandards, und seine Philosophie war schon immer die Wahrung der Abwärtskompatibilität. Dieser Fokus auf Kompatibilität ist angesichts der schieren Menge an WordPress-Websites, die heute online sind, verständlich. Während dies jedoch denjenigen helfen kann, die noch Legacy-Umgebungen mit alten PHP- und MySQL-Versionen verwenden (was an sich ein Sicherheitsrisiko darstellt, aber dies nicht das Thema des heutigen Artikels ist), führte es auch dazu, dass neuere WordPress-Versionen nicht vollständig genutzt wurden die neuesten PHP-Funktionen.

Dies hat auch dazu geführt, dass viele WordPress-Entwickler in einer WordPress-Blase leben, keinen Anreiz haben, neue und moderne Front-End-Entwicklungstechnologien zu lernen, und manchmal in der „guten alten Art“ stecken bleiben, Dinge zu tun.

Können Sie einen modernen Entwicklungsworkflow für WordPress übernehmen?

Das kannst du mit Sicherheit, und der WordPress Roots-Stack ist hier, um dir mit drei erstaunlichen Tools dabei zu helfen, dich wie im Jahr 2019 zu entwickeln:

• Salbei als Startthema,
• Bedrock als moderne WordPress-Boilerplate,
• Trellis zur Verwaltung der Bereitstellung und Bereitstellung in verschiedenen Umgebungen.

Das Roots-Team hat außerdem zwei weitere Tools in der Entwicklung: Acorn, ein Plugin-Building-Framework, und Clover, eine Plugin-Boilerplate. Da sich beide in der Alpha-Phase befinden, sind sie nicht in diesem Artikel enthalten, aber Sie sollten sie auf jeden Fall im Auge behalten.

Was genau ist der Roots-Stack

Ursprünglich als Roots-Theme bekannt, war es ein felsenfestes HTML5-Starter-Theme, das darauf abzielte, einen saubereren Ausgangspunkt für neue WordPress-Websites zu bieten. Im Laufe der Zeit entwickelte es sich zu einem vollständigen Satz von Tools, die alle wichtigen modernen Webtechnologien und -standards durchlaufen (von Grunt bis Gulp und Webpack, LESS und SCSS, NPM und Yarn, Bootstrap, PSR-2-Codierungsstandards und dem DRY-Prinzip). Dies zwingt WordPress-Entwickler, die es übernommen haben, kontinuierlich zu lernen und auf dem Laufenden zu bleiben, was moderne Front-End-Entwicklungstechnologien zu bieten haben.

Heute hat sich Roots zu einem vollständigen Satz von Tools in kontinuierlicher Erweiterung entwickelt, die darauf abzielen, Ihnen dabei zu helfen, bessere WordPress-Sites zu erstellen, indem sie den gesamten Zyklus von der Entwicklung über die Bereitstellung bis zur Produktion verfolgen und Sie zu einem besseren Entwickler machen, indem sie Sie dazu zwingen, aus dem Komfort herauszutreten Zone, die von der sogenannten WordPress-Blase bereitgestellt wird.

Aber werfen wir einen Blick auf die drei wichtigsten Tools, die sie anbieten, was sie sind und warum Sie sie verwenden sollten.

Wurzelsalbei 9

Roots Sage 9 ist die letzte Iteration eines professionell gepflegten WordPress-Starter-Themes , das ursprünglich 2011 nur als Roots veröffentlicht wurde. Während seiner Lebensdauer hat es viele Änderungen, Verbesserungen und Neubetrachtungen von Best Practices durchlaufen, um schließlich was zu werden heute ist ein guter Ausgangspunkt, um einen modernen Front-End-Entwicklungsworkflow für die WordPress-Entwicklung einzuführen.

Sage versucht, ein MVC-Muster (Model-View-Controller) zu übernehmen, bei dem Ansichten und Controller vollständig getrennt sind. Dadurch können wir Views wiederverwenden, die nicht unbedingt „wissen“ müssen, woher die Daten kommen, sondern einfach darauf warten, dass ein Controller sie mit Daten zur Anzeige versorgt.

Der in Sage 9 enthaltene Controller ist nicht der eigentliche Controller, mit dem Sie möglicherweise bereits in anderen Frameworks wie Laravel vertraut sind. Der Hauptunterschied besteht darin, dass der Sage 9-Controller ein vorlagenbasiertes Routing anstelle eines URL-basierten Routings verwendet. Grundsätzlich überlässt du WordPress das URL-Routing und schreibst Controller für Template-Dateien.

Durch das Hinzufügen einiger Komplexitätsgrade zum gesamten Entwicklungsprozess ist Sage 9 möglicherweise nicht die beste Wahl für Anfänger, da Sie einiges lernen müssen, um es schließlich zu beherrschen und in der Lage zu sein, es in der Produktion zu verwenden: richtig Abhängigkeits- und Asset-Management, Code-Versionierung, eine neue Projektstruktur, eine neue Template-Engine, die von Laravel abgeleitet ist, das DRY-Prinzip (Don't Repeat Yourself) und Sie müssen sich an strenge Codierungsstandards halten, die sich ein wenig von what unterscheiden WordPress empfiehlt; Wenn Sie jedoch ein erfahrener Entwickler sind, kann dies ein großer Vorsprung sein.

Wenn Sie mit Sage All-In gehen wollen, beachten Sie einfach diesen Ratschlag von Ben Word, einem der Entwickler des Roots-Teams:

Sage ist kein Theme-Framework, es ist ein Starter-Theme. Sie sollten es selten aktualisieren müssen, und normalerweise sollten Sie keine untergeordneten Themen daraus erstellen. Als Einstiegsthema soll Sage als Ausgangspunkt für ein neues Projekt dienen.

Aber auch:

Wenn Underscores einen Vorsprung von 1.000 Stunden hat, hat Sage einen Vorsprung von 10.000 Stunden.

Datei- und Ordnerstruktur mit Sage

Die Datei- und Ordnerstruktur von Sage unterscheidet sich ein wenig von dem, was wir von anderen Einstiegsthemen wie Underscores oder sogar von der vorherigen Hauptversion von Sage 8 gewohnt sind.

Das finden Sie direkt nach der Installation von Sage:

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

Außerdem einige andere Dateien, die von Code-Editoren und IDEs verwendet werden, wie z. B. .editorconfig, .eslintrc.js, .stylelintrc.js, phpcs.xml usw.

Hier ist ein kurzer Überblick über die grundlegenden Anforderungen von Sage 9:

• WordPress >= 4.7
• PHP >= 7.1.3 (mit aktiviertem php-mbstring)
• Komponist
• Node.js >= 8.0.0
• Garn

Grundgestein

Bedrock ist wie WordPress auf Steroiden!

Wenn Sage Ihre Theme-Entwicklung verbessert, verbessert Bedrock die gesamte WordPress-Installation. Dies geschieht durch die Bereitstellung eines modernen Projektbausteins mit verbesserter Ordnerstruktur und Sicherheit (z. B. indem Sie Ihre Konfigurationsdateien nicht im Stammverzeichnis der Website haben), Konfigurations- und ENV-Dateien und einem ordnungsgemäßen Abhängigkeitsmanagement (ja, einschließlich WordPress-Plugins und -Designs). .

Um es in einem einzigen Satz zu beschreiben, könnten wir sagen, dass Bedrock ein eigenständiges WordPress-Projekt ist, das die Installation von Kerndateien und erforderlichen Plugins automatisiert.

Datei- und Ordnerstruktur

Wenn Sie sich eine einfache Bedrock-Installation ansehen, fühlen Sie sich am Anfang vielleicht verloren. Bedrock trennt Web-, Konfigurations- und Abhängigkeitsdateien in eigene Ordner. So sieht die nackte Knochenstruktur aus:

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

Plus einige andere weniger wichtige Dateien.

Grundgesteinsanforderungen sind:

• PHP >= 7.1
• Komponist

Gitter

Trellis ist ein moderner LEMP-Stack zur nahtlosen Verwaltung Ihrer Entwicklungs-, Staging- und Produktionsserver mit dem Ziel, sie so ähnlich wie möglich zu halten („Entwicklungs- und Produktionsparität“). Das bedeutet, dass, wenn Ihre benutzerdefinierte WordPress-Site in Ihrer Entwicklungsumgebung funktioniert, davon ausgegangen werden kann, dass sie auch in der Produktion funktioniert und Sie sie mit Zuversicht bereitstellen können.

Für die lokale Entwicklung verwendet Trellis Vagrant, mit einem einfachen vagrant up Sie eine virtuelle Maschine, auf der eine angemessene moderne Umgebung ausgeführt wird.

Die Bereitstellung und Bereitstellung in Ihren Staging- und Produktionsumgebungen werden mit Ansible-Playbooks verwaltet, bei denen es sich um YAML-Dateien handelt, die Ansible mitteilen, was zu tun ist.

Von Trellis vorgeschlagene Ordnerstruktur

Trellis hat eine vorgeschlagene Ordnerstruktur, die nur aus zwei Unterordnern besteht:

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

Ich würde empfehlen, es so zu lassen, wie es ist, aber es kann je nach Ihren Vorlieben und Bedürfnissen angepasst werden.

Trellis-Anforderungen

• Komponist
• Virtualbox >= 4.3.10
• Landstreicher >= 2.1.0

Warum Sie es verwenden sollten

Wenn WordPress bereits so funktioniert, wie es ist, warum sollten Sie dann zu einem komplexeren Stack wechseln und viel Zeit damit verbringen, ihn zu beherrschen? Denn es gibt offensichtliche und einige weniger offensichtliche Vorteile. Versuchen wir zu sehen, was sie sind.

Ein Framework-agnostisches Starter-Thema

Zu viele WordPress-Starter-Themes zwingen Sie dazu, ein bestimmtes CSS-Framework zu verwenden, das Sie vielleicht mögen oder nicht mögen oder sogar kennen, aber Sage ist vollständig Framework-agnostisch. Während der Installation haben Sie die Möglichkeit, Bootstrap 4, Bulma, Foundation, Tachyonen, Tailwind CSS oder gar kein Framework automatisch einzubinden, wenn Sie von vorne anfangen oder etwas anderes verwenden möchten (TIPP: In letzter Zeit mag ich Tailwind viel CSS).

PROFITIPP: Auf einem Windows-Rechner erhalten Sie während der Installation möglicherweise die Meldung „Der TTY-Modus wird auf der Windows-Plattform nicht unterstützt“ und Sie können kein Framework auswählen oder Sage konfigurieren. Sie müssen diese drei Befehle manuell aus dem Themenordner ausführen, wenn Sie die Vorteile der automatischen Konfiguration nutzen möchten:

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

Ein moderner Build-Prozess

Mit Webpack, das in Sage enthalten ist, müssen Sie nicht mehr über das Kompilieren von Assets, das Verketten und Minimieren von JavaScript- und CSS-Code, das Optimieren von Bildern, das Überprüfen von JavaScript- und Stilfehlern und das Verwalten externer Bibliotheken nachdenken. Der Build-Prozess kümmert sich um all das mit einem einfachen yarn build (oder yarn build:production wenn Sie möchten, dass Ihre Assets für die Verwendung in der Produktion optimiert werden) und erstellt alle statischen Dateien in Ihrem Theme-Ordner /dist/ .

Modernes PHP und Anforderungen

Die Mindest-PHP-Version, auf der Sie WordPress ausführen können, ist PHP 5.2.4. Dies gewährleistet die Abwärtskompatibilität für alle Benutzer, die ihre Websites in einer Legacy-Umgebung ausführen, aber alte Versionen von PHP (<= 7.0) haben offiziell das Ende von erreicht leben, sodass sie nicht mehr unterstützt werden und Ihre Website möglicherweise Sicherheitslücken und Leistungsproblemen aussetzen.

Sowohl Sage als auch Bedrock erfordern eine vernünftige Version von PHP 7.1 (obwohl Sie die Möglichkeit haben, 7.3 zu wählen, tun Sie dies bitte).

Sage 9 übernimmt auch vollständig die PSR-2-Codierungsstandards (die am weitesten verbreitete und akzeptierte Codierung).

Standards, die in der PHP-Community verwendet werden), die sich ein wenig von den WordPress-Codierungsstandards unterscheiden, aber sie ermöglichen Ihnen einen saubereren und besser wartbaren Code, insbesondere wenn Sie in einem Team arbeiten oder Ihren Code mit anderen teilen müssen.

Bessere Abhängigkeiten und Paketverwaltung

Der Roots-Stack nutzt Composer in großem Umfang, um alle Abhängigkeiten und Pakete zu verwalten, einschließlich WordPress-Kern, Plugins und Themen. Dies könnte ein Problem sein, wenn Sie Tools von Drittanbietern verwenden, um WordPress-Updates zu verwalten (wie ManageWP, MainWP oder InfiniteWP), aber jemand könnte argumentieren, dass Sie mehr Kontrolle haben, wenn Sie alles unter Versionskontrolle haben und es einfacher machen, zu einer früheren Arbeit zurückzukehren Version, wenn etwas schief geht.

Darüber hinaus verwendet Sage Yarn als Paket- und Abhängigkeitsmanager für den Anwendungscode und zum Starten des Build-Prozesses.

Bessere Vorlagendateien

WordPress fehlt eine echte Templating-Engine, um dies auszugleichen, hat Sage Laravel's Blade übernommen und folgt dem DRY-Prinzip: Don't Repeat Yourself.

So sieht die standardmäßige Vorlagendatei single.blade.php aus, nur 6 Zeilen Code:

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

Die Blade-Template-Engine trennt Ansichten und Controller vollständig und ihre Syntax ist eleganter, prägnanter, lesbarer und einfacher zu schreiben als nur PHP-Tags. Als Faustregel gilt hier, den gesamten PHP-Code aus Ihren Vorlagendateien herauszulassen (oder es zumindest zu versuchen).

Ein weiterer Vorteil der Verwendung von Blade ist die Vorlagenvererbung: Eine Basislayoutvorlage (die Standardeinstellung ist /resources/views/layouts/app.blade.php ) definiert Blöcke, die die gemeinsamen Website-Elemente enthalten, die dann von ihren untergeordneten Vorlagen geerbt werden. Die Vorlagenvererbung ist großartig, um wiederholtes Markup aus einzelnen Vorlagen zu entfernen und die Dinge TROCKEN zu halten.

Browsersync

Indem Sie yarn start , starten Sie eine Browsersync-Sitzung. Browsersync ist ein Modul für synchronisiertes Browser-Testen während der Entwicklung. Es wird auf Änderungen an Ihren Front-End-Assets achten und in Zusammenarbeit mit Webpack die Änderungen automatisch in Ihre Browsersitzung einfügen.

Schnelle, einfache und sichere WordPress-Bereitstellung

Trellis bietet WordPress-Bereitstellungen ohne Ausfallzeiten. Wenn Sie eine Bereitstellung starten, klont Trellis Ihr Repository, führt Composer Install aus und aktualisiert dann den Symlink auf die aktuelle Version, sodass die Dateien, die derzeit in der Produktion bereitgestellt werden, niemals direkt bearbeitet werden.

Bei der Verwendung von Bedrock benötigt Trellis auch nur sehr wenig Konfiguration.

Nachteile

Der einzige Nachteil bei der Verwendung des vollständigen Roots-Stacks (abgesehen vom Erlernen neuer Dinge, was überhaupt kein Problem darstellen sollte) ist, dass Sie einen Trellis-freundlichen Hosting-Anbieter wie Kinsta, ein DigitalOcean-Droplet oder einen anderen Host verwenden müssen unterstützen mindestens SSH, Composer und WP-CLI, zusammen mit der Option, den Web-Root-Pfad zu aktualisieren.

Dadurch bleibt das meiste billige Shared Hosting aus dem Spiel, und Sie und / oder Ihr Kunde müssen dies berücksichtigen, bevor Sie ein neues Projekt starten.

Wie man anfängt

Dies kann als eine neue Version der berühmten „WordPress 5-Minuten-Installation“ betrachtet werden, jedoch für moderne Front-End-Entwickler. Es fügt ein paar Grad an Komplexität für die spätere Entwicklung hinzu, aber am Ende sind die Vorteile, die Sie erhalten können, es definitiv wert.

Wir werden uns darauf konzentrieren, den gesamten Stack (Sage, Bedrock und Trellis) zu übernehmen, aber Sie können nur einen oder eine beliebige Kombination davon verwenden. Sage kann als Ausgangspunkt für ein eigenständiges Thema in jeder WordPress-Installation verwendet werden; Bedrock kann mit jedem beliebigen WordPress-Theme verwendet werden; und Trellis-Bereitstellungen sind für Bedrock-basierte Sites konfiguriert und kümmern sich um alles Notwendige, aber mit ein wenig Basteln kann es für fast jeden Bedarf angepasst werden.

So erstellen Sie ein neues Projekt

Das Einrichten eines neuen WordPress-Projekts mit Trellis, Bedrock und Sage ist ganz einfach, nur ein paar Befehlszeilen entfernt.

Installieren Sie Trellis im gewünschten Ordner (z. B. example.com ):

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

Installieren Sie Bedrock im Unterordner /site/ :

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

Sage installieren und erstellen:

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

Bereitstellen

Die Bereitstellung für Staging oder Produktion ist noch einfacher, wenn Sie alles ordnungsgemäß gemäß der offiziellen Dokumentation konfiguriert haben. Es ist nur eine Befehlszeile entfernt (aus dem Ordner example.com/trellis/ ausgeführt):

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

Sie können Ihre Bereitstellung auch einfach rückgängig machen, führen Sie einfach Folgendes aus:

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

Tipps zum Einrichten Ihrer Entwicklungsumgebung unter Windows

Wenn Sie nach der Installation und Verwendung des Roots-Stacks, insbesondere Trellis, googeln, finden Sie viele Tutorials, die sich auf Linux oder MacOS konzentrieren, aber nur sehr wenige Informationen für Windows, wo Sie zwei Hauptprobleme feststellen werden: Ansible ist nicht verfügbar für Windows, und Vagrant ist normalerweise auf Windows-Rechnern extrem langsam.

Als ich ursprünglich über diesen Artikel nachdachte, schlug die offizielle Trellis-Dokumentation für Windows vor, Ansible innerhalb der virtuellen Vagrant-Maschine auszuführen, aber das war eine ziemlich hackige Art, Dinge zu tun, und es war nicht sehr zuverlässig.

Seitdem haben sie die Dokumentation mit den richtigen Anweisungen zum Einrichten von allem mit WSL (Windows Subsystem for Linux) aktualisiert, sodass Sie das Rad nicht neu erfinden und ein Tutorial darüber schreiben müssen. Es ist gut zu wissen, dass es drei Seiten mit detaillierten Schritt-für-Schritt-Anleitungen gibt, denen Sie folgen können, bevor Sie Trellis installieren: Windows Setup, Windows Setup: Sage und Windows Setup: Trellis.

Viel Spaß beim Codieren!