Ein detaillierter Vergleich zwischen WordPress und Oktober CMS

Vor drei Monaten veröffentlichte WordPress endlich React-powered Gutenberg, um seine standardmäßige Inhaltsbearbeitungserfahrung zu unterstützen, was viele Menschen, die mit dieser Änderung nicht zufrieden sind, dazu veranlasste, nach Alternativen zu suchen. Einige Leute haben sich entschieden, WordPress vor Gutenberg zu forken und zu veröffentlichen, aber für mich macht das nicht viel Sinn, da es immer noch 15 Jahre technische Schulden trägt. Wenn ich eine Alternative zu WordPress finden würde, würde ich versuchen, nicht in der Vergangenheit stecken zu bleiben, und einen sauberen Schnitt durch eine ausgereifte Plattform anstreben, die auf modernen Grundlagen aufgebaut ist.

Dieser Artikel vergleicht WordPress mit dem wohl ähnlichen, aber moderneren Oktober-CMS zu einer breiten Palette von sowohl technischen als auch nicht-technischen Themen. Ziel des Artikels ist es nicht, die Leute davon zu überzeugen, bei WordPress zu bleiben oder auf das Oktober-CMS umzusteigen, sondern lediglich aufzuzeigen, welche Aspekte berücksichtigt werden müssen, bevor der Wechsel auf eine andere Plattform abgeschlossen wird. Derselbe Vergleich könnte (und sollte) auch mit anderen Plattformen durchgeführt werden, bevor eine vernünftige Entscheidung getroffen wird.

Warum Oktober CMS

Ich habe von October CMS erfahren, als es einen Preis gewonnen hat. Danach bin ich in den Recherchemodus gegangen und habe viel Zeit damit verbracht, tief in dieses CMS einzudringen – sowohl aus der Sicht eines Benutzers als auch eines Entwicklers. Als ich mir Kenntnisse über dieses CMS aneignete, war ich zuversichtlich, dass ich eine objektive Bewertung seiner Funktionen im Gegensatz zu WordPress abgeben konnte. Ich habe dieses CMS für den Vergleich gegenüber alternativen Optionen wie Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo und anderen aus folgenden Gründen gewählt:

• Ich weiß, wie dieses CMS funktioniert (im Gegensatz zu Grav);
• Es ist kostenlos und Open Source (im Gegensatz zu Statamic und ButterCMS);
• Mit fünf Jahren ist es „relativ“ neu (im Gegensatz zu Joomla und Drupal);
• Es ist ein dynamischer (nicht statischer) Inhaltsgenerator und basiert auf PHP (im Gegensatz zu Jekyll und Hugo).
  

Ich glaube, dass October CMS ein guter Kandidat ist, weil es auf Laravel basiert, einem Framework, das zum Erstellen moderner Anwendungen verwendet wird. Nach sieben Jahren seines Bestehens hat es positive Zustimmung von Entwicklern erhalten (wie durch seine beträchtliche Community und sein Ökosystem belegt) und markiert einen deutlichen Kontrast zur Codierung in WordPress, dh WordPress ist hauptsächlich prozedurale Programmierung, während Laravel entschieden objektorientierte Programmierung ist.

Was ist der Unterschied zwischen den beiden?

Im Folgenden werde ich WordPress und Oktober-CMS in verschiedenen Kategorien vergleichen und hervorheben, was meiner Meinung nach gut und was nicht so gut an ihnen ist. Ich werde jedoch keinen Gewinner auswählen, da dies nicht das Ziel des Artikels ist und es sowieso kein „bestes“ oder gar „besseres“ CMS gibt: Jedes CMS hat seine eigenen Stärken und Schwächen , die es schaffen mehr oder weniger passend für jede Aufgabe, jedes Projekt, jedes Unternehmen, jedes Team und alles andere. Darüber hinaus kann ein Projekt von der Verwendung von mehr als einem CMS profitieren, z. B. von der Verwendung eines CMS zum Verwalten und Bereitstellen von Daten und eines anderen CMS zum Rendern der Ansicht. Die Entscheidung, welches der Dutzenden von CMS für Ihre eigenen Bedürfnisse am besten geeignet ist, liegt ganz bei Ihnen.

Darüber hinaus konnte dieser Artikel niemals endgültige Schlussfolgerungen ziehen, da er sich nur mit einer Teilmenge aller Möglichkeiten befasst. Beispielsweise finden wir auch Online-Vergleiche wie „WordPress vs. Drupal vs. Joomla“, „WordPress vs. Static Site Generators“ und sogar „WordPress vs. Medium“. Da keiner dieser Artikel das vollständige Bild sieht, kann keiner dieser Vergleiche jemals schlüssig sein und sollte nicht als solcher behandelt werden.

Beginnen wir mit dem Vergleich.

Philosophie und Zielgruppe

Es ist kein Zufall, dass WordPress fast 1 von 3 Websites betreibt. Seit seiner Gründung war es bestrebt, äußerst benutzerfreundlich zu sein, und hat dies erfolgreich getan, indem Reibungsverluste für technische und nicht-technische Benutzer sowie für Menschen mit unterschiedlichem Hintergrund beseitigt wurden – unabhängig von ihrer Ausbildung und ihrem wirtschaftlichen Niveau. Der Gründer von WordPress, Matt Mullenweg, drückte aus, dass das Motto von WordPress „Democratize Publishing“ für die aktuelle Ära Folgendes bedeute:

„Menschen aller Hintergründe, Interessen und Fähigkeiten sollten auf Free-as-in-Speech-Software zugreifen können, die es ihnen ermöglicht, sich im offenen Web auszudrücken und ihre Inhalte zu besitzen.“

WordPress ist für jedermann einfach zu bedienen und seine Inklusivität zeigt sich auch auf der Entwicklungsseite: Es ist nicht ungewöhnlich, dass Menschen ohne Programmierhintergrund (wie Vermarkter, Designer, Blogger, Verkäufer und andere) an ihren WordPress-Installationen basteln und entwerfen ihre eigenen Themen und den erfolgreichen Start ihrer eigenen Websites. WordPress ist benutzerzentriert, und die Bedürfnisse der Benutzer übertrumpfen die der Entwickler. In WordPress ist der Benutzer König (oder Königin).

Im Gegensatz dazu richtet sich das Oktober-CMS eher an den Entwickler, wie es bereits bei seiner ersten Veröffentlichung ausdrücklich festgestellt wurde:

„Der Oktober macht eine kühne, aber offensichtliche Annahme: Kunden erstellen keine Websites, Entwickler tun dies. Die Rolle eines Kunden besteht darin, die Website zu verwalten und seine Geschäftsanforderungen zu übermitteln. Der Webentwickler und die Branche selbst dreht sich darum, diese Faktoren zu vermitteln.“

Nach den Worten seiner Gründer besteht die Mission des CMS darin, „zu beweisen, dass das Erstellen von Websites keine Raketenwissenschaft ist“. Oktober CMS basiert auf Laravel und kann behaupten, eine starke Grundlage aus wiederverwendbarem, modularem Code zu haben, der Anwendungen mit ordnungsgemäßer Architektur erstellen kann, die langfristig wartbar und vollständig anpassbar sind, ohne dass Hacks erforderlich sind – der Typ, der ernsthafte Programmierer anzieht. Das Oktober-CMS kann auch eine großartige Benutzererfahrung bieten, ist jedoch nicht so einfach oder reibungslos wie das von WordPress. Benutzern muss möglicherweise erklärt werden, wie sie bestimmte Funktionen verwenden, bevor sie sie verwenden können. Zum Beispiel hat das Einbetten eines Formulars aus einem Plugin eine lange Erklärung, wie es gemacht wird, was umständlicher ist als die selbstverständliche Drag-and-Drop-Funktionalität, die von mehreren Formular-Plugins in WordPress bereitgestellt wird.

Installation

WordPress ist berühmt für seine 5-minütige Installation, obwohl viele Leute darauf hinweisen, dass (unter Berücksichtigung aller Plugins, die installiert werden müssen) eine typische Installation 15 Minuten oder mehr dauert. Darüber hinaus bietet WordPress auch die Multisite-Funktion, mit der wir ein Netzwerk aus mehreren virtuellen Sites unter einer einzigen Installation erstellen können. Diese Funktion erleichtert einer Agentur die Verwaltung der Websites mehrerer Kunden – neben anderen Anwendungsfällen.

Die Installation von October CMS ist ebenfalls sehr einfach: Die Assistenteninstallation selbst dauert weniger als fünf Minuten, und wenn Sie sie über die Konsoleninstallation installieren, ist sie sogar noch schneller. Letzteres erreichen Sie, indem Sie einfach in das Zielverzeichnis navigieren und dann curl -s https://octobercms.com/api/installer | php ausführen curl -s https://octobercms.com/api/installer | php (danach müssen wir die Datenbankkonfiguration eingeben, sonst verhält es sich wie ein Flat-File-CMS). Sobald die Installation abgeschlossen ist, haben wir eine voll funktionsfähige Website, aber noch ziemlich leer (wenn Sie die Zeit hinzufügen, die zum Installieren und Konfigurieren der erforderlichen Plugins benötigt wird, können Sie damit rechnen, dass es mindestens 15 Minuten dauert).

Sicherheit

WordPress wurde vorgeworfen, aufgrund der hohen Anzahl von Sicherheitslücken, die ständig gefunden werden, unsicher zu sein. Dies zwingt Benutzer, die Software für das CMS und alle installierten Plugins immer auf dem neuesten Stand zu halten, um Sicherheitslücken zu vermeiden. Zu den Hauptproblemen gehört die Unterstützung von WordPress für ältere PHP-Versionen, die von der PHP-Entwicklungsgemeinschaft nicht mehr unterstützt werden (WordPress unterstützt derzeit PHP 5.2.4, während die neueste vollständig unterstützte PHP-Version 5.6 ist). Dieses Problem sollte jedoch im April 2019 behoben sein, wenn WordPress offiziell mit der Unterstützung der PHP-Versionen 5.6 und höher beginnt.

Ansonsten ist WordPress nicht unbedingt an sich unsicher, sondern wegen seiner hohen Popularität, die es zu einem primären Angriffsziel für Hacker macht. Dies spielt jedoch in beide Richtungen: Die Allgegenwärtigkeit von WordPress bedeutet, dass das Sicherheitsteam seine Arbeit wirklich ernst nehmen muss, indem es ständig nach Exploits sucht und diese so schnell wie möglich behebt, da sonst bis zu einem Drittel des Webs gefährdet sind. Die Einsätze sind einfach zu hoch.

Oktober CMS hingegen hat nicht den Ruf, unsicher zu sein. Da es jedoch ungefähr 27.000 Live-Sites gibt, die den Oktober verwenden, verglichen mit den Millionen von WordPress, können wir die beiden nicht zu den gleichen Bedingungen beurteilen. Nichtsdestotrotz nimmt das Team hinter October CMS die Sicherheit ernst, wie die Eingabeaufforderung der Wizard-Installation zur Eingabe der CMS-Backend-URL zeigt, die standardmäßig auf /backend gesetzt ist, aber auf etwas anderes geändert werden kann, um es Hackern zu erschweren, auf die Website abzuzielen . Im Gegensatz dazu muss das Ändern der Anmelde- und Backend-URLs von WordPress von /wp-login.php bzw. /wp-admin auf etwas anderes über ein Plugin erfolgen. Darüber hinaus kann das Oktober-CMS als Flat-File-CMS (dh ohne Datenbank) fungieren und datenbankbezogene Schwachstellen wie SQL-Injection vermeiden.

Technologie-Stack

Sowohl WordPress als auch Oktober-CMS laufen auf dem traditionellen LAMP-Stack: Linux, Apache, MySQL und PHP. (Allerdings ist nur PHP festgelegt: Wir können auch Windows, Nginx, MariaDB und andere verwenden.) Das Oktober-CMS kann sich auch als Flat-File-CMS verhalten, das heißt, es kommt ohne Datenbank aus, allerdings auf Kosten des Verzichts Viele Funktionalitäten (wie Blogbeiträge und Benutzer) Die einzige garantierte Funktionalität sind Seiten, die als Grundeinheit für die Erstellung und Veröffentlichung von Inhalten gelten und als Kernfunktion ausgeliefert werden.

In Bezug auf den Sprachstapel basieren Websites, die sowohl mit WordPress als auch mit Oktober-CMS erstellt wurden, auf HTML, CSS und JavaScript (beachten Sie, dass PHP zum Generieren des HTML verwendet wird). October CMS erleichtert auch die Verwendung von LESS- und SASS-Dateien.

Programmierparadigma

WordPress folgt einem funktionalen Programmierparadigma, das auf der Berechnung von Berechnungen durch Aufrufen von Funktionen ohne Anwendungsstatus basiert. Auch wenn WordPress-Entwickler sich nicht an die funktionale Programmierung halten müssen (z. B. zum Codieren ihrer Themen und Plugins), erbt der WordPress-Kerncode dieses Paradigma von 15 Jahren der Wahrung der Abwärtskompatibilität, die eine der Säulen des Erfolgs von WordPress war was aber die unbeabsichtigte Folge hat, technische Schulden anzuhäufen.

Auf der anderen Seite folgt October CMS einem imperativen Programmierparadigma, das auf der Berechnung von Berechnungen durch Manipulation des Zustands von Objekten basiert. Oktober CMS setzt auf Laravel auf, einem Web-Framework, das vollständig auf objektorientierten Programmierprinzipien basiert, die die Erstellung modularer Anwendungen auf der Grundlage von Konzepten wie dem Model-View-Controller ermöglichen, um die Benutzeroberfläche von den Anwendungsdaten zu entkoppeln, Dependency Injection Konfigurieren Sie Klassenabhängigkeiten und das Prinzip der Schnittstellentrennung, um unter anderem die vom Framework bereitgestellten Kerndienste zu definieren.

Haken/Ereignisse

Die Programmierung in WordPress könnte als HDD bezeichnet werden, was für „Hook-Driven Development“ steht. Ein Hook ist ein Mechanismus, der das Ändern eines Standardverhaltens oder -werts ermöglicht und es anderem Code ermöglicht, verwandte Funktionen auszuführen. Hooks werden durch „Aktionen“ ausgelöst, die das Ausführen zusätzlicher Funktionen ermöglichen, und „Filter“, die das Ändern von Werten ermöglichen.

Hooks, die in der gesamten WordPress-Codebasis weit verbreitet sind, sind eines der Konzepte, die mir beim Programmieren in WordPress am besten gefallen. Sie ermöglichen Plugins, auf saubere Weise mit anderen Plugins (oder mit einem Kern oder Thema) zu interagieren, und bieten eine grundlegende Unterstützung der aspektorientierten Programmierung.

Die gute Nachricht ist, dass Laravel (und damit auch das CMS von October) auch das Konzept der Hooks unterstützt, das „Events“ genannt wird. Ereignisse bieten eine einfache Beobachterimplementierung, die es dem Code ermöglicht, Ereignisse, die in der Anwendung auftreten, zu abonnieren und abzuhören und bei Bedarf zu reagieren. Ereignisse ermöglichen es, eine komplexe Funktionalität in Komponenten aufzuteilen, die unabhängig voneinander installiert werden können, aber dennoch zusammenarbeiten, wodurch modulare Anwendungen erstellt werden können.

Abhängigkeit von JavaScript-Bibliotheken

Die neueste Version von WordPress enthält React-powered Gutenberg für die standardmäßige Inhaltserstellung. Daher setzt die WordPress-Entwicklung mittlerweile weitgehend auf JavaScript (vorwiegend über React), auch wenn es auch möglich ist, andere Frameworks oder Bibliotheken zu verwenden (wie etwa Elementor Blocks for Gutenberg, das auf Marionette basiert). Darüber hinaus stützt sich WordPress immer noch auf Backbone.js (für den Media Manager) und jQuery (Legacy-Code). Wir können jedoch davon ausgehen, dass die Abhängigkeit von diesen Bibliotheken nachlässt, wenn Gutenberg als neue Norm konsolidiert wird.

Das Oktober-CMS ist von jQuery abhängig, mit dem es sein optionales AJAX-Framework implementiert, um Daten vom Server zu laden, ohne dass eine Browserseitenaktualisierung erforderlich ist.

Seiten, Themes und Plugins

Sowohl WordPress als auch October CMS behandeln eine Seite als grundlegende Einheit zum Erstellen und Veröffentlichen von Inhalten (im Fall von WordPress zusätzlich zum Beitrag), unterstützen das Ändern des Aussehens und Verhaltens der Website durch Themen und ermöglichen das Installieren und Erweitern der Funktionalitäten der Website durch Plugins . Obwohl die Konzepte in beiden CMS gleich sind, gibt es einige Unterschiede in der Implementierung, die zu etwas unterschiedlichem Verhalten führen.

In WordPress werden Seiten als Inhalt definiert und in der Datenbank gespeichert. Dadurch können Seiteninhalte nur über das CMS erstellt werden (z. B. im Dashboard-Bereich), und der Wechsel von einem Thema zu einem anderen führt nicht dazu, dass eine vorhandene Seite nicht mehr verfügbar ist. Dies erzeugt ein insgesamt reibungsloses Erlebnis.

Im Oktober-CMS hingegen sind Seiten statische Dateien, die im Themenverzeichnis gespeichert sind. Positiv an dieser architektonischen Entscheidung ist, dass Seiteninhalte aus einer externen Anwendung wie Texteditoren wie Sublime oder Visual Studio Code erstellt werden können. Auf der negativen Seite ist es beim Wechseln von einem Thema zu einem anderen erforderlich, die Seiten manuell neu zu erstellen oder vom aktuellen auf das neue Thema zu kopieren, da sie sonst verschwinden.

Bemerkenswert ist, dass das Oktober-CMS das Routing durch Seiten auflöst, daher werden Seiten nicht nur als Container für Inhalte, sondern auch für Funktionalität verwendet. Zum Beispiel ist ein Plugin für das Bloggen von einer Seite abhängig, um die Liste der Blog-Beiträge unter einer ausgewählten URL anzuzeigen, eine andere Seite, um einen einzelnen Blog-Beitrag unter einer anderen ausgewählten URL anzuzeigen, und so weiter. Wenn eine dieser Seiten verschwindet, ist die zugehörige Funktionalität des Plugins nicht mehr verfügbar, und diese URL erzeugt einen 404. Daher sind CMS-Designs und Plugins im Oktober nicht vollständig entkoppelt, und das Wechseln von Designs muss sorgfältig erfolgen.

Kern- vs. Plugin-Funktionalität

WordPress versucht, eine minimale Kernfunktionalität bereitzustellen, die durch Plugins erweitert wird. WordPress verlässt sich auf die „ ⁸⁰ ⁄ ₂₀ -Regel“, um zu entscheiden, ob einige Funktionen in seine Kernerfahrung aufgenommen werden sollen oder nicht. Wenn es 80% der User nützt geht es rein, ansonsten gehört es ins Plugin-Land. Beim Hinzufügen von Plugins zu einer Website können diese zu einer Aufblähung führen, wenn zu viele Plugins installiert sind. Plugins arbeiten möglicherweise auch nicht gut miteinander zusammen oder führen ähnlichen Code aus oder laden ähnliche Assets, was zu einer suboptimalen Leistung führt. Während das Starten einer WordPress-Site relativ einfach ist, ist die allgemeine Wartung und die Aufrechterhaltung eines optimalen und leistungsfähigen Zustands beim Hinzufügen neuer Funktionen eine größere Herausforderung.

Ebenso versucht auch das Oktober-CMS, eine minimale Kernfunktionalität zu liefern, aber auf Steroiden: Die einzige garantierte Funktionalität ist das Erstellen und Veröffentlichen von Seiten, und für alles andere müssen wir das eine oder andere Plugin installieren, das sich wie folgt ausdrückt:

„Alles, was Sie brauchen, und nichts, was Sie nicht brauchen.“

Das Ziel ist klar: Die meisten einfachen Seiten bestehen nur aus Seiten, möglicherweise ohne Blogbeiträge, Benutzer oder Login-Bereich. Warum also sollte die Anwendung Ressourcen dafür laden, wenn sie nicht benötigt werden? Als Konsequenz werden Funktionalitäten für das Bloggen, die Benutzerverwaltung, die Übersetzung und einige andere über das Plugin-Verzeichnis freigegeben.

October CMS enthält auch bestimmte Funktionen in seinem Kern, die (auch wenn sie nicht immer benötigt werden) die Anwendung erheblich verbessern können. Beispielsweise bietet es sofort einsatzbereite Unterstützung zum Hochladen von Mediendateien auf Amazon S3 und greift über das Rackspace CDN darauf zu. Es enthält auch einen Medienmanager, der meistens über Plugins verwendet wird, z. B. um Bilder in einen Blogbeitrag einzufügen. (Seiten können auch den Media Manager verwenden, um Mediendateien einzubetten, das CMS wird jedoch auch mit einem Abschnitt „Assets“ geliefert, um Mediendateien für diese hochzuladen, was geeigneter erscheint.)

Ich glaube, dass die Eigensinnigkeit von October es uns perfekt ermöglichen kann, eine Anwendung zu erstellen, die so schlank wie möglich ist – hauptsächlich für einfache Websites. Es kann jedoch auch nach hinten losgehen und ein Aufblähen fördern, da die Grenze dessen, was benötigt wird und was nicht, willkürlich ist und vom CMS nur schwer im Voraus festgelegt werden kann. Diese Schwierigkeit wird deutlich, wenn man das Konzept eines „Benutzers“ betrachtet: In WordPress gehören Website-Benutzer und Website-Administratoren derselben Benutzerentität an (und durch Rollen und Privilegien können wir einen Benutzer zu einem Administrator machen). Im Oktober-CMS werden diese beiden separat implementiert und liefern im Kern die Implementierung für den Website-Administrator, der sich im Backend-Bereich anmelden und die Einstellungen ändern kann, und über ein Plugin die Implementierung für den Website-Benutzer. Diese beiden Arten von Benutzern haben einen unterschiedlichen Anmeldeprozess und eine unterschiedliche Datenbanktabelle zum Speichern ihrer Daten, wodurch wohl das DRY-Prinzip (Don't Repeat Yourself) verletzt wird.

Dieses Problem tritt nicht nur hinsichtlich des Verhaltens einer Entität auf, sondern auch hinsichtlich der Datenfelder, die sie enthalten muss. Sollen beispielsweise die Benutzerdatenfelder der Website vordefiniert sein? Ist ein Telefonfeld erforderlich? Was ist mit einem Instagram-URL-Feld, wenn man bedenkt, dass Instagram erst vor kurzem irgendwie cool geworden ist? Aber sollten wir beim Erstellen einer professionellen Website nicht stattdessen ein LinkedIn-URL-Feld verwenden? Diese Entscheidungen hängen eindeutig von der Anwendung ab und können weder vom CMS noch vom Plugin entschieden werden.

Das Oktober-CMS-Plugin mit dem Namen User implementiert Benutzer, aber ohne Benutzerfeld, und zusätzlich fügt das Plugin User Plus mehrere willkürliche Benutzerfelder hinzu, die möglicherweise nicht ausreichen, also fügt das Plugin User Plus+ noch andere Benutzerfelder hinzu. Wann, wo und wie stoppen wir diesen Prozess?

Ein weiteres Problem besteht darin, dass es keinen Platz gibt, um einer Entität neue Fähigkeiten hinzuzufügen, was zur Schaffung einer anderen, extrem ähnlichen Entität führt, nur um diese erforderlichen Fähigkeiten zu unterstützen. Zum Beispiel wird Oktober CMS mit Seiten ausgeliefert und ermöglicht es, „statische Seiten“ über ein Plugin zu erstellen. Ihre Natur ist dieselbe: Sowohl Seiten als auch statische Seiten werden als statische Dateien gespeichert. Der einzige Unterschied zwischen ihnen (soweit ich das beurteilen kann) besteht darin, dass statische Seiten mit einem visuellen Editor anstelle des HTML-Editors bearbeitet und zu Menüs hinzugefügt werden können. Meiner Meinung nach könnten nur strukturelle Unterschiede, wie z. B. das Speichern einer Entität als statische Datei und der anderen in der Datenbank, das Erstellen einer zweiten Entität für eine Seite rechtfertigen (dafür gibt es einen Pull-Request), aber einfach Features, wie es derzeit der Fall ist, stellt es eine Entwicklungsaufblähung dar.

Zusammenfassend lässt sich sagen, dass eine gut implementierte Oktober-CMS-Anwendung sehr schlank und effizient sein kann (z. B. indem die Datenbank entfernt wird, wenn sie nicht benötigt wird), aber im Gegenteil kann sie auch unnötig aufgebläht werden, was Entwickler dazu zwingt, mehrere Lösungen für ähnliche Entitäten zu implementieren, und die das können sehr verwirrend sein („Soll ich eine Seite oder eine statische Seite verwenden?“). Da weder WordPress noch Oktober-CMS eine perfekte Lösung zum Entfernen von Aufblähen gefunden haben, müssen wir beide Anwendungsarchitekturen sorgfältig entwerfen, um spätere Probleme zu vermeiden.

Inhaltserstellung

Gutenberg leistet zwei wichtige Beiträge zu WordPress: Es verwendet Komponenten als Einheit zum Erstellen von Websites (was mehrere Vorteile gegenüber dem Codieren von HTML-Blobs bietet) und es führt eine Entität namens „Block“ ein, die nach Abschluss von Gutenberg Phase 2 (vermutlich in 2019) bietet eine einheitliche Möglichkeit, Inhalte in die Website zu integrieren, und ermöglicht so eine einfachere Benutzererfahrung im Gegensatz zum chaotischeren Prozess des Hinzufügens von Inhalten über Shortcodes, TinyMCE-Schaltflächen, Menüs, Widgets und andere.

Da Gutenberg-Blöcke statisches HTML als Teil des Blog-Beitrags erzeugen und speichern können, führt die Installation vieler Gutenberg-Blöcke nicht unbedingt zu einer Aufblähung der Website auf der Benutzerseite, sondern kann auf die Admin-Seite beschränkt bleiben. Daher kann Gutenberg wohl als guter Ansatz angesehen werden, um Websites auf modulare Weise zu erstellen, mit einer einfachen, aber leistungsstarken Benutzererfahrung zum Erstellen von Inhalten. Der möglicherweise größte Nachteil ist die (unvermeidliche, aber nicht einfache) Anforderung, React zu lernen, dessen Lernkurve ziemlich steil ist.

Wenn React-Komponenten die Grundeinheit für die Erstellung von Inhalten in WordPress sind, basiert das Oktober-CMS auf der Prämisse, dass die Kenntnis des guten alten HTML zum Erstellen von Websites ausreicht. Tatsächlich wird uns beim Erstellen einer Seite einfach ein HTML (Markup)-Editor präsentiert:

Wenn die Seite ausschließlich statisches HTML wäre, wäre kein CMS erforderlich. Stattdessen werden Oktober-CMS-Seiten mit Twig-Vorlagen geschrieben, die zu einfachem, optimiertem PHP-Code kompiliert werden. Sie können ein Layout auswählen, um das Gerüst der Seite einzuschließen (dh sich wiederholende Elemente wie Kopfzeile, Fußzeile usw.), können Platzhalter implementieren, die im Layout definiert sind, damit die Seite den Inhalt anpassen kann, und einschließen können Partials, bei denen es sich um wiederverwendbare Codeabschnitte handelt. Darüber hinaus können Seiten Inhaltsblöcke enthalten, bei denen es sich entweder um Text-, HTML- oder Markdown-Dateien handelt, die eigenständig bearbeitet werden können und an die Komponenten angehängt werden können, bei denen es sich um Funktionalitäten handelt, die durch Plugins implementiert werden. Und schließlich, wenn HTML nicht ausreicht und wir dynamischen Code produzieren müssen, können wir PHP-Funktionen hinzufügen.

Der Editor dreht sich alles um HTML. Es gibt keinen TinyMCE- textarea zum visuellen Hinzufügen von Inhalten – zumindest nicht durch die Standarderfahrung (diese Funktionalität gehört zum Plugin-Land). Daher könnten HTML-Kenntnisse als ein Muss für die Verwendung von October CMS angesehen werden. Darüber hinaus sind die vielen unterschiedlichen Eingaben zum Erstellen von Inhalten (Seiten, Layouts, Platzhalter, Partials, Inhaltsblöcke, Komponenten und PHP-Funktionen) zwar sehr effektiv, aber sicherlich nicht so einfach wie über die einheitliche Blockschnittstelle von WordPress. Es kann sogar noch komplexer werden, da auch andere Elemente hinzugefügt werden können (wie statische Seiten und Menüs und Snippets) und einige von ihnen, wie Seiten und statische Seiten, anscheinend die gleiche Funktionalität bieten, was es verwirrend macht, wann zu entscheiden benutze das eine oder andere.

Infolgedessen wage ich zu sagen, dass, obwohl so ziemlich jeder eine WordPress-Site von der Administratorseite aus verwenden kann, das Oktober-CMS eher entwicklerfreundlich als nicht technisch benutzerfreundlich ist, sodass Programmierer es vielleicht als Freude empfinden, es zu verwenden, aber bestimmte andere Rollen (Vermarkter, Vertriebsmitarbeiter und dergleichen) finden es möglicherweise nicht intuitiv.

Medien-Manager

Sowohl WordPress als auch Oktober CMS werden mit einem Medienmanager ausgeliefert, der das mühelose Hinzufügen von Mediendateien zur Website ermöglicht, das gleichzeitige Hinzufügen mehrerer Dateien über eine Drag-and-Drop-Oberfläche unterstützt und die Bilder im Inhaltsbereich anzeigt. Sie sehen ähnlich aus und verhalten sich ähnlich; Die einzigen nennenswerten Unterschiede, die ich gefunden habe, sind, dass der Media Manager von WordPress das Einbetten von Bildergalerien erlaubt und der Media Manager von Oktober es ermöglicht, manuell eine Ordnerstruktur zu erstellen, in der die hochgeladenen Dateien abgelegt werden.

Seit der Einführung von Gutenberg wurden die Medienfunktionen von WordPress jedoch stark verbessert, sodass Videos, Bilder und Fotogalerien an Ort und Stelle eingebettet werden können, im Vergleich zu einem TinyMCE- textarea (der nur eine nicht genaue Version dessen liefert, wie er aussehen wird). auf der Website) und das Freischalten leistungsstarker und dennoch benutzerfreundlicher Funktionen, wie in diesem Video gezeigt.

Internationalisierung

Der WordPress-Kern verwendet gettext , um die Übersetzung von Themes und Plugins zu ermöglichen. Ausgehend von einer .pot -Datei, die alle zu übersetzenden Zeichenfolgen enthält, müssen wir eine .po -Datei erstellen, die ihre Übersetzung in die entsprechende Sprache/Gebietsschema enthält, und diese Datei wird dann zu einer binären .mo -Datei kompiliert, die für eine schnelle Übersetzungsextraktion geeignet ist. Zu den Tools zur Durchführung dieser Aufgaben gehören GlotPress (online) und Poedit (herunterladbare Anwendung). Praktischerweise funktioniert dieser Mechanismus auch für die clientseitige Lokalisierung für Gutenberg.

WordPress liefert derzeit keine Kernlösung zum Übersetzen von Inhalten aus und wird dies auch erst in Phase 4 von Gutenberg tun (geplant für das Jahr 2020+). Bis dahin wird diese Funktionalität von Plugins bereitgestellt, die verschiedene Strategien zum Speichern und Verwalten der übersetzten Inhalte bieten. Während Plugins wie Polylang und INNER JOIN beispielsweise jede Übersetzung in einer eigenen Zeile aus einer benutzerdefinierten Datenbanktabelle speichern (was sauber ist, da Inhalte nicht miteinander vermischt werden, aber langsamer, da beim Abfragen der Datenbank), Plugin qTranslate X speichert alle Übersetzungen in demselben Feld aus der ursprünglichen Datenbanktabelle (schneller für die Abfrage der Daten, aber gemischte Inhalte können auf der Website zu Zerstörungen führen, wenn das Plugin deaktiviert wird). Daher können wir uns umsehen und die für unsere Bedürfnisse am besten geeignete Strategie auswählen.

October CMS liefert die mehrsprachige Funktionalität nicht über seinen Kern aus, sondern als vom October CMS-Team erstelltes Plugin, das eine fehlerfreie Integration in das System garantiert. Aus funktionaler Sicht hält dieses Plugin, was es verspricht. Aus Entwicklungssicht ist es nicht ganz optimal, wie dieses Plugin eigentlich funktioniert. In WordPress ist eine Seite einfach ein Beitrag mit dem Beitragstyp „Seite“ und es gibt einen einzigen Übersetzungsmechanismus dafür, aber im Oktober-CMS gibt es die Entitäten „Seite“, „statische Seite“ und „Blogbeitrag“ und obwohl ziemlich ähnlich, sie benötigen drei verschiedene Implementierungen für ihre Übersetzungen! Dann kann der Inhalt einer „Seite“ Nachrichtencodes enthalten (z. B. Codes namens nav.content , header.title usw.), von denen jeder seine Übersetzungen für alle Gebietsschemata als serialisiertes JSON-Objekt in der Datenbanktabelle rainlab_translate_messages . Der Inhalt einer „statischen Seite“ wird pro Gebietsschema in einer neuen statischen Datei erstellt, jedoch werden alle übersetzten URLs für alle Gebietsschemata nicht in ihrer entsprechenden Datei, sondern in der Datei der Standardsprache gespeichert. Der Inhalt für den „Blogbeitrag“ wird als serialisiertes JSON-Objekt mit einer Zeile pro Gebietsschema in der Datenbanktabelle rainlab_translate_attributes gespeichert und die übersetzte URL wird mit einer Zeile pro Gebietsschema in der Datenbanktabelle rainlab_translate_indexes . Ich weiß nicht, ob diese Komplexität darauf zurückzuführen ist, wie das Plugin implementiert wurde, oder ob es auf die Architektur von October CMS zurückzuführen ist. Was auch immer der Fall ist, dies ist ein weiteres Beispiel für unerwünschtes Aufblähen auf der Entwicklungsseite.

Plugin-Verwaltung

Sowohl WordPress als auch October CMS bieten einen ausgeklügelten Plugin-Manager, der es ermöglicht, nach Plugins zu suchen, neue Plugins zu installieren und aktuell installierte Plugins auf ihre neueste Version zu aktualisieren – alles innerhalb des Backends.

Abhängigkeitsverwaltung

October CMS verwendet Composer als Paketmanager der Wahl, der es Plugins ermöglicht, ihre Abhängigkeiten bei der Installation herunterzuladen und zu installieren, wodurch ein schmerzloses Erlebnis geboten wird.

WordPress hingegen hat Composer (oder einen anderen PHP-Abhängigkeitsmanager) nicht offiziell übernommen, da sich die Community nicht einigen kann, ob WordPress eine Site oder eine Site-Abhängigkeit ist. Wenn sie also Composer für ihre Projekte benötigen, müssen Entwickler es selbst hinzufügen. Mit dem Wechsel zu Gutenberg wurde npm zum bevorzugten JavaScript-Abhängigkeitsmanager, auf dem ein beliebtes Entwickler-Toolkit basiert, und die clientseitigen Bibliotheken werden kontinuierlich als autonome Pakete in der npm-Registrierung veröffentlicht.

Interaktion mit der Datenbank

WordPress bietet Funktionen zum Abrufen von Datenbankdaten (z. B. get_posts ) und zum Speichern (z. B. wp_insert_post und wp_update_post ). Beim Abrufen von Daten können wir Parameter übergeben, um die Ergebnisse zu filtern, einzuschränken und zu ordnen, um anzugeben, ob das Ergebnis als Instanz einer Klasse oder als Array von Eigenschaften und anderen übergeben werden muss. Wenn die Funktion unsere Anforderungen nicht vollständig erfüllt (z. B. wenn wir einen INNER JOIN mit einer benutzerdefinierten Tabelle ausführen müssen), können wir die Datenbank direkt über die globale Variable $wpdb . Beim Erstellen eines Plugins mit einem benutzerdefinierten Beitragstyp führt der Code höchstwahrscheinlich benutzerdefinierte SQL-Abfragen aus, um Daten abzurufen und/oder in benutzerdefinierten Tabellen zu speichern. Zusammenfassend versucht WordPress, den Zugriff auf die Datenbank in der ersten Stufe über generische Funktionen und in der zweiten Stufe durch Low-Level-Zugriff auf die Datenbank bereitzustellen.

October CMS verfolgt einen anderen Ansatz: Anstatt sich sofort mit der Datenbank zu verbinden, kann die Anwendung Laravels Eloquent ORM verwenden, um auf Datenbankdaten durch Instanzen von Klassen namens Models zuzugreifen und diese zu manipulieren, wodurch die Interaktion mit der Datenbank ebenfalls auf objektorientierter Programmierung basiert . Es ist ein High-Level-Zugriff; Ein Plugin kann einfach durch Befolgen der Regeln zum Erstellen von Tabellen und Einrichten von Beziehungen zwischen Entitäten Daten abrufen und/oder speichern, ohne eine Zeile SQL zu schreiben. Der folgende Code ruft beispielsweise ein Objekt aus der Datenbank über model Flight ab, ändert eine Eigenschaft und speichert sie erneut:

 $flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();

Aktualisieren des Datenmodells

Ein weiterer Grund für den Erfolg von WordPress (zusätzlich dazu, dass es die Abwärtskompatibilität nicht beeinträchtigt) war seine Datenbankarchitektur, die so konzipiert wurde, dass Anwendungen im Laufe der Zeit wachsen können. Dieses Ziel wird durch „Meta“-Eigenschaften erreicht, dh Eigenschaften, die einem Datenbankobjekt jederzeit hinzugefügt werden können. Diese Eigenschaften werden nicht in einer Spalte aus der entsprechenden Entitätstabelle gespeichert (entweder wp_posts , wp_users , wp_comments oder wp_terms ), sondern als Zeile in der entsprechenden „Meta“-Tabelle ( wp_postmeta , wp_usermeta , wp_commentmeta oder wp_termmeta ) und durch ein INNER JOIN abgerufen INNER JOIN . Obwohl das Abrufen dieser Metawerte langsamer ist, bieten sie daher unbegrenzte Flexibilität, und das Datenmodell der Anwendung muss selten von Grund auf neu aufgebaut werden, um einige neue Funktionen zu implementieren.

Das Oktober-CMS verwendet keine Meta-Eigenschaften, sondern kann mehrere beliebige Werte, die nicht direkt als Spalten in den Datenbanktabellen abgebildet werden, als serialisiertes JSON-Objekt speichern. Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application's database schema, October CMS relies on Laravel's Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (eg when installing a plugin's new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, ie treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).

A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/... ; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.

Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in several projects in the wild.

On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn't offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (eg accessing a property from a column is faster than from a row in another table through an INNER JOIN , which is the case with WordPress' meta properties).

CLI Support

Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel's Artisan. In addition to Laravel's commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.

Managed Hosting

It is not a problem finding a managed hosting provider for a WordPress site: given WordPress' market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).

Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven't found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.

Marketplace, Ecosystem And Cost

WordPress' commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.

Being relatively new (only five years so far), OctoberCMS certainly doesn't enjoy anything near WordPress' marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.

Hence, even though 600+ plugins doesn't sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October's founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)

In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October's better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.

Gemeinschaft

Being a part of and having access, WordPress' community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.

Furthermore, the WordPress community is real and tangible: it doesn't exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it's also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.

October CMS' community is nothing near in size or diversity as WordPress', even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October's founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.

Maintainers And Governance

Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?

WordPress betreibt ein Drittel aller Websites weltweit und es mangelt nicht an Interessengruppen, die zur Software beitragen. daher brauchen wir nicht zu befürchten, dass die Software verfällt. WordPress führt jedoch interne Überlegungen zu seinem Governance-Modell durch, wobei viele Mitglieder der Community zum Ausdruck bringen, dass Entscheidungen über die Ausrichtung von WordPress einseitig von Automattic, dem Unternehmen, das WordPress.com betreibt, getroffen werden. Im Mittelpunkt dieser Wahrnehmung stand die Entscheidung, Gutenberg zu starten, mit der viele Mitglieder nicht einverstanden waren und die während der Entwicklung und Veröffentlichung unter einem Mangel an angemessener Kommunikation durch die Projektleiter litt. Infolgedessen stellen viele Community-Mitglieder die Rolle des „gutartigen Diktators“ in Frage, die dem Gründer von WordPress und CEO von Automattic, Matt Mullenweg, in der Vergangenheit eingeräumt wurde, und untersuchen verschiedene Governance-Modelle, um ein geeigneteres für die Zukunft von WordPress zu finden. Es ist noch abzuwarten, ob diese Suche zu einem Ergebnis führt oder ob der Status quo fortbesteht.

Entscheidungen über die Ausrichtung von October CMS werden hauptsächlich von den Gründern Alexey Bobkov und Samuel Georges sowie dem Entwickler und Community-Manager Luke Towers getroffen, die das Projekt am Laufen halten. October CMS hat noch nicht den Luxus, ein Governance-Problem zu haben: Derzeit beschäftigt es sich damit, das Projekt nachhaltig zu machen, indem Einnahmen für die Betreuer der Kernsoftware generiert werden.

Dokumentation

Die WordPress-Dokumentation auf ihrer eigenen Seite ist nicht sehr umfassend, aber sie macht den Job ziemlich gut. Wenn man jedoch die gesamte Dokumentation über WordPress aus allen Quellen berücksichtigt, wie z. B. allgemeine Websites (Smashing Magazine, CSS-Tricks und viele andere), spezialisierte Websites (WPShout, WPBeginner und viele andere), persönliche Blogs, Online-Kurse, usw. gibt es praktisch keinen Aspekt im Umgang mit WordPress, der nicht bereits behandelt wurde.

October CMS erfreut sich an den vielen Kursen, Tutorials oder Blog-Posts von Drittanbietern nicht so sehr wie WordPress, aber die Dokumentation auf seiner Website ist ziemlich umfassend und sicherlich genug, um mit dem Programmieren zu beginnen. Oktober-Gründer fügen außerdem regelmäßig neue Dokumentationen durch Tutorials hinzu. Ein Aspekt, der mir persönlich gefallen hat, ist die Duplizierung von Laravels Dokumentation in die October-Dokumentation für alles Relevante, sodass der Leser die Lücken nicht selbst füllen muss und erraten muss, was die Domäne von October und was die von Laravel ist. Dies ist jedoch nicht 100% perfekt. Die Oktober-Dokumentation verwendet aus Laravel stammende Begriffe wie Middleware, Servicecontainer, Fassaden und Verträge, ohne diese hinreichend zu erläutern. Dann kann es hilfreich sein, die Dokumentation von Laravel im Voraus zu lesen (glücklicherweise ist Laravels Dokumentation ausgesprochen umfassend, und Laravels Screencasts, Laracasts, sind eine weitere großartige Lernquelle, nicht nur in Bezug auf Laravel, sondern auf die Webentwicklung im Allgemeinen).

Fazit

Ich wollte herausfinden, welche Funktionen für Entwickler verlockend sein könnten, die nach Alternativen zu WordPress suchen, indem ich WordPress mit einem ähnlichen CMS vergleiche, das ich als kostenlos und Open Source definiert habe, auf PHP basiert und dynamische Inhalte produziert, und die Unterstützung einer Community genieße . Von den CMS, die diese Bedingungen erfüllen, habe ich das Oktober-CMS für den Vergleich ausgewählt, weil ich mich darüber informiert habe und weil ich seinen sauberen und modularen Codierungsansatz wie von Laravel geschätzt habe, der eine frische und moderne Perspektive für Baustellen bieten könnte.

Dieser Artikel wollte keinen Gewinner küren, sondern lediglich analysieren, wann es sinnvoll ist, sich für das eine oder andere CMS zu entscheiden, und deren Stärken und Schwächen aufzeigen. Es gibt kein „bestes“ CMS, sondern nur das für eine bestimmte Situation am besten geeignete CMS. Darüber hinaus sollte jeder, der ein CMS für ein bestimmtes Projekt mit einem bestimmten Team und einem bestimmten Budget sucht, recherchieren und alle Angebote vergleichen, um herauszufinden, welches für den jeweiligen Kontext am besten geeignet ist. Es ist wichtig, sich nicht auf wenige CMS zu beschränken, wie ich es hier in diesem Artikel getan habe, sondern allen eine Chance zu geben.

Persönlich finde ich als Entwickler das, was ich im Oktober-CMS gefunden habe, wirklich ansprechend, vor allem seine Fähigkeit, modulare Anwendungen zu erstellen, wie sie von Laravel bereitgestellt werden. Ich würde dieses CMS auf jeden Fall für eine neue Website in Betracht ziehen. Allerdings habe ich beim Schreiben dieses Artikels auch WordPress „wiederentdeckt“. Da WordPress so beliebt ist, erhält es mehr als genug Kritik, hauptsächlich in Bezug auf seine alte Codebasis und seit kurzem die Einführung von Gutenberg; WordPress hat jedoch auch einige hervorragende Eigenschaften (wie sein superskalierbares Datenbankmodell), die selten gelobt werden, aber ebenfalls berücksichtigt werden sollten. Und am wichtigsten ist, dass WordPress nicht nur unter seinen technischen Aspekten betrachtet werden sollte: Insbesondere die Größe seiner Community und seines Ökosystems platziert es ein oder zwei Stufen über seinen Alternativen. Kurz gesagt, einige Projekte können davon profitieren, bei WordPress zu bleiben, während andere sich besser auf das Oktober-CMS oder eine andere Plattform verlassen.

Abschließend möchte ich anmerken, dass die Erforschung der Funktionsweise eines anderen CMS für sich genommen eine sehr lohnende Aktivität ist, unabhängig von der getroffenen Entscheidung, ob dieses bestimmte CMS verwendet werden soll oder nicht. In meinem Fall habe ich jahrelang nur an WordPress gearbeitet, und das Eintauchen in das Oktober-CMS war sehr erfrischend, da es mir viele Dinge beigebracht hat (z. B. die Existenz von PHP-Standardempfehlungen), denen ich durch WordPress nicht ausgesetzt war. Ich kann mich jetzt entscheiden, das CMS zu wechseln oder bei WordPress zu bleiben und zu wissen, wie man besseren Code produziert.

Weiterführende Literatur zu SmashingMag:

• Intelligent Caching im Zeitalter von Gutenberg
• Verbesserung des WordPress-Codes mit modernem PHP
• Lektionen, die bei der Entwicklung von WordPress-Plugins gelernt wurden
• So verwenden Sie Heatmaps, um Klicks auf Ihrer WordPress-Website zu verfolgen
• Seien Sie wachsam: PHP- und WordPress-Funktionen, die Ihre Website unsicher machen können