Optimizely’den WordPress’e: Tüm Tezimi Kanıtlayan Bir Geçiş

🇬🇧 English: Read this article in English →

Bu seri boyunca aynı şeyi farklı kılıklarda söyleyip durdum: platformlar genellikle teknik başarısızlıktan ölmez, sahiplikten ölür. Birileri şirketi satın alır ve senin içerik stratejin, hiç danışılmadığın bir entegrasyon planının bir satır kalemine dönüşür. Bunu 2000’lerin ciddi her ECM platformunun başına gelirken izledim — Vignette, Interwoven, FatWire, Stellent — hepsi satın alındı, yutuldu, yeniden adlandırıldı, raflara kaldırıldı.

Optimizely bu tezin yaşayan en temiz kanıtı ve geçişe başlamadan önce anlamaya değer, çünkü sana üzerinde durduğun zeminin ne olduğunu anlatıyor.

İnsanların “Optimizely CMS” derken çoğunlukla kastettiği CMS aslında Episerver. Episerver yıllarca saygın bir .NET DXP’ydi. Sonra Episerver, experimentation şirketi Optimizely’i satın aldı — ve onun adını aldı. Çalıştırdığın CMS, kendisine ortak olan şirketin adıyla yeniden vaftiz edildi. Bu, yazılıma yönelik bir eleştiri değil; yazılım gayet yetenekli. Bu, tam da uyarıp durduğum kalıbın canlı bir örneği: faturanda yazan şey, sana sormadan adını da sahibini de önceliklerini de değiştirebilir. Bir müşteri için platform seçerken sorduğum soru şudur: bu şirketi kim satın alabilir ve o ertesi gün benim içeriğime ne olur? Optimizely CMS, tam da bunun çoktan başına geldiği bir platform.

O halde geçişi masaya yatırayım. Önce sade sade, sonra sona doğru teknik kısım.

Ekipler Optimizely CMS’i neden bırakıp WordPress’e geçiyor

• Lisans ve toplam maliyet. Optimizely CMS, lisanslı bir .NET DXP — lisans ücretleri, .NET geliştiricileri ve daha ağır barındırma. Bir içerik sitesi için WordPress bu maliyeti dramatik biçimde çökertir.
• Maliyet-kullanım uçurumu. Her DXP gibi Optimizely de personalization, experimentation ve orkestrasyon için fiyatlanır. Birçok kuruluş bunun ancak bir dilimini kullanır ve tamamının parasını öder. Konuşmayı başlatan şey genellikle işte o uçurumdur.
• Uzmana bağımlılık. Content type’lar, bloklar ve template’ler geliştirici işidir. Editörler, ACF ve blok editörüyle WordPress’te yapabildikleri gibi kendi başlarına iş göremez.
• Sahiplik ve yön. Yukarıda anlattığım gibi — bir satın almadan ve yeniden adlandırmadan zaten geçmiş bir platform, geleceğini senin kontrol etmediğin bir platformdur. WordPress satın alınamaz.

Personalization denetimi — kaybını korkmaya başlamadan önce yap

Optimizely’in asıl kattığı değer experimentation ve personalization. Geçmeden önce, her DXP için önerdiğim dürüst denetimi yap: gerçekte kaç experiment çalışıyor, kaç personalization kuralı gerçekten canlı, kaç audience segment gerçekten var? Müşterilerin gelişmiş personalization motorları satın alıp sonra üç segmentten fazlasını asla kurmadığını izledim — hiç kullanmadıkları bir kabiliyetin parasını ödüyorlar, üstüne onu işletecek uzmanlara bir daha ödüyorlar. Denetim neredeyse boş dönüyorsa, geçişte kaybetmekten korktuğun şey aslında çoktan terk ettiğin bir şey. Bu her şeyi yeniden çerçeveler: bir kabiliyeti bırakmıyorsun, atıl duran bir şeye para ödemeyi bırakıyorsun.

Peki ya experimentation gerçekten yük taşıyorsa — aktif testlerle cidden gelir üretiyorsa — o zaman ya Optimizely’in experimentation ürününü WordPress’in üstünde ayrı bir katman olarak tut (hayata bağımsız bir A/B aracı olarak başladı ve hâlâ öyle çalışıyor) ya da WordPress’e özel bir experimentation aracı benimse. Bunu içerik geçişine dipnot olarak değil, kendi başına bir proje olarak kapsamla.

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

1. Modeli envanterle — page type’lar, block type’lar, content tree, property’ler, medya, diller ve experimentation/personalization konfigürasyonu.
2. Birikmiş page type’ları ve property’leri buda.
3. WordPress’e eşle — page type’lar custom post type’lara, block type’lar Gutenberg bloklarına veya ACF flexible content’e, content tree sayfa hiyerarşisine veya düzleştirilmiş koleksiyonlara, property’ler ACF’e, medya media library’ye.
4. Boş hedefi kur ve editörlerle doğrula.
5. Bir snapshot üzerinden dönüştür, staging’de dry-run yap, tekrarla.
6. Cutover’dan önce yönlendirmeler (redirect).
7. Geçişi yap, sonra izle.

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

Sonucu belirleyen ayrıntılar.

Page type’lar, block type’lar ve content tree

Optimizely içeriği bir content item ağacıdır — .NET kodunda tanımlanan güçlü tipli page type‘lar ve block type‘lar tarafından şekillenir. Page type’lar custom post type’lara, property’leri de ACF’e eşlenir. Block type’lar — Optimizely’in content area’lara yerleştirilen, yeniden kullanılabilir içerik bileşenleri — her sistemin component/dynamic zone karşılığıdır ve aynı uyarıyı taşırlar: WordPress’te temiz bir 1:1 karşılığı yok. Her block type için, bunun bir Gutenberg bloğu/pattern’i mi yoksa bir ACF flexible-content layout’u mu olacağına karar ver ve her birini elle hallet. Content area‘lar (blokların düzenlendiği, kimi zaman görüntü seçenekleri de olan bölgeler) WordPress blok içeriği veya flexible-content alanları olarak yeniden kurulmalıdır. Saatlerin saklandığı yer burasıdır; önce her block type ve content-area kullanımını envanterle.

Shared block’lar — ağaçta saklanan ve birçok sayfada yeniden kullanılan bloklar — özel muamele ister: her shared block’u bir kez içe aktar, sonra içeriğini her yere kopyalamak yerine, onu kullanan her sayfadan iki-geçişli ID haritan üzerinden referansla.

Content tree ve URL’ler

Ağaç, Optimizely’in URL yapısını sürükler. Her item’ın yolunu (path) koru — bu senin redirect haritan ve SEO değerini taşıyan sayfalar da bunlar. Gerçekten hiyerarşik içeriği WordPress sayfa hiyerarşisine, düz koleksiyonları da post artı taxonomy’ye eşle; Optimizely öyle sakladı diye her şeyi zorla ağaca sokma.

Çıkarma (extraction): export paketine uzanma

Optimizely’in yerleşik export’u, Optimizely’den Optimizely’e transfer için tasarlanmış bir .episerverdata paketi üretir — Strapi’nin ve Sitecore’un native paketleri gibi WordPress için işe yaramaz. İçeriği JSON olarak çekmek için Content Delivery API‘yi (REST) ya da Content Graph‘ı (GraphQL) kullan, ya da doğrudan bir veritabanı snapshot’ını oku. Property değerleri ve blok referansları bu kaynaklardan yeniden birleştirilmek zorunda. Bir snapshot dondur, pagination’a saygı göster, toplamları tut, ve dönüşümü dondurulmuş kopya üzerinden yap.

Experimentation ve personalization taşınmaz

Optimizely’in experiment’leri, feature flag’leri ve personalization kuralları içerik değildir ve geçişle birlikte gelmez. Experimentation motorunun veya visitor-profile deposunun WordPress’te bir karşılığı yok. Yukarıdaki denetime göre: atıl duruyorlarsa bırak gitsinler ve kararı belgele; aktiflerse ayrı bir experimentation katmanını (Optimizely’in kendi ürününü bağımsız araç olarak tutmak ya da bir WordPress A/B çözümü) kendi başına bir proje olarak planla. Bunun içerik geçişini rehin almasına izin verme.

Template’ler ve rendering taşınmaz

Optimizely template’leri .NET/Razor’dur (veya Content Graph üzerinden headless bir arayüz). Sunum koddur, içerik değil — taşınmaz. Arayüz, bir WordPress teması veya bloklar olarak yeniden kurulmalıdır. Bugün headless bir arayüz Content Graph’ı tüketiyorsa, tamamen farklı bir yanıt şekliyle WordPress REST API’sine veya WPGraphQL’e geçmesi gerekecek — o veri-katmanı yeniden inşasına bütçe ayır.

Çok dilli içerik

Optimizely dilleri, content item’lar üzerindeki language branch‘ler olarak ele alır. WordPress hedefini — multisite, Polylang veya WPML — dönüştürmeden önce seç ve bazı dillerde çevrilmiş, bazılarında çevrilmemiş item’ları öyle bir hallet ki orphan yaratma. Çok dilli mimariyi önce karara bağla; bu bir çeviri sorunu değil, bir mimari sorunudur.

Medya ve asset’ler

Optimizely’in asset’leri (ağaçtaki medya ve arkalarındaki DDS/blob depolama) indirilip WordPress media library’ye yeniden aktarılmalı, her referans da yeniden yazılmalı — property referansları ve, en kritiği, rich-text ile content-area bloklarının içine gömülü medya. İçerik-içi referanslar, sessizce eski sistemi göstermeye devam edenlerdir.

Kullanıcılar ve roller

Optimizely’in rolleri ve erişim-hakları modeli WordPress’e bire bir eşlenmez ve şifre hash’leri taşınabilir değildir. Şifre sıfırlamalarını ve elle kurulmuş bir rol eşlemesini planla, ve ince taneli item-seviyesi erişimin WordPress’in daha kaba rol modeline çökeceğini kabul et.

Dürüst kapanışım

Bu seriyi Optimizely ile bitirmeyi tesadüfen seçmedim. Bütün bu rehberlerin altındaki tezi en temiz gösteren platform o: yazılım gayet iyiydi ve değişen tek şey sahiplikti — bir yeniden adlandırma, yeni bir sahip, yeni bir yön, senin ağzından çıkanı beklemeden gelen. Tek-satıcılı her platformda taşıdığın risk bu; ve WordPress’in yapısı gereği asla oluşturamayacağı risk de bu, çünkü satın alınacak bir şirket yok.

Personalization’ı kaybetmekten korkmadan önce denetimi yap — çoğu genellikle atıl. Block type’ları elle eşle, redirect’ler için ağacı koru, sunumu yeniden kur, çok dilli modeli önce karara bağla. Ve hedefin neden WordPress olduğunu hatırla: daha fazlasını yaptığı için değil, kimse onu ayağının altından satın alamayacağı ve bugün üzerine yazdığın kod on yıl sonra da çalışacağı için.

Bütün bu serinin tezi işte bu, onu kanıtlayan tek geçiş üzerinden son bir kez söylenmiş hali. Biçim sürekli değişir — CD-ROM, Flash, ECM, DXP, headless. İş hiç değişmez: içeriği doğru yere ulaştır, doğru tut, yaşat. Onu hiçbir satın almanın sessizce raflara kaldıramayacağı bir yere koy; işte o zaman bu işin baştan beri gerçekten önemli olan tek kısmını yapmış olursun.

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

Biri geçmeye karar verir vermez sorduğu ilk soru şu oluyor: Optimizely’den çıkarsak, WordPress’in altından kalkamayacağı bir işi mi ona yüklüyoruz? Hayır. Ve WordPress’i hâlâ “sadece bir blog” sanan herkes şaşırmak üzere — çünkü yalnızca bir DXP yapabilir sandığın üç şeyi WordPress de yapıyor.

Yapılandırılmış içeriği bir DXP gibi modeller. Optimizely’in page type ve block type’ları güçlü tipli içerik bileşenleridir. WordPress aynı şekilleri custom post types, ACF ve native bloklarla modeller — page type’lar CPT’ye, block type’lar Gutenberg bloklarına ya da ACF flexible content’e dönüşür — ve editörler bunların hepsine araya bir .NET geliştirici girmeden dokunur.

Headless de çalışır. Optimizely’in Content Graph’ı onun GraphQL dağıtım katmanıdır; WordPress’in ise 2016 sonundan beri core’da REST API’si var — neredeyse on yıldır sahada pişiyor — üstüne, artık Automattic’in arkasında durduğu ve kanonikleşme yolundaki WPGraphQL. Mevcut headless arayüzünü Content Graph yerine WPGraphQL’e bağla; altındaki CMS’in değiştiğini pek fark etmez bile.

Experimentation’ı da karşılar — dürüstçe. A/B testi gerçekten yük taşıyorsa, üstte ayrı bir experimentation aracı tut; bu bir kaçamak değil, gerçek bir cevap. Ama alttaki CMS’in buna izin vermesi için bir DXP olması gerekmiyor. Önce denetimi yap — kaybetmekten korktuğun personalization’ın çoğu zaten atıl.

Üstüne WordPress, lisanslı bir DXP’nin sana asla veremeyeceği şeyleri kazandırır:

• Gerçek bir ticaret motoru. WooCommerce; sonradan cıvatalanan bir eklenti değil.
• İnsanlar için editoryal güç — block editor, media library, revizyonlar, roller ve SEO’dan forma, üyelikten fazlasına uzanan, hiçbirini sıfırdan yazmadığın bir eklenti ekonomisi.
• Kullanıcı başı ücret yok, kullanım sayacı yok. Yüz editör ekle; fatura kıpırdamaz.
• Sahiplik. Ve burada Optimizely tezimi benim yerime kanıtlıyor: o bizzat satın almanın ta kendisi — Episerver’ın kendi adı ayağının altından satın alındı. WordPress alınamaz. Kimse sahibi değil; dolayısıyla sen üzerinde dururken kimse onu yeniden adlandıramaz, yeniden fiyatlandıramaz ya da raflara kaldıramaz.

İşte sürpriz bu. Optimizely’den çıkmak bir düşüş değil — adı da sahibi de senin ağzından çıkanı beklemeden değişmiş bir platformdan inip, kimsenin asla elinden alamayacağı bir platforma adım atmaktır.