Contentful’dan WordPress’e: Headless Faturası Anlamını Yitirdiğinde

🇬🇧 English: Read this article in English →

Headless içerik yönetimini ana akım hâline getiren Contentful oldu. Fikri aldı — HTML’i CMS’ten dışarı göndermeyi bırak, bana yapılandırılmış JSON ver, web sitem, uygulamam ve diğer her ekran aynı veriyi çeksin — ve bunu geliştiricilerin cidden sevdiği, cilalı bir bulut hizmeti olarak sundu. Fikir doğru. Mimari çok-kanal için gerçekten daha iyi. Bunun tersini iddia edecek değilim.

Ama moda olmayan bir şeyi söylemem gerekiyor, çünkü uzun zamandır buna inanıyorum: çoğu kuruluş headless CMS’i tek bir kanalı besleyerek çalıştırıyor — bir web sitesi. Mimarinin tüm bedelini ödüyorlar — geliştiriciye bağımlılık, kod-olarak yönetilen şema, bir alan bile ekleyemeyip ticket açmak zorunda kalan bir içerik ekibi, API-çağrısı-başı ve kullanıcı-başı ölçeklenen bir fatura — ve çok-kanallı faydanın neredeyse hiçbirini almıyorlar, çünkü çok-kanal diye bir şey yok. Bir web sitesi var.

Ekipler bunu fark ettiğinde WordPress’e bakmaya başlıyor. Bu geçişi ben nasıl düşünüyorum, anlatayım — önce sade, sona doğru teknik.

Ekipler neden Contentful’ı bırakıp WordPress’e geçiyor

• Fatura mı, fayda mı. Contentful’ın fiyatı kullanımla, kayıt sayısıyla ve koltuk sayısıyla ölçeklenir. Çok sayıda kanal besliyorsan buna değer. Tek bir web sitesi besliyorsan, içeriği kendi kapının önüne taşımak için bir dağıtım sistemi satın alıyorsun.
• Editoryal bağımlılık. Contentful’da içerik modeli geliştiricinin arazisidir ve düzenleme deneyimi bilinçli olarak yapısaldır. Pazarlama, WordPress’te kendi başına yapıvereceği değişiklikler için mühendisliği bekler.
• Tüm yığının maliyeti. Headless yalnızca CMS faturası değildir. Özel arayüz, onun barındırması, CI/CD’si ve ikisini de ayakta tutacak geliştiricilerdir. Bunu WordPress’e katlayıp indirmek, koca bir maliyet ve koordinasyon katmanını ortadan kaldırır.
• Sahiplik ve çıkış. Contentful tek ve iyi finanse edilmiş bir satıcıdır. WordPress satın alınamaz ve kimse sahibi değildir. On yıllık bir içerik sitesi için bu az şey değil.

Headless’i var olmadan önce istedim — tam da bu yüzden bunu söylüyorum

Headless’e dışarıdan taş atan biri değilim. Onu daha adı yokken istedim. 1996’da bir gazete ekiyle dağıtılan CD-ROM üzerinde bir üniversite tercih asistanı yayınladım ve bir kontenjan değiştiğinde, disk çoktan yüz bin evde eski sayı içine donmuş hâlde duruyordu. İçeriğin tek bir yerde durmasını, ihtiyaç duyan hangi ekransa ona ulaştırılmasını ve dağıtım katmanına dokunmadan güncellenebilmesini istiyordum. Contentful’ı, Contentful var olmadan otuz yıl önce istiyordum ve kuramadım çünkü altyapı henüz yoktu.

Yani sana headless’e bağlanmadan önce kanallarını say derken, bu şüphecilik değil — tam tersi. Bu mimarinin ihtiyacın olduğunda ne kadar iyi olduğunu tam olarak biliyorum. Bir şeyi istemekle ona ihtiyaç duymak farklı şeylerdir. Dijital fiyat etiketlerini, mağaza içi ekranları, bir mobil uygulamayı, kioskları ve web’i tek bir kaynaktan besliyorsan, Contentful’da kal; tam da yapması gereken şeyi yapıyor. Dürüst cevap “bir web sitesi” ise, o gösterişli mimari, sahip olmadığın bir sorunu çözen bir makinedir ve WordPress’e geçmek bir gerileme değil — doğru ölçeğe çekmektir.

Bir Contentful geçişini nasıl planlarım

Contentful temiz, yapılandırılmış ve cidden iyi bir export aracına sahip; bu da onu uygulaması daha keyifli geçişlerden biri yapıyor — zorluk veriyi çekiştirmekte değil, modelleme kararlarında.

1. İçerik modelini envanterle — her content type, field, reference, Rich Text alanları, asset’ler ve locale’ler.
2. Buda — yerini artık hak etmeyen field’ları ve content type’ları temizle.
3. WordPress’e eşle — content type’ları custom post type’lara, field’ları ACF’e, references’ı ilişkilere, Rich Text’i Gutenberg’e, asset’leri medya kütüphanesine, locale’leri seçtiğin çok-dilli yaklaşıma.
4. Boş hedefi kur ve editörlerle doğrula.
5. Export et, dönüştür, staging’de dry-run yap, tekrarla.
6. Cutover’dan önce yönlendirmeler (redirects).
7. Geçir, sonra izle — frontend’in yeniden kurulması dahil.

Teknik Kısım: Contentful Geçişi Asıl Nerede Kırılıyor

Sonucu belirleyen ayrıntılar.

Export temiz — kullan

Contentful’ın contentful space export CLI’ı, her content type, entry, asset referansı ve locale’i içeren tek bir JSON dosyası üretir ve asset’leri de yanında indirebilir. İçeriği birkaç farklı API’den derlemek zorunda olduğun sistemlere kıyasla bu gerçek bir hediye. Canlı Content Delivery API çağrılarından değil, o dondurulmuş export’tan çalış ki dönüştürmen tekrarlanabilir ve gerektiğinde güvenle patlayabilir olsun. Content Management API (taslaklar dahil tüm veri) ile Content Delivery API (yalnızca yayınlananlar) arasındaki farkı da not et — export’tan önce hangi durumun senin gerçek kaynağın olduğuna karar ver.

Rich Text JSON’dır ve asıl iş budur

Contentful zengin metni HTML olarak saklamaz. Onu Rich Text olarak saklar — kavramsal olarak Sanity’nin Portable Text’ine benzeyen ama farklı bir şemaya sahip, yapılandırılmış bir JSON dokümanı (nodeType, content, marks, data). WordPress ise zengin metni Gutenberg blok markup’ı olarak saklar. Bu boşluğu köprülemek geçişin özüdür. Elinde iki dürüst seçenek var:

• Rich Text’i HTML’e serialize et — Contentful’ın rich-text-html-renderer‘ıyla bir bloğa bırak — hızlı, ama blok-native düzenlemeyi kaybedersin.
• Node-node Gutenberg bloklarına eşle — paragraflar, başlıklar, listeler, alıntılar ve embed’ler core/* karşılıklarına — daha fazla iş, ama editörler içeriğe dokunmaya devam edecekse doğru olan bu.

Ne yaparsan yap canını yakacak kısım, Rich Text içindeki embedded entry’ler ve asset’ler: embedded-entry-block, embedded-asset-block, embedded-entry-inline ve entry-hyperlink node’ları başka Contentful entry ve asset’lerini işaret eder. Her biri, referansı taşınmış WordPress karşılığına çözen bir handler ister. Serializer’ı yazmadan önce her embedded node tipini envanterle, yoksa o embed’ler ya buhar olur ya da yayınlanmış yazılarının içine ham JSON olarak dökülür.

References ve iki-geçiş sorunu

Contentful entry’leri birbirine link field’lar üzerinden, entry ID ile referans verir. O ID’ler WordPress’te anlamsızdır ve bunları tek geçişte çözemezsin çünkü kaynağı import ederken hedef henüz var olmayabilir. İki geçiş: önce her entry’yi import et ve Contentful entry ID’sini yeni WordPress post ID’sine eşleyen bir harita kur (Contentful ID’sini post meta’da sakla); sonra her linki — reference field’lar ve Rich Text içi embed’ler — o haritayı kullanarak ACF ilişki field’larına, post bağlantılarına veya taksonomiye yeniden yaz. Anlamlı bir sıra taşıyan reference dizilerine dikkat et ve o sırayı koru.

Locale’ler

Contentful’da birinci sınıf yerelleştirme vardır — locale’ler yerleşiktir ve yerelleştirilmiş her field, export içinde her locale için ayrı değer taşır. Dönüştürmeden önce WordPress hedefini seç — multisite, Polylang veya WPML — çünkü Contentful’ın locale-başı field değerlerini seçtiğin yapıya bölmek tamamen o seçime bağlıdır. Bazı locale’lerde yerelleştirilmiş ama diğerlerinde olmayan entry’leri de ele al ki öksüz çeviriler yaratmayasın. Çok-dilli mimari önce kararlaştırılır; bu bir çeviri sorunu değil, bir mimari sorundur.

Asset’ler

Contentful asset’leri, kendi CDN’inden sunulan, metadata’lı dosyalardır. Her asset’i export’tan (veya CDN’den) indir, WordPress medya kütüphanesine yeniden import et ve her referansı yeniden yaz — hem asset-link field’ları hem de Rich Text içindeki embedded-asset-block node’ları. İçerik içindeki asset referansları, sessizce Contentful CDN’ini işaret etmeye devam eden ve ona ödeme yapmayı bıraktığın gün patlayan referanslardır.

Frontend contract değişir — bunun için bütçe ayır

En büyük gizli maliyet budur. Bugün bir Next.js, Nuxt, Astro ya da başka bir frontend Contentful’ı Content Delivery API veya GraphQL üzerinden tüketiyorsa, o frontend geçişten dokunulmadan çıkamaz. WordPress REST API’ye ya da WPGraphQL’e geçmesi gerekir ve yanıt şekilleri tamamen farklıdır — Contentful’ın sys/fields/includes yapısı, WordPress endpoint’lerine hiç benzemez. Ya frontend’in veri katmanını yeniden kur, ya da özel frontend’i emekliye ayırıp bir WordPress teması kullan. Bunu ilk toplantıda yüksek sesle söyle; bütçeyi baştan şekillendiren sürpriz budur.

Environment’lar

Contentful environment’larının (içerik için git benzeri branch’lemesi) WordPress’te bir karşılığı yoktur. Production/master environment’ından geç ve environment tabanlı herhangi bir iş akışını, gerekirse bir editoryal eklentiyle birlikte WordPress’in post durumlarına (post statuses) katla.

Dürüst kapanışım

Contentful’dan WordPress’e geçmek, modern mimariden bir geri çekilme değildir. Dürüstçe verilmiş bir karardır: çok-kanallı bir sistemin üstünde tek-kanallı bir web sitesi çalıştırıyordun ve kullanmadığın bir yeteneğin parasını ödüyordun. WordPress bunu doğru ölçeğe çeker: editoryal kontrolü editörlere geri verir, fazladan frontend katmanını katlayıp indirir ve içeriği tamamen senin sahip olduğun bir platforma yerleştirir.

Uygulaması cidden keyiflidir — export temizdir ve model iyi yapılandırılmıştır. Muhakeme kısmı ise Rich Text’in ele alınmasında, iki-geçişli references’ta, locale mimarisinde ve frontend’in yeniden kurulmasındadır. Embedded node’ları elle hallet, references’ı iki geçişte çöz, çok-dilli modele önce karar ver, asset URL’lerini yeniden yaz ve yönlendirmelerini cutover’dan önce kur.

Bütün bunları, headless’i var olmadan otuz yıl boyunca istemiş biri olarak söylüyorum. Fikre karşı hiçbir kin beslemeden sana bunu söyleyebilmemin sebebi tam da bu: kanallarını say. Cevap birse, içerik sıradan insanların ticket açmadan yaşatabileceği bir yerde durmalı — ve işin tamamı da bu zaten.

Son Bir Şey: Peki Contentful’ün Yaptığını WordPress’le Yapamaz mısın?

Biri geçmeye karar verir vermez sorduğu ilk soru şu oluyor: Contentful’dan çıkarsak, asıl sevdiğimiz decoupled mimariden de vazgeçmek zorunda mıyız? Hayır. Değilsin. Ve WordPress’i hâlâ “sadece bir blog” sanan herkesin cidden şaşırdığı yer tam burası.

WordPress bu işe dün girmedi. REST API 2016 sonundan beri core’un içinde — neredeyse on yıldır sahada pişiyor. WPGraphQL da neredeyse o kadar eski; artık Automattic’in arkasında durduğu, WordPress’in kanonikleşme yolundaki GraphQL katmanı. Yani Contentful’a para verme sebebin — yapılandırılmış içeriğin, isteyen her arayüze JSON olarak dağıtılması — WordPress bunu yıllardır, hem de göz önünde yapıyor. Headless tartışmasını kaybetmedi; yuttu, içine aldı.

Demek ki Contentful’dan çıkışın tek değil, iki dürüst yolu var:

• Klasik WordPress — bu yazının geri kalanı. Editörlere temalarını geri ver, ticket açmadan yayınlasınlar.
• Headless WordPress — sevdiğin decoupled mimariyi koru; sadece sayaçlı SaaS motorunu sahibi olduğun bir motorla değiştir. Content type’lar ACF ile modellenmiş custom post types’a, Rich Text bloklara dönüşür ve frontend contract Contentful’ın CDA/GraphQL’inden WPGraphQL’e (ya da REST API’ye) taşınır — tepesinde zaten elindeki Next.js / Nuxt / Astro arayüzü, eskisi gibi oturur.

İçeriğini custom post types ve ACF ile modelle, WPGraphQL ile sorgula; arayüzün altındaki CMS’in değiştiğini pek fark etmez bile. Headless’in her avantajı sende kalır. Asıl seni dik oturtacak kısım da şu: üstüne, saf bir headless SaaS’ın sana asla vermediği şeyleri kazanırsın.

• Gerçek bir ticaret motoru. WooCommerce. Headless-only bir CMS’e olgun bir mağazayı cıvatalamayı dene; hem özel kodun hem faturanın nasıl kabardığını izle.
• İnsanlar için editoryal güç — yalnızca geliştiriciler için değil: block editor, media library, revizyonlar, roller ve SEO’dan forma, üyelikten fazlasına uzanan bir eklenti ekosistemi; hiçbirini sıfırdan yazmıyorsun.
• Kullanıcı başı ücret yok, kullanım sayacı yok. Yüz editör ekle ya da bir milyon API çağrısı; fatura kıpırdamaz.
• Sahiplik. Bu serinin bütün argümanı — WordPress’i kimse ayağının altından satın alamaz.

Contentful yaptığı işi cidden iyi yapıyor — temiz bir içerik modeli, güçlü ve birinci sınıf yerelleştirme, cilalı bir bulut. En başta söyledim, arkasındayım. Ama “yapılandırılmış bir API üzerinden decoupled bir arayüz istiyoruz” cümlesi WordPress’i geride bırakmak için bir sebep değil — WordPress’i headless çalıştırmak için bir sebep. Sevdiğin mimariyi koruyorsun; sadece kapalı, sayaçlı motoru, arkasında bir ekosistem olan açık ve sahiplenilebilir bir motorla değiştiriyorsun.

İşte sürpriz bu. Headless ile WordPress arasında seçim yapmana gerek yoktu. İkisi birden senin olabilir.