Optistream, bin adet halka açık sayfasının hiçbirinde SEO kaybı yaşamadan on iki özel WordPress eklentisini tek bir kod tabanında birleştirdi.

Birleşme neden önemliydi

Tipik bir WordPress sitesi birkaç eklentiyle sonuçlanır; daha büyük bir site ise her biri vızıldayan ancak hiçbirinin fişini çekmenin kolay olmadığı, kablolarla dolu bir atölyeye benzer. Optistream'in sitesi; yayıncı profillerini, e-spor takımlarını ve oyun verilerini yöneten on iki özel eklenti çalıştırıyordu. Bu eklentiler bin adet dizine eklenebilir sayfa oluşturuyordu. Bu URL'leri bozulmadan korumak tartışmaya kapalı bir konuydu; yapılacak herhangi bir değişiklik migrasyonu mahvedebilirdi.

Eski kurulum nasıldı

On iki eklentinin her biri kendi klasöründe yaşıyor, kendi özel yazı türünü (custom post type) kaydediyor ve WordPress'e farklı noktalardan bağlanıyordu (hook). Sorunlar birikmeye başladı:

  • Hook'lar ve varlıklar (assets) dağınıktı, bu da hangi kodun ne zaman çalıştığını tahmin etmeyi zorlaştırıyordu.
  • Yönlendirme mantığı birçok ayrı dosyada bulunuyordu, bu nedenle tek bir URL birkaç eklentiden etkilenebiliyordu.
  • CSS dosyaları öngörülemeyen bir sırayla yükleniyor, bu da stil çakışmalarına yol açıyordu.
  • Hata ayıklama (debugging) işlemi on iki farklı dizini açmayı gerektiriyordu, bu da herhangi bir geliştirici için zaman kaybıydı.

Amaç dosya sayısını azaltmak değil; tüm sisteme tek bir yaşam döngüsü ve bağımlılıkları yönetmek için tek bir yer sağlamaktı.

Migrasyon nasıl planlandı

Ekip; halka açık arayüzü (URL'ler, şablonlar ve meta veriler) bozulamaz bir sözleşme olarak ele aldı. Ön yüzde (front end) değişen herhangi bir şey başarısızlık sayılacaktı. Bu kuralı akılda tutarak, her adımdan sonra uygulanacak bir kontrol listesi hazırladılar.

1. Halka açık sözleşmeleri listeleyin

Her URL yolu; yazı türü, yeniden yazma takma adı (rewrite slug), şablon dosyası ve dayandığı meta anahtarlarıyla birlikte not edildi. Bu e-tablo bir kural kitabına dönüştü: Bir modül taşındıktan sonra bir URL değişirse, migrasyon geri alınıyordu.

2. Basit bir yükleyici (loader) oluşturun

Küçük bir bootstrap dosyası oluşturuldu. Eski eklentilerin her biri artık öngörülebilir bir fonksiyon ismi aracılığıyla tek bir "içerik alanı" (content domain) kaydediyor. Yükleyici karmaşık bir şey yapmıyor; sadece ihtiyaç duyulduğunda doğru modülü WordPress'e çekmeye yetecek kadar işlev görüyor. Sadelik, hataları görünür kılar.

3. Veriyi koruyun

Meta anahtarlarını yeniden adlandırmak, bir kod değişikliğini veri migrasyonuna dönüştürerek gereksiz risk oluşturacaktı. Eski anahtarlar dokunulmadan bırakıldı; yeni yardımcı fonksiyonlar bunları sarmalayarak veritabanı şemasını sabit tuttu.

4. CSS sahipliğini düzeltin

Stil çakışmaları üç önlemle çözüldü:

  • Modül CSS dosyaları, en son yüklenecek şekilde yüksek bir öncelikle sıraya ekleniyor (enqueued).
  • Tüm seçiciler (selectors), her modül için benzersiz bir sarmalayıcı sınıfa (wrapper class) sınırlandırıldı (scoped).
  • Bir stil sayfası değiştiğinde tarayıcı önbelleğini temizlemek için sıraya ekleme sırasında filemtime() kullanılıyor.

5. Güvenli bir döngü kullanın

Migrasyon her seferinde tek bir modül olacak şekilde ilerledi. Bir modülü taşıdıktan sonra ekip, bir sonrakine geçmeden önce yazı türü kaydını, yönlendirmeyi ve mobil düzeni doğruladı. Orijinal eklentiler yüklü ancak pasif olarak kaldı, bu da anında geri alma (rollback) imkanı sağladı.

Canlı ortam kontrol listesi

Her modül değişiminden sonra ekip şunları doğruladı:

  • Her içerik türü URL'si 200 HTTP durum kodu döndürüyor.
  • Canonical URL başlığı orijinal URL ile eşleşiyor.
  • Sayfa başlıkları ve meta açıklamaları değişmedi.
  • Tüm görseller bozuk bağlantı olmadan yükleniyor.
  • Mobil ekranlarda yatay taşma (horizontal overflow) görünmüyor.
  • Tarayıcı konsolu sıfır JavaScript veya CSS hatası gösteriyor.

Ancak kontrol listesi tamamlandığında ekip eski eklentiyi kalıcı olarak devre dışı bıraktı.

Yeni eklenti ne sağlıyor

Sonuçta ortaya çıkan tek eklenti kod tabanını küçültmüyor; sadece sınırları görünür kılıyor. On iki işlevsel alanın tamamı artık tek bir yaşam döngüsünü, tek bir hook setini ve bağımlılıkları yönetmek için tek bir yeri paylaşıyor. Yeni eklenti sistemi küçültmedi. Sınırları görünür kıldı. Bu, daha az eklentiye sahip olmaktan daha yararlı olduğunu kanıtladı.

Riskler ve karşı argümanlar

Optistream vakası, disiplinli bir "önce sözleşme" (contract-first) yaklaşımının ve adım adım yaygınlaştırmanın riskleri kontrol altında tutabileceğini gösteriyor.

Bundan sonra nelere dikkat edilmeli

Benzer bir birleştirme düşünüyorsanız, şu iki temel direkle başlayın:

  1. URL kararlılığı – tek bir satır kod yazmadan önce her halka açık yolu haritalandırın.
  2. Veri kararlılığı – tam bir migrasyona hazır değilseniz veritabanı alanlarını yeniden adlandırmaktan kaçının.

Buradan yola çıkarak, küçük bir yükleyici oluşturun, CSS'i sınırlandırın (scoped) ve sıkı bir canlı ortam kontrol listesi uygularken modülleri tek tek taşıyın.