Kayıt ol

Tovala Akıllı Fırın Deneyimi: Paket Servisten Daha İyi mi?FortiMail'de Kritik Zero-Day Açığı Aktif Saldırılarda Kullanılıyor Meadow: Sosyal Medyasız Minimalist Telefon Deneyimi California'da Gizli Kayıt Yapan Akıllı Gözlük Yasasına Veto Hello Robot Stretch 4, TechCrunch Disrupt 2026'da Canlı Tanıtılacak

JavaScript devre dışı. Daha iyi bir deneyim için, önce lütfen tarayıcınızda JavaScript'i etkinleştirin.

WordPress Staging Nasıl Kurulur? Canlı Siteyi Etkilemeden Değişiklikleri Test Etme

Mesaj: <blockquote data-quote="Admin" data-source="post: 12815" data-attributes="member: 1"><p><h2>WordPress Staging Nasıl Kurulur? Canlı Siteyi Etkilemeden Değişiklikleri Test Etme</h2><p>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.</p><p>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.</p><p>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.</p><h2>WordPress Staging Nedir?</h2><p>Staging, yayın yapan sitenin test amacıyla hazırlanmış kopyasıdır. Genellikle şu adreslerden birinde çalışır:</p><ul> <li data-xf-list-type="ul"><code class="bbCodeInline">test.ornek.com</code></li> <li data-xf-list-type="ul"><code class="bbCodeInline">ornek.com/staging/</code></li> <li data-xf-list-type="ul">Ayrı bir sunucudaki test adresi.</li> </ul><p>Bu kopyada sitenin dosyaları, içerikleri ve ayarları bulunur. Amaç, yapılacak değişikliğin gerçek siteye benzer koşullarda nasıl çalıştığını görmektir.</p><p>Üç ortam arasındaki ayrım şöyledir:</p><table style='width: 100%'><tr><th>Ortam</th><th>Kullanım amacı</th></tr><tr><td>Geliştirme</td><td>Yeni özellikleri ve kodları hazırlamak</td></tr><tr><td>Staging</td><td>Değişiklikleri yayına almadan önce kontrol etmek</td></tr><tr><td>Canlı</td><td>Ziyaretçilerin kullandığı asıl siteyi çalıştırmak</td></tr></table><p></p><p>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.</p><p><strong>Ayrı klasör kullanmak, tek başına tam izolasyon sağlamaz.</strong> Ortak sunucu kaynakları, önbellek servisleri ve harici entegrasyonlar ayrıca değerlendirilmelidir.</p><h2>Hangi Değişiklikler Önce Test Edilmeli?</h2><p>Özellikle sitenin temel işlevlerini etkileyen işlemlerde staging kullanmak faydalıdır:</p><ul> <li data-xf-list-type="ul">WordPress, tema ve eklenti güncellemeleri.</li> <li data-xf-list-type="ul">PHP sürümü değişiklikleri.</li> <li data-xf-list-type="ul">Yeni tema veya sayfa oluşturucu kurulumu.</li> <li data-xf-list-type="ul">Ödeme, kargo ve vergi ayarları.</li> <li data-xf-list-type="ul">Önbellek ve dosya küçültme yapılandırmaları.</li> <li data-xf-list-type="ul">Özel kodlar ve veritabanı değişiklikleri.</li> <li data-xf-list-type="ul">Üyelik, abonelik ve form sistemlerindeki düzenlemeler.</li> </ul><p>Testin kapsamını değişikliğe göre belirleyin. Bir tema güncellemesinde yalnızca ana sayfaya bakmak yeterli olmayabilir; mobil menüyü, ürün sayfalarını ve formları da incelemek gerekir.</p><h2>Kuruluma Başlamadan Önce Hazırlık Yapın</h2><p>Önce canlı sitenin dosya ve veritabanı yedeğini alın. Staging kopyası, bağımsız ve geri yüklenebilir bir yedeğin yerini tutmaz.</p><p>Ardından şu noktaları kontrol edin:</p><ul> <li data-xf-list-type="ul">Kopyalama için yeterli disk alanı bulunuyor mu?</li> <li data-xf-list-type="ul">Test adresinin DNS ve SSL ayarları hazır mı?</li> <li data-xf-list-type="ul">Test ortamına kimler erişebilecek?</li> <li data-xf-list-type="ul">E-posta, ödeme ve diğer entegrasyonlar nasıl sınırlandırılacak?</li> <li data-xf-list-type="ul">Değişiklikler canlıya hangi yöntemle uygulanacak?</li> </ul><p>Test ortamını mümkün olduğunca canlıya benzer hazırlayın. PHP sürümü, PHP eklentileri ve önbellek altyapısı farklıysa testte sorunsuz çalışan bir özellik canlıda hata verebilir.</p><h2>Staging Kurmak İçin Hangi Yöntem Seçilmeli?</h2> <table style='width: 100%'><tr><th>Yöntem</th><th>Teknik seviye</th><th>Avantajı</th><th>Dikkat edilmesi gereken</th></tr><tr><td>WP Staging eklentisi</td><td>Başlangıç</td><td>WordPress panelinden kopya oluşturma</td><td>Ücretsiz sürümde otomatik canlıya aktarım bulunmaz</td></tr><tr><td>Hosting panelindeki WP Toolkit</td><td>Başlangıç–orta</td><td>Klonlama ve veri kopyalamayı panelden yönetme</td><td>Sağlayıcının sunduğu özellikler kontrol edilmeli</td></tr><tr><td>Manuel klonlama</td><td>İleri</td><td>Dosya, veritabanı ve sunucu ayarlarında kontrol</td><td>Yanlış bağlantı veya aktarım canlı verileri etkileyebilir</td></tr></table><p></p><p>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.</p><h2>Yöntem 1: WP Staging Eklentisiyle Test Sitesi Oluşturma</h2><p>WordPress panelinden işlem yapmak isteyenler için WP Staging kullanılabilir.</p><ol> <li data-xf-list-type="ol"><strong>Eklentiler → Yeni Ekle</strong> bölümünde WP Staging’i bulun.</li> <li data-xf-list-type="ol">Eklentiyi kurup etkinleştirin.</li> <li data-xf-list-type="ol">Staging siteleri ekranından yeni bir kopya oluşturun.</li> <li data-xf-list-type="ol">Test ortamına <code class="bbCodeInline">staging</code> gibi bir isim verin.</li> <li data-xf-list-type="ol">Kopyalanacak dosya ve tabloları inceleyin.</li> <li data-xf-list-type="ol">Klonlamayı başlatın ve tamamlandığında test adresini açın.</li> </ol><p>Ücretsiz sürüm, alt klasörde test kopyası oluşturmayı destekler. Varsayılan klonlama, mevcut veritabanında farklı öneklerle yeni tablolar oluşturabilir. Ayrı veritabanına klonlama gibi seçenekler Pro özellikleri arasındadır. Bu ayrım, yedekleme ve veritabanı işlemlerinde önemlidir.</p><p>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.</p><p><strong>Ücretsiz sürümde test yapmak ile değişiklikleri tek tıkla canlıya göndermek farklı özelliklerdir.</strong> Otomatik “Push to Live” işlemi Pro sürüm kapsamında sunulur.</p><h2>Yöntem 2: cPanel WP Toolkit ile Klonlama</h2><p>Hosting hesabınızda WP Toolkit ve klonlama özelliği sunuluyorsa işlemi panel üzerinden yapabilirsiniz.</p><ol> <li data-xf-list-type="ol">cPanel’de <strong>WP Toolkit</strong> bölümünü açın.</li> <li data-xf-list-type="ol">Kopyalamak istediğiniz WordPress kurulumunu seçin.</li> <li data-xf-list-type="ol"><strong>Clone / Klonla</strong> düğmesine tıklayın.</li> <li data-xf-list-type="ol">Test alan adını veya hedef klasörü belirleyin.</li> <li data-xf-list-type="ol">Hedef ayarlarını kontrol ederek işlemi başlatın.</li> </ol><p>Bu işlem için canlı sitenin bulunduğu hedefi seçmediğinizden emin olun. Klonlama tamamlandıktan sonra test adresini, veritabanı bağlantısını ve yönetim panelini kontrol edin.</p><p>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.</p><p>WP Toolkit’in <strong>Copy Data / Veriyi Kopyala</strong> ö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.</p><h2>Yöntem 3: Manuel Staging Kurulumu</h2><p>Manuel yöntemde test sitesini ayrı bir WordPress kurulumu gibi hazırlarsınız.</p><h3>Test adresini ve klasörünü oluşturun</h3><p>Hosting panelinizde <code class="bbCodeInline">test.ornek.com</code> 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.</p><p>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.</p><h3>Dosyaları kopyalayın</h3><p>Canlı sitenin WordPress dosyalarını test klasörüne <strong>kopyalayın</strong>. Canlı klasördeki dosyaları taşımayın veya silmeyin.</p><p>Kopyalanan <code class="bbCodeInline">.htaccess</code> ve sunucu kurallarını inceleyin. Canlı alan adına zorlayan bir yönlendirme, test adresini sürekli asıl siteye gönderebilir.</p><h3>Ayrı veritabanı hazırlayın</h3><p>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.</p><p>Test klasöründeki <code class="bbCodeInline">wp-config.php</code> dosyasına test veritabanının bilgilerini yazın.</p><p><strong>Adres değiştirme işleminden önce bağlantının canlı veritabanını göstermediğini doğrulayın.</strong></p><h3>Site adreslerini güncelleyin</h3><p>Kopyadaki canlı site adreslerini test adresiyle değiştirin. <code class="bbCodeInline">home</code>, <code class="bbCodeInline">siteurl</code> ve varsa <code class="bbCodeInline">wp-config.php</code> içindeki sabit adres tanımlarını birlikte değerlendirin.</p><p>WordPress ayrı bir klasöre kurulmuşsa bu adresler farklı olabilir. Mevcut yapıyı incelemeden ikisini aynı değere zorlamayın.</p><h2>Veritabanındaki Adresleri Nasıl Değiştirmelisiniz?</h2><p>WordPress ve eklentiler, bazı ayarları serileştirilmiş veri olarak saklar. Bu biçimde metnin yanında uzunluk bilgisi de bulunur.</p><p>Ham SQL <code class="bbCodeInline">REPLACE()</code> işlemi, adresin uzunluğunu değiştirirken bu bilgiyi güncellemeyebilir. Sonuçta tema ayarları, bileşenler veya eklenti yapılandırmaları bozulabilir.</p><p>Serileştirilmiş veriyi destekleyen bir araç kullanın. WP-CLI ile, <strong>ayrı test veritabanına bağlandığını doğruladığınız manuel kopyada</strong> önce şu denemeyi yapabilirsiniz:</p><p>[CODE]wp --path=/TEST/WORDPRESS/DIZINI search-replace \</p><p>'https://ornek.com' 'https://test.ornek.com' \</p><p>--all-tables-with-prefix --skip-columns=guid --dry-run[/CODE]</p><p>Dizin ve adresleri kendi kurulumunuza göre düzenleyin. <code class="bbCodeInline">--dry-run</code>, değişiklikleri kaydetmeden rapor oluşturur. Sonucu kontrol edip yedek aldıktan sonra aynı komutu bu seçenek olmadan çalıştırabilirsiniz.</p><p><code class="bbCodeInline">--all-tables-with-prefix</code>, ilgili kurulumun tablo önekiyle eşleşen tabloları kapsar. <code class="bbCodeInline">[B]--all-tables[/B]</code><strong> seçeneğini gelişigüzel kullanmayın:</strong> Aynı veritabanındaki başka kurulumların tablolarını da işleme alabilir. Multisite ağlarında kapsam ayrıca planlanmalıdır.</p><h2>Test Ortamını Dışarıya Kapalı Tutun</h2><p>Test sitesinde <strong>Ayarlar → Okuma</strong> 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.</p><p>Ö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.</p><p><code class="bbCodeInline">robots.txt</code> ile taramayı engellemek de tek başına indekslenmeme garantisi sağlamaz. Google’ın <code class="bbCodeInline">noindex</code> talimatını görebilmesi için ilgili içeriği tarayabilmesi gerekir. Gizlilik için esas önlem erişim kontrolüdür.</p><p>Test kopyasında ayrıca şunları düzenleyin:</p><ul> <li data-xf-list-type="ul">Ödeme sistemlerini sandbox moduna alın.</li> <li data-xf-list-type="ul">Gerçek müşterilere giden e-postaları engelleyin veya test posta kutusuna yönlendirin.</li> <li data-xf-list-type="ul">SMS, webhook ve otomatik yayın bağlantılarını kontrol edin.</li> <li data-xf-list-type="ul">CRM, stok ve muhasebe servisleri için test bağlantıları kullanın.</li> <li data-xf-list-type="ul">Zamanlanmış görevlerin gerçek sistemlerde işlem yapmasını önleyin.</li> </ul><p>WooCommerce test siparişleri de e-posta tetikleyebilir. Test ödemesi kullanmak, bütün yan etkilerin otomatik kapandığı anlamına gelmez.</p><h2>Değişiklikleri Canlıya Taşırken Verileri Koruyun</h2><p>Canlıya aktarımda önemli bir risk, test kopyasının eski verilerini güncel sitenin üzerine yazmaktır.</p><p>Ö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.</p><p>Bu yüzden değişiklik türüne göre hareket edin:</p><table style='width: 100%'><tr><th>Değişiklik</th><th>Uygulanabilecek yaklaşım</th></tr><tr><td>Tema dosyasında CSS düzenlemesi</td><td>İlgili dosyaları yayınlamak</td></tr><tr><td>Eklenti güncellemesi</td><td>Test edilen sürümü canlıda uygulamak</td></tr><tr><td>Sayfa oluşturucuyla tasarım</td><td>İlgili içerik ve ayarları kontrollü aktarmak</td></tr><tr><td>Site ayarı değişikliği</td><td>Gerekli ayarı canlıda uygulamak veya seçerek taşımak</td></tr><tr><td>Veritabanı yapısı değişikliği</td><td>Planlı geçiş ve geri dönüş süreci hazırlamak</td></tr></table><p></p><p>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.</p><p>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ış <code class="bbCodeInline">noindex</code>, test ödeme modu veya erişim kısıtlaması kalmadığını doğrulayın.</p><h2>Sıkça Sorulan Sorular</h2><h3>Staging canlı siteyi hiç etkileyemez mi?</h3><p>Doğru ayrılmış dosya ve veriler, test değişikliklerinin doğrudan canlıya uygulanmasını önler. Ancak aynı hosting kaynakları veya ortak dış servisler kullanılıyorsa etki oluşabilir. Ağır testler canlı siteyi yavaşlatabilir; yanlış entegrasyonlar gerçek işlemler tetikleyebilir.</p><h3>Test ortamı aynı sunucuda olmak zorunda mı?</h3><p>Hayır. Aynı sunucu, ayrı sunucu veya yerel bilgisayar kullanılabilir. Önemli olan test koşullarının amaçlanan canlı yapılandırmaya yeterince benzemesidir.</p><h3>Staging ücretsiz kurulabilir mi?</h3><p>WP Staging’in ücretsiz sürümüyle alt klasörde kopya oluşturulabilir. Manuel kurulumda ayrıca bir staging yazılımı satın almak gerekmez; ancak hosting kaynakları ve bazı gelişmiş araçlar maliyet oluşturabilir.</p><h3>Testte sorunsuz çalışan güncelleme canlıda kesin çalışır mı?</h3><p>Kesinlik sağlamaz. Trafik, sunucu ayarları, önbellek ve entegrasyon farklılıkları sonucu değiştirebilir. Staging riski azaltır; canlıdaki son kontrollerin ve yedeğin yerini tutmaz.</p><h3>Test sitesini ne sıklıkla yenilemeliyim?</h3><p>Yeni bir çalışma başlamadan önce canlı sitenin güncel kopyasını almak faydalıdır. Ancak bu işlem staging’deki mevcut çalışmaların üzerine yazabileceği için önce tamamlanmamış değişiklikleri koruyun.</p><h3>Kullanılmayan staging kopyası silinmeli mi?</h3><p>Evet. İş bitince gereksiz dosyaları, veritabanlarını ve erişim bilgilerini kaldırın. Kalıcı bir test ortamı tutacaksanız güncellemelerini ve erişim korumasını düzenli kontrol edin.</p></blockquote><p></p>