Kentico’dan WordPress’e: Content Tree’yi Kaybetmeden .NET Yığınından Çıkmak

🇬🇧 English: Read this article in English →

.NET CMS dünyasına karşı zayıf bir yanım var, çünkü bir zamanlar ben de içindeydim. Bölgemdeki kurumsal müşteriler açık kaynağa elini bile sürmezken — “kodu herkes görebiliyor” o günlerde bir zaaf sayılırdı — biz kendi içerik yönetim sistemimizi Microsoft’un ASPX yığını üzerine kurduk. Yani bir ekip bana Kentico’da olduklarını ve WordPress’i düşündüklerini söylediğinde, mimariyi bana anlatmalarına gerek kalmıyor. Üzerinde durdukları o şeyi ben inşa ettim.

Kentico — bugünkü adıyla Kentico Xperience — yetenekli bir .NET DXP’si. İçerik hiyerarşik bir ağaçta saklanır, güçlü tipli page type’lar, bir media library, workflow, kişiselleştirme, hepsi SQL Server’ın üstünde oturur. Ciddi siteler için ciddi bir yazılım. Aynı zamanda lisansı pahalı, kadrosu pahalı ve pek çok içerik ekibinin artık taşımak istemediği bir .NET hosting gerçeğine bağlı.

Bu yığından çıkmayı ben şöyle düşünüyorum. Önce yalın haliyle, sonra sona doğru teknik ayrıntı.

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

Sebepler tanıdık bir şekle bürünüyor:

• Lisans ve toplam maliyet. Kentico lisansı, artı .NET geliştiriciler, artı Windows/SQL Server hosting — çoğu zaman, açıkçası, bir içerik sitesi için ağır bir yıllık fatura demek. WordPress bu maliyetin çoğunu yerle bir ediyor.
• Geliştiriciye bağımlılık. Kentico’da page type’lar ve template’ler geliştirici toprağıdır. Yeni bir alan ya da yeni bir bölüm isteyen editörler bir talep açar ve bekler. ACF ve bloklarla WordPress, bunun büyük kısmını editörün eline geri verir.
• İşe alım havuzu. Kentico uzmanları dar bir pazar. WordPress yeteneği ise her yerde. Bir Kentico ekibinden kilit bir geliştirici ayrıldığında, yerine birini koymak başlı başına bir proje olur.
• Ekosistem çekimi. WooCommerce, SEO eklentileri, formlar ve platformu ayakta tutmakta çıkarı olan bir eklenti ekonomisi — karşısında ise yol haritasını senin kontrol etmediğin tek bir satıcı.

Aynı türden bir sistemi inşa ederken öğrendiklerim

ASPX üzerine kurduğumuz CMS iyi çıktı. Hızlıydı. Onlarca ajans kullandı ve hiçbir zaman para almadık, çünkü amaç problemi çözmekti, para değil. Sonra elimizden kaçtı, çünkü hiçbir geriye dönük uyumluluğu yoktu — her sürüm geçmişi unutuyordu ve her yeni sürüm, birinin kapımızı çalıp verisinin elle taşınmasını istemesi demekti. Onu taşıyamadık ve çekip gittik.

Bunu şunun için anlatıyorum: bana kurumsal CMS platformlarını asıl neyin ağırlaştırdığını öğretti ve o şey özellikler değil. Senin binanda kimsenin sertifikalı bir uzman olmadan değiştiremeyeceği bir sistem bir varlık değildir — varlık kostümü giymiş bir bağımlılıktır. 2000’lerin büyük ECM platformlarını öldüren hastalık buydu — Vignette, Interwoven, FatWire, Stellent — her biri satın alındı, yutuldu ve sessizce raflara kaldırıldı; yazılım başarısız olduğu için değil, karmaşıklık yetenekle karıştırıldığı için. Kentico onlardan çok daha hafif, ama aynı soru geçerli: ödediğin şeyin ne kadarını gerçekten kullanıyorsun ve ne kadarı sadece yük? Geçiş yapmadan önce bunu dürüstçe yanıtla, çünkü cevap sana neyi geride bırakacağını söyler.

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

1. Modeli envanterle — her page type, her alan, custom table’lar, content tree yapısı, media library ve çok dilli culture’lar.
2. Kimsenin artık hatırlamadığı sebeplerle var olan page type’ları ve alanları buda.
3. WordPress’e eşle — page type’lar custom post type’lara, alanlar ACF’ye, content tree WordPress’in parent/child sayfa hiyerarşisine, custom table’lar CPT’lere veya custom table’lara, medya media library’ye.
4. Boş hedefi kur ve editörlerle doğrula.
5. Bir veritabanı snapshot’ına karşı dönüştür, staging’de dry-run yap, tekrarla.
6. Cutover’dan önce yönlendirmeler — Kentico’nun URL yapısı ve alias’ları senin redirect haritan olur.
7. Geç, sonra izle.

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

Sonucu belirleyen ayrıntılar. Bu bölüm işi kim yapacaksa onun için.

Content tree bu işin kalbidir

Kentico içeriği hiyerarşik bir ağaç olarak düzenler — her sayfanın bir konumu, bir parent’ı ve ağaçtan türetilen bir alias path’i vardır. WordPress böyle düşünmez; sayfalarının parent/child ilişkileri vardır ama post’lar ve custom post type’lar özünde taksonomiyle düzleştirilmiş, yassı yapılardır. Ağacı korumak, işin merkezindeki modelleme kararıdır. Anlamlı bir hiyerarşiye sahip sayfalar WordPress’in hiyerarşik page/CPT yapılarına eşlenir; aslında yassı bir koleksiyon olan içerik (haberler, makaleler, ürünler) bir ağaca zorlanmak yerine taksonomili post’lara düzleştirilmelidir. Her bölüm için hangisi olduğuna ayrı ayrı karar ver. Ve her düğümün alias path’ini koru, çünkü o path senin redirect haritan — onu kaybetmek yılların SEO’sunu kaybetmek demektir.

Veri SQL Server’da yaşıyor

Kentico içeriği SQL Server’da saklar ve en temiz çıkarım genellikle bir veritabanı snapshot’ına karşı doğrudan, salt-okunur bir sorgudur — ya da etkinleştirdiysen Kentico’nun REST servisi / content staging API’si. Page-type verisi ağaç tabloları ile tipe-özel veri tabloları arasına yayılmıştır; tam bir sayfayı yeniden kurmak için bunları join’lemen gerekir. Hangi yolu seçersen seç, bir dosyaya snapshot al ve dondurulmuş kopyaya karşı dönüştür ki çalışmaların tekrarlanabilir ve başarısız olsa bile güvenli olsun. Canlı production’a karşı dönüştürme.

Page type’lar ve alanlar güzel eşlenir — web part’lar ve widget’lar eşlenmez

Kentico page type’ları doğal olarak custom post type’lara, alanları da ACF’ye eşlenir. Tuzak; web part’lar, widget’lar ve portal-engine layout’u (ya da daha yeni sürümlerde MVC view component’leri). Bunlar sunum ve mantıktır, içerik değil — geçmezler. Her dinamik bölge, her listeleme web part’ı, her kişiselleştirilmiş widget, bir WordPress bloğu, sorgusu ya da template’i olarak yeniden inşa edilmek zorundadır. Bunları erkenden envanterle; bir veri export’unda görünmezler ve sitenin bir bölümü bomboş çıkana kadar unutulmaları çok kolaydır.

Çok dilli culture’lar

Kentico dilleri culture olarak ele alır, her culture kodu için içerik varyantlarıyla. Geçmeden önce WordPress modelini seç — multisite, Polylang veya WPML — çünkü Kentico’nun culture varyantlarını seçtiğin yapıya eşleyen dönüşüm tamamen bu seçime bağlı. Bazı culture’larda var olup diğerlerinde olmayan sayfalara dikkat et; dönüşümün, kısmi çevirileri orphan sayfa yaratmadan idare etmesi gerekir.

Media library ve içeriğe gömülü linkler

Kentico’nun media library’si ve page attachment’ları ikisi de dosya tutar ve ikisinin de indirilip WordPress media library’sine yeniden import edilmesi gerekir. Asıl canını yakan kısım: rich-text alanları, Kentico medya path’lerine mutlak (absolute) linkler içerir (/getmedia/..., attachment GUID’leri). Her birinin yeni WordPress attachment URL’ine yeniden yazılması gerekir, yoksa taşınan sayfaların, birazdan hizmetten çıkaracağın bir Kentico instance’ından görselleri yüklemeye devam eder.

Workflow, kişiselleştirme ve formlar

Kentico; workflow durumlarını, kişiselleştirme kurallarını ve platform-içi bir form modülünü paket olarak sunar. Bunların hiçbiri içerik olarak geçmez. Workflow, WordPress’in post statülerine ve ihtiyacın varsa bir editoryal-workflow eklentisine dönüşür; kişiselleştirme, bir WordPress kişiselleştirme eklentisine dönüşür ya da tamamen düşer (kaç segmentin gerçekten kullanımda olduğu konusunda dürüst ol — benim tecrübemde bu sayı, kurulanların çok daha altındadır); formlar Gravity Forms, Fluent Forms ya da benzerine dönüşür ve her formun submission handling’i ve bildirimleri yeniden inşa edilmek zorundadır. Projeyi kapsamlandırmadan önce bunları envanterle, çünkü içeriğin dışında saklanan gerçek bir iş yükü.

Kullanıcılar ve izinler

Kentico kullanıcı hesapları ve rolleri temiz taşınmaz ve şifre hash’leri taşınabilir değildir. Şifre sıfırlamaları ve Kentico rollerinin WordPress rollerine elle kurulmuş bir eşlemesi için plan yap.

Dürüst kapanışım

Kentico iyi bir yazılım ve ondan çıkmak yanlış seçim yaptığının bir itirafı değil. Genellikle sitenin, platformun inşa edildiği şeyden daha hafif bir şeye dönüştüğünün fark edilmesidir — tam bir DXP’nin maliyetini taşıyan bir içerik sitesi. WordPress’e geçmek bunu doğru boyuta getirmektir: lisanslı, uzmana bağımlı bir .NET yığınını, ekibinin gerçekten kadro kurabileceği ve editörlerinin gerçekten kullanabileceği bir platformla takas etmek.

Bunu, bu sistemlerden birini inşa etmiş ve onu terk etmek zorunda kalmış biri olarak söylüyorum. O tecrübeden taşıdığım ders basit: bir CMS, ancak binandaki sıradan insanlar birini aramadan onu değiştirebildiği sürece bir varlıktır. Ağacı dikkatle eşle, web part’ları yeniden kur, medya linklerini yeniden yaz, şifre sıfırlamalarını planla — ve içerik, kendi şartlarında doğru ve canlı kalabileceği bir yere iner; ki geçiş yapmanın bütün amacı da zaten budur.

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

Bir Kentico ekibi geçmeye karar verir vermez sorduğu ilk soru şu oluyor: .NET yığınından çıkarsak, daha az ciddi bir şeye mi düşüyoruz? Hayır. Ve WordPress’i hâlâ “sadece bir blog” diye dosyalayanlar, cevaba en çok şaşıranlar oluyor.

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 de artık Automattic’in arkasında durduğu, WordPress’in kanonikleşme yolundaki GraphQL katmanı. Yani Kentico’da asıl sevdiğin şey decoupled arayüzse, onu koruyorsun: WordPress de headless çalışır — REST ya da WPGraphQL — hangi arayüze bağlarsan onu besler.

Ama günlük uyum bundan bile temiz. Custom post types artı ACF, Kentico’nun page type’larına ve alanlarına neredeyse birebir eşleniyor; WordPress’in parent/child hiyerarşisi de content tree’ni taşıyor. Çok dilli culture’lar multisite, Polylang ya da WPML’e dönüşüyor. Kentico’da kurduğun model, sevmediği bir şekle zorlanmadan karşıya geçiyor.

Ve geride bıraktığın şey pahalı olan kısım:

• .NET lisansı. Gitti. Yıllık koltuk matematiği yok, kullanım sayacı yok.
• Windows/SQL Server operasyon yükü. Ekibinin uyurken çevirebileceği bir hosting’le takas edildi.
• Sertifikalı-uzman vergisi. Yerine, prim ödeyip elde tuttuğun dar bir pazar değil, her yerde olan bir istihdam havuzu geldi.

Üstüne, bir DXP’nin sana asla ucuza vermediğini kazanıyorsun: WooCommerce, gerçek bir ticaret motoru ve yeniden yazmak yerine tükettiğin bir eklenti ekonomisi — SEO, formlar, üyelikler.

Kentico iyi bir yazılım; söyledim, arkasındayım. Ama “API üzerinden yapılandırılmış bir content tree istiyoruz” cümlesi .NET’te kalmak için bir sebep değil. WordPress’e geçmek için bir sebep. Modeli koruyorsun, arkasına çok daha büyük bir alet çantası koyuyorsun.