WordPress'te PHP Sürümünü Yükseltmeden Önce Neleri Kontrol Etmeli

cPanel'de Software → MultiPHP Manager ekranındasınız. Alan adınızın karşısındaki açılır menüde ea-php74 yazıyor, listenin alt tarafında ea-php84 duruyor ve tek yapmanız gereken seçip Apply demek. Toplam süresi üç saniye. Aynı üç saniye, geri dönüşü olan en kolay işlem de olabilir, e-ticaret sitenizin ödeme adımını sessizce bozan ve iki gün sonra fark edilen bir olay da.

Bu ekrandaki tereddüdün sebebi genelde belirsizliktir: sitede 28 eklenti var, bunların kaçı son iki yılda güncellendi bilmiyorsunuz; tema beş yıl önce alınmış bir ThemeForest teması; ödeme eklentisi lisanslı ve ionCube ile şifreli. "Denerim, olmazsa geri alırım" yaklaşımı teoride doğrudur ama pratikte "olmazsa" anını kimin, ne kadar sürede fark edeceği hesaba katılmaz. Ana sayfa açılıyorsa çoğu kişi işin bittiğini sanır; oysa kırılan şey genellikle ödeme geri dönüşü, e-posta gönderimi ya da yönetici tarafındaki bir ekrandır.

Bu rehber, PHP yükseltmesini bir tıklama değil bir risk yönetimi süreci olarak kurgular: önce envanter, sonra yedek, sonra staging'de gerçek deneme, ardından statik uyumluluk taraması, sonra "deprecated uyarısı" ile "ölümcül hata" ayrımı ve en sonda panelden tek tıkla geri dönüş planı. Sırasıyla gittiğinizde canlı sitede geçirilecek süre gerçekten üç saniyeye iner.

Neden Yükseltmek Zorundasınız: Süre Doldu#

En zayıf gerekçe hızdır; en güçlü gerekçe güvenlik yamalarının bitmesidir. PHP'nin her ana sürümü yaklaşık iki yıl aktif destek, ardından bir yıl daha yalnızca güvenlik yaması alır. Süre bittiğinde bulunan açıklar için resmî yama çıkmaz.

Tabloyu 2026 Ağustos'undan okuduğunuzda tablo netleşiyor: PHP 7.4 ve 8.0 üzerinde çalışan bir site, dört yıldır yamalanmayan bir yorumlayıcı üzerinde duruyor. Bazı dağıtımlar ve CloudLinux gibi katmanlar kendi geriye taşımalarını yapar, ama bu bir kaynak yaması değil, ömrü uzatılmış bir tampondur.

İkinci gerekçe eklenti ekosistemidir. Popüler eklentilerin yeni sürümleri asgari PHP şartını yukarı çekiyor; eski sürümde kalmak, bir noktada güvenlik güncellemesi alamayan bir eklenti sürümüne kilitlenmek demektir. Üçüncüsü performanstır: 7.4'ten 8.x'e geçişte tipik bir WordPress kurulumunda istek başına PHP süresinde belirgin bir düşüş görülür, JIT olmadan bile. Bu kazanç güzeldir ama tek başına yükseltme gerekçesi olarak zayıftır — asıl mesele destek takvimidir.

WordPress tarafında durum şu: çekirdeğin resmî asgari şartı yıllardır 7.x seviyesinde takılı kalsa da önerilen sürüm 8.x'tir. WordPress 6.8 ve sonrası PHP 8.4 ile tam uyumlu olarak belgelenir; 2026'da yayımlanan 7.0 dalı PHP 8.5 desteğini de ekledi. Yine de kendi kurulumunuzun sürüm notlarını doğrulayın: uyumluluğu belirleyen çekirdek değil, sizin eklenti ve tema yığınınızdır.

Yükseltme Öncesi 10 Dakikalık Envanter#

Elinizde ne olduğunu bilmeden risk hesabı yapamazsınız. SSH erişiminiz varsa WP-CLI bu envanteri dakikalar içinde çıkarır:

# Çekirdek sürümü ve mevcut PHP
wp core version
php -v

# Tüm eklentiler: durum, sürüm, bekleyen güncelleme
wp plugin list --fields=name,status,version,update_version --format=table

# Aktif tema ve alt tema
wp theme list --status=active --fields=name,version,update_version

# Çekirdek dosyalarında değişiklik var mı (elle düzenlenmiş çekirdek en büyük risk)
wp core verify-checksums

Buradaki php -v çıktısına dikkat: bu komut satırı PHP sürümüdür ve web sunucusunun kullandığı sürümden farklı olabilir. Sitenin gerçekte hangi sürümle çalıştığını görmek için WordPress panelinde Araçlar → Site Sağlığı → Bilgi → Sunucu bölümüne bakın. Bu ayrımı atlamak, "yükselttim ama değişmedi" sanılarının klasik kaynağıdır.

Envanteri çıkardıktan sonra terk edilmiş eklentileri işaretleyin. Bir eklentinin wordpress.org sayfasında iki şeye bakın: son güncelleme tarihi ve "Şu sürümle test edildi" bilgisi. Pratik eşik şudur:

ionCube ile şifrelenmiş eklenti ve temalar özel bir durumdur: kaynak kodu okunamadığı için hiçbir statik tarama sonuç veremez ve loader'ın hedef PHP sürümü için sunucuda etkin olması gerekir. Bunlarda tek geçerli yöntem, satıcının uyumluluk beyanı ve staging denemesidir.

Yedek: Geri Dönüşü Olmayan Adımı Ortadan Kaldırmak#

Yükseltmenin kendisi geri alınabilir bir işlemdir; yükseltmeden sonra yapılan onarım denemeleri çoğu zaman değildir. Panik anında bir eklentiyi elle silmek, wp-config.php düzenlemek ya da veritabanında bir tabloyu güncellemek, geri dönüşü zorlaştıran şeydir. Bu yüzden yedek, yükseltmeden hemen önce alınır.

Yedeğin iki parçası da şart: dosyalar (public_html tamamı) ve veritabanı. cPanel'de tam hesap yedeği alma adımlarını cPanel yedekleme yazısında, JetBackup kullanan paketlerde anlık nokta seçimini JetBackup nedir yazısında bulabilirsiniz. SSH varsa hızlı yol:

cd ~
tar -czf site-yedek-$(date +%F).tar.gz public_html
wp db export ~/veritabani-yedek-$(date +%F).sql

Üç kural: yedeği sunucudan indirin (sunucu erişilemez hale gelirse üstündeki yedek işe yaramaz), geri yükleme adımını en az bir kez staging'de deneyin, ve yedeğin dosya boyutuna bakın — 4 KB'lik bir .sql dosyası başarısız bir dışa aktarımdır.

Staging'de Gerçek Deneme#

Statik tarama size "şu satır sorunlu olabilir" der; staging size "ödeme adımı çalışıyor mu" cevabını verir. İkisi birbirinin yerine geçmez.

Buradaki en kullanışlı gerçek şudur: cPanel'de MultiPHP Manager alan adı bazında çalışır. Yani staging.ornek.com alt alan adını PHP 8.4'e alırken ana alan adı 7.4'te kalabilir. Aynı hesapta, aynı anda, iki farklı PHP sürümü. Bu, ayrı bir sunucu kiralamadan gerçek bir deneme ortamı kurmanın en ucuz yoludur.

Adımlar:

1. Alt alan adı oluşturun (staging.ornek.com) ve dizinini ana siteden ayırın.
2. Dosyaları kopyalayın, veritabanının bir kopyasını yeni bir veritabanına aktarın.
3. wp-config.php içindeki veritabanı bilgilerini yeni kopyaya çevirin.
4. Site adresini güncelleyin: wp option update home 'https://staging.ornek.com' ve aynısını siteurl için.
5. Arama motorlarına kapatın: Ayarlar → Okuma → Arama motorlarının siteyi indekslemesini engelle.
6. MultiPHP Manager'da yalnızca staging alt alan adını hedef sürüme alın.

WP Toolkit bulunan paketlerde 1-5 arası adımlar tek bir "Clone" düğmesiyle halledilir. Deneme ortamının neden bu kadar merkezi olduğunu ve nasıl kurulacağını staging ortamı nedir yazısında ayrıntılı ele aldık.

Staging'de hata günlüğünü açın ama ziyaretçiye göstermeyin — wp-config.php içinde:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );    // wp-content/debug.log dosyasına yazar
define( 'WP_DEBUG_DISPLAY', false ); // ekrana basmaz
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY değerinin false olması önemlidir: uyarılar ekrana basıldığında JSON yanıtlarının ve yönlendirmelerin başına metin karışır, ortada gerçek bir hata yokken site bozulmuş gibi görünür. Günlüğün nasıl okunacağı için PHP hata raporlama yazısına bakabilirsiniz.

Uyumluluk Taraması: phpcs ile PHPCompatibility#

Statik tarama, gözle taranması imkânsız bir kod tabanında kaldırılmış fonksiyonları ve söz dizimi değişikliklerini bulur. Bir zamanlar önerilen "PHP Compatibility Checker" eklentisi uzun süredir güncellenmiyor; güncel yöntem PHP_CodeSniffer üzerinde PHPCompatibilityWP kural setini çalıştırmaktır. WP tarafındaki geri doldurmaları (polyfill) tanıdığı için yanlış pozitifleri ciddi biçimde azaltır.

mkdir ~/phpcompat && cd ~/phpcompat

composer require --dev \
  squizlabs/php_codesniffer \
  phpcompatibility/phpcompatibility-wp \
  dealerdirect/phpcodesniffer-composer-installer

# Kural setinin yüklendiğini doğrula
vendor/bin/phpcs -i

# Hedef sürüm 8.4 ve üstü için tarama
vendor/bin/phpcs -p \
  --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.4- \
  --extensions=php \
  --report=summary \
  ~/public_html/wp-content/plugins ~/public_html/wp-content/themes

testVersion ifadesinin sözdizimi işin püf noktasıdır. 8.4- "8.4 ve sonrası" demektir. Geri dönme ihtimalini de kapsamak isterseniz aralık verin: --runtime-set testVersion 7.4-8.4. Bu, "hem eski hem yeni sürümde çalışmalı" anlamına gelir ve kademeli geçişlerde daha gerçekçidir.

Özet rapor size hangi dosyada kaç bulgu olduğunu verir; tek bir eklentiyi detaylı görmek için --report=full ile o dizini tarayın. Taramanın sınırlarını da bilin: dinamik fonksiyon çağrıları ($fn = 'each'; $fn(...)), eval içeriği ve şifrelenmiş dosyalar görünmez. Yani temiz bir rapor "sorun yok" demek değildir; yalnızca "bilinen kalıplardan sorun çıkmadı" demektir.

Deprecated Uyarısı ile Ölümcül Hatayı Ayırt Etmek#

Yükseltmeden sonra günlükte yüzlerce satır göreceksiniz. Bunların hepsi acil değil. Ayrımı doğru yapmak, gereksiz geri dönüşleri önler.

PHP 8.x geçişinde en sık karşılaşılan kalıplar:

Kritik nüans şu: bir Deprecated satırı da siteyi bozabilir. Uyarı ekrana basılıyorsa (display_errors açıksa) ve bu, başlıklar gönderilmeden önce oluyorsa, headers already sent hatası çıkar; AJAX yanıtlarının başına metin karışır ve JSON çözümlenemez. Yani "sadece deprecated var, sorun yok" demeden önce uyarıların ekrana değil günlüğe yazdığından emin olun. Canlıda display_errors daima kapalı, log_errors daima açık olmalıdır.

Ölümcül hata aldığınızda WordPress size "Sitenizde kritik bir hata oluştu" ekranını gösterir ve yönetici e-postasına kurtarma bağlantısı yollar. O bağlantı, sorunlu eklentiyi devre dışı bırakarak panele girmenizi sağlar; adımları WordPress kritik hata oluştu yazısında anlattık. Sonuç beyaz bir sayfaysa ve e-posta gelmediyse beyaz ekran hatası yazısındaki teşhis sırasını izleyin.

Panelde Sürümü Değiştirmek ve Unutulan İki Ayar#

Staging temizse sıra canlıdadır. cPanel'de Software → MultiPHP Manager, alan adını işaretleyin, sürümü seçin, Apply. Plesk'te Hosting & DNS → PHP Settings, CloudLinux'lu paketlerde ise Select PHP Version ekranı kullanılır; bu ekranın ayrıntıları için PHP Selector ve CloudLinux yazısına bakın. Panelden bağımsız genel yaklaşım için PHP sürüm yönetimi yazısı iyi bir çerçeve sunar.

Değişiklikten sonra insanların en sık atladığı iki şey var ve ikisi de "yükselttim, site bozuldu" vakalarının çoğunu açıklar:

1. PHP ayarları sürüm başına ayrıdır. memory_limit, max_execution_time, upload_max_filesize gibi değerleri 7.4 için ayarlamış olmanız, 8.4'e taşınmaz. Yükseltmeden sonra site "bellek yetersiz" hatası veriyorsa sebep genellikle budur; cPanel'de MultiPHP INI Editor ile yeni sürüm için aynı değerleri girin. Bellek sınırının WordPress tarafındaki karşılığı için PHP memory limit yazısına bakabilirsiniz.

2. Eklentiler (extension) sürüm başına ayrıdır. imagick, intl, zip, soap, ionCube loader — hepsi yeni sürüm için yeniden işaretlenmelidir. Görsel küçültme çalışmıyorsa ya da lisanslı eklenti "loader bulunamadı" diyorsa buraya bakın; seçim ekranını cPanel PHP eklenti seçimi yazısında anlattık.

Bir de sessiz bir tuzak var: .htaccess dosyasındaki elle yazılmış handler satırları panelin seçimini ezer. Böyle bir blok varsa panelde sürümü değiştirmeniz hiçbir işe yaramaz:

# Bu satırlar MultiPHP Manager seçimini geçersiz kılar
<IfModule mime_module>
  AddType application/x-httpd-ea-php74 .php .php7 .phtml
</IfModule>

Bunları silin ya da panelin kendisinin yazmasına izin verin. Değişiklik sonrası PHP sürümünü daima Site Sağlığı → Bilgi → Sunucu ekranından doğrulayın; php -v size CLI sürümünü söyler ve yanıltır.

Yükseltmeden Sonraki İlk 30 Dakika#

Yükseltme anı bitiş değil, gözlemin başlangıcıdır. Şu sırayla ilerleyin:

1. Ana sayfa ve üç iç sayfa — önbelleği temizleyerek. OPcache eski derlemeleri tutabilir; kalıcı tuhaflıklarda PHP-FPM'i yeniden başlatmak gerekir, ayrıntısı PHP OPcache yazısında.
2. Yönetim paneli — Eklentiler ekranı, Medya kütüphanesi, Ayarlar sayfaları.
3. Formlar — iletişim formu gönderin, e-postanın gerçekten geldiğini doğrulayın.
4. Ödeme akışı — mağazaysa sepetten ödeme dönüşüne kadar test siparişi verin.
5. Görsel yükleme — küçük boyutların üretildiğini kontrol edin (imagick/gd eklentisi testi).
6. Kalıcı bağlantılar — Ayarlar → Kalıcı Bağlantılar'da kaydete basıp kuralları tazeleyin.
7. Hata günlüğü — wp-content/debug.log ve cPanel'deki hata kayıtlarını okuyun. Sunucu tarafı günlüğüne erişim için cPanel hata kayıtları yazısı yol gösterir.
8. Zamanlanmış görevler — wp cron event list ile bekleyen görevlerin çalıştığını görün.

İlk 48 saat boyunca hata günlüğünün boyutuna göz atın. Dosya hızla büyüyorsa, çalışan ama her istekte uyarı üreten bir kod vardır; bu, disk dolduran ve I/O harcayan sessiz bir maliyettir.

Geri Dönüş Planı: Üç Aşamalı#

Planın olması, kullanmanız gerekmediği anlamına gelmez; kullanmadığınızda bile hızlı karar vermenizi sağlar.

Aşama 1 — Sürümü geri al (30 saniye). MultiPHP Manager'dan eski sürümü seçin. Site yükseltme öncesi haline döner çünkü dosyalara ve veritabanına dokunulmamıştır. Ölümcül hata alıp sebebini hemen bulamadığınızda ilk hamle budur; teşhisi sonra, sakin kafayla staging'de yaparsınız.

Aşama 2 — Tekil eklentiyi izole et. Suçlu tek bir eklentiyse tüm siteyi eski PHP'de tutmak gereksizdir. Eklentiyi devre dışı bırakıp yeni sürümde kalın, alternatifini bulun. Hangi eklentinin sorumlu olduğunu bulmanın sistematik yolu için WordPress eklenti çakışması yazısına bakın.

Aşama 3 — Yedekten dön. Yalnızca yükseltmeden sonra dosya ya da veritabanı değiştirdiyseniz gerekir. Sürüm değişikliği tek başına buna ihtiyaç duymaz. Geri yükleme sonrası site açılmıyorsa sebep genellikle yedeğin eksik olmasıdır; bu senaryonun kontrol listesini güncelleme sonrası site bozuldu yazısında topladık.

Son tavsiye zamanlama üzerine: yükseltmeyi haftanın en sakin gününde, mesai başlangıcında yapın. Cuma akşamı 18:00 en kötü seçimdir — sorun ortaya çıktığında elinizde ne trafik verisi ne de yardım edecek biri olur.

Sıkça Sorulan Sorular#

PHP sürümünü yükseltmek sitemi gerçekten hızlandırır mı?#

Genellikle evet, ama beklentiyi doğru kurun. PHP 7.4'ten 8.x'e geçişte istek başına işlem süresinde belirgin bir düşüş görülür; sunucu aynı donanımla daha fazla eşzamanlı isteği karşılar. Ancak sitenizin darboğazı yavaş veritabanı sorguları, optimize edilmemiş görseller ya da harici servis çağrılarıysa, ziyaretçinin hissettiği fark küçük kalır. Yükseltmenin asıl gerekçesi güvenlik yaması takvimidir; hız ikramiyedir.

Bir eklenti yeni PHP sürümünde hata veriyorsa ne yapmalıyım?#

Önce hatanın türüne bakın. Deprecated ise site çalışmaya devam eder, aciliyeti düşüktür ve genellikle eklentinin bir sonraki güncellemesiyle kapanır. Fatal error ise seçenekler sırayla şunlardır: eklentiyi güncelleyin, geliştiriciye hedef sürüm sorusu iletin, aynı işi yapan bakımlı bir alternatife geçin. Eklenti kodunu elle yamalamak son çaredir; ilk güncellemede değişiklik silinir ve kimse hatırlamaz.

PHP sürümünü değiştirdim ama site hâlâ eskisini gösteriyor, sebebi ne?#

Üç klasik sebep var. Birincisi, .htaccess içinde elle yazılmış AddType application/x-httpd-ea-phpXX satırlarının panel seçimini ezmesi. İkincisi, php -v çıktısına bakmanız — o komut satırı sürümünü gösterir, web sunucusunun kullandığını değil. Üçüncüsü, alt alan adları ve park edilmiş alan adlarının ayrı ayrı ayarlanması gerektiğidir. Doğrulamayı Site Sağlığı → Bilgi → Sunucu ekranından yapın.

Yükseltme sırasında sitem kapanır mı, ne kadar sürer?#

Sürüm değişikliğinin kendisi saniyeler sürer ve tipik olarak kesinti oluşturmaz; sunucu yeni isteklerden itibaren yeni yorumlayıcıyı kullanır. Riskli olan süre, değişiklikten sonraki dakikalardır: uyumsuz bir eklenti varsa hata o an ortaya çıkar. Bu yüzden işlem trafik düşükken yapılır ve ilk 30 dakika aktif olarak gözlenir. Geri alma da aynı hızdadır.

PHP 8.4 mü 8.5 mi seçmeliyim?#

2026 ortası itibarıyla çoğu WordPress sitesi için mantıklı varsayılan 8.4'tür: eklenti ekosisteminin büyük bölümü test etmiş durumda ve güvenlik yaması takvimi 2028 sonuna kadar uzanıyor. 8.5, eklenti ve temalarınızın hepsi güncel ve bakımlıysa tercih edilebilir; eski ya da lisanslı bileşenler varsa altı ay beklemek makul bir seçimdir. Hangisini seçerseniz seçin, kararı staging'deki sonuçlara göre verin.

Uyumluluk taraması temiz çıktı, staging denemesini atlayabilir miyim?#

Atlamayın. Statik tarama yalnızca kaynak kodda görebildiği kalıpları yakalar: dinamik olarak çağrılan fonksiyonlar, eval içeriği, ionCube ile şifrelenmiş dosyalar ve çalışma zamanında oluşan tip hataları taramanın kör noktasındadır. Ayrıca tarama, ödeme sağlayıcısına giden bir isteğin başarılı dönüp dönmediğini bilemez. Temiz rapor yalnızca "bilinen kalıplardan sorun çıkmadı" demektir.