Umbraco’dan WordPress’e: İki Açık Kaynak CMS, Tek Dikkatli Hamle

🇬🇧 English: Read this article in English →

Umbraco, bu serideki tek “iki açık kaynak sistem arasında” yapılan geçiş — ve bu, konuşmanın tonunu baştan değiştiriyor. Bu, pahalı bir tescilli satıcının fiyatlandırmasından kaçış hikâyesi değil. Umbraco ücretsiz, açık ve onu kullanan .NET geliştiricileri tarafından gerçekten seviliyor. O yüzden bir ekip Umbraco’dan WordPress’e geçmek istediğinde, gerekçeler daha spesifik oluyor — ve bunlar hakkında dürüst olmakta fayda var, çünkü bu; pahalı bir DXP’yi terk etmek gibi tartışmasız bir kazanç değil.

Önce meseleyi açık açık koyayım, teknik ayrıntıya sona doğru gireceğim.

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

• .NET barındırma ve yetenek gerçeği. Umbraco açık kaynak, ama bir .NET uygulaması — Windows ya da .NET barındırmaya ve .NET geliştiricilerine ihtiyaç duyuyor. Ekibi ve altyapısı PHP/JavaScript dünyasına doğru kayan bir kuruluş için bu, zamanla büyüyen bir sürtünmedir. WordPress ise çok daha yaygın olan barındırma ve işe alım pazarına oturuyor.
• Editoryal özerklik. Umbraco’da document types geliştiriciler tarafından tanımlanır. Bir alan ya da yeni bir içerik bölümü eklemek bir geliştirme işidir. ACF ve blok editörü ile WordPress ise bu kontrolün çoğunu doğrudan editörlere veriyor.
• Ekosistem derinliği. Umbraco’nun sağlıklı bir paket ekosistemi var, ama WordPress’inkinin yanında bir hardal tanesi kadar. WooCommerce, SEO eklentileri, form araçları, üyelik sistemleri, o devasa eklenti ekonomisi — bu yerçekimi bir sürü içerik sitesini WordPress’e doğru çekiyor.
• Zaman içinde değişim maliyeti. Sürekli yeni bölümler ve kampanyalar isteyen bir pazarlama sitesi için, Umbraco’da her değişikliğin geliştirici maliyeti; WordPress’in özerk modeli karşısında zamanla katlanarak birikir.

Dürüst kısım: burada belirleyici faktör açık kaynak değil

Sürekli şunu savunuyorum: açık kaynağın gerçek değeri ücretsiz olması değil — bir çıkış kapısı sunmasıdır. Bir platform açık olduğunda ve bir kavga patlak verdiğinde ya da bir satıcının öncelikleri değiştiğinde, kullanıcıların hâlâ seçeneği vardır, çünkü kod onlarındır. Tam da bu argümanı WordPress dünyasındaki ACF ile WP Engine çatışması için yapmıştım: Secure Custom Fields fork’u dağınık ve politikti, ama mümkündü, çünkü kod açıktı; ve herkes çalışmaya devam etti. Sorun riskin var olması değildi. Sorun çıkışın olmamasıdır — ve açık kaynak, o çıkıştır.

Ama işin özü şu: Umbraco’nun da o çıkışı var. Yani Umbraco’dan WordPress’e geçmek bir kilitlenmeden kaçış değildir — ikisi de açık, ikisi de gitmene izin veriyor. Bu geçiş bir hayatta kalma kararı değil, bir uyum kararıdır. WordPress ekibine, barındırmana, ekosistemine ve editörlerine daha iyi oturduğu için geçiyorsun — Umbraco seni tuzağa düşürdüğü için değil. Bu konuda net olmak seni dürüst tutar; ve müşteriye aslında sunduğun şey “daha iyi bir uyum”ken ona bir “kurtarma operasyonu” vaat etmekten alıkoyar.

Bir Umbraco geçişini nasıl planlıyorum

1. Modeli envanterle — document types, onların property’leri ve data type’ları, content tree, template’ler, Block List/Block Grid içeriği, members ve culture variants.
2. Buda — artık kullanılmayan document types ve property’leri temizle.
3. WordPress’e eşle — document types’ı custom post type’lara, property’leri ACF’ye, content tree’yi sayfa hiyerarşisine ya da düzleştirilmiş koleksiyonlara, blokları Gutenberg bloklarına veya ACF flexible content’e, members’ı WordPress kullanıcılarına.
4. Boş hedefi kur ve editörlerle doğrula.
5. Bir snapshot üzerinde dönüştür, staging’de dry-run yap, tekrarla.
6. Cutover’dan önce yönlendirmeler (redirects).
7. Cutover yap, sonra gözünü ayırma.

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

Sonucu belirleyen ayrıntılar.

Document types ve content tree

Umbraco içeriği bir node ağacıdır — her node bir document type ile biçimlenir (yani içerik tipi, property’leri data type’lar ve property editor’ler tarafından sürülür). Document types custom post type’lara, property’ler de ACF alanlarına eşlenir. Content tree, hiyerarşinin anlamlı olduğu yerde WordPress sayfa hiyerarşisine eşlenir; gerçekte düz bir koleksiyon olduğu yerde ise post-artı-taxonomy’ye düzleştirilmelidir. Umbraco’nun document-type composition’ları (birden fazla tipe karıştırılan ortak property grupları) envanter sırasında çözülmeli ki her node’un tam property setini yakalayabilesin.

Asıl zor kısım: Block List ve Block Grid

Modern Umbraco, Block List ve Block Grid editörlerine yaslanıyor — editör blok tiplerini seçip diziyor, tıpkı bir page builder gibi. Bu, Umbraco’nun component/dynamic zone karşılığı; ve bu tür her sistem gibi WordPress’te temiz bir 1:1 karşılığı yok. Her blok tipi için tek tek karar ver: bir Gutenberg bloğu/pattern’i mı olacak, yoksa bir ACF flexible-content layout’u mu; ve her blok tipini elle işle. Block Grid layout’ları sütun/satır yapısı taşır — bunu koruyacağına mı yoksa düzleştireceğine mi karar vermen gerekir. Saatlerin saklandığı yer burasıdır — transform’u yazmadan önce her blok tipini ve her grid layout’unu envanterle.

Zengin metin: TinyMCE mi, blok editörü mü

Umbraco’nun rich-text property’si geleneksel olarak TinyMCE tabanlı HTML olmuştur; yeni sürümler ise blok tabanlı bir editör sunuyor. HTML tabanlı zengin metin WordPress’e nispeten temiz düşer, ama gömülü macro’lara, yerel bağlantılara (/{localLink:umb://...}) ve satır içi seçilen medyaya dikkat et — bu Umbraco’ya özgü token’lar render olmaz ve transform sırasında gerçek URL’lere çözülmeleri gerekir. Tahmin yapmadan önce her property’nin hangi rich-text türünü kullandığını kontrol et.

Çıkarım (extraction): Content Delivery API, uSync ya da veritabanı

Umbraco’nun temiz bir “WordPress’e dışa aktar” yolu yok. İyi rotalar şunlar: Content Delivery API (Umbraco 12+’daki headless API, içeriği JSON olarak döner), uSync (içeriği ve şemayı diske serialize eder), Management API ya da SQL Server/SQLite veritabanına doğrudan bir okuma. Hangisini seçersen seç, bir snapshot dondur ve transform’unu o dondurulmuş kopya üzerinde, çıktı sıkıcılaşana kadar tekrar tekrar çalıştır. Asla canlı production üzerinde dönüştürme yapma.

Culture variants

Umbraco dilleri bir node üzerinde culture variants olarak ele alır — tek node, birden çok dil değeri. Taşımadan önce WordPress hedefini seç — multisite, Polylang ya da WPML — ve bazı culture’larda yayınlanmış ama bazılarında yayınlanmamış node’ları öyle bir işle ki öksüz çeviriler yaratmayasın. Her zamanki gibi: çok dilli mimari önce kararlaştırılır. Bu bir çeviri problemi değil, bir mimari problemidir; ve bu dersi sayısını hatırlayamadığım kadar çok dilli projede öğrendim — Almanca uzar, Türkçe daha da uzar, Arapça ters yöne akar. Hedefin bir dil varsayıyorsa, daha başlamadan kaybettin.

Medya ve dosya referansları

Umbraco’nun medya bölümü dosyaları, kendi property’leri olan medya node’ları olarak saklar. Bunları indir, WordPress medya kütüphanesine yeniden içeri aktar ve her referansı yeniden yaz — hem media-picker property’lerinde hem de, en kritiği, medyanın URL veya umb://media referansıyla gömüldüğü rich-text içeriğinin içinde. İçerik içindeki referanslar, sen Umbraco örneğini kapattıktan sonra sessizce kırılanlardır.

Members ve template’ler

Umbraco members (arka ofis kullanıcılarından farklı olarak, ön yüz kullanıcı hesapları) WordPress kullanıcılarına eşlenir, ama parola hash’leri taşınabilir değildir — sıfırlama için plan yap. Ve Umbraco template’leri Razor view’lardır: sunum katmanıdırlar, taşınmazlar; ön yüzün bir WordPress teması ya da bloklar olarak yeniden inşa edilmesi gerekir. Bugün headless bir ön yüz Content Delivery API’sini tüketiyorsa, farklı bir yanıt şekliyle WordPress REST API’sine ya da WPGraphQL’e geçmesi gerekecek — o veri katmanı yeniden inşasını bütçene koy.

Dürüst kapanışım

Umbraco iyi bir yazılım ve onu terk etmek bir kurtarma görevi değil. Hem o hem WordPress sana asıl önemli olan tek şeyi veriyor — bir çıkış — bu yüzden bu geçiş hayatta kalma değil, uyum meselesidir. WordPress ekibine, barındırmana ve editörlerine daha iyi oturduğu için geçiyorsun; ve bu, tek başına gayet iyi bir gerekçe.

Yine de modelleme işini yap, özellikle Block List ve Block Grid eşlemesini, çünkü bir Umbraco geçişi asıl orada sessizce raydan çıkıyor. Her blok tipini elle işle, zengin metindeki local-link ve medya token’larını çöz, çok dilli mimariyi önce kararlaştır ve cutover’dan önce yönlendirmelerini kur. Bunu yaparsan, içerik ekibinin gerçekte çalıştığı biçime oturan bir yere iner — ki bu da, ikisi de gitmene izin veren iki sistem arasında geçiş yapmanın tek dürüst gerekçesidir.

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

Bir .NET ekibinin bu hamleyi düşünür düşünmez sorduğu soru şu: Umbraco’dan çıkarsak, Content Delivery API ya da Heartcore ile kurduğumuz decoupled düzeni kaybeder miyiz? Hayır. Kaybetmezsin. Ve WordPress’i hâlâ “sadece bir blog” sanan herkesin cidden şaşırdığı yer tam burası — çünkü biz WP Clan olarak burada WordPress’in hakkını yemeyeceğiz.

WordPress headless’a 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 Umbraco’da sevdiğin o decoupled model — içeriğin, isteyen her arayüze JSON olarak sunulması — WordPress’te de var; hem de göz önünde ve yıllardır. WPGraphQL üzerinden headless WordPress, Umbraco’nun Content Delivery API’si ve Heartcore’unun birebir paraleli. Aynı mimari, farklı backend.

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

• Klasik WordPress — bu yazının geri kalanı. Editörlere bir tema ve bir blok editörü ver, geliştirici ticket’ı açmadan yayınlasınlar. Umbraco da bunu yapabilir, ama WordPress editoryal özerkliğe daha çok yaslanıyor.
• Headless WordPress — kurduğun decoupled mimariyi koru. Document types custom post type’lara, Block List/Block Grid ise ACF flexible content’e ya da native bloklara dönüşür; sorgu katmanında Content Delivery API’nin yerini WPGraphQL (ya da REST API) alır. Arayüzün, altındaki CMS’in değiştiğini pek fark etmez bile.

İkisi de açık kaynak, ikisi de sana bir çıkış veriyor — bunu en başta söyledim, arkasındayım. Ama WordPress aynı sofraya daha fazlasını getiriyor:

• Gerçek bir ticaret motoru. WooCommerce; sonradan cıvatalanmış bir eklenti değil.
• Çok daha büyük bir eklenti ekosistemi — SEO, formlar, üyelikler; hiçbirini sıfırdan yazmıyorsun.
• Devasa, .NET dışı bir barındırma ve yetenek havuzu. Windows ya da .NET zorunluluğu yok; ekibinin zaten doğru kaydığı, çok daha yaygın PHP/JavaScript pazarı.
• İnsanlar için editoryal güç — yalnızca geliştiriciler için değil.
• Kullanıcı başı ücret yok, kullanım sayacı yok ve sahiplik — WordPress’i kimse ayağının altından satın alamaz.

Umbraco iyi bir CMS ve kendi çıkışı da var. Bu bir kurtarma operasyonu değil. Ama “Content Delivery API üzerinden headless çalışıyoruz” cümlesi WordPress’i denklemin dışında bırakmak için bir sebep değil — WordPress’i headless çalıştırmak, klasik seçeneği de cebinde tutmak ve yol boyunca çok daha büyük bir alet çantası edinmek için bir sebep. İşte sürpriz bu: bu bir uyum yükseltmesi ve headless ile WordPress arasında seçim yapman hiç gerekmedi.