Un confronto dettagliato tra WordPress e CMS di ottobre

Tre mesi fa, WordPress ha finalmente rilasciato Gutenberg basato su React per potenziare la sua esperienza di modifica dei contenuti predefinita, spingendo molte persone che non sono contente di questo cambiamento a cercare alternative. Alcune persone hanno deciso di biforcare e rilasciare WordPress pre-Gutenberg, tuttavia, per me questo non ha molto senso poiché comporta ancora 15 anni di debito tecnico. Se dovessi trovare un'alternativa a WordPress, cercherei di evitare di rimanere bloccato nel passato e mirerei a un taglio netto attraverso una piattaforma matura costruita su basi moderne.

Questo articolo confronta WordPress con il CMS di ottobre probabilmente simile ma più moderno su un'ampia gamma di argomenti sia tecnici che non tecnici. L'obiettivo dell'articolo non è convincere le persone ad attenersi a WordPress o a passare a October CMS, ma semplicemente dimostrare quali aspetti devono essere presi in considerazione prima di concludere il passaggio a una piattaforma diversa. Lo stesso confronto potrebbe (e dovrebbe) essere fatto anche con altre piattaforme prima di prendere una decisione sensata.

Perché ottobre CMS

Ho scoperto il CMS di ottobre quando ha vinto un premio, dopodiché sono entrato in modalità ricerca e ho trascorso molto tempo ad approfondire questo CMS, dal punto di vista sia dell'utente che dello sviluppatore. Man mano che ho acquisito conoscenze su questo CMS, mi sono sentito fiducioso di poter fornire una valutazione obiettiva delle sue funzionalità rispetto a WordPress. Ho scelto questo CMS per il confronto tra opzioni alternative come Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo e altri, per i seguenti motivi:

• So come funziona questo CMS (a differenza di Grav);
• È gratuito e open source (a differenza di Statamic e ButterCMS);
• A cinque anni è “relativamente” nuovo (a differenza di Joomla e Drupal);
• È un generatore di contenuti dinamico (non statico) e basato su PHP (a differenza di Jekyll e Hugo).
  

Credo che October CMS sia un buon candidato perché si basa su Laravel che è un framework utilizzato per la creazione di applicazioni moderne. Dopo sette anni di esistenza, ha ricevuto l'approvazione positiva degli sviluppatori (come evidenziato dalla sua consistente comunità ed ecosistema) e segna un netto contrasto sulla codifica in WordPress, ovvero WordPress è per lo più programmazione procedurale mentre Laravel è decisamente una programmazione orientata agli oggetti.

Qual è la differenza tra i due?

Di seguito confronterò WordPress e October CMS su diverse categorie ed evidenzierò ciò che, credo, sia buono e non così buono in loro. Tuttavia, non sceglierò un vincitore, poiché non è questo l'obiettivo dell'articolo e, in ogni caso, non esiste un CMS "migliore" o addirittura "migliore": ogni CMS ha i suoi punti di forza e di debolezza che lo renderanno più o meno adatto ad ogni compito, progetto, azienda, team e quant'altro. Inoltre, un progetto può trarre vantaggio dall'utilizzo di più di un CMS, ad esempio utilizzando alcuni CMS per gestire e fornire dati e un altro CMS per eseguire il rendering della vista. Decidere quale delle dozzine di CMS disponibili è più adatto alle tue esigenze dipende interamente da te.

Inoltre, questo articolo non potrebbe mai trarre conclusioni definitive poiché riguarda solo un sottoinsieme di tutte le possibilità. Ad esempio, possiamo anche trovare confronti online come "WordPress vs Drupal vs Joomla", "WordPress vs Generatori di siti statici" e persino "WordPress vs Medium". Poiché nessuno di questi articoli vede il quadro completo, nessuno di questi confronti può mai essere conclusivo e non dovrebbe essere trattato come tale.

Iniziamo con il confronto.

Filosofia e gruppo target

Non è un caso che WordPress alimenta quasi 1 sito web su 3. Sin dal suo inizio, ha cercato di essere estremamente facile da usare e lo ha fatto con successo, eliminando attriti per utenti tecnici e non tecnici e per persone di ogni estrazione, indipendentemente dal loro livello di istruzione e livello economico. Il fondatore di WordPress, Matt Mullenweg, ha affermato che il motto di WordPress "Democratizzare l'editoria" per l'era attuale significava quanto segue:

"Persone di ogni background, interesse e abilità dovrebbero essere in grado di accedere a software Free-as-in-speech che consenta loro di esprimersi sul Web aperto e di possedere i propri contenuti".

WordPress è facile da usare per tutti e la sua inclusività è evidenziata anche dal lato dello sviluppo: non è raro trovare persone senza un background di programmazione (come marketer, designer, blogger, venditori e altri) che armeggiano con le loro installazioni WordPress, progettando i propri temi e lanciare con successo i propri siti web. WordPress è incentrato sull'utente e le esigenze degli utenti prevalgono su quelle degli sviluppatori. In WordPress, l'utente è re (o regina).

Al contrario, October CMS è più orientato verso lo sviluppatore, come esplicitamente stabilito dalla sua primissima versione:

“Ottobre fa un presupposto audace ma ovvio: i clienti non creano siti Web, lo fanno gli sviluppatori. Il ruolo di un cliente è gestire il sito Web e trasmettere le proprie esigenze aziendali. Lo sviluppatore web e l'industria stessa ruotano attorno alla mediazione di questi fattori".

Nelle parole dei suoi fondatori, la missione del CMS è "dimostrare che la creazione di siti Web non è scienza missilistica". Essendo basato su Laravel, October CMS può affermare di avere solide basi di codice riutilizzabile e modulare in grado di produrre applicazioni adeguatamente architettate, manutenibili a lungo termine e completamente personalizzabili senza richiedere hack, il tipo che attrae i programmatori seri. October CMS può anche fornire un'ottima esperienza utente, tuttavia, non è così semplice o agevole come quella fornita da WordPress. Potrebbe essere necessario spiegare agli utenti come utilizzare determinate funzionalità prima di poterle utilizzare. Ad esempio, l'incorporamento di un modulo da alcuni plug-in ha una lunga spiegazione su come farlo, che è più ingombrante dell'evidente funzionalità di trascinamento della selezione fornita da diversi plug-in di moduli in WordPress.

Installazione

WordPress è famoso per i suoi 5 minuti di installazione, anche se in molti fanno notare che (prendendo in considerazione tutti i plugin che devono essere installati) un'installazione tipica richiede 15 minuti o più. Inoltre, WordPress offre anche la funzione Multisito, che ci consente di creare una rete di più siti virtuali in un'unica installazione. Questa funzione consente a un'agenzia di amministrare facilmente i siti di più clienti, tra gli altri casi utente.

Anche l'installazione di October CMS è molto semplice: l'installazione della procedura guidata richiede anche meno di cinque minuti e, se la si installa tramite l'installazione della console, è ancora più veloce. Puoi fare quest'ultimo semplicemente navigando nella directory di destinazione e quindi eseguendo curl -s https://octobercms.com/api/installer | php curl -s https://octobercms.com/api/installer | php (dopo di che dobbiamo inserire la configurazione del database, altrimenti si comporta come un CMS flat-file). Una volta completata l'installazione, avremo un sito web perfettamente funzionante, ma ancora abbastanza scarno (se si aggiunge il tempo necessario per installare e configurare i plugin richiesti, ci si può aspettare almeno 15 minuti).

Sicurezza

WordPress è stato accusato di essere insicuro a causa dell'elevata quantità di vulnerabilità che si trovano costantemente. Questo costringe gli utenti ad avere il software per il CMS e tutti i plugin installati sempre aggiornati per evitare exploit di sicurezza. Tra i problemi principali c'è il supporto di WordPress per le versioni precedenti di PHP che non sono più supportate dalla comunità di sviluppo di PHP (WordPress attualmente supporta PHP 5.2.4, mentre l'ultima versione di PHP completamente supportata è la 5.6). Tuttavia, questo problema dovrebbe essere risolto nell'aprile 2019 quando WordPress inizierà ufficialmente a supportare le versioni PHP 5.6 e successive.

Altrimenti, WordPress non è necessariamente insicuro a causa di se stesso, ma a causa della sua elevata popolarità, che lo rende un obiettivo primario per gli hacker. Tuttavia, questo funziona in entrambi i modi: l'ubiquità di WordPress significa che il suo team di sicurezza deve davvero prendere sul serio il proprio lavoro cercando costantemente exploit e risolvendoli il prima possibile, altrimenti fino a un terzo del web è a rischio. La posta in gioco è semplicemente troppo alta.

October CMS, d'altra parte, non ha la reputazione di essere insicuro. Tuttavia, poiché ci sono circa 27.000 siti live che utilizzano ottobre rispetto ai milioni di WordPress, non possiamo giudicarli alle stesse condizioni. Tuttavia, il team dietro October CMS prende sul serio la sicurezza, come evidenziato dalla richiesta dell'installazione guidata di inserire l'URL del backend del CMS, impostato come /backend per impostazione predefinita ma modificabile in qualsiasi altra cosa, in modo da rendere più difficile per gli hacker prendere di mira il sito . Al contrario, la modifica degli URL di accesso e back-end di WordPress da /wp-login.php e /wp-admin rispettivamente a qualcos'altro deve essere eseguita tramite un plug-in. Inoltre, October CMS può funzionare come un CMS flat-file (cioè senza un database) ed evitare vulnerabilità legate al database come SQL injection.

Pila di tecnologia

Sia WordPress che October CMS funzionano sullo stack LAMP tradizionale: Linux, Apache, MySQL e PHP. (Tuttavia, solo PHP è corretto: possiamo anche usare Windows, Nginx, MariaDB e altri.) October CMS può anche comportarsi come un CMS flat-file, il che significa che può fare a meno di un database, tuttavia, a costo di rinunciare molte funzionalità (come post di blog e utenti) l'unica funzionalità garantita sono le pagine, che è considerata l'unità di base per la creazione e la pubblicazione di contenuti e fornita come funzionalità principale.

Per quanto riguarda lo stack delle lingue, i siti creati con WordPress e October CMS sono basati su HTML, CSS e JavaScript (si noti che PHP viene utilizzato per generare l'HTML). October CMS semplifica anche l'utilizzo di file LESS e SASS.

Paradigma di programmazione

WordPress segue un paradigma di programmazione funzionale, basato sul calcolo dei calcoli chiamando funzioni prive di stato dell'applicazione. Anche se gli sviluppatori di WordPress non devono attenersi alla programmazione funzionale (ad esempio, per codificare i loro temi e plugin), il codice principale di WordPress eredita questo paradigma da 15 anni di conservazione della compatibilità con le versioni precedenti, che è stato uno dei pilastri del successo di WordPress ma che ha la conseguenza non intenzionale di accumulare debiti tecnici.

Dall'altro lato, October CMS segue un paradigma di programmazione imperativo, basato sul calcolo dei calcoli manipolando lo stato degli oggetti. October CMS si trova sopra Laravel, un framework web completamente fondato sui principi della programmazione orientata agli oggetti che consentono la produzione di applicazioni modulari basate su concetti come Model-View-Controller per disaccoppiare l'interfaccia utente dai dati dell'applicazione, Dependency Injection per configurare le dipendenze delle classi e il principio di segregazione dell'interfaccia per definire i servizi principali forniti dal framework, tra molti altri.

Ganci/Eventi

La programmazione in WordPress potrebbe essere caratterizzata come HDD che sta per "Sviluppo guidato da hook". Un hook è un meccanismo che consente di modificare un comportamento o un valore predefinito e consentire ad altro codice di eseguire funzionalità correlate. Gli hook vengono attivati ​​tramite "azioni" che consentono di eseguire funzionalità extra e "filtri" che consentono di modificare i valori.

Gli hook, che sono diffusi nella codebase di WordPress, sono uno dei concetti che mi piacciono di più della programmazione in WordPress. Consentono ai plug-in di interagire con altri plug-in (o con un core o un tema) in modo pulito, fornendo un supporto di base per la programmazione orientata agli aspetti.

La buona notizia è che Laravel (e di conseguenza October CMS) sostiene anche il concetto di hook, che si chiama “eventi”. Gli eventi forniscono una semplice implementazione dell'osservatore, consentendo al codice di sottoscrivere e ascoltare gli eventi che si verificano nell'applicazione e di reagire secondo necessità. Gli eventi consentono di suddividere una funzionalità complessa in componenti, che possono essere installati indipendentemente ma collaborano tra loro, consentendo così la creazione di applicazioni modulari.

Dipendenza dalle librerie JavaScript

L'ultima versione di WordPress incorpora Gutenberg basato su React per la sua esperienza di creazione di contenuti predefinita. Quindi, lo sviluppo di WordPress ora si basa in gran parte su JavaScript (prevalentemente tramite React), anche se è anche possibile utilizzare altri framework o librerie (come evidenziato da Elementor Blocks for Gutenberg che è basato su Marionette). Inoltre, WordPress si basa ancora su Backbone.js (per Media Manager) e jQuery (codice legacy), tuttavia, possiamo aspettarci che la dipendenza da queste librerie svanisca quando Gutenberg si consolida come la nuova norma.

October CMS dipende da jQuery, che utilizza per implementare il suo framework AJAX opzionale per caricare i dati dal server senza un aggiornamento della pagina del browser.

Pagine, temi e plugin

Sia WordPress che October CMS trattano una pagina come l'unità di base per la creazione e la pubblicazione di contenuti (nel caso di WordPress, oltre al post), supportano la modifica dell'aspetto del sito tramite temi e consentono di installare ed estendere le funzionalità del sito tramite plug-in . Anche se i concetti sono gli stessi in entrambi i CMS, ci sono alcune differenze nell'implementazione che producono un comportamento leggermente diverso.

In WordPress, le pagine sono definite come contenuto e memorizzate nel database. Di conseguenza, il contenuto della pagina può essere creato solo tramite il CMS (ad es. nell'area dashboard) e il passaggio da un tema all'altro non rende non disponibile una pagina esistente. Questo produce un'esperienza complessiva senza attriti.

In ottobre CMS, invece, le pagine sono file statici archiviati nella directory del tema. Il lato positivo di questa decisione architettonica, il contenuto della pagina può essere creato da un'applicazione esterna, come editor di testo come Sublime o Visual Studio Code. Sul lato negativo, quando si passa da un tema all'altro, è necessario ricreare o copiare manualmente le pagine dal tema corrente al nuovo, altrimenti scompariranno.

Significativamente, October CMS risolve il routing attraverso le pagine, quindi le pagine vengono utilizzate non solo come contenitori per il contenuto ma anche per funzionalità. Ad esempio, un plug-in per il blog dipende da una pagina per visualizzare l'elenco dei post del blog sotto un URL scelto, un'altra pagina per visualizzare un singolo post del blog sotto un altro URL scelto e così via. Se una di queste pagine scompare, la funzionalità associata dal plug-in non è disponibile e quell'URL produrrà un 404. Pertanto, in ottobre i temi e i plug-in CMS non vengono completamente disaccoppiati e il cambio di tema deve essere eseguito con attenzione.

Funzionalità core vs plug-in

WordPress tenta di fornire una funzionalità di base minima che viene migliorata tramite i plug-in. WordPress si basa sulla "regola ⁸⁰ ⁄ ₂₀ " per decidere se includere o meno alcune funzionalità nella sua esperienza principale. Se avvantaggia l'80% degli utenti entra, altrimenti appartiene a plugin-land. Quando si aggiungono plug-in a un sito, possono gonfiarsi se vengono installati troppi plug-in. I plug-in potrebbero anche non funzionare bene tra loro, eseguire codice simile o caricare risorse simili, con prestazioni non ottimali. Quindi, mentre avviare un sito WordPress è relativamente facile, una sfida più grande è la sua manutenzione generale e la capacità di preservare uno stato ottimale e performante quando si aggiungono nuove funzionalità.

Allo stesso modo, October CMS tenta anche di fornire una funzionalità core minima, ma con steroidi: l'unica funzionalità garantita è la creazione e pubblicazione di pagine e per tutto il resto dovremo installare un plug-in o un altro, che si esprime come:

"Tutto ciò di cui hai bisogno e niente che non ti serve."

L'obiettivo è chiaro: i siti più semplici sono composti solo da pagine, possibilmente senza post di blog, utenti o area di accesso. Allora perché l'applicazione dovrebbe caricare risorse per questi quando non sono necessari? Di conseguenza, le funzionalità per il blogging, la gestione degli utenti, la traduzione e molte altre vengono rilasciate tramite la directory dei plugin.

October CMS include anche alcune funzionalità nel suo core che (anche se non sono sempre necessarie) possono migliorare significativamente l'applicazione. Ad esempio, fornisce supporto pronto all'uso per caricare file multimediali su Amazon S3 e accedervi tramite Rackspace CDN. Include anche un Media Manager che viene utilizzato principalmente tramite plug-in, ad esempio per aggiungere immagini in un post del blog. (Le pagine possono anche utilizzare Media Manager per incorporare file multimediali, tuttavia, il CMS viene fornito anche con una sezione Risorse per caricare file multimediali per questi che sembra più adatto.)

Credo che l'ostinazione di October possa permetterci perfettamente di produrre un'applicazione il più snella possibile, per lo più relativa a siti semplici. Tuttavia, può anche ritorcersi contro e incoraggiare il rigonfiamento, perché la linea di ciò che è necessario e ciò che non lo è è arbitraria ed è difficile essere impostata in anticipo dal CMS. Questa difficoltà può essere apprezzata quando si considera il concetto di "utente": in WordPress, gli utenti del sito Web e gli amministratori del sito Web appartengono alla stessa entità utente (e tramite ruoli e privilegi possiamo far diventare un utente un amministratore). In ottobre CMS, questi due vengono implementati separatamente, consegnando in core l'implementazione per l'amministratore del sito web che può accedere all'area backend e modificare le impostazioni, e attraverso un plug-in l'implementazione dell'utente del sito web. Questi due tipi di utenti hanno un processo di accesso diverso e una tabella di database diversa per archiviare i propri dati, violando così probabilmente il principio DRY (Don't Repeat Yourself).

Questo problema si pone non solo riguardo al comportamento di un'entità ma anche a quali campi di dati deve contenere. Ad esempio, i campi dei dati utente del sito Web devono essere predefiniti? È obbligatorio un campo telefonico? Che ne dici di un campo URL di Instagram, considerando che Instagram è diventato un po' interessante solo di recente? Ma poi, quando si crea un sito Web professionale, non dovremmo invece utilizzare un campo URL di LinkedIn? Queste decisioni dipendono chiaramente dall'applicazione e non possono essere decise né dal CMS né dal plug-in.

Il plug-in CMS di ottobre chiamato Utente implementa gli utenti ma senza alcun campo utente, oltre al quale il plug-in User Plus aggiunge diversi campi utente arbitrari, che potrebbero non essere sufficienti, quindi il plug-in User Plus+ aggiunge ancora altri campi utente. Quando, dove e come fermiamo questo processo?

Un altro problema è quando non c'è spazio per aggiungere nuove capacità a un'entità, il che porta alla creazione di un'altra entità estremamente simile, solo per supportare quelle capacità richieste. Ad esempio, October CMS viene fornito con le pagine e consente di creare "pagine statiche" tramite un plug-in. La loro natura è la stessa: sia le pagine che le pagine statiche vengono salvate come file statici. L'unica differenza tra loro (per quanto ne so) è che le pagine statiche vengono modificate con un editor visivo anziché con l'editor HTML e possono essere aggiunte ai menu. Secondo me, solo differenze strutturali, come avere un'entità salvata come file statico e l'altra archiviata nel database, potrebbero giustificare la creazione di una seconda entità per una pagina (c'è una richiesta pull per farlo), ma per semplice caratteristiche, come è il caso attualmente, costituisce un rigonfiamento dello sviluppo.

In sintesi, un'applicazione CMS di ottobre ben implementata può essere molto snella ed efficiente (ad esempio rimuovendo il database quando non necessario), ma al contrario può anche diventare inutilmente gonfia, costringendo gli sviluppatori a implementare diverse soluzioni per entità simili e che possono essere molto confuso da usare ("Dovrei usare una pagina o una pagina statica?"). Poiché né WordPress né October CMS hanno trovato una soluzione perfetta per rimuovere il rigonfiamento, dobbiamo progettare con cura l'architettura dell'applicazione per evitare problemi lungo la strada.

Creazione di contenuti

Gutenberg apporta due importanti contributi a WordPress: utilizza i componenti come unità per i cantieri (che offre diversi vantaggi rispetto alla codifica di blob HTML) e introduce un'entità chiamata "blocco" che, una volta completata la Fase 2 di Gutenberg (presumibilmente in 2019), fornirà un modo unificato per incorporare i contenuti nel sito, consentendo così un'esperienza utente più semplice rispetto al processo più caotico di aggiunta di contenuti tramite codici brevi, pulsanti TinyMCE, menu, widget e altri.

Poiché i blocchi Gutenberg possono produrre e salvare HTML statico come parte del post del blog, l'installazione di molti blocchi Gutenberg non si traduce necessariamente in un rigonfiamento sul sito Web dal lato utente, ma può essere limitato al lato amministratore. Quindi, Gutenberg può senza dubbio essere considerato un buon approccio per produrre siti Web in modo modulare, con un'esperienza utente semplice ma potente per la creazione di contenuti. Forse il più grande svantaggio è il requisito (inevitabile, ma non così facile) di imparare React, la cui curva di apprendimento è piuttosto ripida.

Se i componenti di React sono l'unità di base per la creazione di contenuti in WordPress, October CMS si basa sulla premessa che conoscere il buon vecchio HTML è sufficiente per creare siti. Infatti, quando creiamo una pagina, ci viene semplicemente presentato un editor HTML (Markup):

Se la pagina fosse esclusivamente HTML statico, non ci sarebbe bisogno di un CMS. Invece, le pagine CMS di ottobre vengono scritte utilizzando modelli Twig che vengono compilati in un semplice codice PHP ottimizzato. Possono selezionare un layout per includere l'impalcatura della pagina (cioè elementi ripetitivi, come l'intestazione, il piè di pagina e così via), possono implementare segnaposto, che sono definiti nel layout per consentire alla pagina di personalizzare il contenuto e possono includere parziali, che sono blocchi di codice riutilizzabili. Inoltre, le pagine possono includere blocchi di contenuto, che sono file di testo, HTML o Markdown che possono essere modificati da soli e possono allegare componenti che sono funzionalità implementate tramite plug-in. E infine, poiché ogni volta che l'HTML non è sufficiente e dobbiamo produrre codice dinamico, possiamo aggiungere funzioni PHP.

L'editor è tutto incentrato sull'HTML. Non esiste un'area di textarea per l'aggiunta di contenuti in modo visivo, almeno non tramite l'esperienza predefinita (questa funzionalità appartiene a plugin-land). Pertanto, la conoscenza dell'HTML potrebbe essere considerata un must per l'utilizzo di October CMS. Inoltre, i diversi input per la creazione di contenuti (pagine, layout, segnaposto, parziali, blocchi di contenuto, componenti e funzioni PHP) possono essere molto efficaci, tuttavia, non è certamente così semplice come attraverso l'interfaccia a blocchi unificata di WordPress. Può anche diventare più complesso poiché è possibile aggiungere anche altri elementi (come pagine e menu statici e frammenti) e alcuni di essi, come pagine e pagine statiche, apparentemente forniscono la stessa funzionalità, rendendo confuso decidere quando usa l'uno o l'altro.

Di conseguenza, oserei dire che mentre praticamente chiunque può utilizzare un sito WordPress dal lato amministratore, October CMS è più intuitivo per gli sviluppatori che non tecnico per l'utente, quindi i programmatori potrebbero trovarlo una gioia da usare, ma alcuni altri ruoli (addetti al marketing, addetti alle vendite e simili) potrebbero trovarlo non intuitivo.

Direttore multimediale

Sia WordPress che October CMS vengono forniti con un Media Manager che consente di aggiungere file multimediali al sito senza sforzo, supportando l'aggiunta di più file contemporaneamente tramite un'interfaccia drag-and-drop e visualizzando le immagini all'interno dell'area dei contenuti. Sembrano e si comportano in modo simile; le uniche differenze notevoli che ho riscontrato sono che Media Manager di WordPress consente di incorporare gallerie di immagini e Media Manager di ottobre consente di creare manualmente una struttura di cartelle in cui posizionare i file caricati.

Dall'introduzione di Gutenberg, tuttavia, le capacità multimediali di WordPress sono state notevolmente migliorate, consentendo di incorporare video, immagini e gallerie fotografiche rispetto a un'area di testo textarea (che fornisce solo una versione non accurata di come apparirà nel sito) e sbloccare funzionalità potenti ma facili da usare come mostrato in questo video.

Internazionalizzazione

Il core di WordPress utilizza gettext per abilitare la traduzione di temi e plugin. Partendo da un file .pot contenente tutte le stringhe da tradurre, dobbiamo creare un file .po contenente la loro traduzione nella lingua/locale corrispondente, e questo file viene quindi compilato in un file .mo binario adatto per l'estrazione rapida della traduzione. Gli strumenti per eseguire queste attività includono GlotPress (online) e Poedit (applicazione scaricabile). Convenientemente, questo meccanismo funziona anche per la localizzazione lato client per Gutenberg.

WordPress attualmente non fornisce alcuna soluzione nel core per tradurre i contenuti e non lo farà fino alla Fase 4 di Gutenberg (mirata per l'anno 2020+). Fino ad allora, questa funzionalità è fornita da plugin che offrono diverse strategie per la memorizzazione e la gestione dei contenuti tradotti. Ad esempio, mentre plug-in come Polylang e WPML memorizzano ogni traduzione su una propria riga da una tabella di database personalizzata (che è pulita poiché non mescola il contenuto insieme, ma più lenta poiché richiede INNER JOIN aggiuntiva di due tabelle quando si interroga il database), il plugin qTranslate X memorizza tutte le traduzioni sullo stesso campo dalla tabella del database originale (più veloce per interrogare i dati, ma il contenuto mescolato insieme può produrre danni al sito se si disabilita il plugin). Quindi, possiamo guardarci intorno e decidere la strategia più adatta alle nostre esigenze.

October CMS non fornisce la funzionalità multilingue attraverso il suo core, ma come un plug-in creato dal team di October CMS che garantisce un'integrazione impeccabile nel sistema. Da un punto di vista funzionale, questo plugin mantiene ciò che promette. Da un punto di vista dello sviluppo, non è proprio l'ideale come funziona effettivamente questo plugin. In WordPress, una pagina è semplicemente un post con il tipo di post "pagina" e c'è un unico meccanismo di traduzione per loro, ma in ottobre CMS, ci sono entità "pagina", "pagina statica" e "post del blog" e, anche se abbastanza simili, richiedono tre diverse implementazioni per le loro traduzioni! Quindi, il contenuto di una "pagina" può includere codici di messaggio (ad esempio codici chiamati nav.content , header.title e così via), ognuno dei quali contiene le sue traduzioni per tutte le localizzazioni come oggetto JSON serializzato nella tabella del database rainlab_translate_messages . Il contenuto di una "pagina statica" viene creato in un nuovo file statico per locale, tuttavia, tutti gli URL tradotti per tutte le impostazioni locali non vengono archiviati nel file corrispondente ma nel file della lingua predefinita. Il contenuto del "post del blog" viene archiviato come oggetto JSON serializzato con una riga per locale nella tabella del database rainlab_translate_attributes e l'URL tradotto viene archiviato con una riga per locale nella tabella del database rainlab_translate_indexes . Non so se questa complessità sia dovuta a come è stato implementato il plugin o se sia dovuta all'architettura di October CMS. In ogni caso, questo è un altro esempio di rigonfiamento indesiderato dal lato dello sviluppo.

Gestione dei plugin

Sia WordPress che October CMS offrono un sofisticato gestore di plug-in che consente di cercare plug-in, installare nuovi plug-in e aggiornare i plug-in attualmente installati all'ultima versione, il tutto dall'interno del back-end.

Gestione delle dipendenze

October CMS utilizza Composer come gestore di pacchetti preferito, consentendo ai plug-in di scaricare e installare le loro dipendenze durante l'installazione, offrendo così un'esperienza indolore.

WordPress, sul lato opposto, non ha adottato ufficialmente Composer (o qualsiasi gestore di dipendenze PHP) perché la comunità non può essere d'accordo se WordPress sia un sito o una dipendenza da un sito. Quindi, se richiedono Composer per i loro progetti, gli sviluppatori devono aggiungerlo da soli. Con il passaggio a Gutenberg, npm è diventato il gestore delle dipendenze JavaScript preferito, con un popolare toolkit per sviluppatori che dipende da esso e le librerie lato client vengono costantemente rilasciate come pacchetti autonomi nel registro npm.

Interazione con il database

WordPress fornisce funzioni per recuperare i dati del database (come get_posts ) e archiviarli (come wp_insert_post e wp_update_post ). Durante il recupero dei dati, possiamo passare parametri per filtrare, limitare e ordinare i risultati, in modo da indicare se il risultato deve essere passato come istanza di una classe o come array di proprietà e altro. Quando la funzione non soddisfa pienamente i nostri requisiti (ad esempio quando dobbiamo eseguire un INNER JOIN con una tabella personalizzata), possiamo interrogare il database direttamente tramite la variabile globale $wpdb . Quando si crea un plug-in con un tipo di post personalizzato, molto probabilmente il codice eseguirà query SQL personalizzate per recuperare e/o salvare dati in tabelle personalizzate. In sintesi, WordPress tenta di fornire l'accesso al database tramite funzioni generiche nella prima fase e tramite un accesso di basso livello al database nella seconda fase.

October CMS utilizza un approccio diverso: invece di connettersi immediatamente al database, l'applicazione può utilizzare Eloquent ORM di Laravel per accedere e manipolare i dati del database attraverso istanze di classi denominate Modelli, rendendo l'interazione con il database anche basata sulla programmazione orientata agli oggetti . È un accesso di alto livello; semplicemente seguendo le regole su come creare tabelle e impostare relazioni tra entità, un plugin può recuperare e/o salvare dati senza scrivere una riga di SQL. Ad esempio, il codice seguente recupera un oggetto dal database tramite il modello Flight , modifica una proprietà e la memorizza di nuovo:

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

Aggiornamento del modello di dati

Un altro motivo del successo di WordPress (oltre a non compromettere la compatibilità con le versioni precedenti) è stata la sua architettura di database, progettata per consentire alle applicazioni di crescere nel tempo. Questo obiettivo viene raggiunto attraverso proprietà “meta”, cioè proprietà che possono essere aggiunte liberamente a un oggetto di database in qualsiasi momento. Queste proprietà non vengono memorizzate in una colonna dalla tabella di entità corrispondente ( wp_posts , wp_users , wp_comments o wp_terms ), ma invece come una riga nella tabella "meta" corrispondente ( wp_postmeta , wp_usermeta , wp_commentmeta o wp_termmeta ) e recuperate facendo un INNER JOIN . Pertanto, anche se il recupero di questi meta valori è più lento, forniscono una flessibilità illimitata e raramente il modello di dati dell'applicazione deve essere riprogettato da zero per implementare alcune nuove funzionalità.

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 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.

Comunità

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?

Alimentando un terzo di tutti i siti nel mondo, WordPress non è a corto di parti interessate che contribuiscono al software; quindi non dobbiamo temere che il software cada in decadimento. Tuttavia, WordPress sta attraversando deliberazioni interne riguardanti il ​​suo modello di governance, con molti membri della comunità che esprimono che le decisioni riguardanti la direzione di WordPress vengono prese unilateralmente da Automattic, la società che gestisce WordPress.com. Al centro di questa percezione è stata la decisione di lanciare Gutenberg, su cui molti membri non erano d'accordo e che ha subito la mancanza di una comunicazione adeguata da parte dei responsabili del progetto durante il suo sviluppo e rilascio. Di conseguenza, molti membri della comunità stanno mettendo in discussione il ruolo di "dittatore benigno", che è stato storicamente concesso al fondatore di WordPress e CEO di Automattic Matt Mullenweg, e stanno ricercando diversi modelli di governance per trovarne uno più adatto per il futuro di WordPress. È ancora da vedere se questa ricerca produca qualche risultato, o se lo status quo persevera.

Le decisioni riguardanti la direzione di October CMS sono prese principalmente dai fondatori Alexey Bobkov e Samuel Georges e dallo sviluppatore e community manager Luke Towers, che mantengono forte il progetto. October CMS non ha ancora il lusso di avere un problema di governance: la sua attuale preoccupazione è come rendere il progetto sostenibile generando entrate per i manutentori del software principale.

Documentazione

La documentazione di WordPress nel proprio sito non è estremamente completa, ma fa il lavoro abbastanza bene. Tuttavia, quando si tiene conto di tutta la documentazione su WordPress da tutte le fonti, come siti generici (Smashing Magazine, trucchi CSS e molti altri), siti specializzati (WPShout, WPBeginner e molti altri), blog personali, corsi online, e così via, non c'è praticamente nessun aspetto della gestione di WordPress che non sia già stato trattato.

October CMS non gode di nulla vicino ai numerosi corsi, tutorial o post di blog di terze parti al riguardo tanto quanto WordPress, tuttavia, la documentazione sul suo sito è ragionevolmente completa e sicuramente sufficiente per iniziare a programmare. I fondatori di ottobre aggiungono regolarmente anche nuova documentazione tramite tutorial. Un aspetto che personalmente mi è piaciuto è la duplicazione della documentazione di Laravel nella documentazione di October per tutto ciò che è rilevante, quindi il lettore non deve colmare le lacune da solo e dover indovinare qual è il dominio di October e quale è quello di Laravel. Tuttavia, questo non è perfetto al 100%. La documentazione di October utilizza termini provenienti da Laravel, come middleware, contenitori di servizi, facciate e contratti, senza spiegare adeguatamente di cosa si tratta. Quindi, leggere in anticipo la documentazione di Laravel può essere utile (fortunatamente, la documentazione di Laravel è decisamente completa e gli screencast di Laravel, Laracast, sono un'altra grande fonte di apprendimento, non solo per quanto riguarda Laravel ma lo sviluppo web in generale).

Conclusione

Ho deciso di scoprire quali funzionalità potrebbero essere allettanti per gli sviluppatori che cercano alternative a WordPress confrontando WordPress con un CMS simile, che ho definito gratuito e open source, basato su PHP e producendo contenuti dinamici, e godendo del supporto di alcune comunità . Tra i CMS che soddisfano queste condizioni, ho scelto October CMS per il confronto per via delle mie conoscenze e perché ho apprezzato il suo approccio di codifica pulito e modulare fornito da Laravel, che potrebbe offrire una prospettiva fresca e moderna per i cantieri.

Questo articolo non intendeva scegliere un vincitore, ma semplicemente analizzare quando ha senso scegliere l'uno o l'altro CMS, evidenziandone i punti di forza e di debolezza. Non esiste un CMS “migliore”: solo il CMS più adatto ad una specifica situazione. Inoltre, chiunque cerchi un CMS da utilizzare su un particolare progetto con un team specifico e con un determinato budget, dovrebbe fare qualche ricerca e confrontare tutte le offerte disponibili per scoprire quale è più adatto al particolare contesto. È importante non limitarsi a pochi CMS come ho fatto qui in questo articolo, ma dare invece una possibilità a tutti loro.

Da una nota personale, come sviluppatore, quello che ho trovato in ottobre CMS è davvero interessante per me, soprattutto la sua capacità di creare applicazioni modulari fornite tramite Laravel. Prenderei sicuramente in considerazione questo CMS per un nuovo sito web. Tuttavia, nel processo di scrittura di questo articolo ho anche “riscoperto” WordPress. Essendo così popolare, WordPress riceve più della sua giusta dose di critiche, principalmente riguardo alla sua vecchia base di codice e, da poco, all'introduzione di Gutenberg; tuttavia, WordPress ha anche alcune caratteristiche eccellenti (come il suo modello di database super scalabile) che sono raramente elogiate ma dovrebbero anche essere prese in considerazione. E, soprattutto, WordPress non dovrebbe essere considerato solo per i suoi aspetti tecnici: in particolare, le dimensioni della sua comunità e del suo ecosistema lo collocano di un livello o due al di sopra delle sue alternative. In poche parole, alcuni progetti potrebbero trarre vantaggio dall'adesione a WordPress, mentre altri potrebbero fare affidamento su October CMS o su un'altra piattaforma.

Come nota finale, vorrei sottolineare che esplorare come funziona un altro CMS è un'attività molto gratificante di per sé, indipendentemente dalla decisione presa in merito all'utilizzo o meno di quel particolare CMS. Nel mio caso, ho lavorato per anni solo su WordPress e approfondire il CMS di ottobre è stato molto rinfrescante poiché mi ha insegnato molte cose (come l'esistenza delle raccomandazioni sugli standard PHP) a cui non ero stato esposto tramite WordPress. Ora potrei decidere di cambiare CMS o attenermi a WordPress sapendo come produrre codice migliore.

Ulteriori letture su SmashingMag:

• Memorizzazione nella cache intelligente nell'era di Gutenberg
• Miglioramento del codice WordPress con PHP moderno
• Lezioni apprese durante lo sviluppo di plugin per WordPress
• Come utilizzare le mappe di calore per tenere traccia dei clic sul tuo sito Web WordPress
• Fai attenzione: funzioni PHP e WordPress che possono rendere insicuro il tuo sito