Sitecore’dan WordPress’e: O Kadar Personalization’a Ne Oluyor

🇬🇧 English: Read this article in English →

Sitecore gerçekten yetenekli platformlardan biridir ve başka bir şey söylemeden önce bunu açıkça söylemek istiyorum. Yıllarca .NET kurumsal dünyasının sahibiydi ve personalization’da pazara öncülük etti — bir ziyaretçiyi konumundan ve geçmişinden tanıyıp sayfayı ona göre gerçek zamanlı yeniden şekillendiriyordu. Bu gerçek mühendislikti ve sonrasında gelen pek çok şeyin önündeydi.

Ama Sitecore, benim “ECM hastalığı” diye düşündüğüm şeyi devraldı — daha yeni ve daha iyi pazarlanmış bir ambalajın içinde. Lisanslar devasa. Kurulumlar bir yıl sürüyor. Rutin işler için sertifikalı uzmanlara ihtiyacın var. Ve birden fazla kez şuna tanık oldum: bir müşteri bir personalization motoru satın alıyor, sonra üçten fazla audience segment kurmuyor. Kullanmayacakları bir kapasitenin parasını ödüyorlar; üstüne bir de onu işletmek için gereken uzmanların parasını ödüyorlar.

İşte bu boşluk — Sitecore’un yapabildikleriyle bir kuruluşun onunla gerçekten yaptıkları arasındaki boşluk — genellikle WordPress konuşmasını başlatan şey oluyor. Ben bu işe nasıl bakıyorum, önce sade bir dille anlatayım.

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

• Maliyet-kullanım boşluğu. Sitecore’un fiyatını haklı çıkaran şey personalization, deneme (experimentation) ve omnichannel orkestrasyondur. Bunun küçük bir kısmını kullanıyorsan, sahip olmadığın bir sorunu çözmek için bir makine satın alıyorsun demektir. Gördüğüm en yaygın tek sebep bu.
• Uzmana bağımlılık. Rutin içerik ve layout değişiklikleri bile sertifikalı Sitecore geliştiricileri gerektiriyor. Editörler kendi başlarına iş göremiyor. ACF ve blocks ile WordPress bu özerkliğin çoğunu geri veriyor.
• Kurulumun ağırlığı. Bir Sitecore build’i bir yıl süren bir programdır. Bir WordPress içerik sitesi ise bunun zaman ve maliyet olarak küçük bir kesridir.
• İşe alım gerçeği. Sitecore yeteneği kıt ve pahalı. WordPress yeteneği ise her yerde.

Personalization meselesi, deneyimden

Yıllar önce bir perakende markası için gerçekten zamanının ötesinde bir smart mirror kurmuştum — fiziksel bir mekânda personalization, karşısında kim varsa ona göre gösterdiğini yeniden şekillendiriyordu. Yani personalization’ı küçümseyen biri değilim; ben de onun peşinden koştum ve maliyetini ne zaman hak ettiğini biliyorum. Birçok touchpoint’i orkestre ettiğinde ve personalization gerçek gelir yarattığında maliyetini hak eder. Bir pazarlama müdürünün bir kere kurup bir daha dönüp bakmadığı, broşür misali bir sitedeki üç segment olduğunda maliyetini hak etmez.

Sitecore’dan çıkmadan önce dürüst denetimi yap: gerçekten canlı olan kaç tane personalization kuralı var, gerçekten kullanılan kaç segment var, experimentation platformunun ne kadarı gerçekten deney yürütüyor? Cevap “neredeyse hiç” ise, geçişte kaybetmekten korktuğun şey aslında zaten kullanmadığın bir şeydir. Bu, tüm projeyi yeniden çerçeveliyor — bir yetenekten vazgeçmiyorsun, çoktan terk ettiğin bir yeteneğin parasını ödemeyi bırakıyorsun.

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

1. Modeli envanterle — her template, her field, item tree, layout’lar ve rendering’ler, media library, diller ve — en kritiği — personalization ve experimentation konfigürasyonu.
2. Buda — yıllar içinde birikmiş template ve field’ları temizle.
3. WordPress’e eşle — template’ler custom post type’lara, field’lar ACF’ye, item tree sayfa hiyerarşisine ya da düzleştirilmiş koleksiyonlara, 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 redirect’ler.
7. Devreye al, sonra izle.

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

Ayrıntılar. Burası işi bizzat yapan kişi için.

Items, templates ve ağaç

Sitecore’da her şey hiyerarşik bir ağaçtaki bir item‘dır ve yapısını bir template tanımlar (Sitecore’un content type versiyonu; field’lar ve inheritance ile). Template’ler custom post type’lara eşlenir; field’lar ACF’ye; item tree WordPress sayfa hiyerarşisine ya da düz koleksiyonlar için taxonomy’li post’lara eşlenir. Template inheritance‘ı altını çizmeye değer bir incelik — Sitecore template’leri field’ları base template’lerden miras alır, yani bir item’ın tam field listesi demek onun inheritance zincirini çözmek demektir. Bu çözümü transform sırasında değil, model envanterin sırasında yap.

Üç veritabanı ve hangisi gerçek

Sitecore içeriği master, web ve core veritabanlarına yayarak saklar. web veritabanı yayınlanmış versiyondur; master ise yayınlanmamış değişiklikler dahil tüm düzenleme durumunu tutar. Hangisinin kaynağın-gerçeği olduğuna karar ver — temiz bir yayınlanmış snapshot için genelde web — ve bunda kasıtlı ol; yoksa yarım kalmış editoryal işi canlıymış gibi taşırsın. Field değerleri EAV tarzı bir yapıda yaşar (shared, versioned ve unversioned field tabloları), yani tam bir item’ı yeniden inşa etmek bunları birbirine join etmek demektir.

Çıkarma (extraction): yanlış araca uzanma

Sitecore’un .episerverdata karşılığı item serialization’dır (Sitecore CLI, Unicorn ya da TDS) ve yerleşik paketleme Sitecore’dan-Sitecore’a transfer için tasarlanmıştır — WordPress için değil. Daha iyi yollar: item’ları yapılandırılmış bir formata serialize etmek için Sitecore PowerShell Extensions, ya da Item Service / Sitecore Services Client REST API, ya da bir veritabanı snapshot’ına karşı doğrudan okuma. Hangisini seçersen seç, bir snapshot dondur ve tekrar tekrar onun üzerinden dönüştür.

Layout’lar ve rendering’ler taşınmaz

Herkesi şaşırtan kısım bu. Bir Sitecore sayfasının görünümü onun presentation details‘inden gelir — layout, placeholder’lara yerleştirilen rendering’ler ve onların datasource’ları. Bu içerik değildir; konfigürasyon ve koddur. Hiçbiri WordPress’e taşınmaz. Her rendering bir WordPress block’u, pattern’i ya da template’i olarak yeniden inşa edilmeli ve datasource bağlantısı (hangi content item’ın hangi rendering’i beslediği) WordPress query’leri ya da block içeriği olarak yeniden ifade edilmeli. Presentation katmanını baştan inşa etmek için bütçe ayır — içerik taşınır, ama içeriğin nasıl bir araya getirildiği taşınmaz.

xDB, personalization ve experimentation gitti

Sitecore’un personalization kuralları, xConnect/xDB davranışsal verisi ve experimentation konfigürasyonu taşınmaz. xDB profil deposunun WordPress karşılığı yoktur. Personalization iş için gerçekten yük taşıyan bir şeyse, onu özel bir WordPress personalization ya da A/B aracıyla yeniden inşa etmeyi planla ya da ayrı bir experimentation katmanı tut — ve bunu bir dipnot değil, kendi başına bir proje olarak kapsamla. Yük taşıyan bir şey değilse (yukarıdaki denetime bak), bırak gitsin ve bu kararı belgele ki sonradan kimse onu aramaya gelmesin.

Çok dilli version’lar

Sitecore dil version’larını item başına saklar. WordPress hedefini — multisite, Polylang ya da WPML — taşımadan önce seç ve bazı dillerde version’ı olup bazılarında olmayan item’ları öyle bir ele al ki öksüz çeviriler yaratma. Her zaman olduğu gibi: çok dilli mimariye önce karar ver; bu bir çeviri problemi değil, bir mimari problemidir.

Media library ve gömülü referanslar

Sitecore’un media library’si dosyaları kendi field’ları olan item’lar olarak tutar. Bunları indir ve WordPress media library’ye yeniden içe aktar, sonra her referansı yeniden yaz — hem image/media field’larında hem de Sitecore’un medyayı item ID ya da dynamic media URL ile gömdüğü rich-text field’ların içinde. İçerik içindeki referansları kaçırırsan, taşınmış sayfaların sessiz sedasız birazdan kapatacağın bir Sitecore instance’ından görsel yüklemeye devam eder.

Kullanıcılar, roller ve güvenlik

Sitecore’un güvenlik modeli — roller, domain’ler, item-seviyesi erişim — WordPress’inkinden daha zengindir ve birebir eşlenmez. Password hash’leri taşınabilir değil. Password reset’leri ve elle kurulmuş bir rol eşlemesi için plan yap; item-seviyesi güvenlik ayrıntısının WordPress’in daha kaba rol modeline çökeceğini de kabul et.

Dürüst kapanışım

Sitecore’u seçmiş olmak bir hata değil ve onu bırakmak da bir başarısızlık itirafı değil. Birçok kuruluş için bu sadece dürüst bir hesaplaşmadır: platform, işin hiçbir zaman tam kullanmadığı personalization ve orkestrasyon için satın alınmıştı ve altındaki site, WordPress’in bunun küçük bir kesri maliyet ve emekle çalıştırabileceği bir içerik sitesidir.

Zor kısımlar gerçek — presentation katmanı sıfırdan yeniden kuruluyor ve personalization seninle gelmiyor. Ama dürüst denetimi yapar ve “kaybettiğin” yeteneklerin zaten atıl durduğunu görürsen, geçiş hiç de bir gerileme değildir. O an, sessizce kullanmayı bıraktığın bir makinenin parasını ödemeyi bıraktığın andır — ve içeriği, sıradan insanların onu doğru ve canlı tutabileceği bir yere taşıdığın andır; ki otuz yıl platformların gelip gidişini izledikten sonra, bu işin hiç değişmemiş tek parçası da tam olarak budur.

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

Biri geçmeye karar verir vermez sorduğu ilk soru şu oluyor: Sitecore’dan çıkarsak, decoupled arayüzü ve etrafında bütün platformu kurduğumuz personalization’ı kaybeder miyiz? Çoğunlukla hayır — ve o “çoğunlukla” işin dürüst kısmı.

WordPress bu işlerin hiçbirine dün girmedi. REST API 2016 sonundan beri core’un içinde ve WPGraphQL — artık Automattic’in arkasında durduğu, WordPress’in kanonikleşme yolundaki GraphQL katmanı — sana bıraktığından hiç de aşağı kalmayan, ciddi bir sorgu API’si veriyor. Faust.js ya da WPGraphQL ile headless WordPress, doğrudan Sitecore JSS’in rakibi: aynı decoupled mimari, Vercel’de aynı React arayüzü, altında farklı bir motor. Kurumsal tartışmayı kaybetmedi; içine büyüdü.

Demek ki Sitecore’dan çıkışın iki dürüst yolu var:

• Klasik WordPress — bu yazının geri kalanı. Editörlere özerkliğini geri ver, araya sertifikalı bir uzman girmeden yayınlasınlar.
• Headless WordPress — sevdiğin JSS tarzı decoupling’i koru; arkadaki motoru WordPress artı WPGraphQL ile değiştir, tepesine de Faust.js.

Peki ya personalization? Onu denetime geri götür. Bir personalization ya da A/B test eklentisiyle WordPress, çoğu kuruluşun gerçekten çalıştırdığı personalization’ı karşılar — o dürüst saymadaki üç segment’i. Sana açık konuşayım: xDB’nin tüm davranışsal derinliğini birebir kopyalamaz. Ama o derinliği neredeyse hiç kimse kullanmıyor ve istisna olup olmadığını sen zaten biliyorsun.

İşte bu takasın alet çantana eklediği şeyler:

• Gerçek bir ticaret motoru. WooCommerce — cıvatalanmış bir ek değil.
• Bir eklenti ekonomisi ve insanlar için editoryal güç — yalnızca sertifikalı geliştiriciler için değil.
• Kullanıcı başı ücret yok, kullanım sayacı yok, her yıl yenilenen devasa bir lisans yok.
• Sahiplik. WordPress’i kimse ayağının altından satın alamaz.

Bıraktığın şey ise bir yıl süren kurulum ve sertifikalı-uzman şartı. Sitecore işini gerçekten iyi yapıyor; en başta söyledim, arkasındayım. Ama “biraz personalization’lı, decoupled bir site istiyoruz” cümlesi, kurumsal kira ödemeye devam etmek için bir sebep değil — WordPress’i headless çalıştırmak için bir sebep; hem de arkanda çok daha büyük bir alet çantasıyla.