WordPress Staging Nedir, Test Ortamı Neden Gerekir

Bir eklenti güncellemesi bekliyor, “Şimdi güncelle” düğmesi tek tık uzakta. Çoğu gün sorun çıkmaz; bir gün ise ödeme sayfası boş döner ve bunu ilk fark eden, sipariş veremeyen bir müşteri olur. WordPress staging bu riski canlı siteden alıp bir kopyaya taşır. Test ortamının ne olduğu, hangi değişiklikte gerçekten gerektiği ve kopyadan canlıya aktarırken hangi verinin kaybolabileceği bilinmeden kurulan bir staging, sorunu çözmek yerine yeni bir risk ekler.

WordPress staging nedir, canlı siteden farkı ne

Staging, Türkçe panellerde “hazırlık ortamı” olarak geçer. Canlı sitenin dosyaları ve veritabanı ayrı bir adrese kopyalanır; bu kopya ziyaretçilere ve arama motorlarına kapalı tutulur. Eklenti güncellemesi, tema değişikliği ya da yeni bir özellik önce burada yapılır, test edilir ve ancak sonuç doğruysa canlı siteye aktarılır.

WordPress çekirdeği de bu ayrımı tanır. wp_get_environment_type() dokümanına göre bir kurulum local, development, staging ya da production ortamı olarak işaretlenebilir ve hazırlık ortamı sunan barındırma araçlarından bu değeri “staging” olarak ayarlamaları istenir. Eklentiler bu değere bakarak test kopyasında e-posta göndermeyi ya da dış servislere bağlanmayı kapatabilir.

Canlı sitede güncelleme neden riskli

Riskin dört yaygın kaynağı vardır. Eklenti çakışması: iki eklenti aynı işlevi farklı biçimde tanımladığında güncellemeden sonra ölümcül hata oluşur ve site beyaz ekrana düşer. PHP sürüm yükseltmesi: eski bir eklenti ya da tema yeni PHP sürümünde kaldırılmış bir fonksiyonu çağırıyorsa site açılmaz. Tema güncellemesi: doğrudan tema dosyalarına yapılmış özelleştirmeler güncellemeyle silinir.

Dördüncüsü e-ticarettir. Bir mağaza eklentisinin ana sürüm güncellemesi veritabanı yapısını değiştirebilir; ödeme ya da kargo eklentisi yeni sürümle uyumsuzsa sepet çalışır ama ödeme adımı hata verir. Bu hata çoğu zaman yönetim panelinde görünmez, yalnız satın alma denendiğinde ortaya çıkar. Eklenti seçerken güncelleme sıklığına ve uyumluluğa bakmak için WordPress eklentisi seçim kriterleri yazısı iyi bir başlangıçtır.

Değişiklik türüne göre staging gerekli mi

Her değişiklik için test ortamı açmak zaman kaybıdır. Karar, değişikliğin siteyi açılmaz hâle getirme ya da veri yapısını değiştirme ihtimaline göre verilir.

WordPress çekirdeğinin küçük bakım sürümleri genellikle güvenlik ve hata düzeltmesi içerir ve yedekle birlikte doğrudan uygulanabilir. Ana sürüm geçişlerinde ise eklentilerin yeni sürümle uyumunu test ortamında görmek daha güvenlidir.

Staging’den canlıya aktarımda veritabanı çakışması

Test kopyası alındığı anda canlı siteyle ayrışmaya başlar. Siz kopyada yeni temayı denerken canlıda sipariş gelir, yorum yazılır, üye kaydolur, form doldurulur. Değişiklikleri canlıya alırken veritabanının tamamını aktarırsanız canlıdaki veritabanı kopyadakiyle değiştirilir ve aradaki tüm yeni kayıtlar silinir.

Bu yüzden WordPress staging aktarımında üç güvenli yol vardır. Birincisi yalnız dosyaları aktarmak ve veritabanına dokunan ayarları canlıda elle tekrarlamaktır; tema ve eklenti kodu değişikliklerinde çoğu zaman yeterlidir. İkincisi, aktarım aracınız izin veriyorsa yalnız değiştirdiğiniz tabloları aktarmaktır. Üçüncüsü mağazayı kısa bir bakım moduna alıp canlıdan taze bir kopya çekmek, değişikliği bu kopyada hızla tekrarlamak ve aktarımı sipariş gelmeyen birkaç dakikalık pencerede yapmaktır.

Test ortamında unutulan üç ayar

Birincisi arama motorlarıdır. Test kopyası dizine girerse canlı siteyle aynı içeriği taşıyan ikinci bir adres oluşur. Kopyada “arama motorlarının siteyi dizine eklemesini engelle” ayarını açın ya da adresi parolayla koruyun.

İkincisi e-postadır. Kopyadaki zamanlanmış görevler ve mağaza eklentisi gerçek müşterilere sipariş, hatırlatma ya da bülten e-postası gönderebilir. Test ortamında giden e-postayı kapatın ya da tek bir test adresine yönlendirin. Üçüncüsü ödeme ve dış servislerdir: ödeme altyapısını test moduna alın, kargo ve muhasebe entegrasyonlarının kopyadan gerçek kayıt oluşturmasını engelleyin.

Ne zaman staging şart, ne zaman yedek yeter

Kural basittir: geri dönüşü birkaç dakika süren ve veri kaybı yaratmayan değişikliklerde taze bir yedek yeterlidir. Sitenin açılmamasına, ödeme adımının bozulmasına ya da veri yapısının değişmesine yol açabilecek değişikliklerde WordPress staging gerekir. Az trafikli bir tanıtım sitesinde birkaç dakikalık hata kabul edilebilir; günde onlarca sipariş alan bir mağazada aynı hata doğrudan gelir kaybıdır.

Güncelleme sonrası bir sorun çıkarsa hangi eklentinin sorumlu olduğunu bulmak için sorunlu eklenti tespit rehberindeki adımlar kullanılabilir. Hosting tarafında hangi araçların beklenmesi gerektiği ise WordPress için hosting tercihi rehberinde anlatılıyor.

Narhost’ta WordPress staging ortamı

Narhost paylaşımlı hosting paketlerinde cPanel içinde WP Toolkit Deluxe standart gelir. Hazırlık ortamı bu araçtan açılır: WP Toolkit sitenin aynı içerikle ayrı ve herkese kapalı bir kopyasını oluşturur, değişikliği onayladığınızda canlıya alırsınız. Klonlama, hazırlık ortamı ve canlıya alma adımları WP Toolkit kullanım rehberinde ekran yoluyla anlatılıyor.

PHP yükseltmesini denerken cPanel’deki MultiPHP yöneticisinden sürümün alan adı bazında seçildiğini hatırlayın: hazırlık ortamı ayrı bir alt alan adında açıldıysa yeni sürümü yalnız ona atayıp canlıyı mevcut sürümde bırakabilirsiniz. Test kopyası disk alanı kullandığı için işiniz bittiğinde silmeyi unutmayın.

WordPress staging kontrol listesi

• Değişikliğin türüne bakıp test ortamı gerekip gerekmediğine karar verin.
• Test kopyasını açmadan önce canlı sitenin tam yedeğini alın.
• Kopyayı arama motorlarına kapatın ya da parolayla koruyun.
• Kopyada giden e-postayı ve ödeme altyapısını test moduna alın.
• Değişikliği test ederken sepet, ödeme ve form gönderimini uçtan uca deneyin.
• Aktarımdan hemen önce canlı veritabanının yedeğini yeniden alın.
• Canlıda yeni kayıt oluşuyorsa veritabanının tamamını değil, yalnız dosyaları ya da değişen tabloları aktarın.
• İş bitince test kopyasını silin.