WordPress Güncellerken FTP Bilgisi İstiyor: Nedeni ve Çözümü

Eklenti kurmaya çalışıyorsunuz ve WordPress güncelleme sırasında FTP bilgisi istiyor: "Bağlantı Bilgileri — Güncellemeye devam etmek için lütfen FTP bilgilerinizi girin." Bilgileri girseniz bile bazen çalışmıyor, çalışsa bile bir sonraki eklentide ekran yine karşınıza çıkıyor. Özellikle paylaşımlı hostingden VDS'e ya da elle kurduğunuz bir sunucuya geçtiyseniz, bu ekran ilk günün en can sıkıcı engelidir.

Türkçe kaynakların neredeyse tamamı size wp-config.php dosyasına define('FS_METHOD', 'direct'); satırını yapıştırmayı söyler ve orada keser. Bu satır bazı sunucularda işe yarar, bazılarında hiçbir şeyi değiştirmez, bazılarında ise "dizin yazılabilir değil" hatasına dönüşür — çünkü sorunun kökeni o satır değildir. Gerçek sebep, web sunucusunun çalıştığı kullanıcı ile WordPress dosyalarının sahibinin farklı olmasıdır. Bu yazıda önce WordPress'in bu ekranı hangi teste bakarak açtığını göstereceğim, sonra sunucunuzda hangi kullanıcının PHP çalıştırdığını bulup sahipliği chown ile kalıcı ve güvenli biçimde hizalayacağız. FS_METHOD satırının ne zaman doğru karar olduğunu, 777 iznini neden asla vermemeniz gerektiğini ve FTP bilgisi tanımlamanın meşru olduğu senaryoyu da ayrı ayrı ele alacağım.

Bu Ekran Neden Çıkıyor: WordPress'in Dosya Sistemi Testi#

WordPress bir eklenti ya da tema kurmadan önce çok basit bir test yapar: wp-content dizinine geçici bir dosya yazmayı dener. Bu dosyayı oluşturabiliyorsa "doğrudan yazabiliyorum" sonucuna varır ve kuruluma sessizce devam eder. Oluşturamıyorsa, dosyaları başka bir yoldan yerleştirmesi gerektiğine karar verir ve size FTP bilgilerini sorar. Yani bu ekran bir hata mesajı değil, bir yedek plan teklifidir.

Testin mantığı şudur: geçici dosya oluşturulur, oluşturulan dosyanın sahibi ile o anda kodu çalıştıran işlemin sahibi karşılaştırılır. İkisi aynıysa direct yöntemi seçilir. Farklıysa WordPress "ben bu dizine yazabiliyorum ama oluşturduğum dosyalar başka bir kullanıcıya ait olacak, bu tehlikeli" der ve ftpext yöntemine düşer.

Bu ayrım önemlidir çünkü klasöre 777 izni verdiğinizde dosya yazılabilir hâle gelir ama sahiplik hâlâ farklıdır. Bu yüzden 777 veren birçok kullanıcı ekranın kaybolmadığını, kaybolsa bile başka sitelerde tekrar çıktığını görür. Sorun izin bitiyle değil, sahiplikle ilgilidir.

Kök Neden: Web Sunucusu Kullanıcısı ile Dosya Sahibi Farklı#

Bir Linux sunucusunda PHP kodu bir kullanıcı kimliğiyle çalışır. Bu kullanıcı sunucu yapılandırmasına göre değişir:

Klasik senaryo şudur: sunucuyu kurdunuz, root olarak SSH'a bağlandınız, WordPress arşivini wget ile indirip unzip ile açtınız. Böylece tüm dosyaların sahibi root oldu. PHP-FPM ise www-data kullanıcısıyla çalışıyor. WordPress dosya yazmayı deniyor, deneme başarısız oluyor ya da sahiplik uyuşmuyor — ve karşınıza FTP ekranı geliyor. Kurulumu FTP ile yaptıysanız da benzer bir uyumsuzluk oluşur; bu kez sahip FTP kullanıcısıdır.

Bu yüzden çözüm "WordPress'i kandırmak" değil, iki kimliği hizalamaktır.

Sunucunuzda PHP'yi Hangi Kullanıcı Çalıştırıyor#

Sahipliği düzeltmeden önce hedef kullanıcıyı kesin olarak bilmeniz gerekir. Tahmin etmeyin, sorun.

En doğrudan yöntem, çalışan süreçleri listelemektir:

ps aux | grep -E "php-fpm|apache2|httpd|nginx" | grep -v grep

Çıktıda ilk sütun kullanıcı adıdır. master process satırı genellikle root görünür — bu normaldir; siz alt (worker/pool) süreçlerin kullanıcısına bakacaksınız:

root      1180  nginx: master process /usr/sbin/nginx
www-data  1181  nginx: worker process
root       942  php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf)
www-data   955  php-fpm: pool www
www-data   956  php-fpm: pool www

Burada hedef kullanıcı www-data'dır.

PHP-FPM havuz dosyasından da doğrulayabilirsiniz:

grep -E "^(user|group)" /etc/php/8.3/fpm/pool.d/www.conf

user = www-data
group = www-data

Kesin sonucu WordPress'in kendi gözünden almak isterseniz, site kök dizinine geçici bir dosya koyun:

<?php
// kontrol.php — kontrolden sonra SİLİN
echo 'PHP kullanıcısı: ' . get_current_user() . PHP_EOL;
echo 'İşlem sahibi: ' . posix_getpwuid( posix_geteuid() )['name'] . PHP_EOL;
echo 'wp-content yazılabilir mi: ' . ( is_writable( __DIR__ . '/wp-content' ) ? 'evet' : 'hayır' ) . PHP_EOL;

Tarayıcıdan https://ornek.com/kontrol.php adresini açıp çıktıyı okuyun, sonra dosyayı mutlaka silin. Sunucu bilgisini dışarıya açık bırakmak istemezsiniz.

Şimdi mevcut sahipliği görün:

ls -la /var/www/ornek.com/ | head

drwxr-xr-x 5 root root  4096 Aug  2 11:04 .
-rw-r--r-- 1 root root   405 Aug  2 11:04 index.php
-rw-r--r-- 1 root root  3210 Aug  2 11:12 wp-config.php
drwxr-xr-x 6 root root  4096 Aug  2 11:04 wp-content

root root görüyorsanız ve PHP www-data ile çalışıyorsa teşhis tamamlanmıştır.

Kalıcı Çözüm: chown ile Sahipliği Hizalamak#

Doğru çözüm, site dosyalarının sahipliğini PHP'nin çalıştığı kullanıcıya vermektir. Kendi kullanıcı adınızı yukarıda bulduğunuzla değiştirerek:

chown -R www-data:www-data /var/www/ornek.com

Ardından izinleri standart değerlere çekin:

cd /var/www/ornek.com
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 640 wp-config.php

Bu üç komuttan sonra sayfayı yenileyip bir eklenti güncellemeyi deneyin. FTP ekranı çıkmayacaktır ve FS_METHOD satırına da ihtiyacınız kalmayacaktır — çünkü WordPress'in kendi testi artık direct sonucunu üretiyordur.

SSH ile kendiniz de çalışmak istiyorsanız#

Tüm dosyaları www-data'ya verdiğinizde, kendi SSH kullanıcınızla dosya düzenlemek zorlaşır. Yaygın ve güvenli düzen şudur: dosya sahibi sizin kullanıcınız, grup ise web sunucusu kullanıcısı olsun ve gruba yazma izni verilsin.

chown -R deploy:www-data /var/www/ornek.com
find /var/www/ornek.com -type d -exec chmod 775 {} \;
find /var/www/ornek.com -type f -exec chmod 664 {} \;

Bu düzende WordPress yine yazabilir, siz de sudo kullanmadan çalışabilirsiniz. Yeni oluşturulan dosyaların da grubu miras alması için dizinlere setgid biti ekleyin:

find /var/www/ornek.com -type d -exec chmod g+s {} \;

setgid biti olmadan, yeni oluşan klasörler kullanıcının birincil grubunu alır ve birkaç güncelleme sonra izin karmaşası geri döner. İzin bitlerinin ne anlama geldiğini tazelemek isterseniz linux dosya izinleri yazısı temel referanstır; WordPress'e özel dizin dizin dağılım ise wordpress dosya izinleri yazısında.

cPanel kullanıyorsanız#

cPanel'de suEXEC/suPHP varsayılan olarak çalışır ve PHP zaten hesap kullanıcınız olarak çalışır; bu yüzden bu ekranı cPanel'de nadiren görürsünüz. Gördüyseniz genellikle dosyalar bir kurtarma/geri yükleme sırasında farklı bir kullanıcıya geçmiştir. cPanel'de sahiplik değiştirme aracı yoktur; hesap sahibi (WHM erişimi olan taraf) şunu çalıştırır:

chown -R kullanici:kullanici /home/kullanici/public_html

Bu yetki sizde değilse destek talebi açmak doğru yoldur; Dosya Yöneticisi'nden yalnızca izinleri değiştirebilirsiniz, sahipliği değiştiremezsiniz.

FS_METHOD Satırı Ne Yapar ve Ne Zaman Doğru Karardır#

FS_METHOD sabiti, WordPress'in yaptığı otomatik testi geçersiz kılıp "hangi yöntemi kullanacağını" doğrudan söyler. wp-config.php içine, /* That's all, stop editing! */ satırının üstüne eklenir:

define( 'FS_METHOD', 'direct' );

Bu satır dosya sahipliğini değiştirmez; yalnızca WordPress'e "sahiplik testini atla, doğrudan yazmayı dene" der. Bu yüzden:

• Dosyalar zaten PHP kullanıcısı tarafından yazılabiliyorsa (ör. grup yazma izni verilmişse) satır işe yarar ve ekranı kaldırır.
• Dosyalar gerçekten yazılamıyorsa satır hiçbir şey çözmez; FTP ekranı yerine bu kez "Dizin yazılabilir değil" ya da "Güncelleme başarısız oldu" hatası alırsınız. Bu, kötü bir takas değildir — hata mesajı en azından size gerçeği söyler.

Yani FS_METHOD 'direct' doğru bir ayardır, ama sahiplik düzeltilmeden tek başına bir çözüm değildir. Sıralama şu olmalıdır: önce chown, sonra gerekiyorsa FS_METHOD. Çoğu sunucuda ikincisine hiç gerek kalmaz.

Sabitin kabul ettiği diğer değerler ssh2, ftpext ve ftpsockets'tir. ssh2 yalnızca PHP'nin ssh2 uzantısı kuruluysa çalışır ve çoğu paylaşımlı ortamda kurulu değildir.

Neden 777 Vermemelisiniz#

İnternette bu soruna karşı en sık önerilen ikinci çözüm chmod -R 777 komutudur. Bu komut, dosyaları sunucudaki herkesin yazabileceği hâle getirir. Paylaşımlı bir sunucuda "herkes" ifadesi aynı makinedeki diğer hesapları da kapsar. Pratik sonucu şudur: sunucuda kod çalıştırabilen herhangi bir taraf, sizin wp-config.php dosyanızı okuyup veritabanı parolanızı alabilir ya da tema dosyalarınızın içine kendi kodunu yazabilir.

Buna ek olarak birçok barındırma yapılandırmasında suEXEC, 777 izinli dosyaları güvenlik gerekçesiyle çalıştırmayı reddeder; sonuçta ekranı kaldırmak isterken sitenizi 500 hatasına düşürürsünüz. Zararlı yazılım temizliği yaptığım sitelerin belirgin bir bölümünde giriş noktası, yıllar önce "geçici olarak" verilmiş ve unutulmuş bir 777 izniydi.

Doğru değerler değişmez: dizinler 755 (ya da grup yazma senaryosunda 775), dosyalar 644 (ya da 664), wp-config.php 640. Bunun ötesine geçmeniz gereken tek bir meşru senaryo yoktur.

FTP Ekranı Sahiplik Dışında Hangi Nedenlerle Çıkar#

Sahipliği düzelttiğiniz hâlde ekran çıkmaya devam ediyorsa, sırayla şunlara bakın:

1. Disk dolu. WordPress geçici dosyayı yazamaz ve bunu "yazma izni yok" gibi yorumlar. Kontrol: df -h ve inode için df -i. inode'un dolması özellikle çok sayıda küçük dosyası olan sitelerde disk boş görünürken de yaşanır.
2. Salt okunur dosya sistemi. Disk hatası sonrası çekirdek dosya sistemini salt okunur bağlayabilir. Kontrol: mount | grep " / " çıktısında ro görüyorsanız durum budur.
3. SELinux. AlmaLinux/Rocky gibi dağıtımlarda etkindir. getenforce çıktısı Enforcing ise, web dizinine yazma için doğru bağlam gerekir:

getenforce
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/ornek.com/wp-content(/.*)?"
restorecon -Rv /var/www/ornek.com/wp-content

4. DISALLOW_FILE_MODS sabiti. Bazı yönetilen ortamlar ya da bir güvenlik eklentisi wp-config.php içine define('DISALLOW_FILE_MODS', true); koyar. Bu sabit varken kurulum/güncelleme arayüzü tamamen kapanır. Dosyada arayın.
5. Değişmezlik biti. Nadirdir ama zararlı yazılım temizliği sonrası kalabilir: lsattr wp-content çıktısında i görürseniz chattr -i ile kaldırın.
6. Açık open_basedir kısıtı. PHP, geçici dizine erişemiyorsa da yazma testleri tuhaf biçimde başarısız olur. php -i | grep open_basedir ile bakın.

Bu maddeleri elemek beş dakika sürer ve sahiplik dışındaki vakaların tamamına yakınını kapatır. PHP-FPM tarafındaki kullanıcı/havuz ayarlarını daha ayrıntılı yapılandırmak isterseniz nginx php-fpm yapılandırma yazısı bu bölümün devamı gibidir.

FTP Bilgilerini Kalıcı Tanımlamak Ne Zaman Mantıklı#

Bazı barındırma yapılandırmalarında sahipliği hizalamak mümkün değildir; PHP kasıtlı olarak ayrı bir kullanıcıyla çalışır ve dosya yazma işi FTP katmanına bırakılmıştır. Böyle bir ortamda WordPress'in her seferinde bilgi sormasını engellemek için kimlik bilgilerini wp-config.php içinde tanımlayabilirsiniz:

define( 'FTP_HOST', 'ornek.com' );
define( 'FTP_USER', 'ftpkullanici' );
define( 'FTP_PASS', 'parolaburaya' );
define( 'FTP_SSL', true );

Bunu yapmadan önce iki şeyi bilin. Birincisi, parola dosyada düz metin durur; bu yüzden wp-config.php izni mutlaka 640 olmalı ve dosya web kökünün bir üst dizinine taşınabiliyorsa taşınmalıdır. İkincisi, bu bilgiler sunucuya sınırlı erişimi olan bir FTP hesabına ait olmalıdır — ana hesabın parolası değil. FTP_SSL değerini true yapmak bağlantıyı şifreler; sunucunuz destekliyorsa kapatmayın. FTP ve SFTP arasındaki farkı ve hangisinin ne zaman uygun olduğunu ftp sftp dosya yükleme yazısında ayrıntılandırdım.

Kişisel önerim nettir: bu yöntem son çaredir. Sahipliği düzeltebiliyorsanız düzeltin, parolayı yapılandırma dosyasında tutmayın.

Sorunu Çözdükten Sonra: Güncelleme Alışkanlığı#

FTP ekranı kalktıktan sonra çoğu kullanıcı biriken güncellemelerin hepsini aynı anda uygular ve bu kez farklı bir sorunla karşılaşır: site açılmaz ya da düzen bozulur. Uzun süredir güncellenmemiş bir sitede doğru sıra şudur:

1. Tam yedek alın (dosya + veritabanı). Yedeksiz güncelleme yapmayın.
2. Önce WordPress çekirdeğini güncelleyin, siteyi açıp kontrol edin.
3. Eklentileri teker teker güncelleyin, her birinden sonra ön yüzü ve yönetim panelini kontrol edin.
4. Temayı en sona bırakın; özelleştirme yaptıysanız alt tema kullandığınızdan emin olun.
5. Bir şey bozulursa hangi adımda bozulduğunu bilirsiniz — toplu güncellemede bu bilgi kaybolur.

Güncelleme sonrası site açılmazsa ne yapılacağını wordpress güncelleme sonrası site bozuldu yazısında, düzenli bir güncelleme politikası kurmayı ise wordpress güncelleme yönetimi yazısında bulabilirsiniz.

Sıkça Sorulan Sorular#

FS_METHOD direct satırını ekledim ama hâlâ FTP soruyor#

Bu, dosyaların gerçekten yazılamadığını gösterir. FS_METHOD sabiti yalnızca WordPress'in sahiplik testini atlamasını sağlar; dizin PHP kullanıcısı tarafından yazılamıyorsa satır hiçbir şeyi değiştirmez ve bazı sürümlerde ekran yerine "Dizin yazılabilir değil" hatası görürsünüz. Önce ps aux ile PHP'nin hangi kullanıcı olarak çalıştığını bulun, ls -la ile dosya sahibini görün ve chown -R ile ikisini hizalayın. Sahiplik düzeldikten sonra çoğu kurulumda bu satıra hiç gerek kalmaz.

wp-config.php dosyasına satırı tam olarak nereye eklemeliyim#

Satır, dosyanın sonundaki /* That's all, stop editing! Happy publishing. */ yorumunun üstüne eklenmelidir. O yorumdan sonra WordPress kendi çekirdek dosyalarını yüklemeye başlar ve orada tanımlanan sabitler çoğu durumda geç kalır. Dosyanın en başındaki <?php etiketinden önce hiçbir şey — tek bir boşluk bile — olmamalıdır; aksi hâlde "headers already sent" uyarısı alır ve ayrı bir sorunla uğraşırsınız.

777 izni vermek gerçekten bu kadar riskli mi#

Evet, ve risk teorik değildir. 777, dosyayı sunucuda kod çalıştırabilen herkesin yazabilmesi demektir; paylaşımlı bir makinede bu "diğer hesaplar" anlamına gelir ve wp-config.php içindeki veritabanı bilgilerini ifşa eder. Ayrıca suEXEC kullanan yapılandırmalar 777 izinli dosyaları çalıştırmayı reddettiği için sık sık 500 hatasına yol açar. Doğru değerler dizinlerde 755, dosyalarda 644'tür ve bu değerlerle WordPress sorunsuz güncelleme yapar — yeter ki sahiplik doğru olsun.

Sadece bazı eklentiler kurulurken FTP soruyor#

Bu genellikle sahipliğin dizin dizin farklı olmasından kaynaklanır. Örneğin wp-content/plugins PHP kullanıcısına aitken, daha önce elle açtığınız bir eklentinin klasörü root'a ait kalmıştır; WordPress o eklentiyi güncellerken yazma testinden geçemez. ls -la wp-content/plugins çıktısını satır satır inceleyip farklı sahibe ait olan klasörleri tespit edin ve tüm ağaca chown -R uygulayın. Aynı durum wp-content/upgrade dizini eksik ya da yanlış sahiplikteyse de görülür.

Paylaşımlı hostingde bu ekranı görüyorsam ne yapmalıyım#

Paylaşımlı hostingde sahipliği kendiniz değiştiremezsiniz, çünkü chown komutu yönetici yetkisi ister. Böyle bir durumda önce disk ve inode kotanızın dolu olmadığını kontrol panelinden doğrulayın; dolu bir kota bu ekranı üretmenin en yaygın nedenidir. Kota sorunu yoksa, dosya sahipliğinin bozulduğunu belirterek destek talebi açın — sağlayıcı tarafında tek komutla düzeltilen bir durumdur. Bu arada güncellemeyi engellemeyen bir çözüm arıyorsanız eklentiyi Dosya Yöneticisi üzerinden elle yükleyebilirsiniz.

FTP bilgilerimi girdim ama bağlanamadı hatası alıyorum#

En sık sebep, sunucu adresi alanına alan adı yerine ftp:// ön eki ya da yanlış port yazılmasıdır; alan yalnızca sunucu adını ya da IP'yi bekler. İkinci sebep, sunucunuzun FTP değil yalnızca SFTP kabul etmesidir — bu durumda WordPress'in FTP yöntemi çalışmaz ve ssh2 uzantısı kurulu değilse SFTP seçeneği de görünmez. Üçüncü olarak, güvenlik duvarı pasif mod veri bağlantılarını engelliyorsa kimlik doğrulama geçer ama aktarım başlamaz. Bu üç ihtimali elemek yerine sahipliği düzeltmek çoğu zaman daha kısa yoldur.

Bu ekran WordPress'in bir hatası mı#

Hayır, kasıtlı bir güvenlik davranışıdır. WordPress, oluşturacağı dosyaların sahibi ile kendisini çalıştıran kullanıcı farklıysa bunu "paylaşımlı ortamda başka bir hesabın dosyalarına yazıyor olabilirim" riski olarak yorumlar ve doğrudan yazmayı reddeder. Bu davranış, aynı sunucudaki bir hesabın diğerinin dosyalarını ele geçirmesini zorlaştırır. Dolayısıyla amaç ekranı kandırmak değil, sahipliği düzelterek WordPress'in testten temiz geçmesini sağlamaktır.

Kapanış#

FTP bilgisi ekranı bir arıza değil, WordPress'in "bu dosyaları güvenle yazamıyorum" demesinin yoludur. Bu yüzden kalıcı çözüm de yapılandırma dosyasına satır eklemek değil, PHP'nin çalıştığı kullanıcı ile dosya sahibini hizalamaktır: ps aux ile kullanıcıyı bulun, ls -la ile sahibi görün, chown -R ile eşitleyin, dizinlere 755 dosyalara 644 verin. Bu üç adımdan sonra ekran çoğu sunucuda bir daha çıkmaz ve FS_METHOD satırına ihtiyacınız kalmaz. Sahiplik doğruyken hâlâ sorun yaşıyorsanız suçlu dolu disk, salt okunur bağlanmış dosya sistemi, SELinux bağlamı ya da DISALLOW_FILE_MODS sabitidir — hepsi tek tek elenebilir.

Bu tür sunucu düzeyi ayarları kendiniz yönetmek istiyorsanız kök erişimi olan bir VDS sunucu size gereken esnekliği verir; kullanıcı, izin ve PHP-FPM yapılandırmasıyla uğraşmak istemiyorsanız sunucu yönetimi hizmetiyle bu işi devredebilirsiniz. Doğrudan WordPress'e ayarlanmış, sahiplik ve izinleri baştan düzgün gelen bir ortam arıyorsanız WordPress hosting paketleri bu yapılandırmayla teslim edilir; güncellemelerin düzenli ve kontrollü uygulanmasını da devretmek isterseniz WordPress bakım hizmeti tam olarak bunu üstlenir.