Une comparaison détaillée entre WordPress et October CMS

Il y a trois mois, WordPress a finalement publié React-powered ] Gutenberg pour améliorer son expérience d’édition de contenu par défaut, poussant de nombreuses personnes qui ne sont pas satisfaites de ce changement à rechercher des alternatives. Certaines personnes ont décidé de créer et de libérer WordPress avant Gutenberg, mais cela n’a pas beaucoup de sens pour moi, car il porte toujours 15 ans de dette technique. Si je devais trouver une alternative à WordPress, j'essaierais d'éviter de rester bloqué dans le passé et de viser une coupe nette à travers une plate-forme mature reposant sur des fondations modernes.

Cet article compare WordPress à une plate-forme similaire mais plus moderne. Octobre CMS sur un large éventail de sujets techniques et non techniques. Le but de l'article n'est pas de convaincre les gens de s'en tenir à WordPress ou de passer à October CMS, mais simplement de montrer quels aspects doivent être pris en compte avant de conclure le changement de plate-forme. La même comparaison pourrait (et devrait) également être faite avec d'autres plates-formes avant de prendre une décision sensée.

Pourquoi Octobre CMS

J'ai découvert octobre CMS quand il avait gagné un prix après quoi je est passé en mode de recherche et a passé beaucoup de temps à explorer ce CMS – du point de vue de l'utilisateur et du développeur. Ayant acquis des connaissances sur ce CMS, je me sentais confiant de pouvoir fournir une évaluation objective de ses fonctionnalités par rapport à WordPress. J'ai choisi ce CMS pour comparer d'autres options telles que Grav Statamic ButterCMS Joomla Drupal ] Jekyll Hugo et d'autres, pour les raisons suivantes:

• Je sais comment ce CMS fonctionne (contrairement à Grav);
• Il est libre et à code source ouvert ( contrairement à Statamic et ButterCMS);
• À cinq ans, il est "relativement" nouveau (contrairement à Joomla et Drupal);
• Il est un générateur de contenu dynamique (non statique) basé sur PHP (contrairement à Jekyll et Hugo).

Je pense qu'octobre, le système de gestion de contenu est un bon candidat car il est basé sur Laravel un cadre utilisé pour la construction d'applications modernes. Après sept ans d’existence, il a reçu un accueil favorable de la part des développeurs (comme en témoigne son importante communauté et son écosystème) et marque un contraste marqué par rapport au codage dans WordPress, c’est-à-dire que WordPress est principalement une programmation procédurale tandis que Laravel est résolument orienté objet. 19659013] Quelle est la différence entre les deux?

Ci-dessous, je comparerai WordPress et October CMS sur différentes catégories et soulignerai ce qui, à mon avis, est bon et moins bon à leur sujet. Cependant, je ne choisirai pas de gagnant car ce n'est pas l'objectif de l'article et, en tout cas, il n'y a pas de «meilleur» ni même de «meilleur» CMS: chaque CMS a ses propres forces et faiblesses ce qui le rend plus ou moins adapté à chaque tâche, projet, entreprise, équipe et toute autre chose. En outre, un projet peut tirer parti de l'utilisation de plusieurs systèmes de gestion de contenu, tels que l'utilisation d'un système de gestion de contenu pour gérer et fournir des données, et d'un autre système de gestion de contenu pour afficher la vue. C'est à vous de décider lequel des dizaines de CMS disponibles convient le mieux

En outre, cet article ne peut jamais tirer de conclusions définitives puisqu'il ne concerne qu'un sous-ensemble de toutes les possibilités. Par exemple, nous pouvons également trouver des comparaisons en ligne telles que «WordPress vs Drupal vs Joomla», «WordPress vs Static Site Generators» et même «WordPress vs Medium». Comme aucun de ces articles ne donne une image complète, aucune de ces comparaisons ne peut être concluante et ne doit pas être traitée comme telle.

Commençons par la comparaison.

Philosophie et groupe cible

Ce n'est pas coïncidence: WordPress alimente près de 1 site Web sur 3 . Depuis sa création, il s'est efforcé d'être extrêmement convivial et l'a réussi, en supprimant les frictions tant des utilisateurs techniques que non techniques, ainsi que des personnes de tous les horizons, indépendamment de leur formation niveaux économiques. Le fondateur de WordPress, Matt Mullenweg, a déclaré que la devise de « Democratize Publishing » pour l'époque actuelle signifiait:

«Les personnes de tous les horizons, intérêts et capacités devraient pouvoir accéder à Free-as Un logiciel qui leur permet de s’exprimer sur le Web ouvert et de posséder leur contenu. ”

WordPress est facile à utiliser pour tout le monde et son intégrité est également mise en évidence du côté du développement: il n’est pas rare de trouver des personnes sans un contexte de programmation (tels que des spécialistes du marketing, des concepteurs, des blogueurs, des vendeurs et autres) bricolant avec leurs installations WordPress, concevant leurs propres thèmes et lançant avec succès leurs propres sites Web. WordPress est centré sur l'utilisateur, et les besoins des utilisateurs l'emportent sur ceux des développeurs. Dans WordPress, l’utilisateur est roi (ou reine).

En revanche, octobre CMS est plus orienté vers le développeur, car a été explicitement établi dès sa première publication :

“Octobre met en gras hypothèse évidente: les clients ne construisent pas de sites Web, mais les développeurs. Le rôle du client est de gérer le site Web et de communiquer ses besoins opérationnels. Le développeur Web et l'industrie elle-même s'articulent autour de la médiation de ces facteurs. "

En comme le disent ses fondateurs la mission de la CMS est de" prouver que la création de sites Web n'est pas sorcière. " octobre, basé sur Laravel, CMS peut prétendre avoir de solides fondements de code modulaire réutilisable capable de produire des applications correctement architecturées, maintenables à long terme et entièrement personnalisables sans nécessiter de piratage informatique – le type qui attire les programmeurs sérieux. Octobre CMS peut également fournir une expérience utilisateur exceptionnelle, mais ce n’est pas aussi simple et sans friction que celui fourni par WordPress. Il peut être nécessaire d'expliquer aux utilisateurs comment utiliser certaines fonctionnalités avant de pouvoir les utiliser. Par exemple, incorporer un formulaire à partir d'un plugin a une longue explication sur la façon de le faire ce qui est plus fastidieux que la fonctionnalité évidente de glisser-déposer fournie par plusieurs plugins de formulaire dans WordPress .

Installation

WordPress est célèbre pour son installation de 5 minutes bien que de nombreuses personnes soulignent que (en prenant en compte tous les plugins à installer) une installation typique nécessite 15 minutes ou plus . En outre, WordPress offre également la fonctionnalité Multisite qui nous permet de créer un réseau de plusieurs sites virtuels sous une seule installation. Cette fonctionnalité facilite l'administration par une agence des sites de plusieurs clients – parmi d'autres cas d'utilisation .

L'installation du système de gestion d'octobre est également très simple: l'installation de l'assistant prend elle-même moins de cinq minutes, et si vous l’installez via l’installation de la console le processus est encore plus rapide. Vous pouvez le faire en naviguant simplement dans le répertoire cible, puis en exécutant curl -s https://octobercms.com/api/installer | php (après quoi nous devons entrer la configuration de la base de données, sinon elle se comporte comme un CMS à fichier plat). Une fois l’installation terminée, nous aurons un site Web pleinement opérationnel, mais toujours très dépourvu (si vous ajoutez le temps nécessaire pour installer et configurer les plug-ins requis, vous pouvez vous attendre à au moins 15 minutes).

Sécurité

WordPress a été accusé de manque de sécurité en raison du nombre élevé de vulnérabilités constamment découvertes. Cela oblige les utilisateurs à avoir le logiciel du CMS et de tous les plugins installés à jour pour éviter les failles de sécurité. Parmi les principaux problèmes, citons le support de WordPress pour les anciennes versions de PHP qui ne sont plus supportées par la communauté de développement PHP (WordPress supporte actuellement PHP 5.2.4, tandis que la dernière version entièrement prise en charge de PHP est 5.6). Cependant, ce problème devrait être résolu en avril 2019, lorsque WordPress commencera officiellement à prendre en charge les versions 5.6 et supérieures de PHP.

Dans le cas contraire, WordPress n'est pas nécessairement peu sûr à cause de lui-même, mais à cause de sa grande popularité, ce qui en fait une cible primordiale pour les hackers. Cependant, cela joue dans les deux sens: l'omniprésence de WordPress signifie que son équipe de sécurité doit vraiment prendre son travail au sérieux en recherchant constamment des exploits et en les réparant le plus rapidement possible, sans quoi un tiers du Web au moins serait menacé. Les enjeux sont tout simplement trop importants.

Octobre Octobre, par contre, n’a pas la réputation d’être peu sûr. Cependant, comme il y a environ 27 000 sites actifs qui utilisent Octobre par rapport aux millions de WordPress, nous ne pouvons pas juger les deux d’eux de la même manière. Néanmoins, l'équipe responsable de la gestion du serveur de gestion d'octobre Octobre CMS prend la sécurité au sérieux, comme en témoigne l'invite de l'installation de l'Assistant à saisir l'URL de fond du serveur CMS, définie par défaut sur / backend mais elle peut être modifiée pour rendre l'opération plus difficile. pour les pirates de cibler le site. En revanche, le changement des URL de connexion et de backend de WordPress de /wp-login.php et / wp-admin respectivement, en autre chose doit être effectué via un plugin . En outre, October CMS peut fonctionner comme un CMS à fichier plat (c'est-à-dire sans base de données) et éviter les vulnérabilités liées à la base de données telles que l'injection SQL.

Technology Stack

WordPress et October CMS s'exécutent tous les deux. sur la pile LAMP traditionnelle: Linux, Apache, MySQL et PHP. (Cependant, seul PHP est corrigé: nous pouvons également utiliser Windows, Nginx, MariaDB, etc.). October CMS peut également se comporter comme un système de fichiers à plat, ce qui signifie qu'il peut se passer de base de données au prix de la suppression. de nombreuses fonctionnalités (telles que les articles de blog et les utilisateurs), la seule fonctionnalité garantie est celle des pages, considérée comme l'unité de base pour la création et la publication de contenu et livrée en tant que fonctionnalité principale.

En ce qui concerne la pile de langues, les sites construit avec WordPress et October CMS est basé sur HTML, CSS et JavaScript (notez que PHP est utilisé pour générer le code HTML). Octobre CMS facilite également l'utilisation des fichiers LESS et SASS .

Paradigme de la programmation

WordPress suit un paradigme de la programmation fonctionnelle basé sur le calcul des calculs en appelant des fonctions sans application. Etat. Même si les développeurs WordPress n'ont pas besoin de s'en tenir à la programmation fonctionnelle (par exemple, pour coder leurs thèmes et leurs plugins), le code central de WordPress hérite de ce paradigme de 15 années de préservation de la compatibilité ascendante, qui a été l'un des piliers du succès de WordPress. mais qui a pour conséquence involontaire de l’accumulation de dettes techniques

De son côté, October CMS suit un paradigme de programmation impérative basé sur le calcul de calculs en manipulant l’état des objets. Octobre CMS se trouve au sommet de Laravel un framework Web entièrement fondé sur les principes de la programmation orientée objet permettant de produire des applications modulaires basées sur des concepts tels que le Model-View Contrôleur pour découpler l'interface utilisateur des données de l'application, Dependency Injection pour configurer les dépendances de classe et le principe de séparation des interfaces pour définir le ] services de base fournis par le cadre parmi de nombreux autres .

Hooks / Events

La programmation dans WordPress peut être qualifiée de disque dur qui signifie “développement basé sur le crochet”. Un crochet est un mécanisme qui permet de modifier un comportement ou une valeur par défaut et permettant à un autre code d'exécuter des fonctionnalités connexes. Les crochets sont déclenchés par des «actions» permettant d'exécuter des fonctionnalités supplémentaires et des «filtres» permettant de modifier des valeurs.

Les crochets, répandus dans la base de code WordPress, sont l'un des concepts que j'aime le plus du codage dans WordPress. Ils permettent aux plugins d’interagir avec d’autres plugins (ou avec un noyau ou un thème) d’une manière propre, fournissant ainsi un support de base de Programmation orientée aspect .

La bonne nouvelle est que Laravel (et par conséquent Octobre CMS) supporte également le concept de hooks, appelé « events ». Les événements fournissent une simple implémentation d'observateur, permettant au code de s'abonner et d'écouter les événements qui se produisent dans l'application et de réagir au besoin. Les événements permettent de scinder une fonctionnalité complexe en composants, pouvant être installés indépendamment tout en collaborant entre eux, permettant ainsi la création d'applications modulaires.

Dépendance à l'égard des bibliothèques JavaScript

La dernière version de WordPress intègre React-powered Gutenberg pour son expérience de création de contenu par défaut. Par conséquent, le développement de WordPress repose désormais largement sur JavaScript (principalement via React ), même s'il est également possible d'utiliser d'autres frameworks ou bibliothèques (comme le montre Elementor Blocks for Gutenberg est basé sur Marionette ). De plus, WordPress s'appuie toujours sur Backbone.js (pour le gestionnaire de médias) et jQuery (code hérité), mais on peut s'attendre à ce que la dépendance à l'égard de ces bibliothèques disparaisse au même rythme que Gutenberg. La nouvelle norme est consolidée.

Octobre Le CMS dépend de jQuery, qu’il utilise pour implémenter son cadre facultatif AJAX permettant de charger les données du serveur sans actualisation de la page du navigateur.

Pages, Thèmes et Plugins

WordPress et October CMS considèrent une page comme l’unité de base pour la création et la publication de contenu (dans le cas WordPress, en plus de la publication), prennent en charge la modification de l’apparence du site à l’aide de thèmes, et permettent les fonctionnalités du site via des plugins. Même si les concepts sont les mêmes dans les deux CMS, il existe quelques différences d'implémentation qui produisent un comportement quelque peu différent.

Dans WordPress, les pages sont définies en tant que contenu et stockées dans la base de données. En conséquence, le contenu de la page ne peut être créé que par le CMS (par exemple, dans la zone du tableau de bord), et le passage d’un thème à un autre ne rend pas une page existante indisponible. Cela produit une expérience globale sans frottement.

En octobre, par contre, les pages sont des fichiers statiques stockés dans le répertoire theme. Du côté positif de cette décision architecturale, le contenu de la page peut être créé à partir d'une application externe, telle que des éditeurs de texte tels que Sublime ou Visual Studio Code . Du côté négatif, lors du passage d'un thème à un autre, il est nécessaire de recréer ou de copier manuellement les pages du thème actuel vers le nouveau, sinon elles disparaîtront.

De manière significative, October CMS résout le routage . pages les pages sont donc utilisées non seulement comme conteneurs pour le contenu, mais aussi pour les fonctionnalités. Par exemple, un plugin pour bloguer dépend d'une page permettant d'afficher la liste des publications de blog sous une URL choisie, d'une autre page permettant d'afficher une publication de blog sous une autre URL choisie, etc. Si l'une de ces pages disparaît, la fonctionnalité associée au plug-in devient indisponible et cette URL générera un 404. Ainsi, en octobre, les thèmes et les plug-ins du système de gestion de contenu ne sont pas complètement découplés, et le changement de thème doit être effectué avec précaution.

Fonctionnalité de base contre plugin

WordPress tente de fournir une fonctionnalité de base minimale qui est améliorée grâce aux plugins . WordPress s'appuie sur la règle « ⁸⁰ ₂₀ » pour décider d'inclure ou non une fonctionnalité dans son expérience principale. Si cela profite à 80% des utilisateurs, il appartient au plugin-land. Lors de l'ajout de plugins sur un site, ils peuvent entraîner bloat si trop de plugins sont installés. Les plugins peuvent également ne pas fonctionner correctement les uns des autres, exécuter un code similaire ou charger des actifs similaires, entraînant des performances sous-optimales. Par conséquent, alors que lancer un site WordPress est relativement facile, le plus gros défi est sa maintenance générale et sa capacité à conserver un état optimal et performant lors de l’ajout de nouvelles fonctionnalités.

De même, October CMS tente également de fournir une fonctionnalité minimale, mais sur les stéroïdes: la seule fonctionnalité garantie est la création et la publication de pages, et pour tout le reste, nous devrons installez un plugin ou un autre sous la forme:

«Tout ce dont vous avez besoin et rien que vous n’aurez.»

L’objectif est clair: la plupart des sites simples ne sont composés que de pages, avec éventuellement aucun article de blog, utilisateurs ou zone de connexion. Alors, pourquoi l’application devrait-elle charger des ressources pour celles-ci quand elles ne sont pas nécessaires? Par conséquent, les fonctionnalités de blogging de gestion des utilisateurs de traduction et de plusieurs autres fonctionnalités sont publiées dans le [plugin .

Octobre Le CMS inclut également certaines fonctionnalités qui, bien qu’elles ne soient pas toujours nécessaires, peuvent considérablement améliorer l’application. Par exemple, il fournit une prise en charge immédiate pour télécharger des fichiers multimédias sur Amazon S3 et pour y accéder via le CDN de Rackspace. Il inclut également un gestionnaire de média qui est principalement utilisé via des plugins, par exemple. pour ajouter des images dans un article de blog. (Pages peut également utiliser Media Manager pour incorporer des fichiers multimédias, mais le CMS contient également une section Actifs permettant de télécharger des fichiers multimédias pour ceux qui semblent plus appropriés.)

Je pense que l’opinion d’octobre peut parfaitement nous permettre de produire un application qui est aussi maigre que possible – concernant principalement des sites simples. Cependant, cela peut aussi se retourner contre vous et encourager le gonflement, parce que la ligne entre ce qui est nécessaire et ce qui ne l’est pas est arbitraire, et il est difficile d’être définie à l’avance par la CMS. Cette difficulté peut être appréciée lorsque l’on considère le concept d ’« utilisateur »: dans WordPress, les utilisateurs de site Web et les administrateurs de site Web appartiennent à la même entité d’utilisateur (et, grâce aux rôles et privilèges, nous pouvons transformer un utilisateur en administrateur). En octobre, les deux CMS sont implémentés séparément, livrant essentiellement l'implémentation pour l'administrateur du site Web qui peut se connecter à la zone dorsale et modifier les paramètres, et via un plugin l'implémentation de l'utilisateur du site. Ces deux types d’utilisateurs utilisent un processus de connexion et une table de base de données différents pour stocker leurs données, enfreignant ainsi le principe DRY (Don't Repeat Yourself).

Ce problème ne concerne pas seulement le comportement d’une entité, mais également quels champs de données il doit contenir. Par exemple, les champs de données utilisateur du site Web doivent-ils être prédéfinis? Un champ téléphonique est-il requis? Qu'en est-il d'un champ d'URL Instagram, étant donné qu'Instagram n'est devenu vraiment cool que récemment? Mais alors, lors de la création d’un site Web professionnel, ne devrions-nous pas utiliser un champ URL LinkedIn à la place? Ces décisions dépendent clairement de l'application et ne peuvent être décidées ni par CMS ni par plugin.

Le plugin d'octobre CMS appelé User implémente des utilisateurs, mais sans champ utilisateur, sur lequel se greffe le plugin . User Plus ajoute plusieurs champs utilisateur arbitraires, ce qui n'est peut-être pas suffisant. Le plug-in User Plus + ajoute encore d'autres champs utilisateur. Quand, où et comment arrêter ce processus?

Un autre problème réside dans le fait qu'il est impossible d'ajouter de nouvelles capacités à une entité, ce qui entraîne la création d'une autre entité extrêmement similaire, uniquement pour prendre en charge les capacités requises. Octobre CMS, par exemple, est livré avec des pages et permet de créer des «pages statiques» via un plug-in . Leur nature est la même: les pages et les pages statiques sont enregistrées en tant que fichiers statiques. La seule différence entre eux (à ce que je sache) est que les pages statiques sont éditées avec un éditeur visuel au lieu de l'éditeur HTML et peuvent être ajoutées aux menus. À mon avis, seules des différences structurelles, telles que le fait de sauvegarder une entité en tant que fichier statique et l’autre dans la base de données, pourraient justifier la création d’une seconde entité pour une page (il existe une demande de tirage ). ceci, mais pour des fonctionnalités simples, comme c’est le cas à l’heure actuelle, cela constitue un problème de développement.

En résumé, une application CMS octobre bien implémentée peut être très légère et efficace (par exemple en supprimant la base de données lorsqu'elle n’est pas nécessaire), mais au contraire, cela peut également devenir inutilement gonflé, obligeant les développeurs à implémenter plusieurs solutions pour des entités similaires, et pouvant être très déroutant ("Devrais-je utiliser une page ou une page statique?"). Parce que ni WordPress, ni October CMS, n’ont trouvé de solution idéale pour supprimer les ballonnements, nous devons concevoir l’une ou l’autre des applications en prenant soin de ne pas causer de problèmes sur la route.

Création du contenu

Gutenberg apporte deux importantes contributions à WordPress: Il utilise composants comme unité de construction (qui offre plusieurs avantages par rapport aux blocs de code HTML ), et introduit une entité appelée "bloc" qui, une fois Gutenberg Phase 2 est terminée ( vraisemblablement en 2019), fournira un moyen unifié d’incorporer du contenu dans le site, permettant ainsi une expérience utilisateur plus simple, par opposition au processus plus chaotique consistant à ajouter du contenu via des codes courts, des boutons TinyMCE, des menus, des widgets et autres.

Comme les blocs Gutenberg peuvent générer et enregistrer du code HTML statique dans le post du blog, l'installation de nombreux blocs Gutenberg ne se traduit pas forcément par une surcharge du site Web, mais peut être gardé limité au côté admin. Par conséquent, Gutenberg peut être considéré comme une bonne approche pour produire des sites Web de manière modulaire, avec une expérience utilisateur simple mais puissante pour la création de contenu. Le plus gros inconvénient est peut-être l'obligation (inévitable, mais pas tellement facile) d'apprendre React, dont la courbe d'apprentissage est plutôt abrupte .

Si les composants React sont l'unité de base pour créer du contenu dans WordPress, Octobre CMS est basé sur le principe que connaître le bon vieux HTML suffit pour créer des sites. En effet, lors de la création d'une page, un éditeur HTML (Markup) est simplement présenté:

Si la page était uniquement du code HTML statique, aucun système de gestion de contenu ne serait alors nécessaire. Au lieu de cela, les pages d'octobre CMS sont écrites à l'aide de modèles Twig compilés dans un code PHP optimisé. Ils peuvent sélectionner une mise en page pour inclure l'échafaudage de la page (c'est-à-dire des éléments répétitifs, tels que l'en-tête, le pied de page, etc.), peuvent implémenter des espaces réservés définis sur le layout pour permettre à la page de personnaliser le contenu et peut inclure les partiels qui sont des fragments de code réutilisables. De plus, les pages peuvent inclure des blocs de contenu qui sont des fichiers texte, HTML ou Markdown pouvant être édités seuls et pouvant attacher des composants qui sont des fonctionnalités implémentées via des plugins. Et enfin, si HTML ne suffit pas et que nous devons produire du code dynamique, nous pouvons ajouter Fonctions PHP .

L'éditeur est entièrement basé sur HTML. Il n'y a pas de TinyMCE textarea permettant d'ajouter du contenu de manière visuelle – du moins pas avec l'expérience par défaut (cette fonctionnalité appartient à plugin-land). Par conséquent, avoir des connaissances en HTML pourrait être considéré comme une nécessité pour utiliser October CMS. En outre, les différentes entrées permettant de créer du contenu (pages, mises en forme, espaces réservés, partiels, blocs de contenu, composants et fonctions PHP) peuvent s'avérer très efficaces. Cependant, ce n'est certainement pas aussi simple que via l'interface de bloc unifié de WordPress. Cela peut même devenir plus complexe puisque d’autres éléments peuvent également être ajoutés (tels que pages statiques et menus et extraits ), et certains d’entre eux, tels que des pages et des pages statiques, apparemment. fournir la même fonctionnalité, ce qui rend difficile de décider quand utiliser l'un ou l'autre.

En conséquence, j'ose dire que si tout le monde peut utiliser un site WordPress du côté de l'administrateur, October CMS est plus adapté aux développeurs. non-technique convivial, donc les programmeurs peuvent trouver cela agréable, mais certains autres rôles (marketing, commerciaux, etc.) risquent de ne pas être intuitif.

Media Manager

WordPress et October CMS sont livrés avec un gestionnaire de média qui permet d'ajouter des fichiers multimédia sur le site sans effort, en prenant en charge l'ajout simultané de plusieurs fichiers via une interface glisser-déposer et en affichant les images dans la zone de contenu. Ils se ressemblent et se comportent de la même manière; les seules différences notables que j'ai trouvées sont que Media Manager de WordPress permet d'intégrer des galeries d'images et que Media Manager d'octobre permet de créer manuellement une structure de dossiers dans laquelle les fichiers téléchargés sont placés.

Depuis l'introduction de Gutenberg, les capacités de WordPress en matière de médias ont été considérablement améliorées, permettant l'intégration de vidéos, d'images et de galeries de photos au sein d'un TinyMCE . textarea (qui fournit seulement une version non précise de son apparence sur le site) et permet de déverrouiller des fonctionnalités puissantes et faciles à utiliser, comme le montre cette vidéo .

Internationalisation

Le noyau WordPress utilise gettext pour permettre la traduction de thèmes et de plugins . À partir d'un fichier .pot contenant toutes les chaînes à traduire, vous devez créer un fichier .po contenant leur traduction dans la langue / les paramètres régionaux correspondants. Ce fichier est ensuite compilé en un fichier. fichier binaire .mo adapté à l'extraction rapide de traduction. Les outils permettant d’accomplir ces tâches incluent GlotPress (en ligne) et Poedit (application téléchargeable). De manière pratique, ce mécanisme fonctionne également pour la localisation côté client pour Gutenberg.

WordPress ne contient actuellement aucune solution de base pour la traduction de contenu, et ne le fera pas avant la phase 4 de Gutenberg (ciblée pour l'année 2020 +). . Jusque-là, cette fonctionnalité est fournie par des plugins qui offrent différentes stratégies pour stocker et gérer le contenu traduit. Par exemple, alors que des plugins tels que Polylang et WPML stockent chaque traduction sur sa propre ligne à partir d'une table de base de données personnalisée (propre car elle ne mélange pas le contenu ensemble, mais plus lentement depuis. INNER JOIN supplémentaire de deux tables pour interroger la base de données), plug-in qTranslate X stocke toutes les traductions sur le même champ que le tableau d'origine (plus rapide pour interroger les données, mais un contenu mélangé peut produire des ruines sur le site si le plugin est désactivé). Nous pouvons donc faire des recherches et décider de la stratégie la mieux adaptée à nos besoins.

October CMS n’intègre pas la fonctionnalité multilingue dans son cœur, mais sous la forme d’un plug-in créé par l’équipe d’octobre garantissant une intégration sans faille dans le système. D'un point de vue fonctionnel, ce plugin offre ce qu'il promet. Du point de vue du développement, le fonctionnement de ce plugin n’est pas idéal. Dans WordPress, une page est simplement un article avec le type d'article "page" et il existe un mécanisme de traduction unique, mais en octobre, il existe des entités "page", "page statique" et "article de blog" et, même si assez similaires, ils nécessitent trois implémentations différentes pour leurs traductions! Ensuite, le contenu d'une "page" peut inclure des codes de message (par exemple, des codes appelés nav.content header.title etc.), chacun contenant ses traductions pour tous. locales en tant qu'objet JSON sérialisé dans la table de base de données rainlab_translate_messages . Le contenu d’une "page statique" est créé dans un nouveau fichier statique par région. Cependant, toutes les URL traduites pour toutes les régions sont stockées non dans le fichier correspondant, mais dans le fichier de la langue par défaut. Le contenu de la «publication de blog» est stocké sous forme d'objet JSON sérialisé avec une ligne par localisation dans la table de base de données . Rainlab_translate_attributes et l'URL traduite est stockée avec une ligne par localisation dans la table de base de données . Rainlab_translate_indexes ]. I don’t know if this complexity is due to how the plugin was implemented or whether it is due to October CMS’ architecture. Whichever the case, this is another instance of undesired bloat on the development side.

Plugin Management

Both WordPress and October CMS offer a sophisticated plugin manager which allows to search for plugins, install new plugins, and update currently-installed plugins to their latest version — all from within the backend.

Dependency Management

October CMS uses Composer as the package manager of choice, enabling plugins to download and install their dependencies when being installed, thus delivering a painless experience.

WordPress, on the opposite side, hasn’t officially adopted Composer (or any PHP dependency manager) because the community can’t agree if WordPress is a site or a site dependency. Hence, if they require Composer for their projects, developers must add it on their own. With the switch to Gutenberg, npm has become the preferred JavaScript dependency manager, with a popular developer toolkit depending on it, and the client-side libraries being steadily released as autonomous packages in the npm registry.

Interaction With The Database

WordPress provides functions to retrieve database data (such as get_posts) and store it (such as wp_insert_post and wp_update_post). When retrieving data, we can pass parameters to filter, limit and order the results, in order to indicate if the result must be passed as an instance of a class or as an array of properties and others. When the function doesn’t fully satisfy our requirements (e.g. when we need to do an INNER JOIN with a custom table) then we can query the database directly through global variable $wpdb. When creating a plugin with a custom post type, the code will most likely be executing custom SQL queries to retrieve and/or save data into custom tables. In summary, WordPress attempts to provide access to the database through generic functions in the first stage, and through low-level access to the database in the second stage.

October CMS employs a different approach: Instead of connecting to the database straight away, the application can use Laravel’s Eloquent ORM to access and manipulate database data through instances of classes called Modelsmaking the interaction with the database also be based on Object-Oriented Programming. It is high-level access; just by following the rules on how to create tables and set-up relationships among entitiesa plugin can retrieve and/or save data without writing a line of SQL. For instance, the code below retrieves an object from the database through model Flightmodifies a property, and stores it again:

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

Upgrading The Data Model

Another reason for WordPress’ success (in addition to not breaking backward compatibility) has been its database architecturewhich was engineered to enable applications to grow over time. This objective is accomplished through “meta” properties, i.e. properties that can be loosely added to a database object at any moment. These properties are not stored in a column from the corresponding entity table (either wp_postswp_userswp_comments or wp_terms), but instead as a row in the corresponding “meta” table (wp_postmetawp_usermetawp_commentmeta or wp_termmeta) and retrieved doing an INNER JOIN. Hence, even though retrieving these meta values is slower, they provide unlimited flexibility, and the application’s data model rarely needs to be re-architected from scratch in order to implement some new functionality.

October CMS doesn’t use meta properties but instead can store several arbitrary values, which are not directly mapped as columns in the database tables, as a serialized JSON object. 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 Migrationswhich 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 (e.g. when installing a plugin’s new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, i.e. 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 Generatorwhich 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 WPGraphQLwhile 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 modelwhich means more work, but also means that it can be more efficient (e.g. accessing a property from a column is faster than from a row in another table through an INNER JOINwhich 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 onethis 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 Partnersand several others are found DuckDuckGoingbut 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/yearevidencing 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 pluginsdelivering 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 guidelineswe 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 Octoberat 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.

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 Laraconthe 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?

Powering one-third of all sites in the world, WordPress is not short of stakeholders contributing to the software; hence we need not fear that the software will fall into decay. However, WordPress is going through internal deliberations concerning its governance model, with many members of the community expressing that decisions concerning WordPress’s direction are being taken unilaterally by Automatticthe company running WordPress.com. Center stage of this perception was the decision to launch Gutenberg, which many members disagreed with, and which suffered a lack of proper communication by the project leads during its development and release. As a consequence, many community members are questioning the role of “benign dictator”, which has been historically granted to WordPress’ founder and Automattic’s CEO Matt Mullenweg, and researching different governance models to find a more suitable one for the future of WordPress. It is yet to be seen if this quest produces any result, or if the status quo perseveres.

Decisions concerning October CMS’ direction are mainly taken by founders Alexey Bobkov and Samuel Georges and developer and community manager Luke Towerswhich keep the project going strong. October CMS doesn’t have the luxury of having a governance problem yet: Its current concern is how to make the project sustainable by generating income for the core software’s maintainers.

Documentation

WordPress documentation in its own site is not extremely comprehensive, but it does the job reasonably well. However, when taking all of the documentation about WordPress into account from all sources, such as general sites (Smashing MagazineCSS tricksand many others), specialized sites (WPShoutWPBeginnerand many others), personal blogs, online courses, and so on, there is practically no aspect of dealing with WordPress that hasn’t already been covered.

October CMS doesn’t enjoy anything near the many third-party courses, tutorials or blog posts about it as much as WordPress does, however, the documentation on its site is reasonably comprehensive and certainly enough to start coding. October founders also regularly add new documentation through tutorials. One aspect that I personally enjoyed is the duplication of Laravel’s documentation into October’s documentation for everything of relevance, so the reader must not fill the gaps by him/herself and having to guess what is October’s domain and what is Laravel’s. However, this is not 100% perfect. October’s documentation uses terms originating from Laravel, such as middleware, service containers, facades and contracts, without adequately explaining what these are. Then, reading Laravel’s documentation in advance can be helpful (luckily, Laravel’s documentation is decidedly comprehensive, and Laravel’s screencasts, Laracastsare another great source of learning, not just concerning Laravel but web development in general).

Conclusion

I set out to discover what features may be enticing for developers looking for alternatives to WordPress by comparing WordPress to a similar CMS, which I defined as being free and open source, based in PHP and producing dynamic content, and enjoying the support from some community. From the CMSs fulfilling these conditions, I chose October CMS for the comparison because of the knowledge I got about it, and because I appreciated its clean and modular coding approach as provided by Laravel, which could offer a fresh and modern perspective for building sites.

This article did not intend to pick a winner, but simply analyze when it makes sense to choose one or the other CMS, highlighting their strengths and weaknesses. There is no “best” CMS: only the most suitable CMS for a specific situation. Furthermore, anyone looking for a CMS to use on a particular project with a specific team and given a certain budget, should do some research and compare all the offerings out there to find out which one is most suitable for the particular context. It’s important not to limit to a few CMSs as I’ve done here in this article, but instead give a chance to all of them.

On a personal note, as a developer, what I found in October CMS is really appealing to me, mostly its ability to build modular applications as provided through Laravel. I would certainly consider this CMS for a new website. However, in the process of writing this article I also “rediscovered” WordPress. Being so popular, WordPress receives more than its fair share of criticisms, mostly concerning its old codebase and, since recently, the introduction of Gutenberg; however, WordPress also has certain excellent features (such as its super-scalable database model) which are seldom praised but should be taken into account too. And most importantly, WordPress should not be considered on its technical aspects alone: in particular, the size of its community and ecosystem places it a level or two above its alternatives. In a nutshell, some projects may benefit from sticking to WordPress, while others may better rely on October CMS or another platform.

As a final note, I would like to remark that exploring how another CMS works is a very rewarding activity on its own, independent of the decision reached concerning whether to use that particular CMS or not. In my case, I had been working for years on WordPress alone, and delving into October CMS was very refreshing since it taught me many things (such as the existence of PHP Standards Recommendations) which I had not been exposed to through WordPress. I may now decide to switch CMSs, or stick to WordPress knowing how to produce better code.

Further Reading on SmashingMag:

(rb, ra, yk, il)