Herhangi Bir CMS’ten WordPress’e: Otuz Yıldır Kullandığım Geçiş Planı

🇬🇧 English: Read this article in English →

İçeriği, sayabileceğimden çok daha fazla sistemin üstünden taşıdım. CD-ROM’lardan web’e. Flash’tan HTML’e. Bir evden pahalı kurumsal içerik yönetim platformlarından. Kendi elimizle yazdığımız CMS’ten. Drupal, Sitecore, Kentico, Umbraco, Contentful, Strapi, Sanity — kaynak sürekli değişiyor ve her seferinde birileri bana bu sefer farklı diyor.

Hiç de değil. Aslında hiçbir zaman. Dışarıdaki biçim değişir; altındaki problem değişmez. İçeriği doğru yere ulaştır, doğru tut, yaşat. 1996’da bir plastik diskin üstündeki iş buydu ve bugün bir headless yığını taşırken de aynı iş bu. Bunu bir kez kavradığında, her geçişi yeni bir macera gibi görmeyi bırakır, hepsini farklı bir kostüm giymiş aynı problem olarak görmeye başlarsın.

Bu yazı, işin platformdan bağımsız versiyonu — herhangi bir kaynak CMS’e uyguladığım yöntem. Bu serideki platforma özel rehberlerle birlikte oku; onlar her sistemin kendine has huylarını anlatıyor, bu yazı ise değişmeyen yöntemi.

Her şeyi yöneten tek fikir

Geçiş bir export-import problemi değildir. Export-import kostümü giymiş bir içerik modelleme problemidir. Bunu “veriyi dışarı al, veriyi içeri bas” diye ele alan ekipler, teknik olarak tamamlanan ama pratikte çöken geçişler üretir — yanlış biçimde duran içerik, onunla çalışamayan editörler, eski sistemde anlamlı olup yeni sistemde hiçbir anlam ifade etmeyen bir yapı.

Ben matbaadan geliyorum; orada mizanpaj son adımdır, metin sen düzenlemeden önce gelir. O disiplin hiç yakamı bırakmadı: her zaman biçimden önce yapı. Bir geçişte bu şu demek: tek bir satırı bile taşımadan önce içeriği düzgünce modellersin. Geri kalan her şey, biçimi doğru yakalamaktan sonra gelir.

Neden özellikle WordPress

Yönteme geçmeden önce, gerekçe. İnsanları WordPress’e moda olduğu için göndermiyorum. Bedelini zor yoldan ödeyerek öğrendiğim şeyler yüzünden gönderiyorum:

Platformlar teknik başarısızlıktan değil, sahiplikten ölür. 2000’lerin her ciddi ECM platformunun — Vignette, Interwoven, FatWire, Stellent — satın alınıp yutulduğunu, adının değiştirildiğini ve sessizce raflara kaldırıldığını izledim. Bir tanesi bile yazılım kötü olduğu için ölmedi. Öldüler çünkü birileri şirketi satın aldı ve müşterilerinin içerik stratejisi bir entegrasyon planının bir satır kalemine dönüştü. WordPress satın alınamaz. Kimse sahibi değil. Bu küçük bir şey değil.

Geriye dönük uyumluluk (backward compatibility) işin tamamıdır. Bunu, ona sahip olmayan bir CMS yazarak öğrendim. Kendi sistemimizi kurduk, onlarca ajans kullandı ve geriye dönük uyumluluğu yoktu — her sürüm geçmişi unutuyordu, dolayısıyla her yeni sürüm kullanıcılarımızı elle geçiş yapmaya zorluyordu. O yükü taşıyamadık ve kendi kullanıcılarımızı yarı yolda bıraktık. WordPress yirmi yıl boyunca tam tersine oynadı: on yıl önceki kod büyük ölçüde hâlâ çalışıyor. Bir müşteriye sitesinin on yıl sonra da bakımı yapılabilir olacağını söylediğimde, pazarlama lafı tekrarlamıyorum — bunu öğrenmenin bana neye mal olduğunu anlatıyorum.

Açık kaynak bir çıkış kapısı demektir. Mesele bedava olması değil. Mesele şu: bir şeyler ters giderse — bir fork, bir kavga, bir yön değişikliği — kod senindir ve çıkıp gidebilirsin. İnsanların geçiş yaparak ayrıldığı platformların çoğunda o çıkış kapısı yok. WordPress’te var.

Hedefin WordPress olmasının sebebi bu. Şimdi yöntem.

Plan

1. İçerik modelini eksiksiz envanterle

Her içerik türü, her alan, her ilişki, her taksonomi, her medya referansı, her dil varyantı, her yeniden kullanılabilir bileşen. Belli belirsiz bir liste değil — biçimin gerçek bir haritası. Haritalamadığın şeyi taşıyamazsın ve saymadığın şeyi bütçeleyemezsin. Patlayan geçiş bütçelerinin çoğu tam burada patlar, çünkü birileri modeli envanterlemek yerine tahmin etmiştir.

2. Neyi taşımayacağına karar ver

Bu, herkesin direndiği ve atladığına herkesin pişman olduğu adım. Birkaç yıldır büyümüş her içerik modeli; kimsenin doldurmadığı alanlarla, çoktan biten bir kampanya için yaratılmış içerik türleriyle ve sırf bir geliştirici titiz davrandığı için var olan yapılarla doludur. Geçiş, bir şeyleri çöpe atmana izin verilen tek andır. Fırsatı kaçırma.

Burada apaçık olana güvenmeyi öğrendim. “Önemsenmeyecek kadar basit” diye elediğim her fikir sonradan önemli çıktı; kurduğum her fazla mühendislikli yapı sonradan ölü ağırlık çıktı. Acımasızca buda. Daha yalın bir model daha hızlı taşınır, daha kolay doğrulanır ve editörlere daha iyi hizmet eder.

3. Eski modeli WordPress’e — dürüstçe — eşle

İşin zanaat kısmı burası. İçerik türleri custom post type olur. Alanlar native alan, ACF alanı ya da taksonomi olur. İlişkiler ACF relationship alanı, post bağlantısı ya da term olur. Hiyerarşik ağaçlar, hiyerarşinin gerçek olduğu yerde WordPress sayfa hiyerarşisine dönüşür; gerçek olmadığı yerde post-artı-taksonomiye düzleşir. Yeniden kullanılabilir bileşenler ve page-builder blokları — hemen hemen her geçişteki tek en zor şey — Gutenberg blok/pattern’lerine ya da ACF flexible content’e dönüşür; tür tür, elle işlenerek.

Kural: eski sistemin biçimini WordPress’e zorla dayatma ve WordPress’in varsayılanlarını da yapı gerektiren içeriğe zorla dayatma. İçeriğin gerçekte ne olduğuna eşle.

4. Önce boş hedefi kur

Custom post type’ları, ACF field group’larını, taksonomileri ve block pattern’lerini WordPress’te — boş olarak — ayağa kaldır ve biçimi, onun içinde yaşayacak insanlarla doğrula. Eskiden UI öğelerinin lastik damgalarını yapardım ki müşteriler ben herhangi bir şey inşa etmeden önce yapıyı görebilsin; buradaki ilke de aynı. Gerçek içerik gelmeden önce biçimi doğru yakala ve üzerinde anlaş, çünkü import’tan sonra yeniden yapılandırmak on kat iş demektir.

5. Dondurulmuş bir anlık görüntüye çıkar — asla canlıda çalışma

İçeriği kaynak sistemin export aracıyla, API’siyle ya da doğrudan veritabanı okumasıyla dışarı çek — ve bir dosyaya dondur. Sonra dönüşümünü canlı production’a değil, o dondurulmuş kopyaya karşı çalıştır. Geçimimi CD-ROM basarak kazandım; bu işteki en berbat his, geri çağıramadığın bir hatadır. Dondurulmuş bir anlık görüntü senin geri-al düğmen: dönüşümü yüz kez çalıştırabilir, doksan dokuzunda yanlış yapabilir ve kaynağa hiç dokunmazsın.

Evrensel bir uyarı: sayfalamaya (pagination) saygı göster. API tabanlı her export’un limitleri vardır ve saf bir “bana her şeyi ver” çağrısı sessizce kırpılmış bir küme döndürür. Kaynak kayıtlarını say ve export’una güvenmeden önce onunla mutabık kılın. Toplamları kimse kontrol etmediğinde “her şeyi taşıdık” bu işin en tehlikeli cümlesidir.

6. Dönüştür — ve referansları iki geçişte çöz

Dönüşüm, her kaynak kaydını bir WordPress post’una eşler. Evrensel tuzak referanslardır: kaynak kayıtları birbirini WordPress’te hiçbir anlam ifade etmeyen ID’lerle işaret eder ve bunları tek geçişte çözemezsin, çünkü kaynağı import ederken hedef henüz var olmayabilir.

Bunu iki geçişte yap. Birinci, her kaydı import et ve eski ID’yi post meta’da saklayarak eski ID ile yeni WordPress post ID’si arasında bir harita kur. İkinci, her referansı — ilişkileri, taksonomiyi, içerik-içi bağlantıları, gömülü medyayı — o haritayı kullanarak yeniden yaz. Sıralamayı yanlış yaparsan ilişkilerin sessizce yanlış şeyleri işaret eder. Bu kalıp, bugüne dek taşıdığım her kaynak sistemde aynı.

7. Medyayı taşı ve içerik-içi URL’leri yeniden yaz

Her varlığı indir ve WordPress media library’ye yeniden import et. Sonra — herkesin unuttuğu adım — zengin metin içeriğine gömülü her medya URL’sini yeniden yaz, çünkü bunlar eski sistemin alan adına ya da CDN’ine gömülüdür. Bunu kaçırırsan, taşınmış sayfaların görsellerini birazdan kapatacağın bir sistemden yüklemeye devam eder. O sistem karardığında görsellerin de kararır.

8. Yönlendirmeler ve SEO — cutover’dan sonra değil, önce

URL yapın değişecek. Her eski yolu yenisine eşle ve yönlendirmeleri düğmeye basmadan önce yerine koy. Bunu atlarsan, yıllarca inşa ettiğin sıralamaların bir haftada buharlaştığını izlersin. Kaynak sistemlerin çoğu, yönlendirme haritasını mevcut URL/alias yapısında sana bedavaya verir — kullan onu.

9. Staging’de, sıkıcı olana kadar prova yap

Asla doğrudan production’a geçiş yapma. Tüm pipeline’ı bir staging WordPress’e çalıştır, gerçek sayfalara bak, editörlerin etrafta gezinmesine izin ver, yanlış olanı düzelt ve tekrar çalıştır. Bir prova artık hiçbir sürpriz üretmediğinde hazırsın. Önce değil.

10. Geçişi yap, sonra izlemeye devam et

Geçiş, cutover’da bitmez. İçerik ekibi seni aramadan birkaç gerçek şey yayımladığında biter. Yönlendirmeleri izle, 404 loglarını izle, editörleri izle. İşte o zaman tamamlanmıştır.

Neyi bırakırsan bırak doğru olan şeyler

• Bileşenler ve page-builder blokları her zaman en zor kısımdır ve her zaman en çok küçümsenendir. Bunlar için açıkça bütçe ayır.
• Referanslar her zaman iki geçiş ister. Her zaman.
• Zengin metin her zaman gömülü, sisteme özel token’lar saklar — medya, iç bağlantılar, makrolar. Serialize etmeden önce onları envanterle.
• Sunum katmanı asla taşınmaz. Şablonlar, mizanpajlar, render’lar, view’lar — içeriği düzenleyen makine, içerik değil koddur. Onu yeniden inşa etmeyi planla.
• Parolalar asla taşınmaz. Sıfırlamaya göre planla.
• Eski sistemdeki iş mantığı içerikle birlikte gelmez. Hook’lar, yaşam döngüsü işleyicileri, workflow — envanterle ve yeniden uygula.
• Özel bir arayüz, ikinci bir proje demektir. Bir şey eski sistemin API’sini tüketiyorsa, WordPress’e geçmek sözleşmeyi REST ya da WPGraphQL’e değiştirir.

Dürüst kapanışım

Sektörün her yeni platformu bir devrim, her geçişi keşfedilmemiş topraklar gibi ele alışını izledim. İkisi de değil. Araçlar değişir, acı yer değiştirir ama iş, ben veritabanlarını plastik disklerde basarken neyse aynen o: içeriği doğru yere ulaştır, doğru tut, yaşat.

Taşımadan önce modelle. İhtiyacın olmayanı buda. Referanslar için iki geçiş. Medya URL’lerini yeniden yaz. Sunumu yeniden inşa et. Cutover’dan önce yönlendirmeler. Seni sıkana kadar prova. Bunu, herhangi bir kaynak sistemde yap; içerik, sıradan insanların onu yaşatabileceği bir yere iner — ki otuz yıldan ve CD-ROM’dan headless’a her biçimden sonra, bu işin bir kez bile değişmemiş tek kısmı da tam olarak budur.

Son Bir Şey: Peki Eski CMS’inin Yaptığını WordPress’le Yapamaz mısın?

Biri gitmeye karar verir vermez duyduğum itiraz şu: WordPress’e geçersek, eski CMS’imizin asıl iyi olduğu şeylerden vazgeçmek zorunda mıyız? Hayır. Değilsin. Ve The WP Clan olarak WordPress’in hakkını senin önünde yemeyeceğiz — çünkü neyi bırakıyor olursan ol, WordPress onu modelleyebilir ve büyük ihtimalle üstüne bir de fazlasını getirir.

İçeriğin orada hangi biçimi almış olursa olsun — yapılandırılmış türler, derin ilişkiler, zengin taksonomiler, birçok dil — WordPress bunu native olarak modeller. Türler ve alanlar için custom post types ve ACF. İlişkiler için taxonomy’ler. Diller için Multisite, Polylang ya da WPML. Ciddi bir CMS’in tuttuğu şeylerden WordPress’in dürüstçe temsil edemeyeceği pek az şey vardır.

Ve sevdiğin şey headless idiyse — içeriğin API üzerinden dağıtılması — WordPress onu da yapar ve bu işe dün girmedi. REST API 2016 sonundan beri core’un içinde. WPGraphQL da neredeyse o kadar eski; artık Automattic’in arkasında durduğu, WordPress’in kanonikleşme yolundaki GraphQL katmanı. WordPress headless tartışmasını kaybetmedi; yuttu, içine aldı. Next.js, Nuxt ya da Astro arayüzünü koru, arkadaki motoru değiştir, WPGraphQL ile sorgula; arayüzün altındaki CMS’in değiştiğini pek fark etmez bile.

Sonra da saf bir headless SaaS’ın asla vermediğini getirir:

• Gerçek bir ticaret motoru. WooCommerce — elle kurup sonsuza dek bakımını üstlendiğin bir mağaza değil.
• İnsanlar için editoryal güç — yalnızca geliştiriciler için değil: block editor, media library, revizyonlar, roller ve SEO’dan forma, üyeliğe uzanan, hiçbirini sıfırdan yazmadığın bir eklenti ekosistemi.
• Kullanıcı başı ücret yok, kullanım sayacı yok. Yüz editör ekle; fatura kıpırdamaz.
• Sahiplik. Bu serinin bütün argümanı — WordPress’i kimse ayağının altından satın alamaz.

Headless ile WordPress arasında seçim yapmana gerek yok. Eski CMS’inin iyi yaptığı ne varsa, WordPress de yapar — hem de arkasında çok daha büyük bir alet çantasıyla.