WordPress ve Ekim CMS Arasında Ayrıntılı Bir Karşılaştırma

Üç ay önce, WordPress varsayılan içerik düzenleme deneyimini güçlendirmek için nihayet React-powered Gutenberg'i piyasaya sürdü ve bu değişiklikten memnun olmayan birçok insanı alternatif aramaya teşvik etti. Bazı insanlar Gutenberg öncesi WordPress'i çatallayıp yayınlamaya karar verdi, ancak benim için bu pek mantıklı değil çünkü hala 15 yıllık teknik borç taşıyor. WordPress'e bir alternatif bulsaydım, geçmişte takılıp kalmaktan kaçınmaya çalışırdım ve modern temeller üzerine kurulmuş bazı olgun platformlarda temiz bir kesim yapmayı hedeflerdim.

Bu makale, WordPress'i hem teknik hem de teknik olmayan konuların geniş bir düzenlemesinde tartışmalı olarak benzer ancak daha modern Ekim CMS'si ile karşılaştırmaktadır. Makalenin amacı, insanları WordPress'e bağlı kalmaya veya Ekim CMS'ye geçmeye ikna etmek değil, sadece farklı bir platforma geçişi tamamlamadan önce hangi yönlerin dikkate alınması gerektiğini göstermektir. Aynı karşılaştırma, mantıklı bir karar vermeden önce diğer platformlarla da yapılabilir (ve yapılmalıdır).

Neden Ekim CMS

Bir ödül kazandığında Ekim CMS'yi öğrendim, ardından araştırma moduna girdim ve hem kullanıcı hem de geliştirici açısından bu CMS'yi derinlemesine incelemek için çok zaman harcadım. Bu CMS hakkında bilgi edindikçe, WordPress'in aksine özelliklerinin objektif bir değerlendirmesini sağlayabileceğimden emin oldum. Aşağıdaki nedenlerle Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo ve diğerleri gibi alternatif seçeneklerle karşılaştırma yapmak için bu CMS'yi seçtim:

• Bu CMS'nin nasıl çalıştığını biliyorum (Grav'den farklı olarak);
• Ücretsiz ve açık kaynak kodludur (Statamic ve ButterCMS'den farklı olarak);
• Beş yılda, “nispeten” yenidir (Joomla ve Drupal'ın aksine);
• Dinamik (statik değil) bir içerik üreticisidir ve PHP tabanlıdır (Jekyll ve Hugo'nun aksine).
  

Ekim CMS'nin iyi bir aday olduğuna inanıyorum çünkü modern uygulamalar oluşturmak için kullanılan bir çerçeve olan Laravel'i temel alıyor. Yedi yıllık varoluştan sonra, geliştiricilerden olumlu onay aldı (büyük topluluğu ve ekosistemi tarafından kanıtlandığı gibi) ve WordPress'te kodlamaya göre belirgin bir kontrast oluşturuyor, yani WordPress çoğunlukla prosedürel programlama iken Laravel kesinlikle nesne yönelimli programlamadır.

İkisi Arasındaki Fark Nedir?

Aşağıda WordPress ve Ekim CMS'yi farklı kategorilerde karşılaştıracağım ve onlar hakkında neyin iyi olduğunu ve neyin iyi olmadığını vurgulayacağım. Ancak, makalenin amacı bu olmadığı için bir kazanan seçmeyeceğim ve her durumda “en iyi” ve hatta “daha ​​iyi” bir CMS yoktur: her CMS'nin onu başarılı kılacak kendi güçlü ve zayıf yönleri vardır. her görev, proje, şirket, ekip ve diğer her şey için aşağı yukarı uygundur. Ayrıca, bir proje, verileri yönetmek ve sağlamak için bazı CMS'leri ve görünümü oluşturmak için başka bir CMS'yi kullanmak gibi birden fazla CMS kullanmaktan yararlanabilir. Düzinelerce CMS'den hangisinin kendi ihtiyaçlarınıza en uygun olduğuna karar vermek tamamen size kalmış.

Ayrıca, bu makale tüm olasılıkların yalnızca bir alt kümesiyle ilgili olduğu için hiçbir zaman kesin sonuçlara varamaz. Örneğin, "WordPress vs Drupal vs Joomla", "WordPress vs Statik Site Üreticileri" ve hatta "WordPress vs Medium" gibi çevrimiçi karşılaştırmalar da bulabiliriz. Bu makalelerin hiçbiri resmin tamamını görmediğinden, bu karşılaştırmaların hiçbiri kesin olamaz ve bu şekilde ele alınmamalıdır.

Karşılaştırma ile başlayalım.

Felsefe ve Hedef Kitle

WordPress'in yaklaşık 3 web sitesinden 1'ine güç vermesi tesadüf değildir. Kurulduğu günden bu yana, son derece kullanıcı dostu olmaya çabaladı ve bunu başarılı bir şekilde yaptı, hem teknik hem de teknik olmayan kullanıcılar ile eğitim ve ekonomik düzeyleri ne olursa olsun her kökenden insanlar için sürtünmeyi ortadan kaldırdı. WordPress'in kurucusu Matt Mullenweg, WordPress'in içinde bulunduğumuz dönem için “Yayıncılığı Demokratikleştir” sloganının şu anlama geldiğini ifade etti:

"Tüm geçmişlere, ilgi alanlarına ve yeteneklere sahip kişiler, kendilerini açık web'de ifade etme ve içeriklerine sahip olmalarını sağlayan konuşmada ücretsiz yazılıma erişebilmelidir."

WordPress'in kullanımı herkes için kolaydır ve kapsayıcılığı geliştirme tarafında da kanıtlanmıştır: Programlama geçmişi olmayan (pazarlamacılar, tasarımcılar, blogcular, satış görevlileri ve diğerleri gibi) insanların WordPress kurulumlarını kurcalayan, tasarım yapan kişilerle karşılaşmak nadir değildir. kendi temalarını ve kendi web sitelerini başarıyla başlattı. WordPress kullanıcı merkezlidir ve kullanıcıların ihtiyaçları geliştiricilerin ihtiyaçlarını karşılar. WordPress'te kullanıcı kraldır (veya kraliçedir).

Buna karşılık, ilk sürümünden itibaren açıkça belirtildiği gibi, Ekim CMS geliştiriciye yöneliktir:

“Ekim cesur ama bariz bir varsayımda bulunuyor: Müşteriler web siteleri oluşturmaz, geliştiriciler yapar. Bir müşterinin rolü, web sitesini yönetmek ve iş gereksinimlerini iletmektir. Web geliştiricisi ve endüstrinin kendisi, bu faktörlere aracılık etme etrafında dönüyor.”

Kurucularının sözleriyle, CMS'nin misyonu “web sitesi yapmanın roket bilimi olmadığını kanıtlamaktır”. Laravel'i temel alan Ekim CMS, yeniden kullanılabilir, modüler kodun güçlü temellerine sahip olduğunu iddia edebilir; bu, düzgün bir şekilde tasarlanmış uygulamalar üretebilir, uzun vadede bakımı yapılabilir ve hack gerektirmeden tamamen özelleştirilebilir - ciddi programcıları cezbeden tür. Ekim CMS ayrıca harika bir kullanıcı deneyimi sağlayabilir, ancak WordPress tarafından sağlanan kadar basit veya sorunsuz değildir. Kullanıcılara, kullanmadan önce belirli işlevleri nasıl kullanacaklarının açıklanması gerekebilir. Örneğin, bir eklentiden bir form gömmek, bunun nasıl yapılacağına dair uzun bir açıklamaya sahiptir; bu, WordPress'teki çeşitli form eklentileri tarafından sağlanan, kendiliğinden ortaya çıkan, sürükle ve bırak işlevinden daha zahmetlidir.

Kurulum

WordPress, 5 dakikalık kurulumuyla ünlüdür, ancak birçok kişi (kurulması gereken tüm eklentileri dikkate alarak) tipik bir kurulumun 15 dakika veya daha fazla gerektirdiğini belirtse de. Ayrıca WordPress, tek bir kurulum altında birden çok sanal site ağı oluşturmamıza olanak tanıyan Multisite özelliğini de sunar. Bu özellik, bir ajansın diğer kullanıcı durumlarının yanı sıra birden fazla müşterinin sitelerini yönetmesini kolaylaştırır.

Ekim CMS'yi yüklemek de çok kolay: Sihirbaz kurulumunun kendisi beş dakikadan bile daha az sürer ve Konsol kurulumu aracılığıyla kurarsanız, daha da hızlıdır. İkincisini, yalnızca hedef dizine gidip ardından curl -s https://octobercms.com/api/installer | php çalıştırarak yapabilirsiniz. curl -s https://octobercms.com/api/installer | php (bundan sonra veritabanı yapılandırmasını girmemiz gerekir, aksi takdirde düz dosya CMS gibi davranır). Kurulum tamamlandıktan sonra, tamamen işlevsel bir web sitemiz olacak, ancak yine de oldukça boş olacak (gerekli eklentileri kurmak ve yapılandırmak için gereken süreyi eklerseniz, en az 15 dakika sürmesini bekleyebilirsiniz).

Güvenlik

WordPress, sürekli olarak bulunan yüksek miktarda güvenlik açığı nedeniyle güvensiz olmakla suçlandı. Bu, güvenlik açıklarından kaçınmak için kullanıcıları CMS yazılımına ve tüm yüklü eklentilere sahip olmaya zorlar. Ana sorunlar arasında, WordPress'in artık PHP geliştirme topluluğu tarafından desteklenmeyen eski PHP sürümleri için desteği yer almaktadır (WordPress şu anda PHP 5.2.4'ü desteklerken, tam olarak desteklenen en son PHP sürümü 5.6'dır). Ancak bu sorun, WordPress'in resmi olarak PHP 5.6 ve sonraki sürümleri desteklemeye başlayacağı Nisan 2019'da çözülmelidir.

Aksi takdirde, WordPress kendi başına güvensiz değildir, ancak yüksek popülaritesi nedeniyle, onu bilgisayar korsanları için birincil hedef haline getirir. Bununla birlikte, bu her iki şekilde de geçerlidir: WordPress'in her yerde bulunması, güvenlik ekibinin sürekli olarak açıkları arayarak ve bunları mümkün olan en kısa sürede düzelterek işini gerçekten ciddiye alması gerektiği anlamına gelir, aksi takdirde web'in üçte biri risk altındadır. Bahisler çok yüksek.

Ekim CMS ise güvensiz bir üne sahip değil. Bununla birlikte, WordPress'in milyonlarıyla karşılaştırıldığında Ekim'i kullanan yaklaşık 27.000 canlı site olduğundan, ikisini aynı terimlerle yargılayamayız. Yine de, Ekim CMS'nin arkasındaki ekip, Sihirbaz kurulumunun CMS arka uç URL'sini girme isteminde kanıtlandığı gibi, varsayılan olarak /backend olarak ayarlanmış ancak başka herhangi bir şeyle değiştirilebilen, bilgisayar korsanlarının siteyi hedeflemesini zorlaştıracak şekilde güvenliği ciddiye alıyor. . Buna karşılık, WordPress'in giriş ve arka uç URL'lerini sırasıyla /wp-login.php ve /wp-admin admin'den başka bir şeye değiştirmek bir eklenti aracılığıyla yapılmalıdır. Ayrıca, Ekim CMS, düz dosyalı bir CMS (yani veritabanı olmadan) olarak işlev görebilir ve SQL enjeksiyonu gibi veritabanıyla ilgili güvenlik açıklarından kaçınabilir.

Teknoloji Yığını

Hem WordPress hem de Ekim CMS, geleneksel LAMP yığınında çalışır: Linux, Apache, MySQL ve PHP. (Ancak, yalnızca PHP sabittir: Windows, Nginx, MariaDB ve diğerlerini de kullanabiliriz.) Ekim CMS ayrıca düz dosyalı bir CMS gibi davranabilir, yani bir veritabanı olmadan da çalışabilir, ancak bunun pahasına birçok işlevsellik (blog gönderileri ve kullanıcılar gibi) garanti edilen tek işlevsellik, içeriğin oluşturulması ve yayınlanması için temel birim olarak kabul edilen ve temel bir özellik olarak gönderilen sayfalardır.

Dil yığınıyla ilgili olarak, hem WordPress hem de Ekim CMS ile oluşturulan siteler HTML, CSS ve JavaScript'e dayanır (HTML oluşturmak için PHP'nin kullanıldığını unutmayın). Ekim CMS, LESS ve SASS dosyalarının kullanımını da kolaylaştırır.

Programlama Paradigma

WordPress, uygulama durumundan yoksun işlevleri çağırarak hesaplamaları hesaplamaya dayanan işlevsel bir programlama paradigmasını takip eder. WordPress geliştiricilerinin işlevsel programlamaya bağlı kalması gerekmese de (örneğin, temalarını ve eklentilerini kodlamak için), WordPress çekirdek kodu bu paradigmayı, WordPress'in başarısının temel direklerinden biri olan 15 yıllık geriye dönük uyumluluktan miras alır. ancak teknik borç biriktirmek gibi istenmeyen sonuçlara sahiptir.

Öte yandan, Ekim CMS, nesnelerin durumunu manipüle ederek hesaplamaları hesaplamaya dayanan zorunlu bir programlama paradigmasını takip eder. Ekim CMS, kullanıcı arabirimini uygulama verilerinden ayırmak için Model-View-Controller, diğerlerinin yanı sıra çerçeve tarafından sağlanan temel hizmetleri tanımlamak için sınıf bağımlılıklarını ve Arayüz Ayrıştırma İlkesini yapılandırın.

Kancalar/Olaylar

WordPress'te programlama, “Kancaya Dayalı Geliştirme” anlamına gelen HDD olarak tanımlanabilir. Kanca, varsayılan bir davranışı veya değeri değiştirmeye ve diğer kodun ilgili işlevleri yürütmesine izin veren bir mekanizmadır. Kancalar, ekstra işlevlerin yürütülmesine izin veren "eylemler" ve değerlerin değiştirilmesine izin veren "filtreler" aracılığıyla tetiklenir.

WordPress kod tabanında yaygın olarak bulunan kancalar, WordPress'te kodlamadan en çok hoşlandığım kavramlardan biridir. Eklentilerin diğer eklentilerle (veya bir çekirdek veya temayla) temiz bir şekilde etkileşime girmesine izin vererek, En Boy Yönelimli Programlamanın bazı temel desteğini sağlarlar.

İyi haber şu ki, Laravel (ve dolayısıyla Ekim CMS) aynı zamanda “olaylar” olarak adlandırılan kanca kavramını da destekliyor. Olaylar, basit bir gözlemci uygulaması sağlayarak, kodun uygulamada meydana gelen olaylara abone olmasını ve bunları dinlemesini ve gerektiğinde tepki vermesini sağlar. Olaylar, karmaşık bir işlevselliği bağımsız olarak kurulabilen ancak birbirleriyle işbirliği yapabilen bileşenlere ayırmayı mümkün kılar ve böylece modüler uygulamaların oluşturulmasını sağlar.

JavaScript Kitaplıklarına Bağımlılık

WordPress'in en son sürümü, varsayılan içerik oluşturma deneyimi için React-powered Gutenberg'i içerir. Bu nedenle, WordPress geliştirme artık büyük ölçüde JavaScript'e (ağırlıklı olarak React aracılığıyla) dayanmaktadır, ancak diğer çerçeveleri veya kitaplıkları kullanmak da mümkündür (Gutenberg için Marionette'e dayalı Elementor Blokları tarafından kanıtlandığı gibi). Ek olarak, WordPress hala Backbone.js'ye (Medya Yöneticisi için) ve jQuery'ye (eski kod) güveniyor, ancak Gutenberg yeni norm olarak konsolide edildiğinden bu kitaplıklara olan bağımlılığın kaybolmasını bekleyebiliriz.

Ekim CMS, tarayıcı sayfası yenilemesi olmadan sunucudan veri yüklemek için isteğe bağlı AJAX çerçevesini uygulamak için kullandığı jQuery'ye bağlıdır.

Sayfalar, Temalar ve Eklentiler

Hem WordPress hem de Ekim CMS, bir sayfayı içerik oluşturmak ve yayınlamak için temel birim olarak ele alır (gönderiye ek olarak WordPress durumunda), temalar aracılığıyla sitenin görünümünü ve hissini değiştirmeyi destekler ve sitenin işlevlerini eklentiler aracılığıyla yüklemeye ve genişletmeye izin verir. . Her iki CMS'de de kavramlar aynı olsa da, uygulamada biraz farklı davranışlar üreten birkaç farklılık vardır.

WordPress'te sayfalar içerik olarak tanımlanır ve veritabanında saklanır. Sonuç olarak, sayfa içeriği yalnızca CMS aracılığıyla oluşturulabilir (örn. gösterge tablosu alanında) ve bir temadan diğerine geçiş, mevcut bir sayfanın kullanılamaz hale gelmesine neden olmaz. Bu, genel olarak sürtünmesiz bir deneyim sağlar.

Ekim CMS'de ise sayfalar, tema dizini altında depolanan statik dosyalardır. Bu mimari kararın olumlu yanı, Sublime veya Visual Studio Code gibi metin editörleri gibi harici bir uygulamadan sayfa içeriği oluşturulabilir. Olumsuz tarafı, bir temadan diğerine geçerken, sayfaları mevcut temadan yeni temaya manuel olarak yeniden oluşturmak veya kopyalamak gerekir, aksi takdirde bunlar kaybolur.

Önemli bir şekilde, Ekim CMS, sayfalar arasındaki yönlendirmeyi çözer, bu nedenle sayfalar yalnızca içerik için kapsayıcı olarak değil, aynı zamanda işlevsellik için de kullanılır. Örneğin, blog yazmak için bir eklenti, seçilen bir URL altında blog gönderilerinin listesini görüntülemek için bir sayfaya, seçilen başka bir URL altında tek bir blog gönderisini görüntülemek için başka bir sayfaya vb. bağlıdır. Bu sayfalardan herhangi biri kaybolursa, eklentiden ilişkili işlevsellik kullanılamaz hale gelir ve bu URL bir 404 üretecektir. Bu nedenle, Ekim ayında CMS temaları ve eklentileri tamamen ayrıştırılmaz ve temalar arasında geçiş dikkatli bir şekilde yapılmalıdır.

Çekirdek ve Eklenti İşlevselliği

WordPress, eklentiler aracılığıyla geliştirilmiş minimal bir temel işlevsellik sunmaya çalışır. WordPress, temel deneyimine bazı işlevleri dahil edip etmemeye karar vermek için “ ⁸⁰ ⁄ ₂₀ kuralına” güvenir. Girdiği kullanıcıların %80'ine fayda sağlıyorsa, aksi takdirde eklenti arazisine aittir. Bir siteye eklenti eklerken, çok fazla eklenti kurulursa bunlar şişkinliğe neden olabilir. Eklentiler ayrıca birbirleriyle iyi çalışmayabilir veya benzer kodu yürütebilir veya benzer varlıkları yükleyemez, bu da yetersiz performansa neden olabilir. Bu nedenle, bir WordPress sitesini başlatmak nispeten kolay olsa da, daha büyük bir zorluk, genel bakımı ve yeni özellikler eklerken optimum ve performans durumunu koruyabilmesidir.

Benzer şekilde, Ekim CMS de minimal bir çekirdek işlevsellik sağlamaya çalışır, ancak steroidler üzerinde: garanti edilen tek işlevsellik, sayfaların oluşturulması ve yayınlanmasıdır ve diğer her şey için şu şekilde ifade edilen bir eklenti veya başka bir eklenti yüklememiz gerekecek:

“İhtiyacınız olan her şey ve ihtiyacınız olmayan hiçbir şey.”

Amaç açıktır: çoğu basit site, muhtemelen hiçbir blog yazısı, kullanıcı veya oturum açma alanı içermeyen sayfalardan oluşur. Öyleyse, ihtiyaç duyulmadığında uygulama neden bunlar için kaynak yüklesin? Sonuç olarak, blog oluşturma, kullanıcı yönetimi, çeviri ve diğer pek çok işlev eklenti dizini aracılığıyla yayınlanır.

Ekim CMS, özünde (her zaman gerekli olmasa da) uygulamayı önemli ölçüde geliştirebilecek bazı özellikler de içerir. Örneğin, medya dosyalarını Amazon S3'e yüklemek için hazır destek sağlar ve bunlara Rackspace CDN aracılığıyla erişir. Ayrıca, çoğunlukla eklentiler aracılığıyla kullanılan bir Medya Yöneticisi de içerir, örneğin bir blog gönderisine resim eklemek için. (Sayfalar medya dosyalarını gömmek için Medya Yöneticisini de kullanabilir, ancak CMS ayrıca bunlar için medya dosyalarını yüklemek için daha uygun görünen bir Varlıklar bölümü ile birlikte gelir.)

Ekim ayının kanaatkarlığının, çoğunlukla basit sitelerle ilgili olarak, mümkün olduğunca yalın bir uygulama üretmemizi mükemmel bir şekilde sağlayabileceğine inanıyorum. Bununla birlikte, geri tepebilir ve şişkinliği teşvik edebilir, çünkü neyin gerekli olduğu ve neyin olmadığı keyfi bir çizgidir ve CMS tarafından önceden ayarlanması zordur. Bu zorluk, bir "kullanıcı" kavramı düşünüldüğünde anlaşılabilir: WordPress'te, web sitesi kullanıcıları ve web sitesi yöneticileri aynı kullanıcı varlığına aittir (ve roller ve ayrıcalıklar aracılığıyla bir kullanıcıyı yönetici yapabiliriz). Ekim CMS'de, bu ikisi ayrı ayrı uygulanır, arka uç alanında oturum açabilen ve ayarları değiştirebilen web sitesi yöneticisi için uygulamayı ve bir eklenti aracılığıyla web sitesi kullanıcısının uygulamasını temel olarak gönderir. Bu iki tür kullanıcı, verilerini depolamak için farklı bir oturum açma işlemine ve farklı bir veritabanı tablosuna sahiptir, bu nedenle DRY (Kendini Tekrar Etme) ilkesini tartışmaya açık bir şekilde ihlal eder.

Bu sorun yalnızca bir varlığın davranışıyla ilgili değil, aynı zamanda hangi veri alanlarını içermesi gerektiğiyle ilgili olarak da ortaya çıkar. Örneğin, web sitesi kullanıcı veri alanları önceden tanımlanmalı mı? Telefon alanı gerekli mi? Instagram'ın son zamanlarda biraz havalı olduğunu düşünürsek, bir Instagram URL alanına ne dersiniz? Ancak profesyonel bir web sitesi oluştururken bunun yerine bir LinkedIn URL alanı kullanmamız gerekmez mi? Bu kararlar açıkça uygulamaya bağlıdır ve CMS veya eklenti tarafından kararlaştırılamaz.

Kullanıcı olarak adlandırılan Ekim CMS eklentisi, kullanıcıları uygular, ancak herhangi bir kullanıcı alanı olmadan, bunun üzerine User Plus eklentisi, muhtemelen yeterli olmayan birkaç rastgele kullanıcı alanı ekler, bu nedenle User Plus+ eklentisi başka kullanıcı alanları ekler. Bu süreci ne zaman, nerede ve nasıl durduracağız?

Başka bir sorun, bir varlığa yeni yetenekler eklemek için yer olmadığında, bu da sadece gerekli yetenekleri desteklemek için son derece benzer başka bir varlığın yaratılmasına yol açar. Örneğin, Ekim CMS, sayfalarla birlikte gelir ve bir eklenti aracılığıyla "statik sayfalar" oluşturmaya izin verir. Yapıları aynıdır: hem sayfalar hem de statik sayfalar statik dosyalar olarak kaydedilir. Aralarındaki tek fark (anlayabildiğim kadarıyla) statik sayfaların HTML düzenleyicisi yerine görsel düzenleyici ile düzenlenmesi ve menülere eklenebilmesidir. Benim düşünceme göre, yalnızca bir varlığın statik dosya olarak kaydedilmesi ve diğerinin veritabanında saklanması gibi yapısal farklılıklar, bir sayfa için ikinci bir varlık oluşturmayı haklı çıkarabilir (bunu yapmak için bir çekme isteği vardır), ancak basit özellikleri, şu anda olduğu gibi, geliştirme şişkinliği oluşturmaktadır.

Özetle, iyi uygulanmış bir Ekim CMS uygulaması çok yalın ve verimli olabilir (örneğin, gerekmediğinde veritabanını kaldırarak), ancak tam tersine, geliştiricileri benzer varlıklar için çeşitli çözümler uygulamaya zorlayarak gereksiz yere şişebilir ve kullanımı çok kafa karıştırıcı olabilir (“Bir sayfa mı yoksa statik bir sayfa mı kullanmalıyım?”). Ne WordPress ne de Ekim CMS şişkinliği gidermek için mükemmel bir çözüm bulamadığından, yolun aşağısında acıdan kaçınmak için her iki uygulama mimarisini de dikkatli bir şekilde tasarlamalıyız.

İçerik yaratımı

Gutenberg, WordPress'e iki önemli katkı sağlıyor: Bileşenleri site oluşturmak için bir birim olarak kullanır (bu, HTML bloklarını kodlamaya göre çeşitli avantajlar sunar) ve Gutenberg 2. Aşama tamamlandığında (muhtemelen 2019), içeriği siteye dahil etmenin birleşik bir yolunu sağlayacak, böylece kısa kodlar, TinyMCE düğmeleri, menüler, widget'lar ve diğerleri aracılığıyla daha kaotik içerik ekleme sürecinin aksine daha basit bir kullanıcı deneyimi sağlayacaktır.

Gutenberg blokları, blog gönderisinin bir parçası olarak statik HTML üretip kaydedebildiğinden, birçok Gutenberg bloğunun yüklenmesi, kullanıcı tarafında web sitesinde mutlaka şişkinliğe dönüşmez, ancak yönetici tarafı ile sınırlı tutulabilir. Bu nedenle, Gutenberg, içerik oluşturmak için basit ama güçlü bir kullanıcı deneyimi ile modüler bir şekilde web siteleri oluşturmak için tartışmasız iyi bir yaklaşım olarak kabul edilebilir. Muhtemelen en büyük dezavantaj, öğrenme eğrisi oldukça dik olan React'i öğrenmek için (kaçınılmaz, ancak kolay olmayan) gereksinimdir.

WordPress'te içerik oluşturmak için temel birim React bileşenleriyse, Ekim CMS, site oluşturmak için eski HTML'yi iyi bilmenin yeterli olduğu önermesine dayanır. Gerçekten de, bir sayfa oluştururken bize bir HTML (İşaretleme) düzenleyicisi sunulur:

Sayfa yalnızca statik HTML olsaydı, bir CMS'ye gerek olmazdı. Bunun yerine, Ekim CMS sayfaları, düz optimize edilmiş PHP koduna derlenen Twig şablonları kullanılarak yazılır. Sayfanın iskelesini içerecek bir düzen seçebilirler (yani üstbilgi, altbilgi vb. gibi tekrarlayan öğeler), sayfanın içeriği özelleştirmesine izin vermek için düzende tanımlanan yer tutucuları uygulayabilir ve şunları içerebilir: yeniden kullanılabilir kod parçaları olan kısmi parçalar. Ek olarak, sayfalar, kendi başlarına düzenlenebilen metin, HTML veya Markdown dosyaları olan içerik bloklarını içerebilir ve eklentiler aracılığıyla uygulanan işlevsellik bileşenleri ekleyebilir. Ve son olarak, HTML yeterli olmadığında ve dinamik kod üretmemiz gerektiğinde PHP fonksiyonlarını ekleyebiliriz.

Editör tamamen HTML ile ilgilidir. Görsel bir şekilde içerik eklemek için TinyMCE textarea alanı yoktur - en azından varsayılan deneyim yoluyla değil (bu işlev eklenti alanına aittir). Bu nedenle, Ekim CMS'yi kullanmak için HTML bilgisine sahip olmak bir zorunluluk olarak kabul edilebilir. Ek olarak, içerik oluşturmak için birkaç farklı girdi (sayfalar, düzenler, yer tutucular, kısmi öğeler, içerik blokları, bileşenler ve PHP işlevleri) çok etkili olabilir, ancak kesinlikle WordPress'in birleşik blok arayüzü kadar basit değildir. Hatta başka öğeler de eklenebildiğinden (statik sayfalar ve menüler ve snippet'ler gibi) ve sayfalar ve statik sayfalar gibi bazıları görünüşte aynı işlevi sağladığından ve ne zaman yapılacağına karar vermeyi kafa karıştırıcı hale getirdiğinden, daha da karmaşık hale gelebilir. birini veya diğerini kullanın.

Sonuç olarak, hemen hemen herkes bir WordPress sitesini yönetici tarafından kullanabilirken, Ekim CMS'nin teknik olmayan kullanıcı dostu olmaktan çok geliştirici dostu olduğunu söylemeye cüret ediyorum, bu nedenle programcılar bunu kullanmaktan keyif alabilirler, ancak bazı diğer roller (pazarlamacılar, satış elemanları ve benzerleri) bunu sezgisel bulmayabilir.

Medya menajeri

Hem WordPress hem de Ekim CMS, siteye zahmetsizce medya dosyalarının eklenmesine izin veren, bir sürükle ve bırak arayüzü aracılığıyla aynı anda birden fazla dosyanın eklenmesini destekleyen ve görüntüleri içerik alanı içinde görüntüleyen bir Medya Yöneticisi ile birlikte gönderilir. Benzer görünürler ve benzer davranırlar; Bulduğum tek kayda değer fark, WordPress'in Medya Yöneticisinin resim galerilerini gömmeye izin vermesi ve Ekim Medya Yöneticisinin yüklenen dosyaların yerleştirileceği bir klasör yapısını manuel olarak oluşturmaya izin vermesidir.

Gutenberg'in piyasaya sürülmesinden bu yana, WordPress'in medya yetenekleri büyük ölçüde geliştirildi ve videoları, resimleri ve fotoğraf galerilerini bir TinyMCE textarea alanına kıyasla (sadece nasıl görüneceğinin doğru olmayan bir versiyonunu sağlayan) yerleştirmeyi mümkün kıldı. sitede) ve bu videoda gösterildiği gibi güçlü, ancak kullanımı kolay özelliklerin kilidini açın.

Uluslararasılaşma

WordPress çekirdeği, temaların ve eklentilerin çevirisini sağlamak için gettext kullanır. Çevrilecek tüm dizeleri içeren bir .pot dosyasından başlayarak, ilgili dile/yerel ayara çevirilerini içeren bir .po dosyası oluşturmamız gerekiyor ve bu dosya daha sonra hızlı çeviri çıkarma için uygun bir ikili .mo dosyasına derleniyor. Bu görevleri gerçekleştirmek için araçlar GlotPress (çevrimiçi) ve Poedit'i (indirilebilir uygulama) içerir. Uygun bir şekilde, bu mekanizma aynı zamanda Gutenberg için istemci tarafı yerelleştirme için de çalışır.

WordPress şu anda içeriği çevirmek için çekirdekte herhangi bir çözüm sunmuyor ve Gutenberg'in 4. Aşamasına kadar (2020+ yılı hedefleniyor) bunu yapmayacak. O zamana kadar bu işlevsellik, çevrilmiş içeriği depolamak ve yönetmek için farklı stratejiler sunan eklentiler tarafından sağlanır. Örneğin, Polylang ve WPML gibi eklentiler her çeviriyi özel bir veritabanı tablosundan kendi satırında saklarken (bu, içeriği birlikte karıştırmadığından temizdir, ancak sorgu sırasında iki tablodan oluşan ek bir INNER JOIN gerektirdiğinden daha yavaştır). veritabanı), eklenti qTranslate X orijinal veritabanı tablosundaki tüm çevirileri aynı alanda saklar (verileri sorgulamak için daha hızlıdır, ancak eklentinin devre dışı bırakılması durumunda içeriğin bir arada karıştırılması sitede enkaz oluşturabilir). Bu nedenle, alışveriş yapabilir ve ihtiyaçlarımıza en uygun stratejiye karar verebiliriz.

Ekim CMS, çok dilli işlevselliği çekirdeği aracılığıyla değil, Ekim CMS ekibi tarafından sisteme hatasız entegrasyonu garanti eden bir eklenti olarak sunar. İşlevsel bir bakış açısından, bu eklenti vaat ettiklerini sunar. Geliştirme açısından, bu eklentinin gerçekte nasıl çalıştığı pek ideal değil. WordPress'te bir sayfa, yalnızca "sayfa" yazı tipine sahip bir yazıdır ve onlar için tek bir çeviri mekanizması vardır, ancak Ekim CMS'de "sayfa", "statik sayfa" ve "blog yazısı" varlıkları vardır ve her ne kadar oldukça benzer, çevirileri için üç farklı uygulamaya ihtiyaç duyuyorlar! Ardından, bir "sayfadan" header.title , her biri, nav.content veritabanı tablosunda rainlab_translate_messages bir JSON nesnesi olarak tüm yerel ayarlar için çevirilerini içeren mesaj kodlarını (örn. Bir "statik sayfadan" gelen içerik, yerel ayar başına yeni bir statik dosyada oluşturulur, ancak tüm yerel ayarlar için çevrilmiş tüm URL'ler ilgili dosyada değil, bunun yerine varsayılan dilin dosyasında saklanır. "Blog gönderisi"nin içeriği, rainlab_translate_attributes veritabanı tablosunda yerel ayar başına bir satır olacak şekilde serileştirilmiş bir JSON nesnesi olarak depolanır ve çevrilen URL, rainlab_translate_attributes veritabanı tablosunda yerel ayar başına bir satır olacak şekilde rainlab_translate_indexes . Bu karmaşıklığın eklentinin nasıl uygulandığından mı yoksa Ekim CMS mimarisinden mi kaynaklandığını bilmiyorum. Durum ne olursa olsun, bu, geliştirme tarafında istenmeyen şişkinliğin başka bir örneğidir.

Eklenti Yönetimi

Hem WordPress hem de Ekim CMS, eklentileri aramanıza, yeni eklentiler yüklemenize ve şu anda yüklü eklentileri en son sürümlerine güncellemenize izin veren gelişmiş bir eklenti yöneticisi sunar - tümü arka uçtan.

Bağımlılık Yönetimi

Ekim CMS, tercih edilen paket yöneticisi olarak Composer'ı kullanır ve eklentilerin kurulurken bağımlılıklarını indirip kurmasını sağlar, böylece ağrısız bir deneyim sunar.

Karşı tarafta WordPress, Composer'ı (veya herhangi bir PHP bağımlılık yöneticisini) resmi olarak benimsemedi çünkü topluluk, WordPress'in bir site mi yoksa site bağımlılığı mı olduğu konusunda hemfikir değil. Bu nedenle, projeleri için Composer'a ihtiyaç duyarlarsa, geliştiricilerin bunu kendi başlarına eklemeleri gerekir. Gutenberg'e geçişle birlikte, npm tercih edilen JavaScript bağımlılık yöneticisi haline geldi, buna bağlı olarak popüler bir geliştirici araç takımı ve istemci tarafı kitaplıkları npm kayıt defterinde bağımsız paketler olarak düzenli olarak yayınlandı.

Veritabanı ile Etkileşim

WordPress, veritabanı verilerini ( get_posts gibi) almak ve depolamak ( wp_insert_post ve wp_update_post gibi) için işlevler sağlar. Verileri alırken, sonucun bir sınıfın örneği olarak mı yoksa bir dizi özellik ve diğerleri olarak mı iletilmesi gerektiğini belirtmek için sonuçları filtrelemek, sınırlamak ve sıralamak için parametreler iletebiliriz. İşlev gereksinimlerimizi tam olarak karşılamadığında (örneğin, özel bir tabloyla INNER JOIN yapmamız gerektiğinde), veritabanını doğrudan $wpdb global değişkeni aracılığıyla sorgulayabiliriz. Özel gönderi türüne sahip bir eklenti oluştururken, kod büyük olasılıkla verileri almak ve/veya özel tablolara kaydetmek için özel SQL sorguları yürütür. Özetle, WordPress ilk aşamada genel işlevler aracılığıyla veritabanına erişim sağlamaya çalışır ve ikinci aşamada veritabanına düşük seviyeli erişim sağlar.

Ekim CMS farklı bir yaklaşım kullanır: Uygulama, veritabanına hemen bağlanmak yerine, Modeller adı verilen sınıf örnekleri aracılığıyla veritabanı verilerine erişmek ve bunları işlemek için Laravel'in Eloquent ORM'sini kullanabilir, bu da veritabanıyla etkileşimin Nesne Yönelimli Programlamaya dayalı olmasını sağlar. . Üst düzey erişimdir; Bir eklenti, yalnızca tabloların nasıl oluşturulacağına ve varlıklar arasında ilişkilerin nasıl kurulacağına ilişkin kuralları izleyerek, bir satır SQL yazmadan verileri alabilir ve/veya kaydedebilir. Örneğin, aşağıdaki kod Flight modeli aracılığıyla veritabanından bir nesne alır, bir özelliği değiştirir ve tekrar depolar:

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

Veri Modelini Yükseltme

WordPress'in başarısının bir başka nedeni (geriye dönük uyumluluğu bozmamanın yanı sıra), uygulamaların zaman içinde büyümesini sağlamak için tasarlanmış veritabanı mimarisidir. Bu amaç, "meta" özellikler, yani herhangi bir anda bir veritabanı nesnesine gevşek bir şekilde eklenebilen özellikler aracılığıyla gerçekleştirilir. Bu özellikler, karşılık gelen varlık tablosundan ( wp_posts , wp_users , wp_comments veya wp_terms ) bir sütunda saklanmaz, bunun yerine ilgili "meta" tablosunda ( wp_postmeta , wp_usermeta , wp_commentmeta veya wp_termmeta ) bir satır olarak saklanır ve bir INNER JOIN yapılarak alınır. INNER JOIN Bu nedenle, bu meta değerlerin alınması daha yavaş olsa da, sınırsız esneklik sağlarlar ve bazı yeni işlevleri uygulamak için uygulamanın veri modelinin nadiren sıfırdan yeniden yapılandırılması gerekir.

Ekim CMS, meta özellikleri kullanmaz, bunun yerine, serileştirilmiş bir JSON nesnesi olarak, veritabanı tablolarında doğrudan sütunlar olarak eşlenmeyen birkaç keyfi değeri depolayabilir. 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.

Yönetilen Barındırma

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.

Toplum

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?

Dünyadaki tüm sitelerin üçte birine güç sağlayan WordPress, yazılıma katkıda bulunan paydaşlardan yoksun değildir; dolayısıyla yazılımın çürüyeceğinden korkmamıza gerek yok. Bununla birlikte, WordPress, yönetim modeliyle ilgili dahili müzakerelerden geçiyor ve topluluğun birçok üyesi, WordPress'in yönüne ilişkin kararların WordPress.com'u işleten şirket olan Automattic tarafından tek taraflı olarak alındığını ifade ediyor. Bu algının ana aşaması, birçok üyenin aynı fikirde olmadığı ve geliştirilmesi ve piyasaya sürülmesi sırasında proje liderleri tarafından uygun iletişim eksikliği çeken Gutenberg'in piyasaya sürülmesi kararıydı. Sonuç olarak, birçok topluluk üyesi, tarihsel olarak WordPress'in kurucusu ve Automattic'in CEO'su Matt Mullenweg'e verilen “iyi huylu diktatör” rolünü sorguluyor ve WordPress'in geleceği için daha uygun bir yönetim modeli bulmak için farklı yönetim modelleri araştırıyor. Bu arayışın herhangi bir sonuç verip vermeyeceği veya statükonun devam edip etmeyeceği henüz belli değil.

Ekim CMS'nin yönüne ilişkin kararlar, çoğunlukla projenin güçlü kalmasını sağlayan kurucular Alexey Bobkov ve Samuel Georges ile geliştirici ve topluluk yöneticisi Luke Towers tarafından alınmaktadır. Ekim CMS'nin henüz bir yönetişim sorunu yaşama lüksü yok: Şu anki endişesi, çekirdek yazılımın bakımcıları için gelir yaratarak projenin nasıl sürdürülebilir hale getirileceğidir.

belgeler

Kendi sitesindeki WordPress belgeleri son derece kapsamlı değildir, ancak işi oldukça iyi yapar. Bununla birlikte, genel siteler (Smashing Magazine, CSS hileleri ve diğerleri), özel siteler (WPshout, WPBeginner ve diğerleri), kişisel bloglar, çevrimiçi kurslar gibi tüm kaynaklardan WordPress ile ilgili tüm belgeler dikkate alındığında, ve benzerleri, WordPress ile uğraşmanın pratikte henüz ele alınmamış hiçbir yönü yoktur.

Ekim CMS, pek çok üçüncü taraf kursunun, öğreticinin veya blog gönderisinin yanında WordPress kadar hiçbir şeyden hoşlanmaz, ancak sitesindeki belgeler oldukça kapsamlıdır ve kesinlikle kodlamaya başlamak için yeterlidir. Ekim kurucuları ayrıca öğreticiler aracılığıyla düzenli olarak yeni belgeler ekler. Kişisel olarak hoşuma giden bir yön, Laravel'in belgelerinin ilgili her şey için Ekim'in belgelerine kopyalanmasıydı, bu nedenle okuyucu boşlukları kendi başına doldurmamalı ve Ekim'in alanının ve Laravel'in alanının ne olduğunu tahmin etmek zorunda kalmamalıdır. Ancak bu %100 mükemmel değildir. Ekim'in belgeleri, bunların ne olduğunu yeterince açıklamadan, ara katman yazılımı, hizmet kapları, cepheler ve sözleşmeler gibi Laravel'den gelen terimleri kullanıyor. O zaman, Laravel'in belgelerini önceden okumak yardımcı olabilir (neyse ki, Laravel'in belgeleri kesinlikle kapsamlıdır ve Laravel'in ekran görüntüleri, Laracast'ler, sadece Laravel ile ilgili değil, genel olarak web geliştirme ile ilgili olarak başka bir harika öğrenme kaynağıdır).

Çözüm

WordPress'i ücretsiz ve açık kaynak olarak tanımladığım, PHP tabanlı ve dinamik içerik üreten ve bazı toplulukların desteğinden yararlanan benzer bir CMS ile karşılaştırarak, WordPress'e alternatif arayan geliştiriciler için hangi özelliklerin cazip olabileceğini keşfetmeye başladım. . Bu koşulları sağlayan CMS'lerden, hakkında edindiğim bilgiler ve şantiyeler için taze ve modern bir bakış açısı sunabilen Laravel'in sunduğu temiz ve modüler kodlama yaklaşımını beğendiğim için karşılaştırma için Ekim CMS'yi seçtim.

Bu makale bir kazanan seçmeyi amaçlamamıştır, ancak güçlü ve zayıf yönlerini vurgulayarak bir veya diğer CMS'yi seçmenin ne zaman mantıklı olduğunu analiz edin. "En iyi" İYS yoktur: yalnızca belirli bir durum için en uygun İYS'dir. Ayrıca, belirli bir ekiple ve belirli bir bütçeyle belirli bir projede kullanmak üzere bir CMS arayan herkes, belirli bir bağlam için hangisinin en uygun olduğunu bulmak için biraz araştırma yapmalı ve oradaki tüm teklifleri karşılaştırmalıdır. Bu makalede burada yaptığım gibi birkaç CMS ile sınırlandırmamak, bunun yerine hepsine bir şans vermek önemlidir.

Kişisel bir not olarak, bir geliştirici olarak, Ekim CMS'de bulduğum şey bana gerçekten çekici geldi, çoğunlukla Laravel aracılığıyla sağlanan modüler uygulamalar oluşturma yeteneği. Bu CMS'yi kesinlikle yeni bir web sitesi için düşünürdüm. Ancak, bu makaleyi yazma sürecinde WordPress'i de “yeniden keşfettim”. Çok popüler olan WordPress, çoğunlukla eski kod tabanı ve yakın zamanda Gutenberg'in tanıtımı ile ilgili olarak adil payından daha fazlasını alıyor; bununla birlikte, WordPress ayrıca nadiren övülen ancak dikkate alınması gereken bazı mükemmel özelliklere (süper ölçeklenebilir veritabanı modeli gibi) sahiptir. Ve en önemlisi, WordPress tek başına teknik yönleriyle ele alınmamalıdır: özellikle topluluğunun ve ekosisteminin boyutu, onu alternatiflerinin bir veya iki seviye üstüne yerleştirir. Özetle, bazı projeler WordPress'e bağlı kalmaktan fayda sağlayabilirken, diğerleri Ekim CMS'ye veya başka bir platforma daha iyi güvenebilir.

Son bir not olarak, başka bir CMS'nin nasıl çalıştığını keşfetmenin, o belirli CMS'yi kullanıp kullanmama konusunda verilen karardan bağımsız olarak kendi başına çok faydalı bir faaliyet olduğunu belirtmek isterim. Benim durumumda, yıllardır yalnızca WordPress üzerinde çalışıyordum ve Ekim CMS'sini incelemek, bana WordPress aracılığıyla maruz kalmadığım birçok şeyi (PHP Standart Önerilerinin varlığı gibi) öğrettiği için çok canlandırıcıydı. Artık CMS'leri değiştirmeye veya daha iyi kod üretmeyi bilen WordPress'e bağlı kalmaya karar verebilirim.

SmashingMag'de Daha Fazla Okuma :

• Gutenberg Çağında Akıllıca Önbelleğe Alma
• Modern PHP ile WordPress Kodunu Geliştirme
• WordPress Eklentileri Geliştirirken Alınan Dersler
• WordPress Web Sitenizdeki Tıklamaları İzlemek İçin Isı Haritaları Nasıl Kullanılır?
• Dikkatli Olun: Sitenizi Güvensiz Hale Getirebilecek PHP ve WordPress İşlevleri