Modern bir CMS kurmak için web’i yeniden icat etmeniz gerekmiyor
Yeni web teknolojileri heyecan vericidir. Yeni framework’ler, görüntüleme modelleri, derleme sistemleri ve soyutlama katmanları düzenli olarak gerçek sorunları çözer.
Ancak her yeni uygulama yeni bir uygulama mimarisine ihtiyaç duymaz.
WebBlocks CMS oldukça basit bir soruyla başladı:
İyi çalıştıkları alanlarda bildiğimiz web teknolojilerini kullanmaya devam edersek modern bir CMS ne kadar ileri gidebilir?
Bu; uygulama için PHP ve Laravel, yapılandırılmış içerik için ilişkisel veritabanı, işaretleme için HTML, görünüm için CSS ve tarayıcı davranışı gerçekten gerektirdiğinde JavaScript demektir.
Bu fikirlerin hiçbiri yeni değildir.
Bu bilinçli bir tercihtir.
WebBlocks CMS; MVC’yi yeniden icat etme, blokları bulma, Laravel’in yerini alma veya başka bir frontend mimarisi getirme girişimi değildir. Alttaki uygulamayı anlaşılır ve geliştiricinin kontrolünde tutarken yetenekli, modern bir CMS kurma girişimidir.
Giderek daha fazla, aynı yapılandırılmış CMS’yi yapay zeka ve otomasyon araçlarına güvenli biçimde açmak da bunun parçası oluyor.
Laravel uygulamanıza katılan bir CMS
CMS ürünlerinde yaygın varsayım, CMS’nin uygulamanın kendisi olduğudur.
CMS’yi kurar, her şeyi onun dünyasında oluşturur, yönlendirme kurallarını ve genişletme modelini kullanır, projenin geri kalanını ona uyarlarsınız.
WebBlocks farklı bir yaklaşım izler.
Composer paketi olarak dağıtılır ve zaten sahip olduğunuz Laravel uygulamasına kurulabilir.
Laravel uygulaması uygulama olarak kalır.
Şu alanların sahibi olmaya devam eder:
- kimlik doğrulama
- veritabanı yapılandırması
- kuyruklar
- e-posta
- dağıtım
- uygulama rotaları
- altyapı
- iş alanına özgü mantık
WebBlocks içerik yönetimi katmanını ekler: sayfalar, yerleşimler, bloklar, medya, gezinme, yerelleştirme, revizyonlar, yayın iş akışları ve /webadmin çalışma alanı.
Kurulum bilinçli olarak tanıdıktır:
composer require fklavyenet/webblocks-cms
Ardından php artisan webblocks:install çalıştırılır.
Projenin düzenlenebilir içeriğe ihtiyaç duyması, ikinci bir frontend uygulaması oluşturmayı zorunlu kılmaz.
Laravel ürününüz ve web siteniz birlikte çalışabilir
Bu yaklaşım, web sitesi daha büyük bir uygulamanın yalnızca bir parçası olduğunda özellikle yararlıdır.
Zaten şunlardan birine sahip olduğunuzu düşünün:
- SaaS ürünü
- müşteri portalı
- rezervasyon uygulaması
- kurum içi iş sistemi
- üyelik platformu
- e-ticaretle ilgili Laravel uygulaması
- veya önemli miktarda özel iş mantığı içeren bir Laravel projesi
Ürünün kendisi zaten sorunsuz çalışıyor olabilir.
İhtiyaç, editörlerin onun herkese açık kısmını yönetmesidir: ana sayfa, ürün sayfaları, dokümantasyon, açılış sayfaları, yardım içeriği, yasal sayfalar, kampanya sayfaları veya başka editoryal içerik.
Çözümlerden biri başka bir uygulama eklemektir.
Ayrı bir CMS, ayrı bir frontend; belki başka bir framework, başka bir dağıtım süreci ve ürünle web sitesi arasında başka bir entegrasyon sınırı.
WebBlocks ise mevcut Laravel uygulamasının isteğe bağlı web sitesi ve içerik katmanı olabilir.
Ürün mantığı ait olduğu yerde kalır.
Laravel’de.
CMS, içerik odaklı kısımları yönetir.
Birlikte çalışma modeli bunun için tasarlanmıştır.
WebBlocks, geleneksel bir web sitesinin ana CMS’si olarak da çalışabilir. Önemli olan, her Laravel projesini aynı mimariye zorlamamasıdır.
Herkese açık web sitesini de oluşturabilir
WebBlocks yalnızca headless içerik veritabanı olarak çalışmakla sınırlı değildir.
Herkese açık web sitesini bizzat yönetebilir ve oluşturabilir.
Sayfaların gerçek herkese açık adresleri vardır:
/features/contact/docs/internal-content-api
Herkese açık sayfa oluşturucu, editörlerin CMS’de yönettiği aynı yapılandırılmış Sayfa → Yerleşim → Alan → Blok modeli üzerinde çalışır.
Böylece Laravel uygulaması, yalnızca içerik sunmak için başka bir frontend çalışma zamanı eklemeden hem uygulama rotalarını hem CMS tarafından yönetilen herkese açık sayfaları içerebilir.
CMS paketi kendi başına Node, npm, Vite veya ayrı bir frontend framework’ü gerektirmez.
Bu, JavaScript’in yasak olduğu anlamına gelmez.
JavaScript’in web sitesini oluşturmanın ön koşulu olmak yerine, gerçekten gerektiğinde kullanılması anlamına gelir.
Aynı ilke projenin tamamında geçerlidir:
Her teknolojiyi yararlı katkı sağladığı yerde kullanın.
Sayfa → Yerleşim → Alan → Blok yeni bir buluş değil
Blok tabanlı içerik sistemleri uzun yıllardır var.
Drupal’da bölgeler ve bloklar bulunur. Diğer CMS ürünlerinin bölüm, bileşen, modül, widget ve yeniden kullanılabilir içerik için kendi karşılıkları vardır.
WebBlocks bu kavramı icat ettiğini iddia etmez.
İçerik modeli bilinçli olarak anlaşılır tutulur:
Sayfa → Yerleşim → Alan → Blok
Sayfa bir yerleşim seçer.
Yerleşim adlandırılmış bölgeleri tanımlar.
Bu alanlar bloklar içerir.
Bloklar yapılandırılmış içerik taşır; uygun olduğunda iç içe yapıları da destekleyebilir.
Değer, kelimelerin yeni olması değildir.
Değer, editörün, Laravel geliştiricisinin ve otomasyon aracının aynı açık yapıyı anlayıp değerlendirebilmesidir.
CMS ile oluşturulan sayfa arasında gizli bir frontend uygulama modeli bulunması gerekmez.
Yeniden kullanılabilir içerik olağan olmalıdır
Üstbilgileri, altbilgileri, kenar çubuklarını, eylem çağrılarını ve diğer tekrarlanan yapıları her sayfada yeniden kurmak gerekmemelidir.
WebBlocks bunun için Shared Slots kullanır.
Yeniden kullanılabilir içerik, devrim niteliğinde bir CMS buluşu olarak sunulmuyor. Pratik bir CMS’nin sağlaması gereken bir özelliktir.
Ancak önemli bir editoryal sorun da getirir: Paylaşılan içeriği değiştirmek aynı anda birçok sayfayı etkileyebilir.
Bu nedenle Shared Slots görünmez genel parçalar sayılmak yerine kendi kontrollü içerik ve revizyon iş akışlarına katılır.
Yeniden kullanım yararlıdır.
Kontrollü yeniden kullanım daha güvenlidir.
Yayınlama yalnızca açma/kapama düğmesi değildir
İçeriği birden fazla kişi veya farklı türden aktör değiştirebildiğinde CMS daha ilginç hale gelir.
WebBlocks, sayfayı yayımlamanın yayımlanmamış tüm blokları da herkese açacağını varsaymak yerine, sayfa durumuyla blok yayınını ayırır.
Sayfalar editoryal durumlar arasında ilerleyebilir.
Revizyonlar sayfa düzeyinde güvenlik amaçlı anlık görüntüler sağlar.
Paylaşılan içeriğin kendi revizyon geçmişi vardır.
Yayınlama işlemi, sayfaya ait blokların da herkese açılıp açılmayacağını açıkça belirtebilir.
Bu, insan editör ekipleri için önemlidir.
Otomasyon ve yapay zeka iş akışına katıldığında daha da önemli hale gelir.
Çoklu site ve yerelleştirme içerik modelinin parçasıdır
Tek bir WebBlocks kurulumu, site sahipliğini açık tutarak farklı siteleri, alan adlarını ve dilleri yönetebilir.
Yerelleştirme yalnızca “sayfayı çoğalt ve çevir” değildir.
İncelenmiş sayfa yapısı anlaşılır kalırken içerik, adresler ve SEO verileri yerelleştirilebilir.
Bu, birden fazla ürün sitesi, bölgesel site veya çok dilli site işleten ama her biri için ayrı CMS kurulumu istemeyen kuruluşlara yarar sağlar.
Bu, çoklu site veya yerelleştirmenin yeni kavramlar olduğu iddiası değildir.
Bunlar CMS’nin yerleşik sorumluluklarıdır.
Amaç, Laravel uygulamasının mimarisinin kontrolünden vazgeçmesini gerektirmeden bunları sağlamaktır.
Medya da CMS’ye aittir
Editoryal içerik metinden fazlasıdır.
WebBlocks, medyanın sayfalar ve bloklarla aynı yapılandırılmış yayın ortamına katılabilmesi için medya yönetimi ve görsel türevleri sağlar.
Gezinme, arama, revizyonlar, yedekler, site aktarımı ve kontrollü yayınlama ile birlikte amaç, küçük bir blok editörü prototipi göstermek yerine CMS’den beklenen normal operasyonel sorumlulukları karşılamaktır.
Bu ayrım önemlidir.
Blok editörü bir özelliktir.
CMS, içeriğin yaşam döngüsünü de yönetmelidir.
Ardından yapay zeka soruyu değiştirir
Geleneksel mimarinin özellikle ilgi çekici hale geldiği yer burasıdır.
Bugün birçok ürün, yönetim arayüzüne metin kutusu ekleyip bunu bir modele bağlayarak yapay zeka desteği sunuyor.
Bu yararlı olabilir; ancak WebBlocks’un araştırdığı yön bu değil.
Daha ilginç soru şu:
Yapay zeka aracı gerçek CMS’yi güvenli biçimde anlayıp üzerinde işlem yapabilirse ne olur?
WebBlocks, Internal Content API üzerinden yapılandırılmış CMS yeteneklerini sunar.
Güvenilir yapay zeka veya operatör aracı, CMS’nin nasıl çalıştığını tahmin etmek yerine gerçek kurulumu inceleyebilir.
Kullanılabilir siteleri, dilleri, yerleşimleri, blok türlerini ve içerik sözleşmelerini keşfedebilir.
Mevcut yapılandırılmış içeriği inceleyebilir.
Tam bir sayfa planı hazırlayabilir.
İçeriği değiştirmeden önce planı doğrulayabilir.
Taslak içerik oluşturabilir veya düzenleyebilir.
Yayınlama ise açık izin gerektiren ayrı bir yetenek olarak kalır.
Bu ayrım önemlidir.
Yapay zekanın yönetim arayüzünü taraması gerekmez.
Fare tıklamalarını taklit etmesi gerekmez.
HTML uydurup CMS’nin kabul edeceğini umması gerekmez.
CMS’nin de anladığı aynı yapılandırılmış içerik modeliyle çalışabilir.
Yapay zeka erişimi sınırsız erişim anlamına gelmek zorunda değil
Yapay zeka aracına CMS erişimi vermek açık bir soruyu gündeme getirir:
Ne yapmasına izin veriliyor?
Internal Content API, yetki kapsamlarıyla bilinçli olarak sınırlandırılmıştır.
İçerik doğrulama ve içerik uygulama ayrı işlemlerdir.
İçerik önce taslağa uygulanır.
Yayınlama ayrı bir content.publish yeteneği gerektirir.
API, otomasyonu sınırsız yetkili yönetici saymak yerine tanımlı sözleşmelerin dışındaki işlemleri reddeder.
Amaç şu değildir:
“Web sitesini yapay zeka yönetsin.”
Şuna daha yakındır:
“Güvenilir araçlar, diğer uygulama aktörlerinden beklediğimiz sınırlar içinde iyi tanımlanmış CMS işlemlerini gerçekleştirsin.”
Bu, ilginç olanaklar yaratır.
Yapay zeka aracı son yayın kararını editöre bırakarak yeni bir açılış sayfası hazırlayabilir.
Sayfanın tamamını değiştirmeden seçili taslak bölümlerini güncelleyebilir.
İçerik önermeden önce gerçek kurulumun desteklediği blok yapılarını anlayabilir.
Çok dilli sitede site ve dil sınırlarına uyarak çalışabilir.
Bunlar sağlayıcıya özgü yapay zeka entegrasyonu değil CMS yetenekleri olduğu için CMS çekirdeği tek model sağlayıcısına bağımlı olmak zorunda değildir.
Geleneksel olmak statik olmak değildir
Yerleşik teknolojileri kullanmak yeni yetenekleri reddetmek değildir.
Bu yetenekleri farklı bir katmana yerleştirmek olabilir.
İçerik üretimine yapay zeka yardım ettiği için HTML eskiyip geçersiz hale gelmez.
Editör etkileşimli bloklar istediği için Laravel’in JavaScript uygulamasına dönüşmesi gerekmez.
Otomasyon aracı API üzerinden yapılandırılmış içerik yazdığı için ilişkisel veritabanı uygunsuz hale gelmez.
Sunucuda sayfa oluşturmak modern editoryal iş akışlarını engellemez.
Geleneksel Laravel uygulaması da yapay zeka araçlarının güvenle kullanabileceği kadar gelişmiş, makine tarafından okunabilen sözleşmeler sunabilir.
WebBlocks CMS’nin arkasındaki deneme bu birleşimdir.
WebBlocks neyi kanıtlamaya çalışmıyor?
WebBlocks şunların yeni olduğunu kanıtlamaya çalışmıyor:
- MVC
- monolitik uygulamalar
- bloklar
- yeniden kullanılabilir bölgeler
- sunucuda sayfa oluşturma
- CMS iş akışları
Bunların yeni olmadığı açıktır.
Proje, frontend framework’lerinin, headless mimarilerin veya yoğun JavaScript kullanan uygulamaların doğası gereği yanlış olduğunu da savunmuyor.
Bunlar gerçek sorunları çözer ve birçok uygulama için doğru seçimdir.
Daha dar soru, bunların CMS kullanan her Laravel projesi için otomatik gereksinim olup olmamasıdır.
WebBlocks’un yanıtı, onları temel zorunluluk yerine seçenek haline getirmektir.
Bilinçli olarak sıradan bir temel
Yazılımda “sıradan teknoloji” ifadesini özür gibi kullanma eğilimi vardır.
Bu, avantaj da olabilir.
WebBlocks projesini açan Laravel geliştiricisi hâlâ bir Laravel uygulaması görmelidir.
Frontend geliştiricisi hâlâ HTML, CSS ve JavaScript görmelidir.
Editör dağıtım mimarisi değil, sayfalar ve içerik görmelidir.
Yapay zeka aracı ise yönetim arayüzünü tersine mühendislikle çözmek yerine açık şemalar, izinler ve yapılandırılmış işlemler görmelidir.
Bu temelin üzerinde yenilik için bolca alan vardır.
Temelin kendisi yabancı olmak zorunda değildir.
Terimler yerine yaklaşımı deneyin
WebBlocks CMS’nin ayrı ayrı kavramları bilinçli olarak tanıdıktır.
İlginç olan, birlikte nasıl çalıştıklarıdır:
- Composer ile kurulabilen Laravel CMS,
- mevcut ürün için isteğe bağlı içerik katmanı,
- herkese açık web sitesi oluşturma,
- yapılandırılmış sayfalar ve yeniden kullanılabilir içerik,
- çoklu site ve yerelleştirme,
- medya ve gezinme,
- revizyonlar ve kontrollü yayınlama,
- modern yapay zeka araçlarının gerçek CMS iş akışlarına katılabildiği, yetki kapsamlarıyla sınırlandırılmış API’ler.
Bu birleşimin yararlı olup olmadığı, MVC’nin, blokların veya monolitik uygulamaların daha önce var olup olmadığından çok daha ilginç bir sorudur.
Elbette daha önce vardılar.
Proje açık kaynaklıdır, dokümantasyon herkese açıktır ve canlı demo vardır.
Bu yüzden fikri değerlendirmenin en iyi yolu, bileşenlerin yeni olup olmadığını sormak değildir.
CMS’yi deneyin ve bunlarla neler yapılabildiğini görün.