Drupal, TYPO3, Joomla, MODX ve Cotonti Mimari Yapılarının Analizi

17 Jul 2026· Slaweally· 17 dk okuma

Merhabalar efenim, Malumunuz üzere bir süre üzerinde çalışmaya başladığım CPalius projesi için hem kendimi hemde alternatiflerini incelemek ve projemde bana önderlik etmesi için sevgili gemini'a benim yerime araştırmasını söylemiştim sağolsun kapsamlıca bir araştırma yapmış bende bu araştırma sonucunu buraya yapıştırayım daha sonra bana da lazım olacak siz de faydalanırsınız :)

Drupal, TYPO3, Joomla, MODX ve Cotonti Mimari Yapılarının Analizi ve Symfony Tabanlı CMF Tasarımı

İçerik yönetim sistemlerinin evrimi, monolitik ve katı yapılardan daha esnek, modüler ve modern yazılım çerçevelerine (Framework) entegre olan İçerik Yönetim Çerçevelerine (CMF) doğru kaymaktadır. Symfony gibi bileşen tabanlı modern bir PHP framework'ü üzerinde sıfırdan bir CMF geliştirmek, sistemin temel taşlarını kurarken sektörde rüştünü ispatlamış olgun platformların en başarılı mimari desenlerini incelemeyi ve bunları uyumlu bir şekilde sentezlemeyi gerektirir. Bu analiz; Drupal, TYPO3, Joomla, MODX ve Cotonti projelerinin veri yapılarını, şema üretim sistemlerini, yetkilendirme modellerini, dinamik alan yönetimlerini ve iş süreçlerini teknik düzeyde karşılaştırmalı olarak inceleyerek Symfony tabanlı bir CMF projesi için birleştirici bir mimari kılavuz sunmaktadır.

İçerik Yönetim Çerçevelerinde Mimari Standartlar ve CMF Yaklaşımı

Geleneksel içerik yönetim sistemleri, önceden belirlenmiş veri tabanı şemaları ve katı yönetim arayüzleri ile sınırlandırılmıştır. Buna karşılık bir CMF, geliştiricilere veri depolama katmanı, yönlendirme (routing), yetkilendirme ve form üretimi süreçlerinde tamamen genişletilebilir bileşenler sunar. Symfony tabanlı bir CMF tasarlarken, sistemin modülerliğini ve performansını optimize etmek amacıyla, incelenen her platformun kendi alanında lider olduğu mimari çözümler analiz edilmeli ve veri akış şemaları bu doğrultuda yapılandırılmalıdır.

Platform	Veri Modelleme Felsefesi	Fiziksel Depolama Yapısı	Şema Güncelleme Davranışı
Drupal	Varlık Odaklı (Entity-First)	Temel alanlar ana tabloda, özel alanlar dinamik üretilen ilişkili tablolarda.	Değişikliklere kapalıdır; veri varsa FieldStorageDefinitionUpdateForbiddenException fırlatır.
TYPO3	Metaveri Tanımlı (TCA)	SQL tabloları üzerinde PHP tabanlı soyutlama katmanı.	TCA güncellemeleri bootstrap sırasında derlenip önbelleğe alınarak uygulanır.
Joomla	Hiyerarşik Varlık Ağacı (ACL)	İç içe Kümeler (Nested Sets) modeli tabanlı #__assets ağacı.	Şema sabittir; yeni izin kuralları JSON formatında satırlara eklenir.
MODX	Şablon Değişkenleri (TV)	Kaynak alanlarını genişleten metaveri tabloları ve dinamik bağlamalar.	Veri tabanı şeması değişmez; yeni TV tanımları satır olarak eklenir.
Cotonti	Fiziksel Sütun Ekleme (Extrafields)	API aracılığıyla doğrudan hedef tablolara yeni kolon ekleme.	cot_extrafield_add ile veri tabanında doğrudan ALTER TABLE sorgusu çalıştırılır.

Drupal Varlık ve Alan Depolama Yönetimi

Drupal, veri modelleme yaklaşımında tamamen varlık odaklı (Entity-First) bir mimari benimsemektedir. Drupal 8 ile birlikte gerçekleşen büyük dönüşümle, eski sürümlerdeki bağımsız alan depolama (Field Storage) sistemi kaldırılmış ve depolama mantığı tamamen varlık depolama denetleyicisi (Entity Storage Controller) içine taşınmıştır. Bu tasarım tercihi sonucunda alanlar, sistem genelinde paylaşılan küresel nesneler olmaktan çıkıp belirli bir varlık tipine ([entity_type, field_name]) özgü hale getirilmiştir. Bu yapı, farklı varlık tipleri arasında alan adlarının çakışmasını engellerken veri tabanı düzeyinde daha temiz bir yalıtım ve modülerlik sunmaktadır.

Drupal'da veri tabanı şeması, varlık tiplerinin kendisi ve bunlara bağlı temel alan tanımları (Base Field Definitions) referans alınarak otomatik olarak oluşturulmaktadır. Geliştiriciler, içerik modellerini baseFieldDefinitions() metodu üzerinden veya özel alan tiplerinde schema() metodunu uygulayarak tanımlarlar; sistem bu tanımlardan hareketle gerekli SQL tablolarını dinamik olarak inşa eder. SQL tabanlı varlık depoları, veri tabanı sütunlarının tablolara nasıl eşleşeceğini TableMappingInterface ve SqlEntityStorageInterface üzerinden yönetir.

Ancak Drupal, veri bütünlüğünü korumak adına son derece savunmacı ve kısıtlayıcı bir tutum sergiler. Eğer bir alanda veri bulunuyorsa, Entity API bu alanın veri tabanındaki genişliğini (örneğin varchar uzunluğunu 255 karakterden 512 karaktere çıkarmayı) doğrudan engeller ve FieldStorageDefinitionUpdateForbiddenException fırlatır. Bu korumayı aşmak için alt seviye veri tabanı manipülasyonu gerekmektedir. Geliştiriciler, veri tabanındaki sütun boyutunu doğrudan SQL sürücüsüyle (changeField()) güncelledikten sonra, sistemin aktif durumunu takip eden entity.storage_schema.sql isimli anahtar-değer (Key-Value) tablosundaki ilgili metaveriyi manuel olarak güncellemek zorundadır. Bu işlemden sonra configFactory üzerinden runtime kısıtlamaları bypass edilerek aktif alan deposu konfigürasyonu senkronize edilir.

Drupal'ın şema güncellemelerine yaklaşımı da zamanla evrilmiştir. Eskiden update.php üzerinden otomatik olarak halledilen şema düzeltme mekanizmaları, modül güncellemelerinde veri tabanı durumunun öngörülebilir olmasını engellediği için kaldırılmış ve tüm şema değişiklikleri açık güncelleyici fonksiyonlara (Update Functions) dönüştürülmüştür. Bir alanın kardinalitesini (örneğin tekli değerden çoklu değere) değiştirmek için mevcut verilerin geçici olarak yedeklenmesi, şemanın EntityDefinitionUpdateManager ile sıfırlanıp güncellenmesi ve verilerin yeni şemaya göre geri yazılması gerekmektedir.

Veri akış süreçlerinde ise, harici sistemlerle entegrasyonu kolaylaştırmak için "External Entities" modülü kullanılır. Bu modül, verileri alan düzeyinde mikro servislerden tek tek çekmek yerine, veri modeli ve veri depolama katmanlarını birbirinden bağımsız hale getirerek tek bir sorguyla tüm harici nesneyi yükler ve yerel alanlara eşleyerek performans optimizasyonu sağlar.

TYPO3 Tablo Yapılandırma Katmanı ve Çoklu Site Organizasyonu

TYPO3 dünyasında veri tabanı tabloları ve bunların backend formlarındaki davranışları tamamen Tablo Konfigürasyon Dizisi (Table Configuration Array - TCA) adı verilen küresel bir PHP dizisi üzerinden kontrol edilmektedir. TCA, veri tabanı şemalarının ötesine geçerek tablolara semantik anlamlar yükler ve onların backend formlarında nasıl görselleştirileceğini, doğrulanacağını, ilişkilendirileceğini ve işleneceğini tanımlayan bir soyutlama katmanı görevi görür.

TCA'nın hiyerarşik yapısı dört ana bölüme ayrılır: ctrl bölümü, tablonun ikonunu, başlık alanını, silinme durumunu (deleted flag) ve Core Engine (DataHandler - TCE) tarafından nasıl işleneceğini belirleyen kuralları içerir. columns bölümü, her bir tablo sütununun veri tipini, doğrulamalarını ve backend arayüzündeki bileşen tipini tanımlar. TYPO3'ün modern sürümlerinde standart tiplerin yanı sıra uuid, json, language ve category gibi özel tipler de kullanılmaktadır. types bölümü form alanlarının yerleşim düzenini kontrol ederken, palettes bölümü alanların formda yatay olarak yan yana dizilmesini sağlar. Backend'deki tüm veri kayıt işlemleri, TCA kurallarını takip eden DataHandler sınıfı tarafından güvenli bir şekilde yürütülür.

Dinamik veri alanları için TYPO3'te XML tabanlı "FlexForms" yapısı da mevcuttur. Ancak FlexForms verileri tek bir veri tabanı sütununda XML dizesi olarak sakladığı için her okumada XML ayrıştırma (parsing) yükü yaratır; buna karşın TCA, PHP tabanlı yapısıyla bootstrap aşamasında bir kez derlenip önbelleğe alındığı için çok daha kararlı ve performanslı çalışmaktadır.

TYPO3'ün en ayırt edici özelliği ise çoklu site (multisite) ve çok dilli (multilingual) yönetim kapasitesidir. TYPO3, tek bir sayfa ağacı (Page Tree) yapısı içinde sınırsız sayıda bağımsız siteyi, alan adını ve dili yönetebilir. Sayfa ağacındaki kök düğümler küre ikonuyla temsil edilir ve her bir site için YAML tabanlı yapılandırma dosyaları üzerinden domain eşlemeleri, hata sayfaları ve dil ISO kodları tanımlanır. Bu mimari, kaynakların (şablonlar, kullanıcılar, eklentiler) siteler arasında kolayca paylaşılmasını veya özelleştirilmesini sağlar. Editörler, backend arayüzünü terk etmeden farklı diller ve siteler arasında geçiş yapabilir; içerikleri diller arasında kopyalayarak bağımsız düzenleme (Copy Mode) yapabilir veya kaynak dile bağlı kalarak değişiklik takibini (Connected Mode) aktif tutabilirler.

Joomla Gelişmiş Erişim Kontrolü ve Varlık Ağacı Mimarisi

Joomla, içerik erişim ve eylem yetkilendirmesini yönetmek için üç bağımsız sütundan oluşan son derece güçlü bir ACL (Access Control List) mimarisi kullanmaktadır. Bu hiyerarşik yetkilendirme modeli, kullanıcıların rollerini ve içerik üzerindeki eylemlerini tam bir yalıtımla denetler.

Tablo Adı	Barındırdığı Veri	Hiyerarşi / Modelleme Yöntemi	Rolü ve İşlevi
#__users	Kullanıcı hesapları ve kimlik doğrulama verileri.	Düz ilişkisel kayıtlar.	Kullanıcının temel profil bilgilerini ve durumunu saklar.
#__usergroups	Kullanıcı grupları hiyerarşisi.	lft ve rgt sütunları ile Nested Sets ağacı.	Grupların parent-child ilişkilerini ve miras kurallarını tanımlar.
#__user_usergroup_map	Kullanıcılar ve gruplar arasındaki ilişki.	Çoktan-çoğa (Many-to-Many) bağlantı tablosu.	Bir kullanıcının birden fazla gruba üye olabilmesini sağlar.
#__viewlevels	Görüntüleme erişim seviyeleri.	Serileştirilmiş veya JSON formatında grup kimlikleri.	Hangi içeriklerin hangi gruplara görünür olacağını belirler.
#__assets	ACL denetimine tabi tüm varlıklar.	Nested Sets hiyerarşisi (Bileşen -> Kategori -> Öğe).	İzinlerin miras alınmasını ve JSON formatında eylem kurallarının saklanmasını sağlar.

Joomla'nın erişim kontrolü, sadece hangi kullanıcının hangi sayfayı göreceğiyle sınırlı kalmayıp, arka planda devasa bir hiyerarşik izin denetim süreci yürütür. Kullanıcı sisteme giriş yaptığında, ait olduğu tüm gruplar #__user_usergroup_map tablosu üzerinden çekilir. Bu gruplar hiyerarşik olduğundan, bir alt gruba atanan kullanıcı otomatik olarak üst grupların da yetkilerini devralır.

Bir içeriğe erişim talebi geldiğinde, içeriğin bağlı olduğu asset_id üzerinden #__assets tablosundaki izin kuralları sorgulanır. Eğer o seviyede tanımlanmış açık bir kural yoksa, Nested Sets yapısı sayesinde bir üst seviyedeki kategoriye, onun da üzerinde bileşen ayarlarına ve son olarak global ayarlara kadar gidilerek izinler miras yoluyla denetlenir. Bu hiyerarşik miras denetimi, JSON biçiminde saklanan kuralların hızlıca çözülmesiyle son derece performanslı çalışır.

Esnek Veri Genişletme Modelleri: MODX Şablon Değişkenleri ve Cotonti Ekstra Alanları

Dinamik alan yönetiminde MODX ve Cotonti iki uç yaklaşımı temsil etmektedir. MODX, sayfaların (Resources) varsayılan özelliklerini genişletmek için Şablon Değişkenleri (Template Variables - TVs) kullanır. Bir TV tanımlandığında, veri tabanında alanın girdi tipi (tarih, metin, resim), varsayılan değeri ve çıktı biçimlendirmeleri ayrı bir tabloda saklanır. TVs şablonlara atanır ve yalnızca o şablonu kullanan sayfalar düzenlenirken arayüzde belirir.

MODX'i güçlü kılan, veri bağlama (Bindings) sistemidir. @INHERIT bağlaması ile bir sayfa, hiyerarşik olarak en yakın üst atasının alan değerini devralabilir. @SELECT bağlaması doğrudan MySQL sorguları çalıştırarak form girdilerini dinamik olarak doldururken, @EVAL satır içi PHP kodları yürüterek çalışma zamanında değer üretir.

Cotonti ise dinamik alanları "Extrafields" API'si aracılığıyla yönetir. Bir alan eklendiğinde cot_extrafields tablosuna kaydedilir ve hedef veri tabanı tablosuna (örneğin cot_pages) fiziksel olarak yeni bir sütun eklenir. Bu yaklaşım veri tabanı seviyesinde tam normalizasyon sunsa da, büyük veri tabanlarında ALTER TABLE işlemlerinin getirdiği kilitlenme risklerini barındırır. Çok dilli yapılarda, cot_i18n_pages tablosuna dinamik olarak ipage_ önekli sütunlar eklenerek çeviriler yönetilir.

ALTER TABLE yükünden kaçınmak için geliştirilen Cotonti xtradbrowpage eklentisi ise, ekstra alanları ana tablodan ayırarak cot_xtradbrowpage adında bire bir (1:1) ilişkili harici bir tabloda saklar; sayfa silindiğinde ilişkili satırlar da veri tabanı düzeyinde ardışık (cascade) olarak silinir.

Metot	Performans Etkisi	Şema Esnekliği	Yönetim Zorluğu	CMF Entegrasyon Stratejisi
Entity-Attribute-Value (EAV)	Çok sayıda JOIN gerektirdiğinden büyük veri setlerinde düşüktür.	Çok yüksektir; veri tabanında yapısal değişiklik gerektirmez.	Sorgu yazımı ve filtreleme mantığı karmaşıktır.	Doctrine üzerinde esnek dinamik öznitelikler oluşturmak için kullanılır.
JSON Sütunları	JSONB indeksleri kullanıldığında orta-yüksek düzeydedir.	Yüksektir; şemasız ve hiyerarşik veri saklamayı destekler.	Doğrudan indeksleme zordur; SQL standartları sürücüye bağımlıdır.	PostgreSQL tabanlı sistemlerde esnek yapılandırmalar için idealdir.
Fiziksel Kolon Ekleme	Tek tabloda saklandığı için SELECT sorgularında çok yüksektir.	Düşüktür; her yeni alanda tablo kilitlenmesi riski vardır.	Veri göçü (migration) ve şema yönetimi oldukça zordur.	Katı ve nadiren değişen alan modelleri için tercih edilmelidir.
Ayrı 1:1 Satır Tablosu	İlişkili JOIN maliyeti getirir ancak ana tabloyu hafifletir.	Orta düzeydedir; ana tabloyu şema değişikliklerinden korur.	Cascade silme ve veri senkronizasyonu yönetimi gerektirir.	Cotonti xtradbrowpage modelinde olduğu gibi modüler genişlemeler için uygundur.

Symfony Framework Üzerinde Yeni Nesil CMF Bileşenlerinin Tasarımı

Symfony framework'ünün modüler ve bileşen tabanlı yapısı, incelenen tüm bu olgun CMF sistemlerinin en iyi pratiklerini bir araya getirmek için mükemmel bir zemin sunar. Drupal'ın alan yönetimindeki 'Table Mapping' yaklaşımı, Doctrine ORM'in özel ClassMetadata ve NamingStrategy bileşenleri kullanılarak Symfony'ye uyarlanabilir. Dinamik yönlendirme gereksinimleri için, Symfony CMF projesinin sunduğu ChainRouter mimarisi örnek alınarak statik rota tanımları ile veri tabanındaki dinamik rota belgeleri bir arada işlenmelidir.

DynamicRouter, gelen istek yolunu (path info) analiz eder, veri tabanındaki rota tanımlarıyla eşleştirir ve controllers_by_class rota geliştiricisi (Route Enhancer) vasıtasıyla eşleşen varlığın sınıf tipine göre uygun kontrolcüyü belirler. Bu sayede, içerik yöneticilerinin yeni sayfalar oluştururken statik rotalara bağımlı kalması engellenir.

CMF İhtiyacı	İlgili Platform Örneği	Symfony Çözüm Bileşeni	Mimari Uygulama Şekli
Dinamik Rota Eşleme	Drupal & Symfony CMF	ChainRouter ve DynamicRouter [cite: 31]	İstek adresini veri tabanındaki dinamik rotalarla eşleştirip kontrolcüye yönlendirme.
Semantik Form Tanımları	TYPO3 TCA	Symfony Form Types & YAML Metadata	PHP veya YAML dosyalarında form alanlarını, kurallarını ve önyüz widget'larını tanımlama.
Hiyerarşik Yetkilendirme	Joomla ACL	Doctrine Nested Tree & Symfony Security	Varlık ağacını (#__assets benzeri) Nested Sets ile veri tabanında tutup Voter'lar ile denetleme.
Dinamik Veri Bağlama	MODX TV Bindings	Twig Extensions & Doctrine Event Listeners	@INHERIT veya @SELECT gibi özel ifadeleri runtime sırasında çözerek alanları doldurma.
Etkileşimli Arayüz Güncelleme	Modern CMS Deneyimi	Symfony UX Live Components & Turbo	Sunucu taraflı re-render ve LiveProp dehidrasyon/hidrasyon döngüsü.

Arayüz seviyesindeki dinamik form yönetimi, Symfony'nin Form Olayları (Form Events) ile çözülür. DynamicFormBuilder sarmalayıcısı kullanılarak koşullu form yapıları kurulabilir. Örneğin, form yüklenirken POST_SET_DATA olayı tetiklenerek varlığın yeni mi yoksa düzenleme aşamasında mı olduğu kontrol edilir ve sadece yeni kayıtlarda gösterilmesi gereken alanlar forma eklenir. Kullanıcı formda bir seçim yaptığında (örneğin TYPO3'teki gibi dinamik dil veya kategori seçimi), PRE_SUBMIT veya POST_SUBMIT olayları üzerinden form yapısı çalışma zamanında güncellenerek ilgili alt alanlar dinamik olarak yüklenir.

Kullanıcı deneyimini modern bir SPA (Single Page Application) seviyesine taşımak için ise Symfony UX Live Components ve Symfony UX Turbo bileşenleri devreye girer. Form bileşenleri sunucu tarafında #[AsLiveComponent] olarak işaretlenir ve form özellikleri #[LiveProp(writable: true)] ile tanımlanır. Bu yapı, form verilerinin sunucu ve istemci arasında otomatik olarak serileştirilmesini (dehydration/hydration) ve sunucu tarafındaki form işleme mantığının hiçbir ek API uç noktası (endpoint) yazılmadan önyüze dinamik olarak yansıtılmasını sağlar. Böylece, karmaşık JavaScript kütüphanelerine ihtiyaç duyulmadan, sunucu tarafında doğrulanmış ve dinamik olarak güncellenmiş güvenli formlar oluşturulur.

Sonuç ve Stratejik Mimari Tavsiyeler

Symfony tabanlı yeni nesil bir CMF tasarlanırken, mevcut sistemlerin tarihsel süreçte yaşadığı tıkanıklıklardan kaçınmak en önemli önceliktir. Drupal'ın alan yönetimindeki aşırı JOIN maliyetlerini engellemek adına, ilişkisel veri tabanlarının yerel JSONB yetenekleri ile normalize edilmiş fiziksel tablolar hibrit bir yapıda kullanılmalıdır. TYPO3'ün TCA yapısı örnek alınarak, form yerleşimleri ve veri doğrulama kuralları PHP sınıflarından veya YAML dosyalarından dinamik olarak okunmalı; bu sayede backend arayüzünün şemadan bağımsız olarak inşa edilmesi sağlanmalıdır.

Yetkilendirme katmanında, Joomla'nın Nested Sets tabanlı #__assets yapısı taklit edilerek, veritabanı seviyesinde hızlı sorgulanan bir hiyerarşik izin ağacı kurulmalıdır. Bu ağaç, her güvenlik denetiminde veri tabanına yük oluşturmaması adına Redis gibi yüksek performanslı önbellek mekanizmalarıyla sarmalanmalıdır.

Son olarak, MODX'in dinamik veri bağlama felsefesi ile Symfony Form bileşeninin olay tabanlı esnekliği birleştirilerek, veri tabanı şemasını değiştirmeden çalışabilen dinamik alanlar tasarlanmalıdır. Arayüz etkileşimleri ise Symfony UX Live Components mimarisine emanet edilerek, CMF projesinin hem geliştirme hızını hem de çalışma zamanı performansını en üst düzeye çıkaracak modern bir altyapı inşa edilmelidir.

Faydalanılan kaynaklar aşağıda:

The Symfony Content Management Framework is getting ready

Switch from Field-based storage to Entity-based storage [#1497374] | Drupal.org

Write update functions for entity schema updates, automation removed | Drupal.org

[meta] Make the entity storage system handle changes in the entity and field schema definitions [#1498720] | Drupal.org

Drupal Tip: How to change field length with existing data - UndPaul

Introduction — TCA Reference main documentation

New TCA Types in TYPO3 v12 - B13

TYPO3 Content Elements: Flexform vs. TCA - T3Planet

Joomla Database Table: assets

Users and User Groups in Joomla - Peter Martin

MODX Template Variables - Bob's Guides