WordPress Staging: Hosting'de Üretim Pariteli Demo Site Kurulumu

WordPress güncellemesi, tema değişikliği ya da yeni bir eklenti — hepsini direkt canlı sitede test etmek tek bir yanlış adımda siteyi çökertebilir. Staging ortamı bu riski ortadan kaldırır, ama yanlış kurulmuş bir staging "staging'de çalışır, canlıda çalışmaz" ya da tersine "canlıda çalışır, staging'de çalışmaz" tuzağına düşürür. Bu yazıda WordPress demo sitesini hosting ortamında kurarken yapılan teknik hataları ve gerçek üretim paritesini nasıl sağlayacağınızı adım adım ele alıyoruz.

Staging Yöntemi: Subdomain, Alt Dizin ya da Ayrı Sunucu?

Üç temel seçenek var ve her birinin farklı ödünleşimleri (trade-off) mevcut:

Subdomain yöntemi çoğu senaryo için en dengeli seçenektir. cPanel veya DirectAdmin üzerinden birkaç dakikada oluşturulur; ayrı bir belge kökü (document root) alır ve bu sayede dosya izinleri ile yapılandırma üretimden bağımsız yönetilebilir.

Alt dizin yöntemi hızlı kurulumuyla cazip görünür, ancak .htaccess çakışmaları ve WordPress'in wp-config.php içindeki sabit URL değerleri (hardcoded) nedeniyle sorun üretir. Kısa süreli, acil testler dışında önerilmez.

Ayrı sunucu yöntemi tam parite için en doğru yoldur — özellikle farklı PHP sürümü test edecekseniz ya da yük testleri yapacaksanız. Maliyet, canlı sunucuyu kopyalamanızı gerektirdiğinden yüksektir.

wp-config.php: Staging İçin Zorunlu Değişiklikler

Staging sitesi ayrı bir veritabanına bağlanmalıdır. Canlı veritabanını staging'e bağlamak, gerçek kullanıcı verilerinin test sürecinde bozulma riskini doğurur.

wp-config.php içinde en az şu dört satırı değiştirin:

define('DB_NAME',     'staging_db');
define('DB_USER',     'staging_user');
define('DB_PASSWORD', 'guclu-parola');
define('DB_HOST',     'localhost');

Bunun yanında staging ortamına özel iki tanım ekleyin:

define('WP_DEBUG',     true);
define('WP_DEBUG_LOG', true);

Canlı ortamda WP_DEBUG kapalı olmalıdır; staging'de açık tutmak, eklenti uyarılarını ve PHP hatalarını wp-content/debug.log dosyasına yazar — sorun ayıklamayı (debugging) ciddi ölçüde kolaylaştırır.

Staging URL'sini WordPress'e Bildirin

WordPress, veritabanında iki temel URL saklar: siteurl ve home. Canlı veriyi staging'e kopyaladıktan sonra bu değerleri güncellemeyi unutursanız, sitenin tüm bağlantıları canlıya yönlenir ve staging mantıksal olarak çalışmaz.

wp-config.php içine ekleyin:

define('WP_HOME',    'https://staging.siteniz.com');
define('WP_SITEURL', 'https://staging.siteniz.com');

Bu tanımlar veritabanındaki değerleri geçersiz kılar; veritabanını her sıfırladığınızda manuel güncelleme gerekmez.

Veritabanı Kopyalama ve URL Arama-Değiştirme

Canlı veritabanını staging'e taşırken URL'leri tek tek güncellemek yeterli değildir. WordPress, bazı değerleri serileştirilmiş (serialized) PHP dizileri içinde saklar; standart SQL REPLACE() bu verileri bozar.

WP-CLI kullanımı burada zorunlu hale gelir:

wp search-replace 'https://siteniz.com' 'https://staging.siteniz.com' --all-tables

Bu komut serileştirilmiş verileri doğru şekilde işler. Ardından önbelleği (cache) temizleyin:

wp cache flush
wp rewrite flush

cPanel veya Plesk üzerinden phpMyAdmin ile elle SQL çalıştırıyorsanız, WP Migrate DB eklentisi benzer dönüşümü arayüz üzerinden yapar ve serialization hatalarını önler.

Staging'den E-posta Gönderimini Engelleyin

Bu adım, deneyimli geliştiricilerin bile atladığı kritik bir noktadır. Staging sitesinden gerçek kullanıcılara sipariş onayı, şifre sıfırlama ya da WooCommerce bildirimi gitmesi ciddi bir hata ve güven sorunudur.

Yöntem 1 — mu-plugins ile yönlendirin:

wp-content/mu-plugins/ dizinine şu dosyayı bırakın:

<?php
// wp-content/mu-plugins/disable-email.php
add_filter('wp_mail', function($args) {
    $args['to'] = '[email protected]';
    return $args;
});

Tüm e-postalar tek bir test adresine yönlenir; dışarıya hiçbir şey çıkmaz.

Yöntem 2 — Test SMTP sunucusu kullanın:

FluentSMTP veya WP Mail SMTP eklentisi ile tüm e-postaları Mailtrap gibi bir test SMTP sunucusuna yönlendirin. E-postalar gerçek alıcılara gitmez, web arayüzünden incelenir. WooCommerce yoğun kullanıyorsanız bu yöntem tetikleyici testleri için daha kapsamlıdır.

PHP Sürümü ve Sunucu Kaynak Paritesi

"Staging'de çalışır, canlıda çalışmaz" şikayetinin en sık nedeni PHP sürümü uyumsuzluğudur.

cPanel'de her alan adı için bağımsız PHP sürümü atanabilir: MultiPHP Manager bölümünden canlı ve staging'i aynı sürüme getirin. VDS/VPS kullanıyorsanız ve PHP-FPM yapılandırması (pool) farklıysa, bellek sınırı (memory_limit), yükleme boyutu (upload_max_filesize) ve zaman aşımı (max_execution_time) değerlerini de eşitleyin.

Kontrol etmeniz gereken parametreler:

OPcache'i staging'de kapalı bırakırsanız kod değişikliklerinizi anında görürsünüz; ancak canlıdaki önbellek davranışını test etmiş olmazsınız. İkisi de makul tercih — yalnızca bilinçli seçin.

Hassas Veri: Kullanıcı Bilgilerini Staging'e Taşımayın

KVKK açısından gerçek kullanıcı e-posta adreslerini, telefon numaralarını veya ödeme bilgilerini staging veritabanına kopyalamak ciddi bir uyum sorunudur.

Veriyi aktarmadan önce anonimleştirin. WP-CLI ile:

wp user list --field=ID | xargs -I{} wp user update {} --user_email=kullanici{}@test.example

Bu komut tüm kullanıcı e-postalarını test adresiyle değiştirir. WooCommerce kullanıyorsanız sipariş tablolarındaki (wp_postmeta) kişisel verileri de temizlemeniz gerekir — bunun için WP Scrubber eklentisi kullanışlıdır.

Staging Ortamını Arama Motorlarından Gizleyin

Staging sitesi Google tarafından indekslenirse canlı sitenizde yinelenen içerik (duplicate content) sorunu oluşur ve SEO'nuzu etkiler.

İki katmanlı koruma önerilir:

1. WordPress yönetici panelinden engelleme: Ayarlar → Okuma → "Arama motorlarının bu siteyi dizine eklemesini engelle" seçeneğini işaretleyin. Bu robots.txt'e Disallow: / ekler.

2. HTTP temel kimlik doğrulama (Basic Auth): .htaccess ile staging subdomain'ini şifre korumasına alın — hem bot erişimini engeller hem yetkisiz kullanıcıların staging'e girmesini önler:

AuthType Basic
AuthName "Staging - Yetkili Giris"
AuthUserFile /home/kullanici/.htpasswd
Require valid-user

cPanel'de Directory Privacy bölümü bu yapılandırmayı arayüzden oluşturur; sunucuya SSH girişi gerekmez.

Sonuç: Staging'i Bir Kez Doğru Kur, Defalarca Kullan

Staging ortamı, bir kez doğru kurulduktan sonra her güncelleme öncesinde dakikalar içinde sıfırlanabilir bir test zeminine dönüşür. Kritik adımları özetlemek gerekirse:

• Subdomain yöntemiyle ayrı belge kökü kullanın
• wp-config.php'de URL ve veritabanı değişkenlerini staging'e özel tanımlayın
• WP-CLI search-replace komutuyla URL'leri serialization güvenli şekilde güncelleyin
• E-posta gönderimini mu-plugins veya test SMTP ile engelleyin
• PHP sürümü ve php.ini parametrelerini canlıyla eşitleyin
• Gerçek kullanıcı verilerini anonimleştirin
• Basic Auth ve robots.txt ile arama motorlarından ve yetkisiz erişimden koruyun

Hosting sağlayıcınız cPanel veya Plesk sunuyorsa bu adımların büyük bölümü yönetim panelinden yapılabilir. VDS/VPS kullanıcıları için WP-CLI ve SSH erişimi süreci önemli ölçüde hızlandırır. Staging'in değeri, kurulduktan sonraki ilk "güncelleme canlıyı bozardı" anında kendini kanıtlar.