corpusctl vs WordPress: ne kazanırsınız, neden vazgeçersiniz

corpusctl hiçbir zaman bir sayfa render etmez. Tema katmanı yok, şablon hiyerarşisi yok, üzerine akıl yürütülecek bir hook sırası yok. Okuma istemcisi bir sonradan ekleme değil, birincil arayüzdür.

#Biri yazınızı okuduğunda gerçekte ne olur

WordPress: istek PHP'ye ulaşır, PHP MySQL'i sorgular, eklentiler çalışır, tema render eder. Ardından önüne bir önbellekleme eklentisi, sonra belki onun önüne bir CDN koyarsınız ve önbellek geçersiz kılma işine gerçek zaman harcarsınız — çünkü sayfa hesaplanır ve önbellek, her an değişebilecek bir hesaplamanın kopyasıdır.

corpusctl: yayınlama, derleme hattını çalıştırır. İçerik doğrulanır, render edilir ve nesne deposundaki değişmez, hash ile adreslenen bir dosyaya yazılır; manifest yenilenir. Ziyaretçinin istemcisi slug'ı yerel olarak bir manifest parçasına çözer, ardından o adresi nginx kenar önbelleğinden çeker.

Adres bir içerik hash'i olduğu için, aynı adres asla farklı içerik döndüremez — dolayısıyla bir geçersiz kılma stratejisi olmadan otuz gün önbelleğe alınabilir. Yayınlama yeni bir adres yazar. Temizlenecek bir şey yoktur.

İki HTTP isteği, ikisi de önbellekten. Hiçbiri API'ye ulaşmaz. Hiçbiri PostgreSQL'e ulaşmaz.

Bunu takip eden sayı: ziyaretçi trafiği yazma yolunuzu hiç yüklemez. Bir trafik sıçraması sırasında taslak kaydeden bir editör, o sıçramayla rekabet etmez.

#Eklenti yüzeyi aynı zamanda saldırı yüzeyidir

Eklenti ekosistemi WordPress'in en büyük gücüdür ve aynı cümle onun en büyük operasyonel riskidir. Her eklenti, sürecinizde veritabanı erişimiyle çalışan üçüncü taraf kodudur. Otuz eklentili bir sitenin otuz güncelleme akışı ve otuz olası CVE'si vardır ve bozulan eklenti genellikle kimsenin kurduğunu hatırlamadığı eklentidir.

corpusctl'in eklenti pazar yeri yok — bu gerçek bir kayıp, aşağıda dürüstçe listelendi. Onun yerine sahip olduğu şey, CI tarafından uygulanan bir kurala sahip bir modül sistemidir:

• Her özellik bir modüldür: medya, arama, webhook'lar, SEO, GraphQL, içe aktarma, analitik.
• Modüller birbirini import edemez. Aralarındaki tek kanal bir servis kayıt defteri ve bir olay veriyoludur ve pnpm check:isolation bu kural ihlal edilirse derlemeyi başarısız kılar.
• Bir modülü kaldırmak derlemeyi kıramaz. Kuralın bütün amacı budur.

Ve bir özelliği kapatmak hiçbir şeyi yok etmez: disabled veriyi korur ve yeniden etkinleştirmede kaldığı yerden devam eder, uninstalled onu çift onayla temizler ve bir plan düşürülmesi modülleri yalnızca disabled yapar.

#Birden fazla site, tek panel

WordPress Multisite var ve işe yarıyor, ancak işletmecilerin bildiği çekincelerle: ağ genelinde kötü davranan eklentiler, paylaşılan bir veritabanı, her siteye aynı anda inen bir yükseltme ve "bu editör bir ve üç numaralı markalarda çalışır ama iki numaralı markayı görmemeli" için tasarlanmamış bir izin modeli.

corpusctl, auth ve modül kayıt defterinin yanında, çekirdekte çok kiracılıdır:

• Tek panel, sınırsız alan.
• Bir kullanıcı alan başına ayrı bir rol taşır.
• İzolasyon PostgreSQL satır düzeyi güvenliği ile uygulanır — veritabanında, unutulmuş bir filtrenin yaşadığı uygulama katmanının altında.

RLS'in gerekçesi dardır: uygulama düzeyinde izolasyon, filtreyi atlayan tek sorguya kadar dayanır ve o sorgu eninde sonunda, aceleyle, kimsenin yakından incelemediği bir modülde biri tarafından yazılır. RLS, sızıntıyı hatanın altında imkansız kılar.

#Yapılandırılmış içerik ve tasarımın sahibi kim

WordPress içeriği bir yazı veya bir sayfadır; özel alanlar ve bunları yönetmek için bir eklentiyle genişletilir. İşe yarıyor ve model kökenlerini belli ediyor.

corpusctl'de yerleşik içerik tipleri yoktur. Onları panelden veya API'den tanımlarsınız ve alanlar roller taşır — title, slug, body — böylece sistem, siz onu nasıl adlandırdığınıza bağlı kalmadan hangi alanın başlık olduğunu bilir. Yerelleştirme alan bazındadır. Her kayıt sürümlenir, eski sürümler geri yüklenebilir ve yayınlama zamanlanabilir.

Ön yüzde ise blok render'ıcıları sıfır varsayılan stil ile gelir. Tek satır CSS bile yok. Her blok tipi override edilebilir ve bilinmeyen bir blok tipi, hata fırlatmak yerine zarifçe atlanır. Çekirdek render ağacı çerçeve-bağımsızdır; React, Vue ve Next.js adaptörleri onun üstünde ince birer katman olarak durur.

Bunu, miras aldığınız ve sonra override ettiğiniz bir tasarım kararı olan bir WordPress temasıyla karşılaştırın.

#WordPress'te kalmak için üç iyi neden

İşe alma. WordPress bilen birini her şehirde, her bütçeyle, gelecek hafta bulabilirsiniz. Bunu corpusctl için yapamazsınız ve aksini iddia etmek saçma olur.

Ekosistem. Formlar, rezervasyonlar, üyelikler, e-ticaret, SEO araçları, geçiş yardımcıları — bir eklenti vardır, denenmiştir ve 59 dolara mal olur. API'ye karşı eşdeğerini inşa etmek başlı başına bir projedir.

Ücretsiz. WordPress çekirdeği hiçbir ücret istemez ve hiçbir zaman istemedi. Bütçe bağlayıcı kısıtsa, bu tartışmayı bitirir.

Dördüncü, daha az rahat bir neden ekleyin: corpusctl genç. SSO ve sözleşmeli bir SLA yol haritasında, ki bu henüz yoklar demenin kibar yolu. Pazar yeri yok ve küresel CDN yok — kenar önbelleği tek bölgeli. Satın alma kontrol listenizde bunlardan herhangi biri varsa, bu karşılaştırma burada biter.

#Dürüst özet

Tek bir ekip tek bir siteyi düzenliyorsa, ekosistem sizin için gerçek bir iş yapıyorsa ya da kararı bütçe veriyorsa WordPress'te kalın.

Birden fazla proje, birden fazla ön yüz ya da artık denetleyemediğiniz bir eklenti yüzeyi işletiyorsanız — ve okuma yolunun bir önbellekleme sorunu olmaktan çıkmasını istiyorsanız corpusctl'e geçin.

Geçiş mi yapıyorsunuz? İçe aktarma modülü bir WordPress WXR dışa aktarımını okur: yazılar, sayfalar, etiketler ve medya. Alan rolleri eşlenir ve gövde blok modeline dönüştürülür. Bir eklentinin yaptığı her şey için gerçek zaman ayırın — o mantık dışa aktarılmaz.

Mimariye göz atın → · Belgeleri okuyun →

corpusctl vs Directus: içerik platformuna karşı veritabanı sarıcısı