WordPress Taşıma Eklentisiz; Manuel ve Güvenli Rehber

"Error establishing a database connection" hatasını gördünüz mü?

Site eski hostingde çalışıyor, alan adını yeni sunucuya yönlendirdiniz ve şimdi sadece o klasik hatayı gösteren beyaz bir sayfa görüyorsunuz. Ya da daha kötüsü: sayfanın yarısı yükleniyor ve diğer yarısı boş kalıyor, çünkü veritabanındaki absolute yollar hâlâ eski adresi gösteriyor. İşte tam olarak bu anda taşıma eklentileri çalışmaz ve WordPress taşımasını elle yapmanız gerekir.

İyi haber: Bu iş karmaşık değil. Kötü haber: Adımların sırası, adımların kendisinden daha önemlidir. URL değişiminde küçük bir hata, tüm siteyi erişilemez yapar. Bu rehberi sonuna kadar okuyun ve tam olarak aynı sırayla uygulayın.

Ön Koşullar: Neler Gerekli?

Başlamadan önce şu araçları hazırlayın:

• Her iki sunucuya (kaynak ve hedef) SSH erişimi — Sadece cPanel'iniz varsa, WP-CLI ile URL değiştirme bölümünü File Manager'dan da yapabilirsiniz, ancak SSH işi çok daha basitleştirir.
• Hedef sunucuda phpMyAdmin veya MySQL komut satırına erişim.
• DNS'i yeni sunucuya yönlendirilmiş bir alan adı. DNS'i henüz değiştirmediyseniz, resmi taşımadan önce siteyi test etmek için yerel sisteminizdeki /etc/hosts dosyasını kullanabilirsiniz.

PHP ve MySQL sürümlerini de kontrol edin. WordPress 6.4, PHP 7.2 veya üstünü gerektirir, ancak PHP 8.1 veya 8.2 üzerinde çalıştırılması önerilir. Hedef hostingde PHP 5.6 varsa, durun ve önce onu yükseltin.

Adım 1: Dosyaları FTP ile Değil rsync ile Kopyalama

Dosyaları FTP ile taşımak sorunlarla doludur: büyük dosyalarda bağlantının kopması, dosya izinlerinin (permissions) kaybolması ve düşük hız. Hem daha hızlı olan hem de izinleri ve sahipliği koruyan rsync kullanın.

rsync -avz --progress /home/user/public_html/ user@new-server:/var/www/html/

-a bayrağı arşiv modu anlamına gelir ve sembolik bağlantıları, izinleri ve zaman damgalarını korur. -z bayrağı, internet üzerinden aktarım için gerekli olan sıkıştırmayı etkinleştirir. Video gibi büyük dosyalarınız varsa, bağlantı koparsa kaldığı yerden devam etmesi için --partial bayrağını da ekleyin.

Bittikten sonra rsync'i bir kez daha çalıştırın. Bu, yalnızca ilk aktarım sırasında değişen dosyaları aktarır ve son kopyanın kaynakla senkronize olmasını sağlar.

İşte burada hata yaparlar: .htaccess ve .user.ini gibi gizli klasörleri unutmak. FTP kullanıyorsanız, bu dosyaları görmezsiniz ve aktarılmazlar. Sonuç? Site yüklenir ancak permalinkler çalışmaz veya 500 hatası alırsınız. rsync ile bu sorun yoktur çünkü tüm dosyaları aktarır.

Adım 2: mysqldump ile Veritabanı Dökümü

Şimdi sıra veritabanında. Kaynak sunucuda şu komutu çalıştırın:

mysqldump -u username -p --single-transaction --quick --lock-tables=false database_name > database_backup.sql

--single-transaction bayrağı InnoDB tabloları için gereklidir; onsuz dökümünüz tutarsız olabilir ve tabloları yazılırken kopyalayabilir. --quick bayrağı da büyük veritabanları için gereklidir, böylece çıktı bellekte tutulmak yerine doğrudan diske yazılır.

Veritabanınız büyükse (1 GB'den fazla), çıktıyı sıkıştırın:

mysqldump -u username -p --single-transaction database_name | gzip > database_backup.sql.gz

Ardından dosyayı hedef sunucuya aktarın ve orada içe aktarın:

gunzip -c database_backup.sql.gz | mysql -u username -p database_name

Hedef veritabanını henüz oluşturmadıysanız, önce cPanel veya CREATE DATABASE komutuyla oluşturun. Yeni veritabanının kullanıcı adını ve şifresini de not edin; bir sonraki adımda gerekecek.

Adım 3: wp-config.php Dosyasını Düzenleme

Hedef sunucuda wp-config.php dosyasını açın ve şu değerleri yeni veritabanı bilgileriyle değiştirin:

define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'new_database_password' );
define( 'DB_HOST', 'localhost' );

DB_HOST değeri genellikle localhost'dur, ancak bazı hostingler mysql.example.com gibi farklı bir adres kullanır. Bu bilgiyi hostinginizin veritabanı yönetim sayfasından alın.

Güvenlik anahtarlarını (Authentication Unique Keys) da değiştirirseniz daha iyi olur. Bu, tüm kullanıcıların oturumunu kapatır ve eski oturumları geçersiz kılar. Bu anahtarları bu sayfadan alabilirsiniz.

Adım 4: WP-CLI ile URL Değiştirme

Bu en önemli adımdır. Site URL'sini değiştirmezseniz, WordPress yüklenir ancak tüm bağlantılar eski adresi gösterir. Görseller gelmez, menüler bozulur ve siteyi yeni adresten açarsanız eski adrese yönlendirilirsiniz.

Yanlış yöntem: UPDATE wp_options SET option_value = 'new_url' WHERE option_name = 'siteurl' gibi basit bir SQL sorgusu kullanmak. Bu yalnızca iki alanı değiştirir ve wp_posts, wp_postmeta ve wp_options tablolarındaki diğer bağlantılar değişmeden kalır.

Doğru yöntem: WP-CLI. Hedef sunucuya SSH erişiminiz varsa, WordPress kök klasöründen şu komutu çalıştırın:

wp search-replace 'http://old-domain.com' 'http://new-domain.com' --all-tables --precise

--all-tables bayrağı yalnızca varsayılan tabloları değil, tüm WordPress tablolarını kontrol eder. Kendi tablolarına sahip eklentiler (WooCommerce veya Yoast gibi) kurduysanız bu bayrak gereklidir. --precise bayrağı da daha büyük bir kelimenin parçası olan dizelerin yanlış değiştirilmesini önler.

WP-CLI sunucuda kurulu değilse, Search Replace DB scriptini kullanabilirsiniz. Bu scripti kök klasöre yükleyin, tarayıcıdan çalıştırın ve bitirdikten sonra mutlaka silin. Bu dosya sunucuda kalırsa ciddi bir güvenlik açığıdır.

Başka bir alternatif: "Better Search Replace" eklentisini geçici olarak kurun, değiştirmeyi yapın ve ardından eklentiyi silin. Bu yöntem SSH erişimi olmayanlar için çalışır, ancak eklentiyi silmeyi unutmayın.

İşte burada hata yaparlar: http ile https arasındaki farkı unutmak. Önceki site HTTPS ile çalışıyorsa ve yeni site de HTTPS kullanıyorsa, değiştirme dizesi tam olarak https:// içermelidir. Yalnızca http://old-domain.com değerini değiştirirseniz, https:// ile kaydedilmiş bağlantılar değişmeden kalır ve sitenin yarısı bozulur.

Adım 5: Taşıma Sonrası Kontrol Listesi

Dosya ve veritabanı taşıması bitti. Şimdi kontrol zamanı. Bu kontrol listesini sırayla uygulayın:

1. Site ana sayfasını açın. 500 hatası alırsanız, wp-config.php dosyasını kontrol edin ve gerçek hatayı görmek için define( 'WP_DEBUG', true ); ekleyin.
2. Bir yazı ve bir sayfa açın ve permalinklerin doğru çalıştığından emin olun. 404 alırsanız, permalink ayarlarına gidin ve .htaccess dosyasının yeniden yazılması için tekrar kaydedin.
3. Medya kütüphanesinden bir görsel açın ve adresini kontrol edin. Eski alan adını gösteriyorsa, URL değiştirme adımını tekrar yapın.
4. Yeni bir yazı oluşturun ve yayınlayın. Bu, veritabanının yazılabilir olduğundan ve WordPress cron işlerinin doğru çalıştığından emin olmanızı sağlar.
5. İletişim formunu veya başka bir formu test edin. SMTP kullanıyorsa, e-posta ayarlarını da kontrol edin.
6. Siteyi site hız testi ile kontrol edin. TTFB yüksekse, muhtemelen hedef sunucunun önbelleğini etkinleştirmemişsinizdir veya PHP-FPM optimize ayarlara sahip değildir.

Bu kontrollerden sonra her şey doğruysa, DNS'i değiştirin. DNS'i taşımadan önce değiştirdiyseniz ve siteyi yeni adresten test ediyorsanız, yerel DNS önbelleğinizin temizlendiğinden emin olun.

Paylaşımlı Hostingden Özel Linux Hostinge Taşıma

Paylaşımlı hostingden Linux hostinge veya sanal sunucuya taşınıyorsanız, önemli bir fark vardır: dosya sahipliği. Paylaşımlı hostingde dosyalar genellikle size aittir. Sanal sunucuda, dosyaların PHP'nin çalıştığı kullanıcıya (genellikle www-data veya cPanel kullanıcısı) ait olduğundan emin olmalısınız.

chown -R www-data:www-data /var/www/html/

Bunu yapmazsanız, WordPress dosyaları yazamayabilir ve görsel yüklerken veya eklenti kurarken "Permission denied" hatasıyla karşılaşabilirsiniz.

Büyük Veritabanı ile WordPress Taşıma; Az Bilinen Bir İpucu

Veritabanınız 2 GB'den büyükse, standart döküm ve içe aktarma yöntemi timeout hatasıyla karşılaşabilir. Bu durumda, tüm veritabanını dökmek yerine tabloları ayrı ayrı dökün:

mysqldump -u username -p --single-transaction database_name wp_posts wp_postmeta > content_tables.sql

Ardından kalan tabloları ayrı bir dökümde alın. Bu, hataları izole etmenizi sağlar ve bir tabloda sorun varsa yalnızca onu yeniden aktarabilirsiniz.

Sıkça Sorulan Sorular

WordPress'i eklentisiz taşımak güvenli midir?

Evet, adımları doğru sırayla uygularsanız. Ana risk, WP-CLI ve --precise bayrağıyla en aza indirilen URL değişimidir. Taşıma eklentileri bazen haftalar sonra ortaya çıkan gizli hatalar oluşturabilir; manuel taşıma daha şeffaftır.

Taşımadan sonra site eski alan adına yönlendiriliyor. Sorun nedir?

URL değiştirmeyi tam olarak yapmadınız. wp search-replace komutunu tekrar çalıştırın ve hem http:// hem de https:// durumlarını kapsadığınızdan emin olun. Ayrıca tarayıcı önbelleğini ve DNS önbelleğini temizleyin.

WordPress taşımasından sonra 500 hatası; nereden başlamalıyım?

Önce wp-config.php dosyasını kontrol edin ve define( 'WP_DEBUG', true ); ekleyin. Gerçek hatayı göreceksiniz. En yaygın neden, yanlış dosya izinleri veya PHP sürüm uyumsuzluğudur. Hata görüntülenmezse, .htaccess dosyasını geçici olarak silin.

DNS'i değiştirmeden siteyi test edebilir miyim?

Evet. Yerel sisteminizdeki /etc/hosts dosyasını düzenleyin ve yeni sunucunun IP adresini alan adınıza atayın. Bu şekilde yalnızca sizin sisteminizde site yeni alan adıyla yüklenir ve diğer kullanıcılar hâlâ eski hostingi görür.