WordPress PHP Sürümü Güncelleme ve Geçiş Rehberi (2026)

WordPress PHP Sürümü Güncelleme ve Geçiş Rehberi (2026)

WordPress sitenizi PHP 7.4'ten PHP 8.3'e bir tıklamayla geçirmek hem hızlı hem riskli bir karardır. Hızlıdır çünkü cPanel'in MultiPHP Manager arayüzünde sadece bir açılır menü değişikliğidir; risklidir çünkü beş yıl önce yazılmış bir eklenti veya tema, yeni PHP sürümünde "Call to undefined function" hatası fırlatıp sitenizi WSOD (White Screen Of Death) durumuna getirebilir. Üstelik bu hata bazen anasayfada çıkmaz, sadece checkout sayfasında veya WooCommerce siparişi tamamlanırken görünür — yani satışınızı kaybettikten sonra fark edersiniz.

Bu rehber sıradan bir "PHP sürümünü güncelle" yazısı değil. WordPress'e özel PHP sürüm geçiş (migration) sürecini baştan sona anlatıyor: eklenti uyumluluk pre-check'inden staging ortamına klonlama, WP-CLI ile otomatik tarama, WP_DEBUG ile fatal error yakalama, cPanel MultiPHP ile domain bazlı geçiş, 24 saatlik gözlem dönemi, ve bir şeyler ters giderse downgrade prosedürüne kadar. cPanel PHP altyapısının genel anlatımı (CloudLinux PHP Selector, MultiPHP UI'ın detayları, PHP-FPM pool, OPcache JIT genel) için ayrı bir rehberimiz var: cPanel PHP Yönetimi. Burada WordPress odağındayız.

Buyukweb perspektifi: WordPress hosting paketlerimiz ve cPanel paketlerimiz PHP 5.2'den PHP 8.4'e kadar MultiPHP desteği sunar. Bursa Tier 3 veri merkezi, CloudLinux PHP Selector ile per-user PHP override, LiteSpeed LSAPI handler, OPcache aktif, günlük yedekleme (cPanel JetBackup), ImunifyAV+ malware tarama dahildir. Sürüm geçişi sırasında bir şeyler ters giderse 0850 302 60 70 destek hattımız tek tıkla yedekten geri yükleme yapar. VDS sunucularımızda PHP-FPM kendi pool'unuzu yönetebilirsiniz (root erişim tam).

PHP Sürüm Lifecycle 2026: WordPress Açısından Hangi Sürüm Güvende?

PHP, her büyük sürümü için 2 yıl aktif bug fix + 1 yıl sadece güvenlik desteği sağlar. Toplam 3 yıllık ömrü doluştan sonra sürüm EOL (End of Life) olur ve hiçbir yama yayınlanmaz. WordPress sitenizin altında EOL PHP varsa, ortaya çıkacak her CVE (Common Vulnerabilities and Exposures) açığında çakışmaya açıksınız demektir.

2026 Mayıs itibarıyla durum:

PHP Sürümü	Çıkış	Aktif Bug Fix Sonu	Security Sonu	2026 Durumu
PHP 7.4	Kasım 2019	Kasım 2021	Kasım 2022	EOL — kullanılmamalı
PHP 8.0	Kasım 2020	Kasım 2022	Kasım 2023	EOL — kullanılmamalı
PHP 8.1	Kasım 2021	Kasım 2023	Aralık 2025	EOL oldu — geçiş zamanı
PHP 8.2	Aralık 2022	Aralık 2024	Aralık 2026	Security only — 8.3+ önerilir
PHP 8.3	Kasım 2023	Kasım 2025	Kasım 2027	Üretim için önerilen
PHP 8.4	Kasım 2024	Kasım 2026	Aralık 2028	En yeni, olgunlaşmış
PHP 8.5	Kasım 2025	Kasım 2027	Kasım 2028	Yeni, eklenti uyumluluğu izlenmeli

WordPress topluluğu açısından: WordPress core, resmi olarak PHP 7.4 minimum kabul eder, ama 8.1+ önerir. WordPress 6.x serisi PHP 7.4 desteğini koruyor; WordPress 7.x (büyük olasılıkla 2026 sonu / 2027 başı) PHP 8.1'i minimum yapacak. Yani 2026 boyunca PHP 7.4 ve 8.0 üzerinde çalışan WordPress siteleri, bir sonraki WP major sürüm yayınlandığında otomatik güncellemeyi alamayacak ve manuel müdahale gerektirecek.

Pratik karar 2026 Mayıs için:

• WordPress + standart eklenti seti → PHP 8.3 (en güvenli denge: olgun + uzun destek)
• WordPress + WooCommerce + 30+ eklenti → PHP 8.2 veya 8.3 (8.4'te bazı eski WooCommerce add-on'ları test edin)
• Eski özel/legacy eklenti var → PHP 8.1 son durak; en kısa sürede 8.2+ geçiş planı yapın
• PHP 7.4 hâlâ çalışıyor → ACİL geçiş; her geçen ay güvenlik riskidir

Neden PHP Güncellemeli? Üç Somut Fayda

1. Güvenlik: Açık Bir Versiyondan Çıkmak

EOL bir PHP sürümü, üzerinde herhangi bir kritik açık çıkması durumunda resmi yama almaz. CloudLinux gibi ticari sağlayıcılar PHP Hardened Extended Support (CloudLinux Extended Lifecycle Support) ile EOL sürümleri için arka uçta yamalar üretir ve Buyukweb cPanel paketlerinde bu hizmet aktiftir, ama bu kalıcı bir çözüm değildir. EOL sürümünde takılan bir site, dünya çapında saldırı yüzeyi haritalarında kolay hedef olarak işaretlenir.

Tipik PHP CVE türleri:

• Use-after-free zafiyetleri (RCE — Remote Code Execution potansiyeli)
• Buffer overflow PHP extension'larında (özellikle GD, imagick, mbstring)
• Integer overflow sayısal işlemlerde (denial of service)
• Type confusion unserialize() üzerinde (yetkisiz kod çalıştırma)

PHP 8.x'in modern type system ve readonly property gibi özellikleri bir kısım bu tip zafiyetleri yapısal olarak engeller (örn. typed property ile type confusion daha zordur).

2. Performans: %15-30 Hız Kazanımı

PHP 8.0'dan itibaren JIT (Just-In-Time) derleyici tracing JIT ve function JIT modlarında çalışır. WordPress gibi I/O-bound (veritabanı + dosya okuma ağırlıklı) uygulamalarda JIT'in etkisi özel hesaplama yüklü uygulamalar kadar büyük değil ama yine de gözle görülür:

Karşılaştırma	Tipik WordPress İstek Süresi	Notlar
PHP 7.4 + OPcache	100 ms (referans)	Mod_php / standart
PHP 8.0 + OPcache	85-90 ms	Type optimizasyonu, internal speedup
PHP 8.1 + OPcache + JIT	78-85 ms	Tracing JIT etkili
PHP 8.2 + OPcache + JIT	75-82 ms	Readonly class, type fixes
PHP 8.3 + OPcache + JIT	70-78 ms	typed_constants, JIT iyileştirme
PHP 8.4 + OPcache + JIT	68-75 ms	Property hooks, performans inceltme

Bu sayılar standart bir WordPress kurulumu ile alınmış sentetik testlerden derlenmiştir; gerçek hızınız sayfa tipi, eklenti yükü, sorgu sayısı ve sunucu özelliklerine göre değişir. WordPress'te en büyük kazanım PHP 7.4 → 8.0 geçişindedir (yaklaşık %15); sonraki adımlar daha küçük artımsal kazanımlar verir.

Özel hesaplama yapan workloadlar (matematiksel modelleme, ML inferencing, image manipulation) için JIT etkisi %30-50 seviyesine çıkar. WordPress'in çoğu request'i veritabanı sorgusu beklerken geçtiği için JIT katkısı görece sınırlıdır — ama OPcache + realpath cache + opcache.validate_timestamps ayarları çok daha büyük etki yapar.

3. WordPress Core Gereksinimi

WordPress topluluk, eskiden geriye dönük uyumluluğa çok düşkündü; ama PHP 5.6/7.0 desteğini sürdürmenin maliyeti yüksek olduğu için son yıllarda minimum PHP sürüm gereksinimi yükseldi. Tarihsel olarak:

• WordPress 5.0 (2018) — PHP 5.2.4 minimum
• WordPress 5.6 (2020) — PHP 5.6.20 minimum
• WordPress 6.0 (2022) — PHP 5.6.20 minimum (önerilen 7.4+)
• WordPress 6.3+ (2023+) — PHP 7.0 minimum (önerilen 7.4+)
• WordPress 7.0 (beklenen) — PHP 7.4 veya 8.1 minimum

Eklenti ve tema geliştiricileri WP core'dan daha radikal olabilir. Modern bir eklenti (örn. Elementor, WooCommerce 8.x, Yoast SEO premium) PHP 7.4 minimum gerektirebilir ve PHP 8.1+ önerebilir. PHP 7.4'te kalan site, modern eklenti güncellemesi alamaz; eski versiyonda kalır ve onun da güvenlik yaması azalır. Bir kısır döngüye girersiniz.

WP-CLI ile Pre-Check: Eklenti ve Tema Uyumluluğunu Listele

WP-CLI, WordPress'in komut satırı aracıdır ve sürüm geçişi öncesi otomatik uyumluluk kontrolü için en güvenilir yöntemdir. Buyukweb cPanel paketlerinde WP-CLI sunucuda kuruludur; SSH ile bağlanıp doğrudan kullanabilirsiniz.

Eklenti Listesi ve Sürüm Bilgisi

# SSH ile cPanel hesabınıza bağlanın
ssh [email protected]

# WordPress dizinine geçin
cd ~/public_html

# Tüm aktif eklentileri listele
wp plugin list --status=active --format=table

# Çıktı örneği:
# +--------------------+----------+-----------+---------+
# | name               | status   | update    | version |
# +--------------------+----------+-----------+---------+
# | woocommerce        | active   | none      | 8.5.1   |
# | yoast-seo          | active   | available | 21.8    |
# | elementor          | active   | none      | 3.18.2  |
# | wordfence          | active   | available | 7.11.0  |
# +--------------------+----------+-----------+---------+

Tema Listesi

wp theme list --format=table

# Aktif tema PHP gereksinimi kontrol
wp theme get astra --field=requires_php
# Çıktı: 5.6 (örnek; modern tema 7.4+ ister)

Hangi Eklenti Hangi PHP'yi İstiyor?

WP-CLI doğrudan eklenti PHP requirement'ını listelemez, ama her eklentinin ana dosyasındaki header'da Requires PHP satırı vardır:

# Tüm aktif eklenti dosyalarında Requires PHP header'ı tara
for plugin in $(wp plugin list --status=active --field=name); do
  file=$(find wp-content/plugins/${plugin} -maxdepth 2 -name "*.php" -exec grep -l "Plugin Name:" {} \; | head -1)
  php_req=$(grep -i "Requires PHP" "$file" | head -1 | sed 's/.*Requires PHP:\s*//' | tr -d '[:space:]')
  echo "${plugin}: PHP ${php_req:-belirtilmemis}"
done

Çıktı örneği:

woocommerce: PHP 7.4
yoast-seo: PHP 7.2.5
elementor: PHP 7.4
wordfence: PHP 7.4
contact-form-7: PHP 7.4

"PHP belirtilmemiş" çıkan eklentiler risk grubudur — geliştirici PHP uyumluluğunu açıkça belirtmemiş, manuel test gerekir.

Composer Tabanlı Eklenti / Tema İncelemesi

Kendi geliştirdiğiniz veya özel olarak satın aldığınız eklenti / tema Composer kullanıyorsa, composer.json içindeki PHP constraint'i kontrol edin:

cat wp-content/plugins/ozel-eklentim/composer.json | grep -A 2 '"php"'

Tipik çıktı:

"require": {
  "php": "^7.4 || ^8.0",
  "guzzlehttp/guzzle": "^7.5"
}

^7.4 || ^8.0 ifadesi: "PHP 7.4.x veya 8.0.x.x" anlamına gelir. PHP 8.1+ açıkça desteklenmediği için, sürüm geçişi öncesi composer update --with-all-dependencies ile bağımlılıkları yenilemeniz ve constraint'i >=7.4 olacak şekilde gevşetmeniz gerekebilir.

PHPCompatibility Composer Paketi ile Otomatik Tarama

PHP kodunun yeni sürümlerle uyumluluğunu denetlemek için açık kaynak bir tarayıcı vardır: phpcompatibility/PHPCompatibility (PHP_CodeSniffer üzerine kurulu sniff seti). Geliştirme makinesinde veya staging ortamında şöyle çalıştırabilirsiniz:

# Composer global kurulum
composer global require "squizlabs/php_codesniffer=*" "phpcompatibility/php-compatibility=*"

# Tüm aktif eklenti ve temayı tara
phpcs --standard=PHPCompatibility \
      --runtime-set testVersion 8.3 \
      wp-content/plugins/ wp-content/themes/

# Rapor JSON formatında çıksın
phpcs --standard=PHPCompatibility --runtime-set testVersion 8.3 \
      --report=json --report-file=php-compat.json \
      wp-content/plugins/

Çıktıda tipik uyarılar:

• "The 'each()' function has been removed since PHP 8.0" — eski WP plugin kodunda each($array) bulundu
• "The 'create_function()' has been removed since PHP 8.0" — runtime function tanımı eski
• "Curly brace syntax for string offset access is deprecated since PHP 7.4 and removed since PHP 8.0" — $str{0} yerine $str[0] kullanılmalı
• "Calling 'ReflectionMethod' on a non-callable is deprecated since PHP 8.0"

Bu uyarıların her biri bir potansiyel fatal error'a karşılık gelir. Liste eldeyken eklenti güncellemelerine bakmak veya geliştiriciye düzeltme talebi yapmak çok daha sistematik olur.

WordPress Site Health (Tools → Site Health)

WordPress 5.2'den itibaren admin panelde Site Health modülü yerleşik gelir. Tools menüsü → Site Health → Status sekmesi açın:

• "Your site is running an outdated version of PHP" — turuncu/kırmızı uyarı
• "PHP version" satırı altında mevcut sürümünüz ve önerilen sürüm
• Info sekmesinde PHP extension listesi, php.ini değerleri (memory_limit, max_execution_time vs.)

Bu modül WP-CLI olmadan da hızlı bir göz atma için kullanışlıdır. Ancak eklenti bazlı uyumluluk göstermez — sadece WP core'un kendi gereksinimini bildirir.

Staging Ortamı: Canlıyı Bozmadan Test

PHP sürüm geçişinin birinci kuralı: önce staging ortamında test et. Canlıda doğrudan değiştirip "bakalım ne olacak" stratejisi, en kötü zamanda (örn. Cuma akşamı bir alışveriş kampanyasının ortasında) çakılma getirir.

Staging Nasıl Oluşturulur?

cPanel paketinde WordPress staging için üç yaklaşım vardır:

1. WordPress Toolkit ile Staging Klonu (Plesk panelinde standart)

Plesk paketi müşterilerinde WordPress Toolkit dahili. "Clone" düğmesiyle bir tıkla staging.siteniz.com.tr alt domaini oluşturulup site kopyalanır. Plesk Toolkit Clone aşamasında bağımsız PHP sürümü seçebilirsiniz.

2. WP Staging Eklentisi (Cpanel ve diğer panellerde)

wp-staging eklentisi ile canlı site içinde siteniz.com.tr/staging/ altında bir kopya oluşturulur. Ücretsiz versiyonu çekirdek klonlama yapar; Pro versiyonu farklı subdomain'e push, dış sunucuya kopya gibi gelişmiş özellikler verir.

3. cPanel Subdomain Manuel Klon

cPanel'de subdomain oluştur → dosya yöneticisi veya WP-CLI ile site kopyala → veritabanını dump al ve yeni veritabanına yükle → wp-config.php güncelle. WP-CLI ile yapısı:

# Canlı siteyi yedekle
cd ~/public_html
wp db export ~/canli-backup.sql
tar -czf ~/canli-files.tar.gz wp-content/ wp-config.php

# Subdomain dizinine geç (cPanel'de oluşturulmuş)
cd ~/public_html/staging

# Dosyaları kopyala
tar -xzf ~/canli-files.tar.gz

# Yeni veritabanı oluştur (cPanel MySQL Databases'ten)
# Sonra DB'yi içe aktar
wp db import ~/canli-backup.sql

# wp-config.php'de DB_NAME, DB_USER, DB_PASSWORD güncelle
wp config set DB_NAME staging_db
wp config set DB_USER staging_user
wp config set DB_PASSWORD 'yeni_parola'

# URL'leri değiştir
wp search-replace 'https://siteniz.com.tr' 'https://staging.siteniz.com.tr' --all-tables

# Search engine indexlemesini kapat
wp option update blog_public 0

Bu son adım kritik — Google staging ortamını indexlemesin diye blog_public=0 yapıyoruz; ek olarak robots.txt ile staging subdomain'i Disallow: / ile kapatmak iyi pratiktir.

Staging'te PHP Sürüm Değiştir ve Test Et

cPanel MultiPHP Manager'da staging.siteniz.com.tr için yeni PHP sürümü seçin (örn. PHP 8.3). Apply'a basın, 10-30 saniye bekleyin.

Sonra manuel + otomatik test seti uygulayın:

1. Site önyüz tıklama testi — anasayfa, blog liste, blog detay, ürün liste, ürün detay, sepet, checkout, kullanıcı hesabı, iletişim formu
2. Admin paneli işlev testi — yeni yazı oluştur, eklenti güncelle, kullanıcı ekle, ayar değiştir
3. WP-CLI komutlarıyla otomatik test:

wp cron event list   # Cron job'lar sorunsuz mu?
wp post list --post_type=page --format=count   # Sayfa sayısı eşleşiyor mu?
wp option get blogname   # Temel option okunabiliyor mu?
wp plugin status   # Tüm eklenti aktif mi, hata yok mu?
wp theme status   # Tema aktif mi?

4. Error log incele — tail -f wp-content/debug.log (WP_DEBUG aktifse) ve cPanel "Errors" modülünde son 24 saatin error log'ları
5. WooCommerce varsa test sipariş — sandbox ödeme yöntemi ile gerçek bir sipariş döngüsünü tamamlayın

Bu testlerin hiçbiri fatal error vermediği ve görsel anomali olmadığı zaman canlıya geçiş için hazırsınız demektir.

WP_DEBUG ve Query Monitor ile Hata Yakalama

PHP sürüm geçişi sırasında deprecation notice ve warning'leri yakalamak için WordPress'in debug modunu aktif edin. wp-config.php dosyanıza şu satırları ekleyin:

// wp-config.php — DB tanımlamalarından SONRA, "/* That's all, stop editing!" SATIRINDAN ÖNCE
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );          // wp-content/debug.log'a yaz
define( 'WP_DEBUG_DISPLAY', false );     // Ekranda gösterme (canlı/staging için)
define( 'SCRIPT_DEBUG', true );          // Minimize edilmemiş JS/CSS yükle
@ini_set( 'display_errors', 0 );

// Sorgu logları
define( 'SAVEQUERIES', true );

Ardından siteyi normal şekilde gezdiğinizde her PHP notice, warning, deprecated ve fatal error wp-content/debug.log dosyasına yazılır:

# Canlı izleme
tail -f wp-content/debug.log

# Tipik çıktı:
# [11-May-2026 14:32:01 UTC] PHP Deprecated: Function strftime() is deprecated in /home/user/public_html/wp-content/plugins/eski-plugin/inc/date-helper.php on line 47
# [11-May-2026 14:32:15 UTC] PHP Warning: Trying to access array offset on value of type null in /home/user/public_html/wp-content/themes/ozel-tema/functions.php on line 128
# [11-May-2026 14:33:02 UTC] PHP Fatal error: Uncaught Error: Call to undefined function each() in /home/user/public_html/wp-content/plugins/eski-plugin/inc/loop.php:88

Her bir satır bir geliştirici eylem maddesidir. Ya eklentinin yeni sürümüne geçilecek ya eklenti devre dışı bırakılacak ya da koda yama yapılacak.

Query Monitor Eklentisi

wp plugin install query-monitor --activate

Query Monitor admin bar'da bir sekme oluşturur ve her sayfa yüklemesi için çalışan sorgular, PHP hataları, hook'lar, conditional'lar, çağrılan eklentiler ve süreleri listeler. PHP sürüm geçişi sonrası hata avı için en iyi araçtır.

Önemli: Query Monitor sadece giriş yapmış admin için gösterilir; canlıda bırakabilirsiniz, ziyaretçi performansını etkilemez. Ama bellek ek yükü var — uzun süreli üretim kullanımı için debug edildikten sonra deaktif edin.

Sürüm Geçiş Prosedürü: Adım Adım

Tüm hazırlık tamamlandıktan sonra fiili sürüm geçişi şu adımlarla yapılır:

Adım 1: Tam Yedek

cPanel'de JetBackup → "Generate Backup" → Full Account Backup oluşturun. Saklayın (yerel makinenize indirin). Bu sürüm sonrası rollback için sigortanızdır.

Buyukweb cPanel paketlerinde günlük otomatik yedekleme zaten aktif; ancak sürüm geçişi öncesi manuel + güncel bir yedek almak iyi pratiktir.

Adım 2: Eklenti ve Temayı Güncel Yap

Eski eklentinin yeni PHP'de sorun çıkarma olasılığı, güncel eklentiden çok daha yüksektir. Geçiş ÖNCESİ tüm eklentileri ve temayı en son sürüme güncelleyin:

wp plugin update --all
wp theme update --all
wp core update
wp core update-db

Premium eklenti / tema lisansınız varsa, lisans aktifse otomatik güncelleme alır; yoksa manuel zip yükleyin.

Adım 3: Staging'te Test Et

Yukarıdaki "Staging Ortamı" bölümünü uygulayın. Staging'te PHP 8.3'e geçin, manuel + otomatik test setini tamamlayın, debug.log temiz olduğunu (fatal yok) doğrulayın.

Adım 4: Düşük Trafikli Bir Saat Seç

Trafik analitiklerinizi açın (Buyukweb sunucularında AWStats veya Google Analytics). En düşük trafikli zaman dilimini belirleyin — genelde Türkiye için sabah 04:00-07:00 arası veya Cumartesi sabah erken saatler.

Adım 5: cPanel MultiPHP Manager ile Sürüm Değiştir

cPanel > Software > MultiPHP Manager
  1. Domain listesinde siteniz.com.tr'yi bulun
  2. "PHP Version" sütunundaki açılır menüyü tıklayın
  3. PHP 8.3 (önerilen) veya 8.4 seçin
  4. "Apply" butonuna basın
  5. 10-30 saniye bekleyin

Alternatif: SSH üzerinden .htaccess ile direkt handler ataması:

# public_html/.htaccess
AddHandler application/x-httpd-lsphp83 .php

(MultiPHP Manager UI'ı yeniyse .htaccess direktifini ezer; sadece UI'da yapın daha güvenli.)

Adım 6: Sayfa Önbelleğini Temizle ve OPcache'i Resetle

# OPcache reset (PHP-FPM restart eşdeğeri)
wp cli alias add @prod --path=/home/user/public_html
wp eval "opcache_reset();" --path=/home/user/public_html

# WordPress object cache (varsa Redis/Memcached) temizle
wp cache flush

# Eğer cache plugin varsa (LiteSpeed Cache, W3 Total Cache, WP Super Cache):
wp litespeed-purge all   # LiteSpeed Cache eklentisi
# veya admin panel: Settings → Cache → Purge All

Adım 7: 24 Saat Gözlem ve Monitoring

Sürüm değiştikten sonra 24 saat aktif gözlem dönemi başlatın:

• debug.log izle — tail -f wp-content/debug.log her saat başı kontrol
• cPanel Error Pages modülü — 500/502/504 hataları görüntü
• Uptime monitoring — UptimeRobot, Better Uptime, Hetrix gibi servisle 1 dakikalık ping kontrolü
• Admin paneli — ödeme, form gönderme, eklenti güncelleme, yazı yayınlama gibi temel akışları manuel test edin
• Sitemap + Search Console — Google Search Console'da yeni indeksleme hatası geliyor mu

24 saat sorunsuz geçerse sürüm geçişi başarılı kabul edilir. Yedekleri tutmaya devam edin (en az 1 hafta), debug log'u arşivleyip WP_DEBUG'ı kapatın (canlıda log dosyası şişirmesin diye).

Rollback / Downgrade Prosedürü: İşler Ters Giderse

Nadiren — ama bazen — yeni PHP'de uygulanamaz bir hata çıkar. Ya bir eklentinin geliştiricisine ulaşamazsınız ya gelir kaybını göze alamazsınız. Bu durumda eski PHP sürümüne geri dön (rollback) yapılır:

Hızlı Rollback (cPanel)

cPanel > Software > MultiPHP Manager
  1. Domain'i seç
  2. PHP Version listesinden önceki sürümü (örn. PHP 8.1) seç
  3. Apply'a bas
  4. 10-30 saniye bekle
  5. Site tekrar açıldı mı kontrol et

Bu işlem dosyada ve veritabanında değişiklik yapmaz — sadece hangi PHP sürümünün isteklere bakacağını söyler. Yani geri alınabilir bir işlemdir.

Tam Site Rollback (yedekten geri yükleme)

Eğer rollback sırasında veritabanı veya dosyalar değişmişse (eklenti güncellemesi yapılmış, içerik yayınlanmış) tam restore gerekir:

cPanel > Files > JetBackup 5
  > "Restore" sekmesi
  > Tarihten önce alınan yedek seçilir
  > "Restore" butonuna basılır
  > 5-30 dakika içinde site restore olur

Buyukweb cPanel paketlerinde günlük yedek mevcuttur; günün herhangi bir saatinden geri dönüş genelde son 24 saat içindeki bir nokta seçilerek yapılabilir. JetBackup retention varsayılan 30 gün — yani son 30 günün herhangi bir gününe geri gidebilirsiniz.

Eklenti Sürüm Rollback

Yeni PHP'de yeni eklenti sürümü patladıysa, sadece eklentinin sürümünü düşürmek yeterli olabilir:

wp plugin install woocommerce --version=8.4.0 --force
# Veya WP Rollback eklentisi ile admin panelden:
wp plugin install wp-rollback --activate
# Sonra admin > Plugins > eklenti adı > "Rollback" tıklayın

WP Rollback eklentisi, WordPress.org repo'sundaki eski sürümlere geçişi kolaylaştırır. Premium eklentilerde geliştiriciden eski sürüm zip dosyasını talep etmeniz gerekir.

Eklenti / Tema Uyumsuzluk Debug: Tipik Hatalar ve Çözümleri

PHP 8.x'e geçişte en sık karşılaşılan WordPress eklenti / tema hataları:

1. "Call to undefined function each()"

each() fonksiyonu PHP 8.0'da kaldırıldı. Eski eklentilerde sıkça görülür.

Çözüm: Eklentiyi son sürümüne güncelleyin; modern WordPress eklentilerinin tamamı bunu kaldırmıştır. Eski premium/özel eklenti için foreach ile değiştirin:

// ESKİ (PHP 8.0'da fatal)
while (list($key, $value) = each($array)) { ... }

// YENİ
foreach ($array as $key => $value) { ... }

2. "Call to undefined function create_function()"

create_function() PHP 8.0'da kaldırıldı. Genelde eski tema veya widget eklentilerinde.

Çözüm: Anonim fonksiyon (closure) kullanın:

// ESKİ
$sort = create_function('$a, $b', 'return strcmp($a["name"], $b["name"]);');

// YENİ
$sort = function($a, $b) { return strcmp($a['name'], $b['name']); };

3. "Cannot use isset() on the result of a function call"

Bu eski PHP 7.x'te warning'di, PHP 8.0+'da fatal. Eski form / validation eklentilerinde.

// ESKİ — fatal PHP 8.0+
if (isset(get_option('my_option'))) { ... }

// YENİ
$val = get_option('my_option');
if ($val !== false) { ... }

4. "Trying to access array offset on value of type null"

Sıklıkla null dönen get_post_meta() veya get_user_meta() sonuçlarına dizi gibi erişmeye çalışıldığında.

// SORUNLU
$meta = get_post_meta($post_id, 'detaylar', true);
$ad = $meta['ad'];  // $meta string veya '' olabilir → fatal

// GÜVENLİ
$meta = get_post_meta($post_id, 'detaylar', true);
$ad = (is_array($meta) && isset($meta['ad'])) ? $meta['ad'] : '';

5. "Deprecated: strftime() is deprecated"

PHP 8.1'de strftime() deprecated; PHP 9'da kaldırılacak. WordPress'in date_i18n() veya wp_date() fonksiyonu ile değiştirilmeli.

// ESKİ
echo strftime('%d %B %Y', $timestamp);

// YENİ
echo wp_date('j F Y', $timestamp);

6. "Cannot pass parameter by reference"

PHP 8.0+'da call_user_func_array çağrılarında ref ile geçiş daha sıkı. Tipik eski filter hook kullanımlarında.

// ESKİ — PHP 8.x'te warning/error
add_filter('the_content', array($this, 'filter_method'), 10, 1);
// filter_method($content) içinde $content değişiyor ama by-value alınmış

// YENİ — referans dönen değer kullanın
public function filter_method($content) {
    return modify($content); // değiştirilmiş içeriği döndürün
}

7. Eklenti Bisection (Bisection Debug)

Hangi eklentinin soruna yol açtığını bilmiyorsanız ikilik arama uygulayın:

# Tüm eklentileri deaktive et
wp plugin deactivate --all

# Site açılıyor mu? Evet → eklentilerin biri sorunlu
# Hayır → tema sorunlu (varsayılan WP temasına geç: wp theme activate twentytwentyfour)

# Eklentilerin yarısını aktif et
wp plugin activate $(wp plugin list --status=inactive --field=name | head -n 10)

# Site açılıyor mu? Açılmıyorsa sorun bu yarıda
# Bu yarıyı tekrar ikiye böl, devam et

# Hızlı yöntem: tek tek aktif et + her aktifleştirmeden sonra debug.log kontrol
for plugin in $(wp plugin list --field=name); do
  wp plugin activate $plugin
  echo "--- $plugin aktif ---"
  tail -5 wp-content/debug.log
done

Bisection 30-60 dakikada suçlu eklentiyi tespit eder. Sonra geliştiricisine bildirin veya alternatif eklentiye geçin.

php.ini Ayarları: WordPress İçin Kritik Değerler

PHP sürümünü değiştirmek yeterli değildir; php.ini ayarlarının da sürümden sürüme aynı kaldığını doğrulamanız gerekir. Buyukweb cPanel'de iki yol var: MultiPHP INI Editor (her domain için ayrı) ve PHP Selector Options (CloudLinux LVE — kullanıcı bazlı).

Kritik direktifler ve önerilen değerler:

Direktif	Tipik WordPress Önerisi	WooCommerce Önerisi	Açıklama
memory_limit	256M	512M	Eklenti yükü + büyük tema için
max_execution_time	120 (saniye)	300	Uzun süren import/export işlemleri
max_input_time	120	300	Form gönderim süresi
post_max_size	64M	128M	Tek POST içeriği max boyutu
upload_max_filesize	64M	128M	Tek dosya yükleme max
max_input_vars	3000	5000+	Form alanı sayısı; WooCommerce için kritik
max_file_uploads	20	50	Aynı anda yüklenen dosya sayısı
default_charset	UTF-8	UTF-8	TR karakter sorunları için
date.timezone	Europe/Istanbul	Europe/Istanbul	TR saat dilimi
opcache.enable	1	1	OPcache aktif
opcache.memory_consumption	256	512	OPcache RAM (MB)
opcache.max_accelerated_files	20000	30000	WP + eklenti dosya sayısı
opcache.validate_timestamps	1	1	Geliştirme sırasında 1, prod'da 0 düşünülebilir
opcache.revalidate_freq	2	2	2 saniyede bir dosya değişimi kontrol
opcache.jit_buffer_size	100M	100M	JIT için ayrı RAM
opcache.jit	tracing	tracing	Tracing JIT (varsayılan)
realpath_cache_size	4096K	8192K	Büyük WP'de I/O hızlandırıcı
realpath_cache_ttl	600	600	Cache yaşam süresi (saniye)

MultiPHP INI Editor (cPanel)

cPanel > Software > MultiPHP INI Editor
  > Basic Mode: yaygın ayarlar tek tek
  > Editor Mode: tam php.ini görünümü, tüm direktifler

Domain seçin → değerleri girin → Apply

PHP Selector — Per-User Override

cPanel > Software > Select PHP Version
  > "PHP Options" sekmesi
  > Modül listesi + ini değerleri

Buradan değiştirilen değerler **kullanıcı bazlı**dır; tüm domain'lerinizi etkiler.

.htaccess ile (Bazı Direktifler — Apache/LiteSpeed)

# public_html/.htaccess
php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_input_vars 3000

Önemli: LiteSpeed LSAPI ortamında .htaccess php_value direktifleri genelde çalışır, ancak cPanel MultiPHP INI Editor öncelik taşır. Çakışma varsa UI kazanır.

OPcache ve JIT: WordPress'te Doğru Ayarlar

OPcache, PHP scriptlerinin bytecode'unu RAM'de tutarak her isteğin yeniden parse + compile maliyetini ortadan kaldırır. WordPress için doğru ayarlanmış OPcache, tek başına %30-50 hız artışı sağlar — JIT'ten çok daha büyük etki yapar.

Önerilen OPcache Ayarları (php.ini)

opcache.enable = 1
opcache.enable_cli = 0
opcache.memory_consumption = 256          ; MB, büyük WP için 512
opcache.interned_strings_buffer = 16      ; MB
opcache.max_accelerated_files = 20000     ; WP + eklenti + temalar
opcache.validate_timestamps = 1           ; dev için 1, prod için 0 düşünülebilir
opcache.revalidate_freq = 2               ; saniye
opcache.fast_shutdown = 1
opcache.save_comments = 1                 ; WP doc-block reflection için zorunlu
opcache.enable_file_override = 0
opcache.huge_code_pages = 0               ; bazı kernel sürümlerinde sorun çıkarır

JIT Ayarları (PHP 8.0+)

opcache.jit_buffer_size = 100M
opcache.jit = tracing                     ; veya 1255 (sayı formu)
opcache.jit_max_recursive_calls = 2
opcache.jit_max_recursive_returns = 2

JIT modları:

• tracing (önerilen) — sık çalışan kod yollarını runtime'da derler
• function — fonksiyon bazında derleme (daha az agresif)
• disable — JIT kapalı (memory limit veya stabilite için)

WordPress'in çoğu request'i I/O-bound olduğu için JIT etkisi sınırlıdır; ancak özel framework'lü WP siteleri (custom Gutenberg block, headless WP, REST API ağırlıklı) için tracing JIT %5-15 ek hız sağlar.

Realpath Cache (Büyük WP'de Kritik)

WordPress, her request'te 100-500 dosya açar (core + eklenti + tema). Bu dosyaların tam yol çözümlemesi (realpath()) maliyetlidir. Realpath cache bu sonuçları RAM'de tutar.

realpath_cache_size = 4096K               ; standart WP
realpath_cache_size = 8192K               ; 50+ eklentili WP
realpath_cache_ttl = 600                  ; 10 dakika

Büyük WP sitelerinde realpath cache'i 2-4 katına çıkarmak request başına 10-50ms tasarruf sağlar.

OPcache Durum Kontrolü

# WP-CLI ile durumu görüntüle
wp eval 'print_r(opcache_get_status(false));'

# Veya bir PHP dosyasında:
# opcache-status.php
<?php
echo "<pre>";
print_r(opcache_get_status(false));
print_r(opcache_get_configuration());
?>

Çıktıda dikkat edilecekler:

• memory_usage.current_wasted_memory — yüksekse OPcache full, memory_consumption artırın
• opcache_statistics.hits vs misses — hit ratio %95+ olmalı
• statistics.hash_restarts — sıfıra yakın olmalı; yüksekse max_accelerated_files artırın

PHP-FPM Pool Tuning (Buyukweb VDS Müşterileri)

VDS sunucu müşterilerimizde PHP-FPM kendi pool'unuzu yönetebilirsiniz (root erişim tam). PHP-FPM, statik veya dinamik proses havuzu ile istekleri karşılar.

Tipik WordPress PHP-FPM Pool Config

/etc/php/8.3/fpm/pool.d/wordpress.conf:

[wordpress]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm-wordpress.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Process Manager - dinamik (önerilen WP için)
pm = dynamic
pm.max_children = 50           ; (RAM / proses başı) — 8 GB VDS için 50 uygun
pm.start_servers = 10           ; başlangıçta hazır proses
pm.min_spare_servers = 5        ; minimum boşta
pm.max_spare_servers = 20       ; maksimum boşta
pm.max_requests = 500           ; proses başına max istek sonra restart (memory leak'e karşı)
pm.process_idle_timeout = 30s

; Hız ve güvenlik
request_terminate_timeout = 120s
request_slowlog_timeout = 5s
slowlog = /var/log/php/wordpress-slow.log

; Session
php_admin_value[session.save_path] = /var/lib/php/sessions/wordpress
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
php_admin_value[memory_limit] = 256M
php_admin_value[max_execution_time] = 120

pm.max_children Hesaplama

pm.max_children = (Toplam_RAM - sistem_overhead) / proses_basina_RAM

Örnek:

• VDS: 8 GB RAM
• Sistem overhead (kernel + MariaDB + Nginx + diğer): 2 GB
• WP proses başına ortalama: 80-150 MB
• max_children = (8192 - 2048) / 120 = 51 proses

Çok yüksek max_children → swap, OOM kill; çok düşük → request kuyruğa düşer, yavaşlama. Doğru ayar trafik testiyle bulunur.

slowlog Analizi

request_slowlog_timeout = 5s ile 5 saniyeden uzun süren WP request'leri /var/log/php/wordpress-slow.log'a yazılır. Backtrace dahil. Yavaş eklenti veya sorgu tespiti için altın madeni.

Buyukweb Karar Matrisi: cPanel MultiPHP mi, VDS PHP-FPM mi?

Hangi yol sizin için doğru?

Senaryo	Trafik (günlük PV)	Eklenti Sayısı	Önerilen Paket
Küçük blog / kurumsal	0-1.000	5-15	cPanel Başlangıç
KOBİ web sitesi + blog	1.000-10.000	15-30	cPanel Performans / Uçak
WooCommerce 50-500 ürün	5.000-25.000	30-50	cPanel Uçak / Jet
WooCommerce 500+ ürün, yüksek trafik	25.000-100.000	50+	VDS Sunucu — kendi PHP-FPM pool
Multisite ağı, 10+ alt site	Değişken	Site başına 10-20	VDS Sunucu — site başına ayrı pool
Headless WP / REST API	Yüksek API çağrısı	API + 5-10	VDS Sunucu — JIT optimizasyonu

cPanel paylaşımlı paket size yeterli mi diye sormak için kontrol listesi:

• Saatlik request 50.000'in altında mı?
• Toplam aktif eklenti 60'ın altında mı?
• Site dosya boyutu 5 GB'ın altında mı?
• Veritabanı boyutu 2 GB'ın altında mı?
• Özel PHP-FPM pool tuning ihtiyacı yok mu?

Tümü "Evet" ise cPanel paylaşımlı paket sizin için doğru. Bir veya birkaç "Hayır" varsa VDS'e geçiş düşünülmeli.

Realist Geçiş Zaman Planı

PHP sürüm geçişi acil bir iş değil; ancak ertelenebilir de değil. Tipik bir profesyonel geçiş zaman planı:

Faz	Süre	Aktivite
Hazırlık	3-5 gün	Eklenti / tema güncellemeleri, PHPCompatibility tarama, WP-CLI envanteri
Staging	1-2 gün	Staging klonu, sürüm değişimi, test seti, debug.log analizi
Bekleme	2-3 gün	Tespit edilen sorunlar için eklenti güncellemesi veya alternatif
Geçiş	1 saat	Tam yedek, MultiPHP sürüm değişimi, cache temizliği
Gözlem	1-3 gün	24-72 saat aktif izleme, debug.log + uptime monitoring
Stabilizasyon	1 hafta	Sorun yoksa WP_DEBUG kapat, yedekler arşive

Toplam yaklaşık 1-2 haftalık bir süreçtir. Acele etmeyin — bir-iki hafta ertelemek, çakılma maliyetinden çok daha düşüktür.

Sık Sorulan Sorular (SSS)

"Sitem hâlâ PHP 5.6'da. Ne yapayım?"

PHP 5.6, 2018'den beri EOL — yani 7+ yıl güvenlik güncellemesi almayan bir sürümdür. Kesinlikle ve acilen geçiş yapılmalı, ancak direkt 8.3'e atlamayın. Ara adım izleyin: 5.6 → 7.4 → 8.1 → 8.3. Her ara adımda staging'te test edin. Eski tema / eklentiler PHP 8 ile patlar; her ara adımda en az 5-10 deprecation / fatal beklemelisiniz. Geliştirici desteği olmayan bir tema veya eklenti, modern bir alternatifle değiştirmeniz gerekebilir.

"WP-CLI'ım yok, panel arayüzünden yapabilir miyim?"

Evet. cPanel MultiPHP Manager arayüzü tek başına yeterlidir — açılır menüden PHP sürümü seçin, Apply'a basın. WP-CLI olmadan da WordPress Site Health (Tools → Site Health) sayfasında bir kısım uyumluluk uyarısı görürsünüz. Ama eklenti bazlı PHP requirement görmek için WP-CLI çok daha verimli; SSH erişimini destek hattımızdan açabilirsiniz.

"Eklentilerim PHP 8.3 ile uyumlu olduğunu söylemiyor ama eski tek alternatifim de yok. Ne yapmalıyım?"

Üç seçenek var:

1. Geliştiriciyle iletişime geç — eklentinin geliştiricisine bir destek talebi açın, PHP 8.3 uyumluluk planı sorun. Çoğu modern eklenti zaten uyumludur; sadece "Tested up to" header'ı güncellenmemiş olabilir.
2. Staging'te test et — uyumluluğu yazılı belirtmemiş olsa bile, modern PHP'de çalışabilir. Staging'te çalıştığını doğrulayın, debug.log temizse canlıya geçin.
3. Alternatif eklentiyi araştırın — aynı işlevi sağlayan modern, aktif güncel bir eklentiye geçin. Migration eklenti veri taşıması için ek emek gerektirebilir.

"Geçiş sırasında sitem ne kadar süre offline kalır?"

cPanel MultiPHP Manager üzerinden sürüm değişikliği 5-30 saniye sürer. Bu süre içinde 1-2 request belki 502 alabilir, ama "siteniz kapandı" değil "anlık dalgalanma" anlamına gelir. Genelde ziyaretçi fark etmez. Düşük trafik saatinde yaparsanız risk en aza iner. Bazı durumlarda cache temizliği için ek 1-2 dakika gerekebilir.

"Yönetilen WordPress hosting'iniz var mı?"

Buyukweb şu an için resmi "yönetilen WordPress" markası altında bir paket sunmuyor. Ancak WordPress hosting paketlerimizde MultiPHP desteği, LiteSpeed Cache entegrasyonu, günlük yedekleme, ImunifyAV+ malware tarama ve 0850 302 60 70 destek hattı dahildir. Sürüm geçişi, eklenti uyumluluk debug, php.ini ayarları için destek ekibimiz size yardımcı olur. Tam yönetilen managed servis (sizin yerinize sürüm değişimi yapma, eklenti audit'i yapma) için destek hattımızdan kurumsal danışmanlık görüşmesi planlayabilirsiniz.

"Ücretsiz WordPress migration sunuyor musunuz?"

Yeni müşterilerimize standart WordPress migration desteği veriyoruz: mevcut hostingden Buyukweb'e geçişte siteyi taşımak için destek ekibimiz devreye girer. Sürüm geçişi ile birlikte migration paketleri için 0850 302 60 70 numarasını arayın veya iletişim sayfasından yazın. Migration sırasında PHP sürüm güncellemesi otomatik dahil edilebilir.

"Downgrade yaptım, ama eski sürümde de aynı hata var. Ne oldu?"

Genelde eklenti güncellemesi sorun çıkardı (PHP sürümü değil). Eklenti güncellemesi PHP sürümünden bağımsızdır; eski sürüme dönmek dosyaları geri almaz. Bu durumda JetBackup ile tam restore gerekir — geçiş öncesi aldığınız yedekten geri yükleyin. Veya eklenti rollback yapın: wp plugin install <ad> --version=<eski> --force veya WP Rollback eklentisi.

"PHP 8.4'e mi 8.3'e mi geçeyim?"

2026 Mayıs itibarıyla:

• PHP 8.3 — 1.5 yıllık olgunluk, eklenti uyumluluk %95+, security desteği Kasım 2027'ye kadar. Önerilen.
• PHP 8.4 — 6 aylık olgunluk, eklenti uyumluluk %85-90, security desteği Aralık 2028'e kadar. En son özellik isteyen ve test yapacak vakti olanlar için.

Riski en aza indirmek için PHP 8.3 ile başlayın, 6 ay sonra 8.4'e geçişi planlayın. WordPress 7.0 yayınlandığında muhtemelen 8.4 minimum olacak — yine de ertelemeden geçiş yapılmasını öneririz.

Sonuç: Hazırlanmış Geçiş Riski En Aza İndirir

PHP sürüm güncellemesi WordPress için opsiyonel değildir — güvenlik, performans ve gelecek uyumluluğun gereğidir. Ancak hazırlıksız bir geçiş, üretim sitenizi çakabilir ve gelir kaybı yaratabilir. Bu rehberin özeti:

1. PHP 7.4 ve 8.0 EOL — kullanıyorsanız acil geçiş zamanı
2. 2026 öneri sürümü: PHP 8.3 (olgun + uzun destek)
3. WP-CLI ile pre-check — eklenti / tema uyumluluk envanteri
4. PHPCompatibility tarayıcı ile kod uyumluluk testi
5. Staging ortamında zorunlu test — WP_DEBUG aktif, debug.log incele
6. cPanel MultiPHP Manager ile domain bazlı sürüm değişimi
7. 24 saat aktif gözlem sonrası geçiş kabul
8. JetBackup ile günlük yedek — rollback için sigorta
9. php.ini ayarlarını kontrol et — memory_limit, max_input_vars (WooCommerce için 3000+)
10. OPcache + JIT doğru ayarlanırsa %30-50 hız artışı

Sürüm geçişi planlamanız, eklenti uyumluluk denetimi, staging klonu, php.ini ayarları veya VDS PHP-FPM pool tuning konularında destek için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezi, günlük yedekleme, ImunifyAV+ ve PHP 5.2-8.4 MultiPHP desteğiyle yanınızdayız.

---

İlgili Büyükweb Hizmetleri

• WordPress Hosting — MultiPHP, LiteSpeed Cache, günlük yedek, ImunifyAV+
• cPanel Web Hosting — PHP 5.2-8.4 MultiPHP Manager, CloudLinux PHP Selector
• Plesk Hosting — WordPress Toolkit, Smart Updates, staging
• VDS Sunucu — Root erişim, PHP-FPM kendi pool, JIT optimizasyonu
• cPanel PHP Yönetimi Rehberi — php.ini, OPcache, PHP-FPM detay
• WordPress Hosting Seçim Rehberi — Paket karşılaştırma