Puan
18
Çözümler
0
- Katılım
- 3 Kas 2025
- Mesajlar
- 99
- Tepkime puanı
- 0
WordPress Staging Nasıl Kurulur? Canlı Siteyi Etkilemeden Değişiklikleri Test Etme
WordPress’te bir eklentiyi güncellemek birkaç saniye sürebilir. Güncellemenin ardından bozulan ödeme sayfasını, kaybolan tasarımı veya açılmayan yönetim panelini düzeltmek ise çok daha uzun sürer.Staging, değişiklikleri önce sitenizin bir kopyasında denemenizi sağlar. Yeni temayı burada kurabilir, PHP sürümünü değiştirebilir ve eklenti uyumluluğunu kontrol edebilirsiniz. Testler tamamlandıktan sonra değişiklikleri planlı şekilde canlı siteye uygularsınız.
Ancak test ortamı oluşturmak tek başına bütün riskleri ortadan kaldırmaz. Kopyanın canlı verilerden ayrılması, dış servislere yanlışlıkla işlem göndermemesi ve canlıya aktarımın dikkatle yapılması gerekir.
WordPress Staging Nedir?
Staging, yayın yapan sitenin test amacıyla hazırlanmış kopyasıdır. Genellikle şu adreslerden birinde çalışır:test.ornek.comornek.com/staging/- Ayrı bir sunucudaki test adresi.
Üç ortam arasındaki ayrım şöyledir:
| Ortam | Kullanım amacı |
|---|---|
| Geliştirme | Yeni özellikleri ve kodları hazırlamak |
| Staging | Değişiklikleri yayına almadan önce kontrol etmek |
| Canlı | Ziyaretçilerin kullandığı asıl siteyi çalıştırmak |
Test ortamının dosyaları ve verileri canlı siteden ayrılmalıdır. Bunun nasıl sağlandığı kullanılan araca bağlıdır: Bazı çözümler ayrı veritabanı oluştururken bazıları aynı veritabanında farklı tablo önekleri kullanır.
Ayrı klasör kullanmak, tek başına tam izolasyon sağlamaz. Ortak sunucu kaynakları, önbellek servisleri ve harici entegrasyonlar ayrıca değerlendirilmelidir.
Hangi Değişiklikler Önce Test Edilmeli?
Özellikle sitenin temel işlevlerini etkileyen işlemlerde staging kullanmak faydalıdır:- WordPress, tema ve eklenti güncellemeleri.
- PHP sürümü değişiklikleri.
- Yeni tema veya sayfa oluşturucu kurulumu.
- Ödeme, kargo ve vergi ayarları.
- Önbellek ve dosya küçültme yapılandırmaları.
- Özel kodlar ve veritabanı değişiklikleri.
- Üyelik, abonelik ve form sistemlerindeki düzenlemeler.
Kuruluma Başlamadan Önce Hazırlık Yapın
Önce canlı sitenin dosya ve veritabanı yedeğini alın. Staging kopyası, bağımsız ve geri yüklenebilir bir yedeğin yerini tutmaz.Ardından şu noktaları kontrol edin:
- Kopyalama için yeterli disk alanı bulunuyor mu?
- Test adresinin DNS ve SSL ayarları hazır mı?
- Test ortamına kimler erişebilecek?
- E-posta, ödeme ve diğer entegrasyonlar nasıl sınırlandırılacak?
- Değişiklikler canlıya hangi yöntemle uygulanacak?
Staging Kurmak İçin Hangi Yöntem Seçilmeli?
| Yöntem | Teknik seviye | Avantajı | Dikkat edilmesi gereken |
|---|---|---|---|
| WP Staging eklentisi | Başlangıç | WordPress panelinden kopya oluşturma | Ücretsiz sürümde otomatik canlıya aktarım bulunmaz |
| Hosting panelindeki WP Toolkit | Başlangıç–orta | Klonlama ve veri kopyalamayı panelden yönetme | Sağlayıcının sunduğu özellikler kontrol edilmeli |
| Manuel klonlama | İleri | Dosya, veritabanı ve sunucu ayarlarında kontrol | Yanlış bağlantı veya aktarım canlı verileri etkileyebilir |
Seçimi yalnızca kurulum kolaylığına göre yapmayın. Test bittikten sonra değişiklikleri nasıl yayınlayacağınız da önemlidir.
Yöntem 1: WP Staging Eklentisiyle Test Sitesi Oluşturma
WordPress panelinden işlem yapmak isteyenler için WP Staging kullanılabilir.- Eklentiler → Yeni Ekle bölümünde WP Staging’i bulun.
- Eklentiyi kurup etkinleştirin.
- Staging siteleri ekranından yeni bir kopya oluşturun.
- Test ortamına
staginggibi bir isim verin. - Kopyalanacak dosya ve tabloları inceleyin.
- Klonlamayı başlatın ve tamamlandığında test adresini açın.
Kopyayı oluşturduktan sonra erişim korumasını oturum açmadan kontrol edin. Eklenti, klon için yönetici erişimi ve indeksleme önlemleri sunar; yine de dosyaların ve özel uç noktaların erişimini ayrıca inceleyin.
Ücretsiz sürümde test yapmak ile değişiklikleri tek tıkla canlıya göndermek farklı özelliklerdir. Otomatik “Push to Live” işlemi Pro sürüm kapsamında sunulur.
Yöntem 2: cPanel WP Toolkit ile Klonlama
Hosting hesabınızda WP Toolkit ve klonlama özelliği sunuluyorsa işlemi panel üzerinden yapabilirsiniz.- cPanel’de WP Toolkit bölümünü açın.
- Kopyalamak istediğiniz WordPress kurulumunu seçin.
- Clone / Klonla düğmesine tıklayın.
- Test alan adını veya hedef klasörü belirleyin.
- Hedef ayarlarını kontrol ederek işlemi başlatın.
Test ortamındaki parola korumasını ve arama motoru görünürlüğünü de doğrulayın. Bunların her kurulumda aynı şekilde otomatik ayarlanacağını varsaymayın.
WP Toolkit’in Copy Data / Veriyi Kopyala özelliğiyle dosyalar, veritabanı veya seçili tablolar başka bir kuruluma aktarılabilir. Kaynak ve hedef yönünü dikkatle kontrol edin; mümkünse işlem öncesinde geri dönüş noktası oluşturun.
Yöntem 3: Manuel Staging Kurulumu
Manuel yöntemde test sitesini ayrı bir WordPress kurulumu gibi hazırlarsınız.Test adresini ve klasörünü oluşturun
Hosting panelinizdetest.ornek.com gibi bir alt alan adı tanımlayın. Bu adresi canlı sitenin klasörüne değil, test için oluşturduğunuz ayrı dizine bağlayın.DNS kaydını ve SSL sertifikasını hazırlayın. Mümkünse kopyalama başlamadan önce hedefi parola veya IP kısıtlamasıyla koruyun.
Dosyaları kopyalayın
Canlı sitenin WordPress dosyalarını test klasörüne kopyalayın. Canlı klasördeki dosyaları taşımayın veya silmeyin.Kopyalanan
.htaccess ve sunucu kurallarını inceleyin. Canlı alan adına zorlayan bir yönlendirme, test adresini sürekli asıl siteye gönderebilir.Ayrı veritabanı hazırlayın
Canlı veritabanını dışa aktarın. Test için yeni bir veritabanı ve mümkünse yalnızca bu veritabanına yetkili yeni bir kullanıcı oluşturun. Verileri yeni veritabanına aktarın.Test klasöründeki
wp-config.php dosyasına test veritabanının bilgilerini yazın.Adres değiştirme işleminden önce bağlantının canlı veritabanını göstermediğini doğrulayın.
Site adreslerini güncelleyin
Kopyadaki canlı site adreslerini test adresiyle değiştirin.home, siteurl ve varsa wp-config.php içindeki sabit adres tanımlarını birlikte değerlendirin.WordPress ayrı bir klasöre kurulmuşsa bu adresler farklı olabilir. Mevcut yapıyı incelemeden ikisini aynı değere zorlamayın.
Veritabanındaki Adresleri Nasıl Değiştirmelisiniz?
WordPress ve eklentiler, bazı ayarları serileştirilmiş veri olarak saklar. Bu biçimde metnin yanında uzunluk bilgisi de bulunur.Ham SQL
REPLACE() işlemi, adresin uzunluğunu değiştirirken bu bilgiyi güncellemeyebilir. Sonuçta tema ayarları, bileşenler veya eklenti yapılandırmaları bozulabilir.Serileştirilmiş veriyi destekleyen bir araç kullanın. WP-CLI ile, ayrı test veritabanına bağlandığını doğruladığınız manuel kopyada önce şu denemeyi yapabilirsiniz:
Kod:
wp --path=/TEST/WORDPRESS/DIZINI search-replace \
'https://ornek.com' 'https://test.ornek.com' \
--all-tables-with-prefix --skip-columns=guid --dry-run--dry-run, değişiklikleri kaydetmeden rapor oluşturur. Sonucu kontrol edip yedek aldıktan sonra aynı komutu bu seçenek olmadan çalıştırabilirsiniz.--all-tables-with-prefix, ilgili kurulumun tablo önekiyle eşleşen tabloları kapsar. [B]--all-tables[/B] seçeneğini gelişigüzel kullanmayın: Aynı veritabanındaki başka kurulumların tablolarını da işleme alabilir. Multisite ağlarında kapsam ayrıca planlanmalıdır.Test Ortamını Dışarıya Kapalı Tutun
Test sitesinde Ayarlar → Okuma bölümündeki arama motoru görünürlüğü seçeneğini işaretleyin. Ancak bu ayar ziyaretçilerin erişimini engelleyen bir parola koruması değildir.Özel içerikler ve müşteri verileri bulunan bir kopyada sunucu düzeyinde parola, IP kısıtlaması veya uygun bir erişim kontrolü kullanın.
robots.txt ile taramayı engellemek de tek başına indekslenmeme garantisi sağlamaz. Google’ın noindex talimatını görebilmesi için ilgili içeriği tarayabilmesi gerekir. Gizlilik için esas önlem erişim kontrolüdür.Test kopyasında ayrıca şunları düzenleyin:
- Ödeme sistemlerini sandbox moduna alın.
- Gerçek müşterilere giden e-postaları engelleyin veya test posta kutusuna yönlendirin.
- SMS, webhook ve otomatik yayın bağlantılarını kontrol edin.
- CRM, stok ve muhasebe servisleri için test bağlantıları kullanın.
- Zamanlanmış görevlerin gerçek sistemlerde işlem yapmasını önleyin.
Değişiklikleri Canlıya Taşırken Verileri Koruyun
Canlıya aktarımda önemli bir risk, test kopyasının eski verilerini güncel sitenin üzerine yazmaktır.Örneğin pazartesi oluşturduğunuz staging kopyasında yeni tasarımı hazırlarken canlı mağazaya salı günü siparişler gelebilir. Çarşamba günü staging veritabanını bütünüyle canlıya aktarırsanız bu siparişleri kaybedebilirsiniz.
Bu yüzden değişiklik türüne göre hareket edin:
| Değişiklik | Uygulanabilecek yaklaşım |
|---|---|
| Tema dosyasında CSS düzenlemesi | İlgili dosyaları yayınlamak |
| Eklenti güncellemesi | Test edilen sürümü canlıda uygulamak |
| Sayfa oluşturucuyla tasarım | İlgili içerik ve ayarları kontrollü aktarmak |
| Site ayarı değişikliği | Gerekli ayarı canlıda uygulamak veya seçerek taşımak |
| Veritabanı yapısı değişikliği | Planlı geçiş ve geri dönüş süreci hazırlamak |
Yalnızca dosya aktarımı her değişikliği kapsamaz. Sayfa oluşturucu tasarımları, menüler ve birçok tema ayarı veritabanında tutulur. Seçili tablo aktarımı da otomatik olarak kayıtları birleştirmez; hedef verilerin üzerine yazabilir.
Yayından önce güncel yedek alın. İşlemden sonra formları, giriş ekranını, ödeme akışını ve mobil görünümü kontrol edin. Canlı sitede staging’den taşınmış
noindex, test ödeme modu veya erişim kısıtlaması kalmadığını doğrulayın.