CSS-Tricks auf Flywheel

Ich habe zum ersten Mal von Flywheel durch ihr Produkt Local erfahren, eine native Anwendung für die Arbeit an WordPress-Websites. Wenn man sich umhört, was die Leute für diese Art von Arbeit verwenden, erhält man alle möglichen Antworten, aber sehr, sehr viele dringende Empfehlungen für Local. Ich gehöre jetzt auch dazu! Wir haben schließlich einen gesponserten Beitrag für Local gemacht, aber das basiert auf der Tatsache, dass jetzt 100% meiner lokalen WordPress-Entwicklungsarbeit damit erledigt wird und ich sehr zufrieden damit bin.

Jetzt habe ich den nächsten Schritt getan und alle meine Produktions-Websites zu Flywheel Hosting umgezogen!

Volle Offenlegung hier: Flywheel ist jetzt ein Sponsor von CSS-Tricks. Ich habe schon eine Weile gewünscht, mit ihnen zusammenzuarbeiten. Ich war schon dort, um sie in Omaha zu besuchen! (👋 an Jamie, Christi, Karissa und alle, mit denen ich dort zusammengearbeitet habe.) Ein Teil unseres Deals beinhaltet das Hosting. Aber ich war schon zuvor ein zahlender Kunde und Nutzer von Flywheel für einige Websites, und meine guten Erfahrungen dort haben dazu geführt, dass ich diese Sponsoring-Partnerschaft vorantreiben wollte! Es gab große Neuigkeiten, dass Flywheel von WP Engine übernommen wurde. Ich bin auch ein Fan von WP Engine, da sie ebenfalls ein Premium-WordPress-Hoster sind, der innovative Dinge im Hosting-Bereich getan hat. Daher bin ich optimistisch, dass gerade ein echtes WordPress-Hosting-Kraftpaket entsteht und meine Websites am richtigen Ort sind.

Die Entwicklung mit Local ist ein Kinderspiel

Es fühlt sich wie ein frischer Wind an, da das Betreiben aller Entwicklungsabhängigkeiten für WordPress schon immer ein wenig mühsam war. Manchmal funktioniert es gut, aber dann bricht etwas auf die undurchschaubarste Weise zusammen und es dauert ewig, bis es wieder läuft. Egal, Sie wissen, was ich meine. Mittlerweile benutze ich Local seit über einem Jahr und hatte fast keine Probleme damit.

Es gibt alle möglichen Funktionen, die es wert sind, hier angeschaut zu werden. Hier ist eine, die für größere Teams sehr nützlich sein dürfte. Angenommen, Sie haben ein Flywheel-Konto mit einer Reihe von Produktions-Websites darauf. Dann beginnt eine neue Person mit Ihnen zu arbeiten und hat ihren eigenen Computer. Sie verbinden Local mit Flywheel und können die Website herunterladen und sie zur Arbeit vorbereiten. Das ist ziemlich cool.

Local bindet Sie auch an nichts. Sie können Local für die lokale Entwicklung verwenden und buchstäblich nichts anderes. Local kann eine Website auch zu Flywheel Hosting hochladen, was ich als sehr nützlich empfand, insbesondere für die erste Bereitstellung einer neuen Website, aber Sie müssen das nicht tun, wenn Sie nicht wollen. Mehr über den Workflow werde ich unten besprechen.

Weitere Funktionen, die ich erwähnenswert finde

• Das Starten einer neuen Website dauert nur eine Sekunde. Ein kurzer Rundgang durch einen Assistenten, bei dem Ihnen einige Anmeldedaten abgefragt werden, der aber ansonsten intelligente, aber anpassbare Standardeinstellungen bietet.
• Der Umgang mit HTTPS lokal ist einfach. Mit einem Klick wird ein Zertifikat für Sie erstellt und lokal vertrauenswürdig gemacht.
• Sie können „Live Link“ aktivieren, das ngrok verwendet, um eine live, teilbare URL zu Ihrer lokalen Website zu erstellen. Großartig, um einem Kunden oder Kollegen vorübergehend etwas zu zeigen, ohne etwas verschieben zu müssen.
• Ein Klick, um die Datenbank in Sequel Pro zu öffnen, meinem kostenlosen Lieblingsdatenbanktool. Viel einfacher, als phpMyAdmin oder Ähnliches im Web zu starten, um von dort aus zu verwalten.

Flywheels Dashboard ist so übersichtlich

Ich liebe die einfache Benutzeroberfläche von Local und mir gefällt wirklich, wie sich das gleiche Design und der gleiche Geist in das Flywheel Hosting Dashboard übertragen.

Es gibt so viele Dinge, die das Dashboard einfach macht

• Sie benötigen ein SSL-Zertifikat? Klicken Sie auf ein paar Schaltflächen.
• Möchten Sie HTTPS erzwingen? Schalten Sie einen Schalter um.
• Möchten Sie die Website in Multisite konvertieren? Drücken Sie einen Knopf.
• Müssen Sie die Datenbank bearbeiten? Es gibt eine integrierte Benutzeroberfläche dafür.
• Wünschen Sie ein CDN? Schalten Sie ein Ding um.
• Müssen Sie einen Mitarbeiter für eine Website einladen? Machen Sie es.
• Benötigen Sie ein Backup? Es gibt welche, laden Sie es herunter oder stellen Sie es zu diesem Zeitpunkt wieder her.

Es ist ein großer Vorteil, wenn alles einfach ist und funktioniert. Es bedeutet, dass Sie keine Stunden damit verbringen, mit Werkzeugen zu kämpfen, und sie für Arbeiten nutzen können, die Sie voranbringen.

Workflow

Als ich meinen neuen CSS-Tricks-Workflow einrichtete, ließ ich Flywheel die Website für mich umziehen (danke, Leute!) (keine Sonderbehandlung, das machen sie für jeden).

Ich habe Local bereits, also ist mein lokaler Entwicklungsprozess derselbe. Aber ich musste meinen Bereitstellungs-Workflow für das neue Hosting aktualisieren. Local kann eine Website zu Flywheel Hosting hochladen, aber es komprimiert alles und lädt es hoch. Gut für die erste Bereitstellung, aber nicht ideal für kleine Änderungen wie 95% meiner Arbeit. Es gibt eine neue Funktion Local for Teams, die das, was sie MagicSync nennen, für die Bereitstellung verwendet, das nur geänderte Dateien bereitstellt. Das ist sehr cool, aber ich arbeite gerne mit einem Git-basierten System, bei dem letztendlich Merges nach Master die Bereitstellung der geänderten Dateien auslösen.

Jahrelang habe ich Beanstalk für Git-basierte Bereitstellung über SFTP verwendet. Ich benutze Beanstalk immer noch für viele Websites und halte es für eine großartige Wahl, aber Beanstalk hat die Einschränkung, dass das Git-Repository im Grunde ein privates Git-Repository ist, das von Beanstalk selbst gehostet wird.

Während dieses Wechsels musste ich die Wurzel des Repos ändern (mehr dazu gleich), also wollte ich ein neues Repo erstellen. Ich dachte mir, anstatt das auf Beanstalk zu machen, erstelle ich ein privates GitHub-Repo und richte von dort aus die Bereitstellung ein. Es gibt Dienste wie DeployHQ und DeployBot, die gut dafür funktionieren, aber ich habe mich für Buddy entschieden, das eine wirklich, wirklich schöne Benutzeroberfläche für die Verwaltung all dieser Dinge hat und viel mehr kann, als nur Bereitstellung, falls ich das letztendlich benötige.

Was das Repository selbst angeht, so habe ich bei meinen WordPress-Websites immer das gesamte Ding ab der Wurzel als Repository verwendet. Ich glaube, das ist einfach eine Gewohnheit/Komfortzone. Ich hatte einige Dateien im Stammverzeichnis, die ich zusammen mit allem anderen bereitstellen wollte, und das schien der einfachste Weg zu sein. In der WordPress-Welt wird das normalerweise nicht so gemacht. Es ist üblicher, dass der Ordner /wp-content/ die Wurzel des Repos ist, da dies im Wesentlichen die einzigen Dateien sind, die für Ihre Installation einzigartig sind. Ich kann mir Setups vorstellen, bei denen sogar einzelne Themes Repos sind und separat bereitgestellt werden.

Ich dachte, ich würde mich einer besser scopeden Bereitstellung anschließen, aber ich hatte auch keine große Wahl. Flywheel sperrt buchstäblich alle WordPress-Core-Dateien, sodass Ihr Bereitstellungssystem fehlschlägt, wenn es versucht, diese zu überschreiben. Das klingt für mich eigentlich großartig. Es gibt keinen Grund, warum jemand von außen diese Dateien ändern sollte, es ist am besten, dies als Angriffsvektor zu eliminieren. Flywheel selbst hält die WordPress-Version auf dem neuesten Stand. Also habe ich ein neues Repo mit /wp-content/ im Stammverzeichnis erstellt und es auf GitHub erstellt, einfach weil es ein so offensichtlicher Hub der Entwickleraktivität ist und meine Optionen für Bereitstellungsentscheidungen offen hält.

Aus ähnlichen Gründen habe ich während des Umzugs die DNS zu Cloudflare migriert. Das gibt mir die Kontrolle über die DNS von einem Drittanbieter, sodass ich Dinge einfach dort hinleiten kann, wo ich sie brauche. Eine Art Dezentralisierung der Zuständigkeiten. Das ist nicht jedermanns Sache, aber für mich bei diesem Projekt großartig. Während ich jetzt möglicherweise unter Cloudflare-Ausfällen leiden kann (selten, aber es ist gerade passiert), profitiere ich von all der zusätzlichen Sicherheit und Leistung, die Cloudflare bieten kann.

Der Workflow lautet also Local > GitHub > Buddy > Flywheel.

Und das Hosting ist Cloudflare > Flywheel mit Bildinhalten auf Cloudinary.

Und ich habe Backups von Flywheel und Jetpack/VaultPress.