XAMPP Sitesini Canlıya Aktarma: Localhost'tan Hostinge Taşıma

XAMPP sitesini canlıya aktarma, Türkiye'de web geliştirmeye başlayan hemen herkesin er ya da geç geldiği ilk gerçek eşiktir. Aylarca localhost/proje adresinde sorunsuz çalışan site, hostinge yüklendiği anda ya beyaz ekran verir, ya Türkçe karakterler soru işaretine döner, ya da "veritabanına bağlanılamadı" der. Bunun sebebi kodunuzun kötü olması değil; XAMPP'ın size sunduğu ortamın gerçek bir sunucudan birkaç önemli noktada ayrılmasıdır — kullanıcı yetkileri, karakter seti, dosya adı duyarlılığı ve hata görünürlüğü.

Bu yazıda localhost'taki bir projeyi dosya, veritabanı ve bağlantı ayarları dahil uçtan uca canlıya taşıyacağız. Sıra şu: taşınacakların envanteri, dosyaların doğru şekilde toplanması, veritabanının doğru karakter setiyle dışa aktarılması, sunucuda veritabanı ve kullanıcı oluşturma, bağlantı ayarlarının güncellenmesi ve adreslerin düzeltilmesi. Ardından XAMPP'a özgü altı tuzağı tek tek açacağım — root/şifresiz MySQL kullanıcısının sunucuda karşılığı olmaması, latin1 ile utf8mb4 farkı, Linux'un büyük-küçük harf duyarlılığı, port numaraları, display_errors kapalıyken gelen beyaz ekran ve mail() fonksiyonunun davranışı. Türkçe kaynakların büyük kısmı bunun tersini, yani "XAMPP'a WordPress kurulumu"nu anlatır; canlıya çıkış tarafı boş kalmıştır.

Taşımadan Önce: Neyi Taşıyorsunuz#

Bir XAMPP projesi üç parçadan oluşur ve üçü de ayrı ayrı taşınır. Bu ayrımı baştan netleştirmek, sonradan "veritabanını da almam gerekiyormuş" tipi kayıpları önler.

Önce projede kullanılan veritabanı adını, kullanıcı adını ve tablo önekini not edin. WordPress'te bunlar wp-config.php içindedir; özel bir PHP projesinde genelde config.php, db.php ya da .env dosyasındadır. Nerede olduğunu bulamıyorsanız veritabanı bilgileri nereden bulunur yazısı hangi sistemde hangi dosyaya bakılacağını listeler.

İkinci not: projede mutlak yol kullanan bir kod var mı? C:/xampp/htdocs/proje/uploads/ gibi bir satır varsa, canlı sunucuda kesinlikle çalışmaz. Bunları taşımadan önce __DIR__ veya $_SERVER['DOCUMENT_ROOT'] tabanlı göreli yollara çevirin; sonradan aramak çok daha zordur.

Adım 1: Dosyaları Toplama ve Yükleme#

Dosyaları tek tek FTP ile yüklemek, binlerce küçük dosyalı bir projede hem çok yavaş hem de yarım kalmaya açıktır. Doğru yöntem sıkıştırıp tek dosya olarak yüklemektir.

1. C:\xampp\htdocs\projeadi klasörüne girin.
2. İçindeki her şeyi seçip zip yapın — klasörün kendisini değil, içindekileri. Aksi hâlde sunucuda site siteniz.com/projeadi/ altında kalır.
3. Zip dosyasını FTP veya cPanel Dosya Yöneticisi ile public_html dizinine yükleyin.
4. cPanel Dosya Yöneticisi'nde dosyaya sağ tıklayıp Extract deyin.
5. Zip dosyasını çıkarma bittikten sonra silin. Sunucuda duran bir site arşivi, adresini tahmin eden herkes tarafından indirilebilir.

Gizli dosyalara özellikle dikkat edin. .htaccess, .env ve .user.ini nokta ile başladığı için hem Windows'ta hem FTP istemcilerinde varsayılan olarak görünmez. Zip yaparken Windows Gezgini'nde Gizli öğeler kutusunu işaretleyin; FileZilla kullanıyorsanız Sunucu → Gizli dosyaları göstermeye zorla seçeneğini açın. .htaccess atlanırsa WordPress'te güzel bağlantılar çalışmaz ve pek çok yönlendirme kaybolur.

Yükleme bittiğinde dosya sayısını karşılaştırın. Sunucuda SSH erişiminiz varsa:

find public_html -type f | wc -l

Bu sayıyı Windows tarafında klasör özelliklerinde gördüğünüz dosya sayısıyla karşılaştırın. Ciddi bir fark varsa çıkarma işlemi yarım kalmıştır. Statik bir HTML projesi taşıyorsanız süreç burada büyük ölçüde biter; ayrıntılar için HTML sitesi hostinge yükleme yazısına bakabilirsiniz.

Adım 2: Veritabanını Doğru Karakter Setiyle Dışa Aktarma#

Burada Türkçe siteleri en çok yakan tuzak var. XAMPP'ın varsayılan MySQL yapılandırması geleneksel olarak latin1 eğilimlidir; canlı sunucular ise utf8mb4 kullanır. Dışa aktarma sırasında karakter seti doğru belirtilmezse Türkçe karakterler sunucuda ü, ÅŸ, ı gibi bozuk dizilere dönüşür ve bu, içe aktardıktan sonra düzeltilmesi çok zahmetli bir hasardır.

Önce yereldeki gerçek durumu öğrenin. phpMyAdmin'de SQL sekmesine geçip şunu çalıştırın:

SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'veritabani_adiniz';

Sonuçta utf8mb4_unicode_ci görüyorsanız işiniz kolay. latin1_swedish_ci görüyor ama site yerelde düzgün görünüyorsa, veriniz aslında UTF-8 ama latin1 kabıyla saklanıyor demektir — bu duruma "çift kodlama" denir ve dışa aktarma yöntemi buna göre değişir.

Doğru dışa aktarma (phpMyAdmin): Veritabanını seçin → Dışa Aktar → Özel yöntemi seçin → Biçim SQL → Karakter kümesi olarak utf-8 seçin → Sıkıştırma olarak zip seçip indirin. Varsayılan "Hızlı" seçeneği bu ayarları göstermez; bu yüzden mutlaka Özel'i seçin.

Komut satırını tercih ediyorsanız XAMPP'ın kendi mysqldump aracı çok daha güvenilir sonuç verir:

C:\xampp\mysql\bin\mysqldump.exe -u root -p --default-character-set=utf8mb4 --single-transaction veritabani_adi > C:\yedek.sql

--default-character-set=utf8mb4 parametresi burada isteğe bağlı değil; bunu yazmadığınızda dump sunucunun varsayılanıyla alınır ve bozulma tam olarak orada başlar. Dosya oluştuktan sonra bir metin editöründe açıp Türkçe karakterlerin düzgün göründüğünü gözle doğrulayın — dump içinde bozuksa içe aktarınca da bozuk olur, sunucuyu suçlamayın.

Dışa aktarma ve içe aktarma ekranlarının tamamı için phpMyAdmin içe/dışa aktarma yazısına bakabilirsiniz.

Adım 3: Sunucuda Veritabanı ve Kullanıcı Oluşturma#

XAMPP'ta MySQL'e root kullanıcısıyla ve çoğu zaman şifresiz bağlanırsınız. Canlı sunucuda böyle bir şey yoktur ve olmamalıdır: paylaşımlı hostingte root erişimi verilmez, kendi sunucunuzda ise root'u web uygulamasına vermek doğrudan bir güvenlik açığıdır. Bu yüzden ilk iş, projeye özel bir veritabanı ve kullanıcı oluşturmaktır.

cPanel'de sıra şudur:

1. MySQL® Veritabanları ekranını açın.
2. Yeni veritabanı adı yazıp Veritabanı Oluştur deyin. Panel adın başına hesap adınızı ekler: kullanici_proje.
3. Aynı sayfada aşağı inip yeni bir MySQL kullanıcısı oluşturun; güçlü bir parola üretin ve bir yere kaydedin.
4. Kullanıcıyı Veritabanına Ekle bölümünde kullanıcıyı veritabanıyla eşleştirin.
5. Yetki ekranında ALL PRIVILEGES işaretleyip kaydedin.

Buradaki en kritik ayrıntı isim önekidir. Yerelde veritabanı adınız proje iken sunucuda kullanici_proje olur; kullanıcı adı da aynı şekilde önek alır. Bağlantı dosyasına yazarken öneki dahil tam adı yazmanız gerekir, aksi hâlde "Access denied for user" hatası alırsınız.

Şimdi dump dosyasını içe aktarın: phpMyAdmin'de yeni veritabanını seçin → İçe Aktar → dosyayı seçin → Karakter kümesi olarak utf-8 seçili olduğundan emin olun → Başlat. Dosya büyükse (tipik olarak 50 MB üzeri) phpMyAdmin yükleme sınırına takılır; o durumda dosyayı SSH üzerinden aktarmak veya parçalara bölmek gerekir. Bu senaryonun tüm seçenekleri büyük SQL dosyası nasıl yüklenir yazısında ele alınıyor.

SSH erişiminiz varsa içe aktarma en temiz şekilde şöyle yapılır:

mysql -u kullanici_dbuser -p --default-character-set=utf8mb4 kullanici_proje < yedek.sql

Adım 4: Bağlantı Ayarlarını Güncelleme#

Veritabanı yerinde ama site hâlâ yerel bilgilerle bağlanmaya çalışıyor. Şimdi bağlantı dosyasını düzeltiyoruz. WordPress'te wp-config.php:

define('DB_NAME',     'kullanici_proje');
define('DB_USER',     'kullanici_dbuser');
define('DB_PASSWORD', 'buraya-guclu-parola');
define('DB_HOST',     'localhost');
define('DB_CHARSET',  'utf8mb4');
define('DB_COLLATE',  '');

DB_HOST değerinin localhost kalması çoğu paylaşımlı hostingte doğrudur; veritabanı sunucusu ayrıysa hosting paneli size gerçek host adını verir. DB_CHARSET mutlaka utf8mb4 olmalı, DB_COLLATE boş bırakılmalıdır.

Özel yazılmış bir PHP projesinde aynı değerler config.php veya .env içindedir:

$db_host = 'localhost';
$db_name = 'kullanici_proje';
$db_user = 'kullanici_dbuser';
$db_pass = 'buraya-guclu-parola';
$pdo = new PDO("mysql:host=$db_host;dbname=$db_name;charset=utf8mb4", $db_user, $db_pass);

Bağlantı dizesindeki charset=utf8mb4 kısmını atlamayın: veritabanı utf8mb4 olsa bile bağlantı latin1 ile kurulursa PHP verileri yanlış yorumlar ve Türkçe karakterler ekranda bozuk çıkar — veritabanı içinde ise gayet düzgün durur. Bu, "phpMyAdmin'de doğru görünüyor ama sitede bozuk" şikâyetinin en yaygın sebebidir ve tamamı WordPress Türkçe karakter sorunu yazısında açıklanıyor.

Son olarak dosya izinlerini düzeltin. Windows'tan gelen dosyalar Linux izinleri taşımaz:

find public_html -type d -exec chmod 755 {} \;
find public_html -type f -exec chmod 644 {} \;
chmod 600 public_html/wp-config.php

Adım 5: Adresleri Güncelleme#

Site artık veritabanına bağlanıyor ama içeride hâlâ http://localhost/proje adresleri var. WordPress'te acil çözüm wp-config.php içine iki satır eklemektir:

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

Bu, siteyi hemen açılır hâle getirir ama yalnızca geçici bir yamadır: yazı içeriklerine, galeri kayıtlarına ve sayfa kurucu verilerine gömülü localhost adresleri yerinde kalır. Kalıcı çözüm için veritabanındaki tüm adresleri serileştirilmiş veriyi bozmadan değiştirmeniz gerekir. Bunun doğru yöntemleri ve neden düz bir SQL replace'in siteyi çökerttiği site taşıma sonrası URL değiştirme yazısında ayrıntılı olarak anlatılıyor. XAMPP'tan gelirken aranacak değerin genelde http://localhost/projeadi biçiminde, port kullandıysanız http://localhost:8080/projeadi biçiminde olduğunu unutmayın.

XAMPP'a Özgü Altı Tuzak#

1. Root ve şifresiz MySQL kullanıcısı. Yerelde root / boş parola ile çalışan kod, sunucuda hiçbir zaman çalışmaz. Projede sabit yazılmış root kullanıcı adı arayın: grep -r "'root'" . komutu bunları bulur. Bazı eski projeler bağlantı bilgilerini birden fazla dosyada tekrarlar; hepsini güncellemeniz gerekir.

2. Büyük-küçük harf duyarlılığı. Windows'ta include 'Header.php'; satırı header.php dosyasını da bulur; Linux'ta bulmaz ve fatal hata verir. Taşıma sonrası "yerelde çalışıyordu" diyen kırık include/require satırlarının neredeyse tamamı budur. Aynı sorun görsel adlarında da çıkar: Logo.PNG ile logo.png Linux'ta iki ayrı dosyadır. Alışkanlık olarak tüm dosya adlarını küçük harf, boşluksuz ve Türkçe karaktersiz tutun.

3. Port numaraları. XAMPP'ta Apache sık sık 8080, MySQL bazen 3307 portunda çalışır ve bu değerler kodun içine sızmış olabilir. Sunucuda web trafiği 80/443, MySQL ise 3306 üzerindedir. Kodda :8080 veya port=3307 geçen her yeri temizleyin.

4. Karakter seti farkı. Yukarıda ayrıntılı işlendi; özet kural şudur: dışa aktarırken utf8mb4, içe aktarırken utf8, bağlantı dizesinde utf8mb4. Üçünden biri eksikse Türkçe karakterler bozulur.

5. display_errors kapalıdır. XAMPP hataları ekrana basar, canlı sunucular basmaz — bu yüzden yereldeki bir "uyarı" sunucuda beyaz ekran olarak görünür. Hata gerçekten yok değil, sadece gizlenmiştir. Bunun nasıl görünür kılınacağı bir sonraki bölümde.

6. mail() fonksiyonu. XAMPP'ta e-posta genelde hiç gitmez, bu yüzden yerelde e-posta kodunuz test edilmemiştir. Canlı sunucuda mail() çalışabilir ama gönderilen postalar büyük olasılıkla spam klasörüne düşer. Site e-postası gönderiyorsa SMTP kullanmak neredeyse zorunludur; WordPress'te bir SMTP eklentisi, özel projede PHPMailer bunu çözer.

Beyaz Ekran Geldiyse: Hatayı Görünür Yapın#

Site açıldı ve bomboş bir sayfa geldiyse tahmin yürütmeyin, hatayı okuyun. İki yol var ve ikisi de bir dakikanızı alır.

Birincisi, sunucunun hata günlüğüne bakmaktır. cPanel'de Ölçümler → Hatalar ekranı son PHP hatalarını gösterir; SSH'ınız varsa:

tail -n 50 ~/logs/error_log

İkincisi, hataları geçici olarak ekrana açmaktır. WordPress'te wp-config.php içinde:

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

Bu yapılandırma hatayı ziyaretçiye göstermeden wp-content/debug.log dosyasına yazar — canlı sitede doğru olan budur. Özel bir PHP projesinde aynı işi dosyanın en üstüne geçici olarak eklenen şu satırlar yapar:

ini_set('display_errors', 1);
error_reporting(E_ALL);

Sorunu bulduktan sonra bu satırları mutlaka kaldırın. Açık bırakılan hata çıktısı, dosya yollarını ve bazen veritabanı bilgilerini ziyaretçiye gösterir. Hata raporlama seçeneklerinin tamamı PHP hata raporlama yazısında, WordPress'e özel beyaz ekran senaryoları ise WordPress beyaz ekran hatası yazısında ele alınıyor.

En sık gördüğüm üç hata ve karşılıkları şöyledir:

Son satır özellikle önemlidir: XAMPP pek çok PHP eklentisini açık gelir, paylaşımlı hostingte ise bazıları kapalı olabilir. cPanel'de Select PHP Version → Extensions ekranından mbstring, intl, gd, zip gibi eklentileri açabilirsiniz.

Yayına Almadan Önce Son Kontroller#

1. Ana sayfa, bir iç sayfa ve bir form sayfasını tek tek açın.
2. Bir görsel yükleyip yüklenenler klasörünün yazılabilir olduğunu doğrulayın.
3. Türkçe karakterleri hem sitede hem panelde kontrol edin.
4. İletişim formunu doldurup e-postanın gerçekten geldiğini test edin.
5. Yönetici parolasını değiştirin — yerelde kullandığınız admin/123456 gibi bir parola canlıda birkaç saat içinde denenir.
6. Test dosyalarını silin: test.php, info.php, phpinfo.php, yedek.sql ve yüklediğiniz zip dosyası sunucuda kalmamalıdır.
7. SSL sertifikasını etkinleştirip siteyi HTTPS'e yönlendirin.
8. Yeni sitenin ilk yedeğini alın.

phpinfo.php maddesini özellikle vurguluyorum: bu dosya sunucunun tüm yapılandırmasını, dosya yollarını ve yüklü eklentileri herkese açık şekilde yayımlar ve otomatik tarayıcıların ilk aradığı dosyalardan biridir.

Sıkça Sorulan Sorular#

XAMPP sitesini canlıya almak için ne gerekiyor#

Üç şey gerekir: bir hosting hesabı, bir alan adı ve projenizin iki parçası — dosyalar ile veritabanı. Dosyaları htdocs klasöründen sıkıştırıp public_html dizinine yükler, veritabanını phpMyAdmin'den dışa aktarıp sunucuda oluşturduğunuz yeni veritabanına içe aktarırsınız. Ardından bağlantı ayarlarını sunucudaki yeni veritabanı adı, kullanıcı ve parola ile güncellemeniz gerekir. Statik bir HTML projesinde veritabanı adımı hiç yoktur.

Localhost'ta çalışan site sunucuda neden beyaz ekran veriyor#

Çünkü XAMPP hataları ekrana basacak şekilde ayarlıdır, canlı sunucular ise güvenlik nedeniyle basmaz. Yerelde uyarı olarak geçiştirilen bir hata sunucuda ölümcül hata hâline gelir ve ekrana hiçbir şey yazılmadığı için sayfa bomboş görünür. Çözüm hatayı görünür kılmaktır: sunucunun hata günlüğüne bakın ya da hata raporlamayı geçici olarak açıp mesajı okuyun. Bu hataların büyük çoğunluğu eksik PHP eklentisi, büyük-küçük harf farkı veya bellek sınırıdır.

Türkçe karakterler neden bozuk geliyor#

Bu neredeyse her zaman karakter seti uyuşmazlığından kaynaklanır. Veritabanını dışa aktarırken utf8mb4 belirtmediyseniz, içe aktarırken karakter kümesini yanlış seçtiyseniz ya da PHP bağlantı dizesinde charset=utf8mb4 yoksa Türkçe harfler bozuk dizilere dönüşür. En sık görülen belirti, verinin phpMyAdmin'de düzgün ama sitede bozuk görünmesidir; bu, veritabanının değil bağlantının yanlış karakter setiyle kurulduğunu gösterir.

Veritabanı adı neden sunucuda farklı oluyor#

Çünkü paylaşımlı hosting panelleri, farklı hesapların veritabanı adlarının çakışmaması için adın başına hesap kullanıcı adınızı ekler. Yerelde proje olan veritabanı sunucuda kullanici_proje hâline gelir; aynı kural MySQL kullanıcı adı için de geçerlidir. Bağlantı dosyasına öneksiz adı yazarsanız "Unknown database" veya "Access denied" hatası alırsınız. Doğru adı her zaman panelin veritabanı listesinden kopyalayın.

Dosyaları FTP ile tek tek yüklemek yerine ne yapmalıyım#

Klasörün içeriğini zip yapıp tek dosya olarak yükleyin, sonra sunucuda çıkarın. Binlerce küçük dosyayı FTP ile tek tek aktarmak hem saatler sürer hem de bağlantı düştüğünde sessizce eksik kalır; site açılır ama bazı sayfalar veya görseller kayıptır. Zip yöntemi ayrıca dosya sayısını doğrulamayı kolaylaştırır. Çıkarma işleminden sonra zip dosyasını sunucudan silmeyi unutmayın.

Site açıldı ama görseller ve stiller gelmiyor#

Bunun en yaygın sebebi veritabanında hâlâ localhost adreslerinin bulunmasıdır; tarayıcı görselleri sizin bilgisayarınızdan istemeye çalışır ve alamaz. İkinci sebep dosya izinleridir: Windows'tan gelen dosyalar Linux izinleri taşımadığı için görsel klasörleri erişilemez hâle gelebilir. Üçüncü sebep büyük-küçük harf farkıdır. Tarayıcıda F12 ile konsolu açıp hatanın 404 mü 403 mü olduğuna bakmak, üç ihtimalden hangisiyle karşı karşıya olduğunuzu doğrudan söyler.

Taşıma sırasında sitem kesintiye uğrar mı#

XAMPP'tan canlıya çıkışta kesinti kavramı yoktur, çünkü site zaten yayında değildir; yalnızca alan adının hosting hesabına yönlendirilmesi için DNS'in yayılmasını beklersiniz. Bu süre tipik olarak birkaç saat içinde tamamlanır. Bekleme sırasında siteyi test etmek isterseniz bilgisayarınızın hosts dosyasına sunucu IP'sini yazarak yalnızca kendi bilgisayarınızda yeni sunucuya bağlanabilirsiniz.

Yerelde kullandığım PHP sürümü sunucuda da olmalı mı#

Aynı olması şart değil ama uyumlu olması gerekir. XAMPP'ın PHP sürümü sunucudakinden çok eskiyse, yerelde çalışan bazı eski fonksiyonlar sunucuda kaldırılmış olabilir ve fatal hata verir. Yayına almadan önce phpversion() çıktısını iki tarafta karşılaştırın; sunucu tarafında sürümü hosting panelinden seçebilirsiniz. Kodunuzu güncel bir PHP sürümüne uyumlu hâle getirmek uzun vadede hem güvenlik hem performans açısından doğru olanıdır.

Kapanış#

XAMPP sitesini canlıya aktarmak, adımların kendisi zor olduğu için değil, yerel ortamın gerçek sunucudan sessizce ayrıldığı noktalar bilinmediği için zorlaşır. Root kullanıcısı, karakter seti, büyük-küçük harf duyarlılığı, port numaraları, gizlenen hatalar ve çalışmayan mail() — bu altı fark bilinerek gidildiğinde taşıma birkaç saatlik düzenli bir işe dönüşür. Sıraya sadık kalın: önce dosyalar, sonra veritabanı, sonra bağlantı ayarları, en son adres güncellemesi ve güvenlik temizliği.

Projenizi barındıracak yeri henüz seçmediyseniz, PHP sürümü ve eklentileri panelden yönetilebilen bir web hosting paketi bu yazıdaki adımların tamamı için yeterlidir; taşıdığınız site WordPress ise WordPress hosting tarafında sunucu ayarları hazır gelir ve izin, bellek sınırı gibi kalemlerle uğraşmazsınız. Kendi PHP sürümünüzü, eklentilerinizi ve MySQL yapılandırmanızı baştan sona kendiniz belirlemek istiyorsanız VDS sunucu daha uygun bir zemin verir. Aktarımı hiç kendiniz yapmak istemiyorsanız site taşıma hizmeti dosya, veritabanı ve adres güncellemesini birlikte üstlenir.