Szczegółowe porównanie WordPressa z październikowym CMS

Trzy miesiące temu WordPress w końcu wypuścił Gutenberga opartego na React, aby zasilać jego domyślną edycję treści, zmuszając wielu ludzi, którzy nie są zadowoleni z tej zmiany, do szukania alternatyw. Niektórzy zdecydowali się na rozwidlenie i wypuszczenie WordPressa sprzed Gutenberga, jednak dla mnie nie ma to większego sensu, ponieważ nadal niesie za sobą 15-letni dług techniczny. Gdybym miał znaleźć alternatywę dla WordPressa, starałbym się nie utknąć w przeszłości i dążyć do czystego przebicia się przez dojrzałą platformę zbudowaną na nowoczesnych fundamentach.

Ten artykuł porównuje WordPress do prawdopodobnie podobnego, ale bardziej nowoczesnego październikowego systemu CMS w szerokim zakresie zarówno technicznych, jak i nietechnicznych tematów. Celem artykułu nie jest przekonanie ludzi do trzymania się WordPressa lub przejścia na październikowy CMS, ale po prostu pokazanie, jakie aspekty należy wziąć pod uwagę przed podjęciem decyzji o przejściu na inną platformę. To samo porównanie można (i należy) przeprowadzić również z innymi platformami przed podjęciem rozsądnej decyzji.

Dlaczego październikowy CMS

O październikowym CMS dowiedziałem się, gdy zdobył nagrodę, po czym przeszedłem do trybu badań i spędziłem sporo czasu zagłębiając się w ten CMS — zarówno z perspektywy użytkownika, jak i programisty. Gdy zdobyłem wiedzę na temat tego CMS-a, nabrałem pewności, że mogę przedstawić obiektywną ocenę jego funkcji w porównaniu z WordPressem. Wybrałem ten CMS do porównania z alternatywnymi opcjami, takimi jak Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo i innymi z następujących powodów:

• Wiem, jak działa ten CMS (w przeciwieństwie do Grav);
• Jest darmowy i open source (w przeciwieństwie do Statamica i ButterCMS);
• Po pięciu latach jest „stosunkowo” nowy (w przeciwieństwie do Joomli i Drupala);
• Jest to dynamiczny (nie statyczny) generator treści oparty na PHP (w przeciwieństwie do Jekylla i Hugo).
  

Uważam, że październikowy CMS jest dobrym kandydatem, ponieważ bazuje na Laravelu, czyli frameworku służącym do budowania nowoczesnych aplikacji. Po siedmiu latach istnienia uzyskała pozytywną aprobatę programistów (o czym świadczy jego pokaźna społeczność i ekosystem) i stanowi wyraźny kontrast w stosunku do kodowania w WordPressie, tj. WordPress to głównie programowanie proceduralne, podczas gdy Laravel jest zdecydowanie programowaniem obiektowym.

Jaka jest różnica między tymi dwoma?

Poniżej porównam WordPress i październikowy CMS w różnych kategoriach i podkreślę, co moim zdaniem jest w nich dobre, a co nie tak dobre. Nie wybiorę jednak zwycięzcy, ponieważ nie taki jest cel artykułu, a w każdym razie nie ma „najlepszego” ani nawet „lepszego” CMS: każdy CMS ma swój własny zestaw mocnych i słabych stron , które sprawią, że będzie mniej lub bardziej odpowiedni do każdego zadania, projektu, firmy, zespołu i czegokolwiek innego. Co więcej, projekt może czerpać korzyści z używania więcej niż jednego CMS, na przykład używania jednego CMS do zarządzania i dostarczania danych, a innego CMS do renderowania widoku. Decyzja, który z kilkudziesięciu dostępnych systemów CMS jest najbardziej odpowiedni dla Twoich potrzeb, zależy wyłącznie od Ciebie.

Ponadto artykuł ten nigdy nie mógł wyciągnąć ostatecznych wniosków, ponieważ dotyczy tylko podzbioru wszystkich możliwości. Na przykład możemy również znaleźć porównania online, takie jak „WordPress vs Drupal vs Joomla”, „WordPress vs statyczne generatory stron”, a nawet „WordPress vs Medium”. Ponieważ żaden z tych artykułów nie zawiera pełnego obrazu, żadne z tych porównań nigdy nie może być rozstrzygające i nie powinno być traktowane jako takie.

Zacznijmy od porównania.

Filozofia i grupa docelowa

To nie przypadek, że WordPress obsługuje prawie 1 na 3 strony internetowe. Od samego początku starał się być niezwykle przyjazny dla użytkownika i robił to z powodzeniem, usuwając problemy zarówno z użytkownikami technicznymi, jak i nietechnicznymi, a także z ludźmi ze wszystkich środowisk — niezależnie od ich wykształcenia i poziomu ekonomicznego. Założyciel WordPressa, Matt Mullenweg, powiedział, że motto WordPressa „Demokratyzuj publikowanie” w obecnej epoce oznacza, że:

„Ludzie ze wszystkich środowisk, zainteresowań i umiejętności powinni mieć dostęp do oprogramowania Free-as-in-speech, które umożliwia im wyrażanie siebie w otwartej sieci i posiadanie własnych treści”.

WordPress jest łatwy w użyciu dla każdego, a jego otwartość jest również widoczna po stronie programistów: często zdarza się, że ludzie bez doświadczenia w programowaniu (np. marketerzy, projektanci, blogerzy, sprzedawcy i inni) majstrują przy instalacjach WordPressa, projektowaniu własnych tematów i z sukcesem uruchamiając własne strony internetowe. WordPress jest zorientowany na użytkownika, a potrzeby użytkowników przewyższają potrzeby programistów. W WordPressie użytkownik jest królem (lub królową).

W przeciwieństwie do tego, październikowy CMS jest bardziej nastawiony na programistę, jak wyraźnie ustalono od pierwszego wydania:

„Październik stawia jedno śmiałe, ale oczywiste założenie: klienci nie tworzą stron internetowych, programiści robią. Rolą klienta jest zarządzanie stroną internetową i przekazywanie swoich wymagań biznesowych. Twórca stron internetowych i sama branża obracają się wokół pośredniczenia w tych czynnikach”.

Wedle słów jego założycieli, misją CMS jest „udowodnienie, że tworzenie stron internetowych nie jest nauką rakietową”. Opierając się na Laravelu, October CMS może twierdzić, że ma mocne podstawy wielokrotnego użytku, modułowego kodu, który może tworzyć aplikacje o odpowiedniej architekturze, możliwe do utrzymania w dłuższej perspektywie i w pełni konfigurowalne bez konieczności hackowania — typ, który przyciąga poważnych programistów. Październikowy CMS może również zapewnić wspaniałe wrażenia użytkownika, jednak nie jest tak prosty i bezproblemowy, jak ten zapewniany przez WordPress. Użytkownikom może być konieczne wyjaśnienie, jak korzystać z niektórych funkcji, zanim będą mogli z nich korzystać. Na przykład osadzanie formularza z jakiejś wtyczki zawiera obszerne wyjaśnienie, jak to zrobić, co jest bardziej kłopotliwe niż oczywista funkcja przeciągania i upuszczania zapewniana przez kilka wtyczek formularzy w WordPress.

Instalacja

WordPress słynie z 5-minutowej instalacji, choć wiele osób zwraca uwagę, że (biorąc pod uwagę wszystkie wtyczki, które trzeba zainstalować) typowa instalacja wymaga 15 minut lub więcej. Ponadto WordPress oferuje również funkcję Multisite, która pozwala nam stworzyć sieć wielu wirtualnych witryn w ramach jednej instalacji. Ta funkcja ułatwia agencji administrowanie witrynami wielu klientów — między innymi w przypadku innych użytkowników.

Instalacja October CMS jest również bardzo płynna: sama instalacja Kreatora zajmuje nawet mniej niż pięć minut, a jeśli zainstalujesz go poprzez instalację konsoli, jest jeszcze szybsza. Możesz zrobić to drugie, po prostu przechodząc do katalogu docelowego, a następnie wykonując curl -s https://octobercms.com/api/installer | php curl -s https://octobercms.com/api/installer | php (po czym musimy wprowadzić konfigurację bazy danych, w przeciwnym razie zachowuje się jak płaski plik CMS). Po zakończeniu instalacji będziemy mieli w pełni działającą stronę internetową, ale nadal dość pustą (jeśli dodasz czas potrzebny na instalację i konfigurację wymaganych wtyczek, możesz oczekiwać, że zajmie to co najmniej 15 minut).

Bezpieczeństwo

WordPress został oskarżony o brak bezpieczeństwa ze względu na dużą liczbę stale znajdowanych luk w zabezpieczeniach. Zmusza to użytkowników do posiadania zawsze aktualnego oprogramowania dla systemu CMS i wszystkich zainstalowanych wtyczek, aby uniknąć luk w zabezpieczeniach. Jednym z głównych problemów jest wsparcie WordPressa dla starszych wersji PHP, które nie są już obsługiwane przez społeczność programistów PHP (WordPress obecnie obsługuje PHP 5.2.4, podczas gdy najnowsza w pełni obsługiwana wersja PHP to 5.6). Jednak ten problem powinien zostać rozwiązany w kwietniu 2019 roku, kiedy WordPress oficjalnie zacznie wspierać wersje PHP 5.6 i nowsze.

W przeciwnym razie WordPress niekoniecznie sam w sobie jest niepewny, ale z powodu swojej dużej popularności, co czyni go głównym celem hakerów. Jednak działa to w obie strony: wszechobecność WordPressa oznacza, że ​​jego zespół ds. bezpieczeństwa musi naprawdę poważnie potraktować swoją pracę, stale szukając exploitów i jak najszybciej je naprawiać, w przeciwnym razie nawet jedna trzecia sieci jest zagrożona. Stawka jest po prostu zbyt wysoka.

Z drugiej strony październikowy CMS nie ma reputacji niepewnego bezpieczeństwa. Ponieważ jednak istnieje około 27 000 aktywnych witryn, które korzystają z października, w porównaniu z milionami WordPressa, nie możemy ich oceniać na tych samych warunkach. Niemniej jednak zespół stojący za październikowym CMS traktuje bezpieczeństwo poważnie, o czym świadczy monit instalacji Kreatora o wprowadzenie adresu URL zaplecza CMS, ustawionego domyślnie jako /backend , ale można go zmienić na cokolwiek innego, aby utrudnić hakerom atakowanie witryny . W przeciwieństwie do tego, zmianę adresów URL logowania i backendu WordPress z /wp-login.php i /wp-admin na coś innego należy wykonać za pomocą wtyczki. Ponadto October CMS może działać jako CMS w postaci plików płaskich (tj. bez bazy danych) i unikać luk związanych z bazą danych, takich jak wstrzyknięcie SQL.

Stos technologii

Zarówno WordPress, jak i październikowy CMS działają na tradycyjnym stosie LAMP: Linux, Apache, MySQL i PHP. (Jednak tylko PHP jest naprawione: możemy również używać Windows, Nginx, MariaDB i innych.) Październikowy CMS może również zachowywać się jak CMS w postaci plików płaskich, co oznacza, że ​​może obejść się bez bazy danych, jednak za cenę rezygnacji wiele funkcjonalności (takich jak wpisy na blogu i użytkownicy) jedyną gwarantowaną funkcjonalnością są strony, które są uważane za podstawową jednostkę do tworzenia i publikowania treści i dostarczane jako główna funkcja.

Jeśli chodzi o stos językowy, witryny zbudowane przy użyciu zarówno WordPress, jak i October CMS są oparte na HTML, CSS i JavaScript (należy zauważyć, że PHP jest używane do generowania kodu HTML). Październikowy CMS ułatwia również korzystanie z plików LESS i SASS.

Paradygmat programowania

WordPress kieruje się paradygmatem programowania funkcjonalnego, polegającym na obliczaniu obliczeń poprzez wywoływanie funkcji pozbawionych stanu aplikacji. Mimo że programiści WordPress nie muszą ograniczać się do programowania funkcjonalnego (na przykład do kodowania swoich motywów i wtyczek), rdzeń WordPressa dziedziczy ten paradygmat z 15 lat zachowywania kompatybilności wstecznej, co było jednym z filarów sukcesu WordPressa ale która ma niezamierzoną konsekwencję w postaci akumulacji długu technicznego.

Z drugiej strony October CMS działa zgodnie z paradygmatem programowania imperatywnego, opartym na obliczaniu obliczeń poprzez manipulowanie stanem obiektów. Październikowy CMS znajduje się na szczycie Laravel, frameworku internetowego w pełni opartego na zasadach programowania obiektowego, który umożliwia tworzenie aplikacji modułowych opartych na koncepcjach, takich jak Model-View-Controller w celu oddzielenia interfejsu użytkownika od danych aplikacji, Dependency Injection do skonfigurować zależności klas i zasadę segregacji interfejsów, aby zdefiniować między innymi podstawowe usługi dostarczane przez framework.

Haki/Wydarzenia

Programowanie w WordPress można scharakteryzować jako HDD, co oznacza „Hook-Driven Development”. Zaczep to mechanizm, który umożliwia zmianę domyślnego zachowania lub wartości i umożliwienie innemu kodowi wykonania powiązanej funkcjonalności. Hooki są wyzwalane przez „akcje”, które pozwalają na wykonanie dodatkowej funkcjonalności, oraz „filtry”, które pozwalają modyfikować wartości.

Hooki, które są szeroko rozpowszechnione w kodzie WordPress, to jedna z koncepcji, które najbardziej lubię w kodowaniu w WordPressie. Pozwalają wtyczkom na interakcję z innymi wtyczkami (lub z rdzeniem lub motywem) w czysty sposób, zapewniając podstawową obsługę programowania zorientowanego na aspekty.

Dobrą wiadomością jest to, że Laravel (a co za tym idzie październikowy CMS) również wspiera koncepcję hooków, którą nazywamy „zdarzeniami”. Zdarzenia zapewniają prostą implementację obserwatora, umożliwiając kodowi subskrybowanie i nasłuchiwanie zdarzeń występujących w aplikacji oraz reagowanie w razie potrzeby. Eventy umożliwiają rozbicie złożonej funkcjonalności na komponenty, które mogą być instalowane niezależnie, ale współpracują ze sobą, umożliwiając w ten sposób tworzenie aplikacji modułowych.

Zależność od bibliotek JavaScript

Najnowsza wersja WordPressa zawiera oparte na React Gutenberga do domyślnego tworzenia treści. W związku z tym rozwój WordPressa opiera się teraz w dużej mierze na JavaScript (głównie przez React), chociaż możliwe jest również korzystanie z innych frameworków lub bibliotek (o czym świadczy Elementor Blocks dla Gutenberga, który jest oparty na Marionette). Ponadto WordPress nadal opiera się na Backbone.js (dla menedżera mediów) i jQuery (starszy kod), jednak możemy oczekiwać, że zależność od tych bibliotek zniknie, gdy Gutenberg zostanie skonsolidowany jako nowa norma.

Październikowy CMS opiera się na jQuery, które wykorzystuje do implementacji opcjonalnego frameworka AJAX do ładowania danych z serwera bez odświeżania strony w przeglądarce.

Strony, motywy i wtyczki

Zarówno WordPress jak i październikowy CMS traktują stronę jako podstawową jednostkę do tworzenia i publikowania treści (w przypadku WordPressa jako dodatek do postu), wspierają zmianę wyglądu strony poprzez motywy oraz pozwalają instalować i rozszerzać funkcjonalności strony poprzez wtyczki . Mimo że koncepcje są takie same w obu systemach CMS, istnieje kilka różnic w implementacji, które powodują nieco inne zachowanie.

W WordPressie strony są definiowane jako treść i przechowywane w bazie danych. Dzięki temu zawartość strony może być tworzona tylko przez CMS (np. w obszarze dashboardu), a przełączenie z jednego motywu na inny nie powoduje, że istniejąca strona staje się niedostępna. Zapewnia to ogólne wrażenia bez tarcia.

Z kolei w październiku CMS strony są statycznymi plikami przechowywanymi w katalogu motywów. Pozytywną stroną tej decyzji architektonicznej jest to, że zawartość strony można utworzyć z aplikacji zewnętrznej, takiej jak edytory tekstu, takie jak Sublime lub Visual Studio Code. Z drugiej strony przy przechodzeniu z jednego motywu na drugi wymagane jest ręczne odtworzenie lub skopiowanie stron z bieżącego do nowego motywu, w przeciwnym razie znikną.

Co ważne, październikowy CMS rozwiązuje routing przez strony, dlatego strony są używane nie tylko jako kontenery na treść, ale także na funkcjonalność. Na przykład wtyczka do blogowania zależy od strony do wyświetlania listy wpisów na blogu pod wybranym adresem URL, innej strony do wyświetlania pojedynczego wpisu na blogu pod innym wybranym adresem URL i tak dalej. Jeśli którakolwiek z tych stron zniknie, powiązana z nią funkcjonalność wtyczki stanie się niedostępna, a ten adres URL wygeneruje błąd 404. W związku z tym w październiku motywy i wtyczki CMS nie są całkowicie rozdzielone, a przełączanie motywów musi być wykonywane ostrożnie.

Funkcjonalność rdzenia i wtyczki

WordPress stara się zapewnić minimalną podstawową funkcjonalność, która jest ulepszana za pomocą wtyczek. WordPress opiera się na zasadzie „ ⁸⁰ ₂₀ ”, aby zdecydować, czy uwzględnić jakąś funkcjonalność w swoim podstawowym środowisku, czy nie. Jeśli przynosi korzyści 80% użytkowników, w przeciwnym razie należy do krainy wtyczek. Dodawanie wtyczek do witryny może prowadzić do wzdęcia, jeśli zainstalowano zbyt wiele wtyczek. Wtyczki mogą również nie działać dobrze ze sobą lub wykonywać podobny kod lub ładować podobne zasoby, co skutkuje nieoptymalną wydajnością. Dlatego o ile uruchomienie witryny WordPress jest stosunkowo łatwe, większym wyzwaniem jest jej ogólna konserwacja i możliwość zachowania optymalnego i wydajnego stanu podczas dodawania nowych funkcji.

Podobnie październikowy CMS również stara się zapewnić minimalną podstawową funkcjonalność, ale na sterydach: jedyną gwarantowaną funkcjonalnością jest tworzenie i publikowanie stron, a do wszystkiego innego będziemy potrzebować zainstalować taką lub inną wtyczkę, co wyraża się jako:

„Wszystko, czego potrzebujesz i nic, czego nie potrzebujesz”.

Cel jest jasny: większość prostych witryn składa się wyłącznie ze stron, bez postów na blogu, użytkowników lub obszaru logowania. Dlaczego więc aplikacja miałaby ładować dla nich zasoby, gdy nie są one potrzebne? W konsekwencji za pośrednictwem katalogu wtyczek udostępniane są funkcje do blogowania, zarządzania użytkownikami, tłumaczenia i kilka innych.

Październikowy CMS zawiera również w swoim rdzeniu pewne funkcje, które (choć nie zawsze są potrzebne) mogą znacznie ulepszyć aplikację. Na przykład zapewnia gotową obsługę przesyłania plików multimedialnych do Amazon S3 i uzyskiwania do nich dostępu za pośrednictwem CDN Rackspace. Zawiera również Menedżera Mediów, który jest najczęściej używany za pośrednictwem wtyczek, np. do dodawania obrazów do posta na blogu. (Strony mogą również używać Menedżera multimediów do osadzania plików multimedialnych, jednak system CMS jest również dostarczany z sekcją Zasoby, w której można przesyłać pliki multimedialne, co wydaje się bardziej odpowiednie.)

Uważam, że październikowa zawziętość może doskonale umożliwić nam stworzenie aplikacji, która jest jak najbardziej szczupła — głównie w przypadku prostych witryn. Jednak może też odbić się i zachęcać do wzdęć, ponieważ linia tego, co jest potrzebne, a co nie, jest arbitralna i trudno ją z góry ustalić przez CMS. Trudność tę można docenić, rozważając koncepcję „użytkownika”: W WordPressie użytkownicy witryny i administratorzy witryny należą do tej samej jednostki użytkownika (a poprzez role i uprawnienia możemy sprawić, że użytkownik zostanie administratorem). W październiku CMS te dwa wdrażane są osobno, dostarczając w rdzeniu implementację dla administratora serwisu, który może zalogować się do obszaru backendu i modyfikować ustawienia, a poprzez wtyczkę implementację użytkownika serwisu. Te dwa typy użytkowników mają inny proces logowania i inną tabelę bazy danych do przechowywania swoich danych, co prawdopodobnie narusza zasadę DRY (Don't Repeat Yourself).

Problem ten pojawia się nie tylko w odniesieniu do zachowania podmiotu, ale także tego, jakie pola danych musi zawierać. Na przykład, czy pola danych użytkownika strony internetowej powinny być predefiniowane? Czy wymagane jest pole telefoniczne? A co z polem adresu URL na Instagramie, biorąc pod uwagę, że Instagram dopiero niedawno stał się fajny? Ale czy w przypadku tworzenia profesjonalnej witryny internetowej nie powinniśmy zamiast tego używać pola adresu URL LinkedIn? Decyzje te wyraźnie zależą od aplikacji i nie mogą być podejmowane przez ani CMS, ani wtyczkę.

Wtyczka październikowa CMS o nazwie User implementuje użytkowników, ale bez żadnego pola użytkownika, do którego dodatek User Plus dodaje kilka dowolnych pól użytkownika, co może nie wystarczyć, więc wtyczka User Plus+ dodaje jeszcze inne pola użytkownika. Kiedy, gdzie i jak zatrzymać ten proces?

Innym problemem jest to, że nie ma miejsca na dodawanie nowych możliwości do jednostki, co prowadzi do stworzenia innej, niezwykle podobnej jednostki, tylko po to, by wspierać te wymagane zdolności. Na przykład październikowy CMS jest dostarczany ze stronami i umożliwia tworzenie „stron statycznych” za pomocą wtyczki. Ich natura jest taka sama: zarówno strony, jak i strony statyczne są zapisywane jako pliki statyczne. Jedyną różnicą między nimi (o ile wiem) jest to, że statyczne strony są edytowane za pomocą edytora wizualnego zamiast edytora HTML i można je dodawać do menu. Moim zdaniem tylko różnice strukturalne, takie jak zapisanie jednej encji jako pliku statycznego, a drugiej w bazie danych, mogą uzasadniać utworzenie drugiej encji dla strony (jest do tego pull request), ale dla prostych funkcji, tak jak ma to miejsce obecnie, stanowi naddatek rozwojowy.

Podsumowując, dobrze zaimplementowana październikowa aplikacja CMS może być bardzo szczupła i wydajna (np. usuwając bazę danych, gdy nie jest potrzebna), ale wręcz przeciwnie może też stać się niepotrzebnie rozdęta, zmuszając deweloperów do wdrożenia kilku rozwiązań dla podobnych podmiotów, a które mogą być bardzo mylące w użyciu („Czy powinienem użyć strony czy strony statycznej?”). Ponieważ ani WordPress, ani październikowy CMS nie znalazły idealnego rozwiązania do usuwania wzdęć, musimy zaprojektować dowolną architekturę aplikacji z rozwagą, aby uniknąć uciążliwego bólu.

Tworzenie treści

Gutenberg wnosi dwa ważne wkłady do WordPressa: wykorzystuje komponenty jako jednostkę do tworzenia witryn (co ma kilka zalet w porównaniu z kodowaniem blobów HTML) i wprowadza encję zwaną „blokiem”, która po zakończeniu fazy 2 Gutenberga (przypuszczalnie w 2019), zapewni ujednolicony sposób włączania treści do witryny, umożliwiając w ten sposób prostsze wrażenia użytkownika w przeciwieństwie do bardziej chaotycznego procesu dodawania treści za pomocą skrótów, przycisków TinyMCE, menu, widżetów i innych.

Ponieważ bloki Gutenberga mogą tworzyć i zapisywać statyczny kod HTML jako część wpisu na blogu, instalowanie wielu bloków Gutenberga niekoniecznie przekłada się na rozrost w witrynie po stronie użytkownika, ale może być ograniczone do strony administratora. Dlatego Gutenberg można prawdopodobnie uznać za dobre podejście do tworzenia witryn internetowych w sposób modułowy, z prostym, ale potężnym interfejsem użytkownika do tworzenia treści. Prawdopodobnie największą wadą jest (nieunikniony, ale niełatwy) wymóg nauczenia się Reacta, którego krzywa uczenia się jest dość stroma.

Jeśli komponenty React są podstawową jednostką do tworzenia treści w WordPressie, październikowy CMS opiera się na założeniu, że do budowania witryn wystarczy znajomość starego dobrego HTML. Rzeczywiście, podczas tworzenia strony jest nam po prostu przedstawiany edytor HTML (Markup):

Gdyby strona była wyłącznie statycznym kodem HTML, nie byłoby potrzeby korzystania z systemu CMS. Zamiast tego październikowe strony CMS są pisane przy użyciu szablonów Twig, które są kompilowane do zwykłego zoptymalizowanego kodu PHP. Mogą wybrać układ, który będzie zawierał rusztowanie strony (tj. powtarzające się elementy, takie jak nagłówek, stopka itd.), mogą zaimplementować symbole zastępcze, które są zdefiniowane w układzie, aby umożliwić stronie dostosowanie treści i mogą zawierać podszablony, które są fragmentami kodu wielokrotnego użytku. Ponadto strony mogą zawierać bloki treści, które są plikami tekstowymi, HTML lub Markdown, które można samodzielnie edytować i dołączać komponenty będące funkcjonalnościami zaimplementowanymi za pomocą wtyczek. I na koniec, gdy tylko HTML nie wystarcza i musimy stworzyć dynamiczny kod, możemy dodać funkcje PHP.

W edytorze chodzi o HTML. Nie ma obszaru textarea do dodawania treści w sposób wizualny — przynajmniej nie poprzez domyślne doświadczenie (ta funkcjonalność należy do krainy wtyczek). Dlatego znajomość HTML może być uważana za niezbędną do korzystania z październikowego CMS. Ponadto kilka różnych danych wejściowych do tworzenia treści (stron, układów, symboli zastępczych, części, bloków treści, komponentów i funkcji PHP) może być bardzo skutecznych, jednak z pewnością nie jest to tak proste, jak poprzez zunifikowany interfejs blokowy z WordPressa. Może być nawet bardziej złożona, ponieważ można również dodać inne elementy (takie jak statyczne strony i menu oraz fragmenty), a niektóre z nich, takie jak strony i strony statyczne, pozornie zapewniają tę samą funkcjonalność, co sprawia, że ​​trudno jest zdecydować, kiedy użyj jednego lub drugiego.

W rezultacie śmiem twierdzić, że chociaż prawie każdy może korzystać z witryny WordPress od strony administratora, październikowy CMS jest bardziej przyjazny dla programistów niż nietechniczny, więc programiści mogą z niego korzystać, ale niektóre inne role (marketerzy, sprzedawcy itp.) mogą uznać to za nieintuicyjne.

Menedżer mediów

Zarówno WordPress, jak i October CMS są dostarczane z menedżerem mediów, który umożliwia bezproblemowe dodawanie plików multimedialnych do witryny, obsługując dodawanie wielu plików jednocześnie za pomocą interfejsu „przeciągnij i upuść” i wyświetlając obrazy w obszarze zawartości. Wyglądają i zachowują się podobnie; jedyne godne uwagi różnice, jakie znalazłem, to to, że Media Manager WordPressa pozwala na osadzanie galerii obrazów, a październikowy Media Manager pozwala ręcznie tworzyć strukturę folderów, w których można umieszczać przesłane pliki.

Jednak od czasu wprowadzenia Gutenberga możliwości multimedialne WordPressa zostały znacznie ulepszone, umożliwiając osadzanie filmów, zdjęć i galerii zdjęć w miejscu w porównaniu z obszarem textarea (który zapewnia tylko niedokładną wersję tego, jak będzie wyglądać w witrynie) i odblokowanie potężnych, ale łatwych w użyciu funkcji, jak pokazano w tym filmie.

Umiędzynarodowienie

Rdzeń WordPressa wykorzystuje gettext , aby umożliwić tłumaczenie motywów i wtyczek. Zaczynając od pliku .pot zawierającego wszystkie ciągi do przetłumaczenia, musimy utworzyć plik .po zawierający ich tłumaczenie na odpowiedni język/lokal, a następnie ten plik jest kompilowany do binarnego pliku .mo odpowiedniego do szybkiego wyodrębniania tłumaczenia. Narzędzia do wykonywania tych zadań obejmują GlotPress (online) i Poedit (aplikacja do pobrania). Dogodnie ten mechanizm działa również w przypadku lokalizacji po stronie klienta dla Gutenberga.

WordPress obecnie nie dostarcza żadnego rozwiązania w rdzeniu do tłumaczenia treści i nie zrobi tego do fazy 4 Gutenberga (docelowo na rok 2020+). Do tego czasu tę funkcjonalność zapewniają wtyczki, które oferują różne strategie przechowywania przetłumaczonej treści i zarządzania nią. Na przykład, podczas gdy wtyczki takie jak Polylang i WPML przechowują każde tłumaczenie w osobnym wierszu z niestandardowej tabeli bazy danych (która jest czysta, ponieważ nie miesza ze sobą treści, ale wolniej, ponieważ wymaga dodatkowego INNER JOIN dwóch tabel podczas zapytania bazy danych), wtyczka qTranslate X przechowuje wszystkie tłumaczenia w tym samym polu z oryginalnej tabeli bazy danych (szybciej w przypadku zapytań o dane, ale zmieszana zawartość może spowodować zniszczenie witryny po wyłączeniu wtyczki). Dzięki temu możemy rozejrzeć się i wybrać najbardziej odpowiednią strategię dla naszych potrzeb.

October CMS nie dostarcza wielojęzycznej funkcjonalności poprzez swój rdzeń, ale jako wtyczkę stworzoną przez zespół October CMS, która gwarantuje bezbłędną integrację z systemem. Z funkcjonalnego punktu widzenia ta wtyczka zapewnia to, co obiecuje. Z punktu widzenia rozwoju nie jest idealnie, jak ta wtyczka faktycznie działa. W WordPressie strona jest po prostu postem z wpisem typu „strona” i istnieje dla nich pojedynczy mechanizm tłumaczenia, ale w październikowym CMS istnieją encje „strona”, „strona statyczna” i „post na blogu” i, mimo że dość podobne, wymagają trzech różnych implementacji do swoich tłumaczeń! Następnie zawartość „strony” może zawierać kody wiadomości (np. kody o nazwie nav.content , header.title itd.), z których każdy zawiera swoje tłumaczenia dla wszystkich lokalizacji jako zserializowany obiekt JSON w tabeli bazy danych rainlab_translate_messages . Treść „strony statycznej” jest tworzona w nowym pliku statycznym dla każdego ustawienia regionalnego, jednak wszystkie przetłumaczone adresy URL dla wszystkich ustawień regionalnych są przechowywane nie w odpowiadającym im pliku, ale w pliku domyślnego języka. Treść „postu na blogu” jest przechowywana jako zserializowany obiekt JSON z jednym wierszem na ustawienia regionalne w tabeli bazy danych rainlab_translate_attributes , a przetłumaczony adres URL jest przechowywany z jednym wierszem na ustawienia regionalne w tabeli bazy danych rainlab_translate_indexes . Nie wiem, czy ta złożoność wynika z implementacji wtyczki, czy z architektury październikowego CMS. W każdym razie jest to kolejny przypadek niepożądanego rozdęcia po stronie rozwoju.

Zarządzanie wtyczkami

Zarówno WordPress, jak i October CMS oferują wyrafinowany menedżer wtyczek, który umożliwia wyszukiwanie wtyczek, instalowanie nowych wtyczek i aktualizowanie aktualnie zainstalowanych wtyczek do ich najnowszej wersji — wszystko z poziomu zaplecza.

Zarządzanie zależnościami

October CMS używa Composera jako wybranego menedżera pakietów, umożliwiając wtyczkom pobieranie i instalowanie ich zależności podczas instalacji, zapewniając w ten sposób bezbolesne wrażenia.

WordPress, z drugiej strony, oficjalnie nie przyjął Composera (ani żadnego menedżera zależności PHP), ponieważ społeczność nie może się zgodzić, czy WordPress jest witryną, czy zależnością witryny. Dlatego też, jeśli potrzebują Composera do swoich projektów, programiści muszą go dodać samodzielnie. Po przejściu na Gutenberg, npm stał się preferowanym menedżerem zależności JavaScript, z popularnym zestawem narzędzi dla programistów zależnym od niego, a biblioteki po stronie klienta są stopniowo udostępniane jako autonomiczne pakiety w rejestrze npm.

Interakcja z bazą danych

WordPress udostępnia funkcje do pobierania danych z bazy danych (takich jak get_posts ) i ich przechowywania (takich jak wp_insert_post i wp_update_post ). Podczas pobierania danych możemy przekazać parametry do filtrowania, ograniczania i porządkowania wyników, aby wskazać, czy wynik musi być przekazany jako instancja klasy, czy jako tablica właściwości i inne. Gdy funkcja nie spełnia w pełni naszych wymagań (np. gdy musimy wykonać INNER JOIN z niestandardową tabelą), możemy wysłać zapytanie do bazy danych bezpośrednio przez zmienną globalną $wpdb . Podczas tworzenia wtyczki z niestandardowym typem posta kod najprawdopodobniej będzie wykonywał niestandardowe zapytania SQL w celu pobrania i/lub zapisania danych w niestandardowych tabelach. Podsumowując, WordPress stara się zapewnić dostęp do bazy danych poprzez funkcje ogólne w pierwszym etapie, a poprzez niskopoziomowy dostęp do bazy w drugim etapie.

October CMS stosuje inne podejście: zamiast od razu łączyć się z bazą danych, aplikacja może korzystać z Eloquent ORM Laravela, aby uzyskać dostęp do danych bazy danych i manipulować nimi za pośrednictwem instancji klas zwanych modelami, dzięki czemu interakcja z bazą danych będzie również oparta na programowaniu zorientowanym obiektowo . Jest to dostęp na wysokim poziomie; po prostu przestrzegając zasad tworzenia tabel i konfigurowania relacji między jednostkami, wtyczka może pobierać i/lub zapisywać dane bez pisania wiersza SQL. Na przykład poniższy kod pobiera obiekt z bazy danych za pośrednictwem modelu Flight , modyfikuje właściwość i ponownie ją przechowuje:

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

Aktualizacja modelu danych

Innym powodem sukcesu WordPressa (oprócz niełamania wstecznej kompatybilności) jest jego architektura bazy danych, która została zaprojektowana tak, aby umożliwić rozwój aplikacji w czasie. Cel ten jest realizowany poprzez „meta” właściwości, czyli właściwości, które w dowolnym momencie można dodać do obiektu bazy danych. Te właściwości nie są przechowywane w kolumnie z odpowiedniej tabeli encji ( wp_posts , wp_users , wp_comments lub wp_terms ), ale zamiast tego jako wiersz w odpowiedniej tabeli „meta” ( wp_postmeta , wp_usermeta , wp_commentmeta lub wp_termmeta ) i pobierane w wyniku INNER JOIN . W związku z tym, mimo że pobieranie tych meta wartości jest wolniejsze, zapewniają one nieograniczoną elastyczność, a model danych aplikacji rzadko wymaga ponownej architektury od zera w celu zaimplementowania nowych funkcji.

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.

Społeczność

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?

Zasilając jedną trzecią wszystkich witryn na świecie, WordPress nie brakuje interesariuszy wnoszących wkład w oprogramowanie; dlatego nie musimy się obawiać, że oprogramowanie popadnie w ruinę. Jednak WordPress jest w trakcie wewnętrznych rozważań dotyczących swojego modelu zarządzania, a wielu członków społeczności wyraża, że ​​decyzje dotyczące kierunku WordPressa są podejmowane jednostronnie przez Automattic, firmę prowadzącą WordPress.com. Centralnym punktem tej percepcji była decyzja o uruchomieniu Gutenberga, z którą wielu członków się nie zgadzało i która cierpiała na brak odpowiedniej komunikacji ze strony liderów projektu podczas jego rozwoju i wydania. W rezultacie wielu członków społeczności kwestionuje rolę „łagodnego dyktatora”, która historycznie została przyznana założycielowi WordPressa i dyrektorowi generalnemu Automattic Mattowi Mullenwegowi, i bada różne modele zarządzania, aby znaleźć bardziej odpowiedni dla przyszłości WordPressa. Nie wiadomo jeszcze, czy ta misja przyniesie jakiś rezultat, czy też utrzyma się status quo.

Decyzje dotyczące kierunku październikowego CMS podejmują głównie założyciele Alexey Bobkov i Samuel Georges oraz deweloper i community manager Luke Towers, dzięki czemu projekt jest mocny. Październikowy CMS nie ma jeszcze luksusu posiadania problemu z zarządzaniem: jego aktualnym problemem jest zapewnienie trwałości projektu poprzez generowanie dochodów dla opiekunów oprogramowania.

Dokumentacja

Dokumentacja WordPressa we własnej witrynie nie jest zbyt obszerna, ale radzi sobie całkiem nieźle. Jednak biorąc pod uwagę całą dokumentację dotyczącą WordPressa ze wszystkich źródeł, takich jak strony ogólne (Smashing Magazine, sztuczki CSS i wiele innych), strony specjalistyczne (WPShout, WPBeginner i wiele innych), blogi osobiste, kursy online, i tak dalej, praktycznie nie ma aspektu radzenia sobie z WordPressem, który nie został jeszcze omówiony.

Październikowy CMS nie cieszy się niczym w pobliżu wielu zewnętrznych kursów, samouczków lub wpisów na blogu na ten temat tak samo jak WordPress, jednak dokumentacja na jego stronie jest dość obszerna i z pewnością wystarczająca do rozpoczęcia kodowania. Październikowi założyciele również regularnie dodają nową dokumentację poprzez samouczki. Jednym z aspektów, który mi się osobiście podobał, jest powielanie dokumentacji Laravela do dokumentacji October dla wszystkiego, co ma znaczenie, więc czytelnik nie może sam wypełniać luk i musi zgadywać, co jest domeną October, a co Laravel. Nie jest to jednak w 100% idealne. Dokumentacja październikowa używa terminów pochodzących z Laravela, takich jak oprogramowanie pośredniczące, kontenery usług, fasady i umowy, bez odpowiedniego wyjaśnienia, co to jest. Wtedy pomocne może być wcześniejsze przeczytanie dokumentacji Laravela (na szczęście dokumentacja Laravela jest zdecydowanie obszerna, a screencasty Laravela, Laracasts, są kolejnym świetnym źródłem wiedzy, nie tylko dotyczącym Laravela, ale ogólnie tworzenia stron internetowych).

Wniosek

Postanowiłem odkryć, jakie funkcje mogą być kuszące dla programistów szukających alternatywy dla WordPressa, porównując WordPress z podobnym CMS, który określiłem jako wolny i otwarty, oparty na PHP i tworzący dynamiczną zawartość oraz cieszący się wsparciem ze strony społeczności . Spośród systemów CMS spełniających te warunki wybrałem do porównania październikowy CMS ze względu na posiadaną wiedzę na jego temat oraz ponieważ doceniłem jego przejrzyste i modułowe podejście do kodowania oferowane przez Laravela, które może oferować świeże i nowoczesne spojrzenie na place budowy.

Ten artykuł nie miał na celu wyłonienia zwycięzcy, ale po prostu przeanalizuj, kiedy warto wybrać jeden lub drugi CMS, podkreślając jego mocne i słabe strony. Nie ma „najlepszego” CMS: tylko najbardziej odpowiedni CMS do konkretnej sytuacji. Co więcej, każdy, kto szuka systemu CMS do wykorzystania w konkretnym projekcie z określonym zespołem i przy określonym budżecie, powinien przeprowadzić rozeznanie i porównać wszystkie dostępne tam oferty, aby dowiedzieć się, który z nich jest najbardziej odpowiedni w konkretnym kontekście. Ważne jest, aby nie ograniczać się do kilku systemów CMS, jak to zrobiłem w tym artykule, ale zamiast tego dać szansę wszystkim z nich.

Osobiście, jako programisty, to, co znalazłem w październiku CMS, naprawdę przemawia do mnie, głównie jego zdolność do budowania aplikacji modułowych, dostarczanych przez Laravela. Z pewnością rozważyłbym ten CMS dla nowej strony internetowej. Jednak w trakcie pisania tego artykułu „odkryłem na nowo” WordPressa. Będąc tak popularnym, WordPress otrzymuje więcej niż sprawiedliwy udział krytyki, głównie w odniesieniu do starej bazy kodu i od niedawna wprowadzenia Gutenberga; jednak WordPress ma również pewne doskonałe funkcje (takie jak super-skalowalny model bazy danych), które rzadko są chwalone, ale również powinny być brane pod uwagę. A co najważniejsze, WordPressa nie należy rozpatrywać wyłącznie ze względu na aspekty techniczne: w szczególności wielkość jego społeczności i ekosystemu stawia go o poziom lub dwa powyżej jego alternatyw. Krótko mówiąc, niektóre projekty mogą skorzystać na trzymaniu się WordPressa, podczas gdy inne mogą lepiej polegać na październikowym CMS lub innej platformie.

Na koniec chciałbym zauważyć, że badanie, jak działa inny CMS, jest samo w sobie bardzo satysfakcjonującym zajęciem, niezależnie od podjętej decyzji, czy użyć tego konkretnego CMS, czy nie. W moim przypadku przez lata pracowałem nad samym WordPressem, a zagłębienie się w październikowy CMS było bardzo odświeżające, ponieważ nauczyło mnie wielu rzeczy (takich jak istnienie rekomendacji standardów PHP), z którymi nie miałem kontaktu za pośrednictwem WordPressa. Mogę teraz zdecydować się na zmianę systemu CMS lub pozostać przy WordPressie, wiedząc, jak tworzyć lepszy kod.

Dalsze czytanie na SmashingMag:

• Inteligentne buforowanie w epoce Gutenberga
• Ulepszanie kodu WordPress za pomocą nowoczesnego PHP
• Lekcje zdobyte podczas tworzenia wtyczek WordPress
• Jak korzystać z map ciepła do śledzenia kliknięć w witrynie WordPress?
• Bądź czujny: funkcje PHP i WordPress, które mogą sprawić, że Twoja witryna stanie się niebezpieczna