O comparație detaliată între WordPress și CMS octombrie

În urmă cu trei luni, WordPress a lansat în sfârșit Gutenberg alimentat de React pentru a-și alimenta experiența implicită de editare a conținutului, determinând mulți oameni care nu sunt mulțumiți de această schimbare să caute alternative. Unii oameni au decis să forkeze și să lanseze WordPress pre-Gutenberg, totuși, pentru mine, acest lucru nu are prea mult sens, deoarece încă mai are 15 ani de datorii tehnice. Dacă ar fi să găsesc o alternativă la WordPress, aș încerca să evit să fiu blocat în trecut și aș viza o tăietură curată printr-o platformă matură construită pe baze moderne.

Acest articol compară WordPress cu CMS-ul octombrie, probabil similar, dar mai modern, pe o gamă largă de subiecte atât tehnice, cât și non-tehnice. Scopul articolului nu este de a convinge oamenii să rămână pe WordPress sau să treacă la CMS octombrie, ci pur și simplu să demonstreze ce aspecte trebuie luate în considerare înainte de a încheia mutarea pe o altă platformă. Aceeași comparație ar putea (și ar trebui) să fie făcută și cu alte platforme înainte de a lua o decizie sensibilă.

De ce octombrie CMS

Am aflat despre CMS din octombrie când a câștigat un premiu, după care am intrat în modul de cercetare și am petrecut mult timp să sapă adânc în acest CMS - atât din perspectiva unui utilizator, cât și a unui dezvoltator. Pe măsură ce am acumulat cunoștințe despre acest CMS, m-am simțit încrezător că aș putea oferi o evaluare obiectivă a caracteristicilor sale, spre deosebire de WordPress. Am ales acest CMS pentru comparație față de opțiuni alternative precum Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo și altele, din următoarele motive:

• Știu cum funcționează acest CMS (spre deosebire de Grav);
• Este gratuit și open source (spre deosebire de Statamic și ButterCMS);
• La cinci ani, este „relativ” nou (spre deosebire de Joomla și Drupal);
• Este un generator de conținut dinamic (nu static) și bazat pe PHP (spre deosebire de Jekyll și Hugo).
  

Cred că October CMS este un candidat bun, deoarece se bazează pe Laravel, care este un cadru folosit pentru construirea de aplicații moderne. După șapte ani de existență, a primit aprobare pozitivă de la dezvoltatori (după cum o demonstrează comunitatea și ecosistemul său considerabil) și marchează un contrast distinct față de codificarea în WordPress, adică WordPress este mai ales programare procedurală, în timp ce Laravel este programare orientată pe obiecte.

Care este diferența dintre cei doi?

Mai jos voi compara WordPress și Octombrie CMS pe diferite categorii și voi evidenția ceea ce, cred eu, este bun și nu atât de bun la ele. Cu toate acestea, nu voi alege un câștigător, deoarece acesta nu este obiectivul articolului și, în orice caz, nu există un CMS „cel mai bun” sau chiar „mai bun”: fiecare CMS are propriul său set de puncte tari și puncte slabe care îl vor face. mai mult sau mai puțin potrivit pentru fiecare sarcină, proiect, companie, echipă și orice altceva. Mai mult, un proiect poate beneficia de utilizarea a mai mult de un CMS, cum ar fi utilizarea unor CMS pentru a gestiona și furniza date și a unui alt CMS pentru a reda vizualizarea. Pentru a decide care dintre zecile de CMS-uri existente este cel mai potrivit pentru propriile nevoi, depinde în întregime de dvs.

În plus, acest articol nu ar putea trage niciodată concluzii definitive, deoarece se referă doar la un subset al tuturor posibilităților. De exemplu, putem găsi și comparații online precum „WordPress vs Drupal vs Joomla”, „WordPress vs Static Site Generators” și chiar „WordPress vs Medium”. Deoarece niciunul dintre aceste articole nu vede imaginea completă, atunci nici una dintre aceste comparații nu poate fi vreodată concludentă și nu ar trebui tratată ca atare.

Să începem cu comparația.

Filosofie și grup țintă

Nu este o coincidență că WordPress alimentează aproape 1 din 3 site-uri web. Încă de la înființare, s-a străduit să fie extrem de ușor de utilizat și a făcut acest lucru cu succes, eliminând frecarea atât pentru utilizatorii tehnici, cât și pentru utilizatorii non-tehnici, precum și pentru oamenii din toate mediile, indiferent de educația și nivelul economic. Fondatorul WordPress, Matt Mullenweg, a spus că motto-ul WordPress „Democratizează publicarea” pentru epoca actuală a însemnat următoarele:

„Oamenii de toate mediile, interesele și abilitățile ar trebui să poată accesa software-ul Free-as-in-speech care le dă puterea să se exprime pe web deschis și să-și dețină conținutul.”

WordPress este ușor de utilizat pentru toată lumea, iar incluziunea sa este evidențiată și în ceea ce privește dezvoltarea: nu este neobișnuit să găsești oameni fără cunoștințe de programare (cum ar fi marketeri, designeri, bloggeri, oameni de vânzări și alții) care își schimbă instalațiile WordPress, proiectează propriile teme și lansarea cu succes a propriilor site-uri web. WordPress este centrat pe utilizator, iar nevoile utilizatorilor le depășesc pe cele ale dezvoltatorilor. În WordPress, utilizatorul este rege (sau regină).

În schimb, October CMS este mai orientat către dezvoltator, așa cum s-a stabilit explicit încă de la prima sa lansare:

„Octombrie face o presupunere îndrăzneață, dar evidentă: clienții nu construiesc site-uri web, dezvoltatorii fac. Rolul unui client este de a gestiona site-ul web și de a-și transmite cerințele de afaceri. Dezvoltatorul web și industria în sine se învârt în jurul medierii acestor factori.”

În cuvintele fondatorilor săi, misiunea CMS este să „demonstreze că realizarea de site-uri web nu este știință rachetă”. Bazat pe Laravel, October CMS poate pretinde că are baze solide de cod reutilizabil, modular, care poate produce aplicații bine arhitecturate, care pot fi întreținute pe termen lung și complet personalizabile fără a necesita hack-uri - tipul care atrage programatori serioși. Octombrie CMS poate oferi, de asemenea, o experiență excelentă pentru utilizator, cu toate acestea, nu este la fel de simplu sau fără fricțiuni precum cel oferit de WordPress. Este posibil ca utilizatorilor să fie nevoie să li se explice cum să folosească anumite funcționalități înainte de a le putea folosi. De exemplu, încorporarea unui formular dintr-un plugin are o explicație lungă despre cum se face, care este mai greoaie decât funcționalitatea evidentă, de tip drag-and-drop oferită de mai multe plugin-uri de formulare din WordPress.

Instalare

WordPress este renumit pentru instalarea sa de 5 minute, chiar dacă mulți oameni subliniază că (ținând cont de toate pluginurile care trebuie instalate) o instalare tipică necesită 15 minute sau mai mult. În plus, WordPress oferă și caracteristica Multisite, care ne permite să creăm o rețea de mai multe site-uri virtuale sub o singură instalare. Această caracteristică facilitează pentru o agenție să administreze site-urile mai multor clienți, printre alte cazuri de utilizatori.

Instalarea October CMS este, de asemenea, foarte simplă: instalarea Wizard în sine durează chiar mai puțin de cinci minute, iar dacă o instalați prin instalarea Consolei, este și mai rapidă. Puteți face acest lucru din urmă pur și simplu navigând la directorul țintă și apoi executând curl -s https://octobercms.com/api/installer | php curl -s https://octobercms.com/api/installer | php (după care trebuie să introducem configurația bazei de date, altfel se comportă ca un CMS cu fișier plat). Odată finalizată instalarea, vom avea un site web complet funcțional, dar încă destul de gol (dacă adăugați timpul necesar pentru a instala și configura pluginurile necesare, vă puteți aștepta să dureze cel puțin 15 minute).

Securitate

WordPress a fost acuzat că este nesigur din cauza cantității mari de vulnerabilități care se găsesc în mod constant. Acest lucru obligă utilizatorii să aibă software-ul pentru CMS și toate pluginurile instalate mereu la zi, pentru a evita exploatările de securitate. Printre problemele principale se numără suportul WordPress pentru versiunile mai vechi de PHP, care nu mai sunt acceptate de comunitatea de dezvoltare PHP (WordPress acceptă în prezent PHP 5.2.4, în timp ce cea mai recentă versiune PHP complet acceptată este 5.6). Cu toate acestea, această problemă ar trebui să fie rezolvată în aprilie 2019, când WordPress va începe oficial să accepte versiunile PHP 5.6 și versiuni ulterioare.

În caz contrar, WordPress nu este neapărat nesigur din cauza sa, ci din cauza popularității sale ridicate, ceea ce îl face o țintă principală pentru hackeri. Cu toate acestea, acest lucru joacă în ambele sensuri: ubicuitatea WordPress înseamnă că echipa sa de securitate trebuie să-și ia cu adevărat treaba în serios, căutând în mod constant exploit-uri și reparându-le cât mai curând posibil, altfel până la o treime din web este în pericol. Miza este pur și simplu prea mare.

Octombrie CMS, pe de altă parte, nu are reputația de a fi nesigur. Cu toate acestea, deoarece există aproximativ 27.000 de site-uri live care folosesc octombrie în comparație cu milioanele WordPress, nu le putem judeca pe cele două în aceiași termeni. Cu toate acestea, echipa din spatele CMS Octombrie ia în serios securitatea, așa cum demonstrează solicitarea instalației Expertului de a introduce adresa URL de backend CMS, setată ca /backend în mod implicit, dar care poate fi schimbată cu orice altceva, pentru a face mai dificilă pentru hackeri să vizeze site-ul. . În schimb, schimbarea adreselor URL de conectare și backend ale WordPress de la /wp-login.php și, respectiv, /wp-admin în altceva trebuie făcută printr-un plugin. În plus, October CMS poate funcționa ca un CMS cu fișier plat (adică fără o bază de date) și poate evita vulnerabilitățile legate de baze de date, cum ar fi injecția SQL.

Stiva de tehnologie

Atât WordPress, cât și CMS octombrie rulează pe stiva tradițională LAMP: Linux, Apache, MySQL și PHP. (Totuși, numai PHP este fix: putem folosi și Windows, Nginx, MariaDB și altele.) October CMS se poate comporta și ca un CMS cu fișier plat, ceea ce înseamnă că se poate descurca fără o bază de date, cu prețul renunțării. multe funcționalități (cum ar fi postări de blog și utilizatori), singura funcționalitate care este garantată sunt paginile, care sunt considerate a fi unitatea de bază pentru crearea și publicarea de conținut și livrate ca o caracteristică de bază.

În ceea ce privește stiva de limbi, site-urile construite atât cu WordPress, cât și cu CMS October se bazează pe HTML, CSS și JavaScript (rețineți că PHP este folosit pentru a genera HTML). October CMS facilitează, de asemenea, utilizarea fișierelor LESS și SASS.

Paradigma de programare

WordPress urmează o paradigmă de programare funcțională, bazată pe calcularea calculelor apelând funcții lipsite de starea aplicației. Chiar dacă dezvoltatorii WordPress nu trebuie să se țină de programarea funcțională (de exemplu, pentru codificarea temelor și a pluginurilor), codul de bază WordPress moștenește această paradigmă de la 15 ani de păstrare a compatibilității inverse, care a fost unul dintre pilonii succesului WordPress. dar care are drept consecinţă neintenţionată acumularea datoriilor tehnice.

Pe de altă parte, October CMS urmează o paradigmă de programare imperativă, bazată pe calcularea calculelor prin manipularea stării obiectelor. Octombrie CMS se află deasupra Laravel, un cadru web complet bazat pe principiile de programare orientată pe obiecte care permit producerea de aplicații modulare bazate pe concepte precum Model-View-Controller pentru a decupla interfața utilizator de datele aplicației, Dependency Injection la configurați dependențele de clasă și Principiul de segregare a interfeței pentru a defini serviciile de bază furnizate de cadru, printre multe altele.

Cârlige/Evenimente

Programarea în WordPress ar putea fi caracterizată ca HDD, care înseamnă „Hook-Driven Development”. Un cârlig este un mecanism care permite modificarea unui comportament sau o valoare implicită și care permite altor coduri să execute funcționalitatea aferentă. Cârligele sunt declanșate prin „acțiuni” care permit executarea de funcționalități suplimentare și „filtre” care permit modificarea valorilor.

Cârligele, care sunt larg răspândite în baza de coduri WordPress, sunt unul dintre conceptele care îmi plac cel mai mult de la codificare în WordPress. Acestea permit pluginurilor să interacționeze cu alte plugin-uri (sau cu un nucleu sau o temă) într-un mod curat, oferind un suport de bază pentru programarea orientată pe aspecte.

Vestea bună este că Laravel (și, în consecință, CMS octombrie) susține și conceptul de cârlige, care se numește „evenimente”. Evenimentele oferă o implementare simplă de observator, permițând codului să se aboneze și să asculte evenimentele care apar în aplicație și să reacționeze după cum este necesar. Evenimentele fac posibilă împărțirea unei funcționalități complexe în componente, care pot fi instalate independent, dar colaborează între ele, permițând astfel crearea de aplicații modulare.

Dependență de bibliotecile JavaScript

Cea mai recentă versiune de WordPress încorporează Gutenberg alimentat de React pentru experiența sa implicită de creare de conținut. Prin urmare, dezvoltarea WordPress se bazează acum în mare parte pe JavaScript (predominant prin React), chiar dacă este posibil să se utilizeze și alte cadre sau biblioteci (după cum demonstrează Elementor Blocks pentru Gutenberg, care se bazează pe Marionette). În plus, WordPress se bazează în continuare pe Backbone.js (pentru Media Manager) și jQuery (codul moștenit), cu toate acestea, ne putem aștepta ca dependența de aceste biblioteci să dispară pe măsură ce Gutenberg este consolidată ca nouă normă.

Octombrie CMS depinde de jQuery, pe care îl folosește pentru a implementa cadrul său opțional AJAX pentru a încărca date de pe server fără o reîmprospătare a paginii browserului.

Pagini, teme și pluginuri

Atât WordPress, cât și CMS octombrie tratează o pagină ca unitate de bază pentru crearea și publicarea conținutului (în cazul WordPress, pe lângă postare), acceptă schimbarea aspectului și simțului site-ului prin teme și permit instalarea și extinderea funcționalităților site-ului prin plugin-uri . Chiar dacă conceptele sunt aceleași în ambele CMS, există câteva diferențe în implementare care produc un comportament oarecum diferit.

În WordPress, paginile sunt definite ca conținut și stocate în baza de date. Ca urmare, conținutul paginii poate fi creat numai prin CMS (de exemplu, în zona tabloului de bord), iar trecerea de la o temă la alta nu face ca o pagină existentă să devină indisponibilă. Acest lucru produce o experiență generală fără frecare.

În octombrie CMS, pe de altă parte, paginile sunt fișiere statice stocate în directorul temei. Pe partea pozitivă a acestei decizii arhitecturale, conținutul paginii poate fi creat dintr-o aplicație externă, cum ar fi editori de text precum Sublime sau Visual Studio Code. Pe partea negativă, la trecerea de la o temă la alta, este necesară recrearea sau copierea manuală a paginilor din tema curentă în noua, altfel acestea vor dispărea.

În mod semnificativ, October CMS rezolvă rutarea prin pagini, prin urmare paginile sunt folosite nu doar ca containere pentru conținut, ci și pentru funcționalitate. De exemplu, un plugin pentru blogging depinde de o pagină pentru afișarea listei de postări de blog sub o adresă URL aleasă, de o altă pagină pentru afișarea unei singure postări de blog sub o adresă URL aleasă și așa mai departe. Dacă oricare dintre aceste pagini dispare, funcționalitatea asociată din plugin devine indisponibilă, iar acea adresă URL va produce un 404. Prin urmare, în octombrie temele și pluginurile CMS nu sunt complet decuplate, iar schimbarea temelor trebuie făcută cu atenție.

Funcționalitate de bază vs plugin

WordPress încearcă să ofere o funcționalitate de bază minimă, care este îmbunătățită prin pluginuri. WordPress se bazează pe „regula ^80⁄ ₂₀ ” pentru a decide dacă include sau nu unele funcționalități în experiența sa de bază. Dacă beneficiază 80% dintre utilizatorii în care intră, în caz contrar, aparține plugin-land. Când adăugați pluginuri pe un site, acestea pot duce la balonare dacă sunt instalate prea multe plugin-uri. De asemenea, pluginurile pot să nu funcționeze bine între ele sau să execute cod similar sau să încarce active similare, ceea ce duce la performanțe suboptime. Prin urmare, în timp ce lansarea unui site WordPress este relativ ușoară, o provocare mai mare este întreținerea generală a acestuia și posibilitatea de a păstra o stare optimă și performantă atunci când adăugați noi funcții.

De asemenea, October CMS încearcă să ofere și o funcționalitate de bază minimă, dar pe steroizi: singura funcționalitate garantată este crearea și publicarea paginilor, iar pentru orice altceva va trebui să instalăm un plugin sau altul, care se exprimă astfel:

„Tot ce ai nevoie și nimic din ce nu ai.”

Obiectivul este clar: cele mai multe site-uri simple sunt compuse doar din pagini, eventual fără postări de blog, utilizatori sau zonă de conectare. Deci, de ce aplicația ar trebui să încarce resurse pentru acestea atunci când nu sunt necesare? În consecință, funcționalitățile pentru blogging, managementul utilizatorilor, traducere și multe altele sunt lansate prin directorul de pluginuri.

October CMS include, de asemenea, anumite caracteristici în nucleul său care (deși nu sunt întotdeauna necesare) pot îmbunătăți aplicația în mod semnificativ. De exemplu, oferă asistență gata de utilizare pentru a încărca fișiere media pe Amazon S3 și le accesează prin intermediul CDN-ului Rackspace. Include, de asemenea, un Media Manager care este utilizat în principal prin pluginuri, de exemplu pentru adăugarea de imagini într-o postare de blog. (Paginile pot folosi, de asemenea, Media Manager pentru a încorpora fișiere media, cu toate acestea, CMS-ul este livrat cu o secțiune de active pentru a încărca fișiere media pentru acestea, ceea ce pare mai potrivit.)

Cred că părerea lui Octombrie ne poate permite perfect să producem o aplicație cât mai slabă posibil - în principal referitoare la site-uri simple. Cu toate acestea, se poate întoarce și încuraja balonarea, deoarece linia a ceea ce este necesar și a ceea ce nu este este una arbitrară și este dificil să fie stabilită în avans de către CMS. Această dificultate poate fi apreciată atunci când luăm în considerare conceptul de „utilizator”: În WordPress, utilizatorii site-ului web și administratorii site-ului aparțin aceleiași entități de utilizator (și prin roluri și privilegii putem face ca un utilizator să devină admin). În octombrie CMS, acestea două sunt implementate separat, livrând în nucleu implementarea pentru administratorul site-ului web care se poate autentifica în zona de backend și poate modifica setările, iar printr-un plugin implementarea utilizatorului site-ului web. Aceste două tipuri de utilizatori au un proces diferit de autentificare și un tabel de bază de date diferit pentru stocarea datelor lor, încălcând astfel principiul DRY (Don’t Repeat Yourself).

Această problemă apare nu numai în ceea ce privește comportamentul unei entități, ci și ce câmpuri de date trebuie să conțină. De exemplu, câmpurile de date ale utilizatorului site-ului ar trebui să fie predefinite? Este obligatoriu un câmp de telefon? Ce zici de un câmp URL Instagram, având în vedere că Instagram s-a cam cool doar recent? Dar atunci, atunci când construim un site web profesional, nu ar trebui să folosim un câmp URL LinkedIn? Aceste decizii depind în mod clar de aplicație și nu pot fi decise nici de CMS, nici de plugin.

Pluginul CMS din octombrie numit Utilizator implementează utilizatori, dar fără niciun câmp de utilizator, peste care pluginul User Plus adaugă câteva câmpuri de utilizator arbitrare, care probabil nu sunt suficiente, așa că pluginul User Plus+ adaugă încă alte câmpuri de utilizator. Când, unde și cum oprim acest proces?

O altă problemă este atunci când nu există loc pentru a adăuga noi capabilități unei entități, ceea ce duce la crearea unei alte entități, extrem de asemănătoare, doar pentru a susține acele capabilități necesare. De exemplu, October CMS este livrat cu pagini și permite crearea de „pagini statice” printr-un plugin. Natura lor este aceeași: atât paginile cât și paginile statice sunt salvate ca fișiere statice. Singura diferență dintre ele (din câte îmi pot da seama) este că paginile statice sunt editate cu un editor vizual în loc de editorul HTML și pot fi adăugate în meniuri. După părerea mea, doar diferențele structurale, cum ar fi să aibă o entitate salvată ca fișier static și cealaltă stocată în baza de date, ar putea justifica crearea unei a doua entitati pentru o pagină (există o cerere de extragere pentru a face acest lucru), dar pentru simplu caracteristici, așa cum este cazul în prezent, constituie balonare de dezvoltare.

În rezumat, o aplicație CMS octombrie bine implementată poate fi foarte slabă și eficientă (de exemplu, prin eliminarea bazei de date atunci când nu este nevoie), dar, dimpotrivă, poate deveni și umflată inutil, forțând dezvoltatorii să implementeze mai multe soluții pentru entități similare și care pot fi foarte confuz de utilizat („Ar trebui să folosesc o pagină sau o pagină statică?”). Deoarece nici WordPress, nici CMS Octombrie nu au găsit o soluție perfectă pentru a elimina balonarea, trebuie să proiectăm oricare dintre arhitecturile aplicației cu grijă pentru a evita durerile de pe drum.

Crearea continutului

Gutenberg aduce două contribuții importante la WordPress: folosește componente ca unitate pentru șantierele de construcție (care oferă mai multe avantaje față de codarea blob-urilor de HTML) și introduce o entitate numită „bloc” care, odată ce Gutenberg Faza 2 este finalizată (probabil în 2019), va oferi o modalitate unificată de a încorpora conținut în site, permițând astfel o experiență de utilizator mai simplă, spre deosebire de procesul mai haotic de adăugare a conținutului prin coduri scurte, butoane TinyMCE, meniuri, widget-uri și altele.

Deoarece blocurile Gutenberg pot produce și salva HTML static ca parte a postării pe blog, atunci instalarea multor blocuri Gutenberg nu se traduce neapărat în umflare pe site-ul web din partea utilizatorului, dar poate fi limitată la partea de administrator. Prin urmare, Gutenberg poate fi considerat o abordare bună pentru a produce site-uri web într-un mod modular, cu o experiență de utilizator simplă, dar puternică pentru crearea de conținut. Posibil cel mai mare dezavantaj este cerința (inevitabil, dar nu ușor) de a învăța React, a cărui curbă de învățare este destul de abruptă.

Dacă componentele React sunt unitatea de bază pentru crearea de conținut în WordPress, October CMS se bazează pe premisa că cunoașterea unui HTML vechi bun este suficientă pentru a construi site-uri. Într-adevăr, atunci când creăm o pagină, ni se prezintă pur și simplu un editor HTML (Markup):

Dacă pagina ar fi doar HTML static, atunci nu ar fi nevoie de un CMS. În schimb, paginile CMS din octombrie sunt scrise folosind șabloane Twig care sunt compilate în cod PHP simplu optimizat. Ei pot selecta un aspect care să includă schelele paginii (adică elemente repetitive, cum ar fi antetul, subsolul și așa mai departe), pot implementa substituenți, care sunt definiți pe aspect pentru a permite paginii să personalizeze conținutul și pot include parțiale, care sunt bucăți de cod reutilizabile. În plus, paginile pot include blocuri de conținut, care sunt fie fișiere text, HTML sau Markdown care pot fi editate singure și pot atașa componente care sunt funcționalități implementate prin pluginuri. Și în sfârșit, pentru ori de câte ori HTML nu este suficient și trebuie să producem cod dinamic, putem adăuga funcții PHP.

Editorul este doar despre HTML. Nu există o zonă de textarea pentru adăugarea de conținut într-o manieră vizuală - cel puțin nu prin experiența implicită (această funcționalitate aparține plugin-land). Prin urmare, cunoștințele de HTML ar putea fi considerată o necesitate pentru utilizarea CMS-ului octombrie. În plus, mai multe intrări diferite pentru crearea de conținut (pagini, machete, substituenți, partiale, blocuri de conținut, componente și funcții PHP) pot fi foarte eficiente, cu toate acestea, cu siguranță nu este la fel de simplu ca prin interfața bloc unificat de la WordPress. Poate deveni chiar mai complex, deoarece pot fi adăugate și alte elemente (cum ar fi pagini și meniuri statice și fragmente), iar unele dintre ele, cum ar fi paginile și paginile statice, par să ofere aceeași funcționalitate, ceea ce face confuz să decideți când să foloseste una sau alta.

În consecință, îndrăznesc să spun că, deși aproape oricine poate folosi un site WordPress din partea administratorului, October CMS este mai prietenos pentru dezvoltatori decât ușor de utilizat non-tehnic, așa că programatorilor le poate găsi o plăcere, dar anumite altele rolurile (marketing, oameni de vânzări și altele asemenea) ar putea găsi acest lucru neintuitiv.

Manager media

Atât WordPress, cât și CMS October sunt livrate cu un Media Manager care permite adăugarea fără efort de fișiere media pe site, acceptând adăugarea mai multor fișiere simultan printr-o interfață drag-and-drop și afișarea imaginilor în zona de conținut. Ei arată și se comportă similar; singurele diferențe notabile pe care le-am găsit sunt că Media Managerul WordPress permite încorporarea galeriilor de imagini, iar Managerul Media din octombrie permite crearea manuală a unei structuri de foldere în care să plaseze fișierele încărcate.

De la introducerea lui Gutenberg, totuși, capacitățile media ale WordPress au fost îmbunătățite foarte mult, permițând încorporarea videoclipurilor, imaginilor și galeriilor foto în loc, în comparație cu o zonă de text TinyMCE (care oferă doar o versiune textarea a modului în care va arăta. pe site) și deblocarea funcțiilor puternice, dar ușor de utilizat, așa cum se arată în acest videoclip.

Internaționalizarea

Nucleul WordPress folosește gettext pentru a permite traducerea temelor și a pluginurilor. Pornind de la un fișier .pot care conține toate șirurile de tradus, trebuie să creăm un fișier .po care să conțină traducerea acestora în limba/localitatea corespunzătoare, iar acest fișier este apoi compilat într-un fișier binar .mo potrivit pentru extracția rapidă a traducerii. Instrumentele pentru a efectua aceste sarcini includ GlotPress (online) și Poedit (aplicație descărcabilă). În mod convenabil, acest mecanism funcționează și pentru localizarea pe partea clientului pentru Gutenberg.

WordPress nu oferă în prezent nicio soluție de bază pentru a traduce conținutul și nu va face acest lucru până în Faza 4 a lui Gutenberg (vizată pentru anul 2020+). Până atunci, această funcționalitate este asigurată de plugin-uri care oferă diferite strategii de stocare și gestionare a conținutului tradus. De exemplu, în timp ce pluginuri precum Polylang și WPML stochează fiecare traducere pe propriul rând dintr-un tabel de bază de date personalizat (care este curat, deoarece nu amestecă conținutul împreună, dar mai lent, deoarece necesită un INNER JOIN suplimentar de două tabele atunci când interogând baza de date), pluginul qTranslate X stochează toate traducerile în același câmp din tabelul original al bazei de date (mai rapid pentru interogarea datelor, dar conținutul amestecat poate produce ruine pe site dacă dezactivați pluginul). Prin urmare, putem căuta și decide cea mai potrivită strategie pentru nevoile noastre.

October CMS nu oferă funcționalitatea multilingvă prin nucleul său, ci ca un plugin creat de echipa October CMS care garantează o integrare fără greșeli în sistem. Din punct de vedere funcțional, acest plugin oferă ceea ce promite. Din punct de vedere al dezvoltării, nu este deloc ideal cum funcționează de fapt acest plugin. În WordPress, o pagină este pur și simplu o postare cu post de tip „pagină” și există un singur mecanism de traducere pentru ele, dar în octombrie CMS, există entități „pagină”, „pagină statică” și „post de blog” și, chiar dacă destul de asemănătoare, necesită trei implementări diferite pentru traducerile lor! Apoi, conținutul dintr-o „pagină” poate include coduri de mesaj (de exemplu, coduri numite nav.content , header.title și așa mai departe), fiecare dintre ele conține traducerile sale pentru toate localitățile ca obiect JSON serializat în tabelul bazei de date rainlab_translate_messages . Conținutul dintr-o „pagină statică” este creat într-un fișier static nou pentru fiecare localitate, cu toate acestea, toate adresele URL traduse pentru toate localitățile sunt stocate nu în fișierul corespunzător, ci în fișierul limbii implicite. Conținutul „postării de blog” este stocat ca un obiect JSON serializat cu un rând pentru fiecare localitate în tabelul bazei de date rainlab_translate_attributes , iar URL-ul tradus este stocat cu un rând pentru fiecare localitate în tabelul bazei de date rainlab_translate_indexes . Nu știu dacă această complexitate se datorează modului în care a fost implementat pluginul sau dacă se datorează arhitecturii CMS din octombrie. Oricare ar fi cazul, acesta este un alt exemplu de balonare nedorită din partea dezvoltării.

Managementul pluginurilor

Atât WordPress, cât și CMS October oferă un manager de pluginuri sofisticat care permite căutarea de pluginuri, instalarea de noi pluginuri și actualizarea pluginurilor instalate în prezent la cea mai recentă versiune - totul din backend.

Managementul Dependenței

October CMS folosește Composer ca manager de pachete ales, permițând pluginurilor să descarce și să instaleze dependențele lor atunci când sunt instalate, oferind astfel o experiență nedureroasă.

WordPress, pe partea opusă, nu a adoptat oficial Composer (sau orice manager de dependență PHP) deoarece comunitatea nu poate fi de acord dacă WordPress este un site sau o dependență de site. Prin urmare, dacă au nevoie de Composer pentru proiectele lor, dezvoltatorii trebuie să îl adauge singuri. Odată cu trecerea la Gutenberg, npm a devenit managerul de dependență JavaScript preferat, cu un set de instrumente pentru dezvoltatori popular depinzând de acesta, iar bibliotecile de pe partea clientului fiind lansate în mod constant ca pachete autonome în registrul npm.

Interacțiunea cu baza de date

WordPress oferă funcții pentru a prelua datele bazei de date (cum ar fi get_posts ) și pentru a le stoca (cum ar fi wp_insert_post și wp_update_post ). La preluarea datelor, putem trece parametri pentru a filtra, limita și ordona rezultatele, pentru a indica dacă rezultatul trebuie transmis ca o instanță a unei clase sau ca o matrice de proprietăți și altele. Când funcția nu satisface pe deplin cerințele noastre (de exemplu, când trebuie să facem o INNER JOIN cu un tabel personalizat), atunci putem interoga baza de date direct prin variabila globală $wpdb . Când creați un plugin cu un tip de postare personalizat, codul va executa cel mai probabil interogări SQL personalizate pentru a prelua și/sau a salva date în tabele personalizate. În rezumat, WordPress încearcă să ofere acces la baza de date prin funcții generice în prima etapă și prin acces la baza de date la nivel scăzut în a doua etapă.

Octombrie CMS folosește o abordare diferită: în loc să se conecteze imediat la baza de date, aplicația poate utiliza Eloquent ORM de la Laravel pentru a accesa și manipula datele bazei de date prin instanțe de clase numite Modele, făcând ca interacțiunea cu baza de date să se bazeze și pe programarea orientată pe obiecte. . Este acces la nivel înalt; doar urmând regulile despre cum să creați tabele și să stabiliți relații între entități, un plugin poate prelua și/sau salva date fără a scrie o linie de SQL. De exemplu, codul de mai jos preia un obiect din baza de date prin modelul Flight , modifică o proprietate și o stochează din nou:

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

Actualizarea modelului de date

Un alt motiv pentru succesul WordPress (pe lângă faptul că nu a încălcat compatibilitatea cu versiunea anterioară) a fost arhitectura bazei de date, care a fost concepută pentru a permite aplicațiilor să crească în timp. Acest obiectiv este realizat prin proprietăți „meta”, adică proprietăți care pot fi adăugate în mod liber la un obiect de bază de date în orice moment. Aceste proprietăți nu sunt stocate într-o coloană din tabelul de entități corespunzătoare (fie wp_posts , wp_users , wp_comments sau wp_terms ), ci, în schimb, ca un rând în tabelul „meta” corespunzător ( wp_postmeta , wp_usermeta , wp_commentmeta sau wp_termmeta ) și retrievered INNER JOIN . Prin urmare, chiar dacă recuperarea acestor metavalori este mai lentă, ele oferă o flexibilitate nelimitată, iar modelul de date al aplicației rareori trebuie rearhitectat de la zero pentru a implementa unele funcționalități noi.

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.

Comunitate

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?

Asigurând o treime din toate site-urile din lume, WordPress nu este lipsit de părți interesate care contribuie la software; prin urmare, nu trebuie să ne temem că software-ul va cădea în decădere. Cu toate acestea, WordPress trece prin deliberări interne cu privire la modelul său de guvernare, mulți membri ai comunității exprimând că deciziile privind direcția WordPress sunt luate unilateral de Automattic, compania care administrează WordPress.com. În centrul acestei percepții a fost decizia de a lansa Gutenberg, cu care mulți membri nu au fost de acord și care a suferit o lipsă de comunicare adecvată din partea liderilor de proiect în timpul dezvoltării și lansării sale. În consecință, mulți membri ai comunității pun la îndoială rolul de „dictator benign”, care a fost acordat istoric fondatorului WordPress și CEO al Automattic, Matt Mullenweg, și cercetează diferite modele de guvernare pentru a găsi unul mai potrivit pentru viitorul WordPress. Mai rămâne de văzut dacă această căutare produce vreun rezultat sau dacă status quo-ul perseverează.

Deciziile privind direcția CMS din octombrie sunt luate în principal de fondatorii Alexey Bobkov și Samuel Georges și de dezvoltatorul și managerul comunității Luke Towers, care mențin proiectul să meargă puternic. Octombrie CMS nu are încă luxul de a avea o problemă de guvernare: preocuparea sa actuală este cum să facă proiectul sustenabil prin generarea de venituri pentru întreținerii software-ului de bază.

Documentație

Documentația WordPress din propriul său site nu este extrem de cuprinzătoare, dar își face treaba destul de bine. Cu toate acestea, atunci când luați în considerare toată documentația despre WordPress din toate sursele, cum ar fi site-uri generale (Smashing Magazine, trucuri CSS și multe altele), site-uri specializate (WPShout, WPBeginner și multe altele), bloguri personale, cursuri online, și așa mai departe, practic nu există niciun aspect al confruntării cu WordPress care să nu fi fost deja acoperit.

Octombrie CMS nu se bucură de nimic în apropierea numeroaselor cursuri, tutoriale sau postări de blog ale terților despre el la fel de mult ca WordPress, cu toate acestea, documentația de pe site-ul său este destul de cuprinzătoare și cu siguranță suficientă pentru a începe codarea. Fondatorii din octombrie adaugă în mod regulat documentație nouă prin tutoriale. Un aspect care mi-a plăcut personal este duplicarea documentației lui Laravel în documentația lui Octombrie pentru tot ceea ce are relevanță, așa că cititorul nu trebuie să umple golurile de unul singur și să fie nevoit să ghicească care este domeniul lui Octombrie și ce este al lui Laravel. Cu toate acestea, acest lucru nu este 100% perfect. Documentația din octombrie folosește termeni care provin din Laravel, cum ar fi middleware, containere de servicii, fațade și contracte, fără a explica în mod adecvat care sunt acestea. Apoi, citirea documentației lui Laravel în avans poate fi utilă (din fericire, documentația lui Laravel este cuprinzătoare, iar screencast-urile lui Laravel, Laracasts, sunt o altă sursă excelentă de învățare, nu doar în ceea ce privește Laravel, ci și dezvoltarea web în general).

Concluzie

Mi-am propus să descopăr ce caracteristici pot fi atrăgătoare pentru dezvoltatorii care caută alternative la WordPress, comparând WordPress cu un CMS similar, pe care l-am definit ca fiind gratuit și open source, bazat pe PHP și care produce conținut dinamic și bucurându-se de sprijinul unei comunități. . Dintre CMS-urile care îndeplinesc aceste condiții, am ales Octombrie CMS pentru comparație datorită cunoștințelor pe care le-am primit despre el și pentru că am apreciat abordarea sa de codare curată și modulară, așa cum este oferită de Laravel, care ar putea oferi o perspectivă proaspătă și modernă șantierelor.

Acest articol nu și-a propus să aleagă un câștigător, ci pur și simplu să analizeze când are sens să alegeți unul sau altul CMS, evidențiind punctele forte și punctele slabe ale acestora. Nu există „cel mai bun” CMS: doar cel mai potrivit CMS pentru o situație specifică. În plus, oricine caută un CMS pe care să îl folosească într-un anumit proiect cu o anumită echipă și având un anumit buget, ar trebui să facă câteva cercetări și să compare toate ofertele de acolo pentru a afla care dintre ele este cea mai potrivită pentru contextul respectiv. Este important să nu ne limităm la câteva CMS-uri, așa cum am făcut aici, în acest articol, ci să le dai o șansă tuturor.

Pe o notă personală, în calitate de dezvoltator, ceea ce am găsit în octombrie CMS este cu adevărat atrăgător pentru mine, mai ales capacitatea sa de a construi aplicații modulare, așa cum este furnizat prin Laravel. Cu siguranță aș lua în considerare acest CMS pentru un site web nou. Cu toate acestea, în procesul de scriere a acestui articol, am „redescoperit” și WordPress. Fiind atât de popular, WordPress primește mai mult decât partea echitabilă de critici, mai ales cu privire la vechea sa bază de cod și, de recent, introducerea lui Gutenberg; cu toate acestea, WordPress are, de asemenea, anumite caracteristici excelente (cum ar fi modelul său de bază de date super-scalabilă) care sunt rareori lăudate, dar care ar trebui să fie luate în considerare. Și, cel mai important, WordPress nu ar trebui să fie luat în considerare numai în ceea ce privește aspectele sale tehnice: în special, dimensiunea comunității și a ecosistemului său îl plasează cu un nivel sau două deasupra alternativelor sale. Pe scurt, unele proiecte ar putea beneficia de aderarea la WordPress, în timp ce altele se pot baza mai bine pe October CMS sau pe altă platformă.

Ca o notă finală, aș dori să remarc că explorarea modului în care funcționează un alt CMS este o activitate foarte plină de satisfacții în sine, independent de decizia luată cu privire la utilizarea sau nu a respectivului CMS. În cazul meu, lucram de ani de zile numai pe WordPress, iar explorarea CMS-ului din octombrie a fost foarte revigorantă, deoarece m-a învățat multe lucruri (cum ar fi existența recomandărilor de standarde PHP) la care nu am fost expus prin WordPress. S-ar putea să decid acum să schimb CMS-urile sau să rămân la WordPress știind cum să produc un cod mai bun.

Citiți suplimentare despre SmashingMag:

• Memorarea inteligentă în cache în epoca lui Gutenberg
• Îmbunătățirea codului WordPress cu PHP modern
• Lecții învățate în timpul dezvoltării pluginurilor WordPress
• Cum să utilizați hărțile termice pentru a urmări clicurile pe site-ul dvs. WordPress
• Fiți atenți: funcțiile PHP și WordPress care vă pot face site-ul nesigur