PHP Sürüm Geçişi: Uyumluluk Testi, Çoklu Sürüm ve Geri Dönüş

PHP sürümünü panelden değiştirmek iki saniye sürer. Sonrasında eski bir özel eklentinin, tema fonksiyonunun veya gece çalışan bir cron betiğinin fatal error verdiğini fark etmek bazen günler alır; çünkü sitenin yalnız bir bölümü sessizce çalışmaz hale gelir. Ana sürüm geçişini bu yüzden bir ayar değişikliği olarak değil, uyumluluk analizi, çoklu sürümle kademeli geçiş ve yazılı geri dönüş planından oluşan bir iş olarak ele alıyoruz. Aşağıdaki adımlar WordPress ve özel PHP uygulamaları yöneten sistem yöneticileri ve geliştiriciler için.

PHP sürümünü güncel tutmanın gerekçeleri

Her PHP ana dalının önce aktif destek, ardından yalnız güvenlik düzeltmesi aldığı bir dönemi vardır; bu süre dolunca dal için resmi güvenlik yaması çıkmaz. Güncel tarihler php.net’in desteklenen sürümler sayfasında yayımlanır; planlamayı bu sayfaya göre yapın.

Sık atlanan bir ayrıntı: Debian, Ubuntu LTS ve RHEL gibi dağıtımlar, kendi depolarındaki PHP paketlerine dağıtım destek süresi boyunca güvenlik yamalarını geri taşıyabilir. Yani php.net’te desteği bitmiş görünen bir sürüm numarası, dağıtımın güvenlik desteği sürdükçe yama alıyor olabilir. Üçüncü taraf depolardan (ör. Debian/Ubuntu için Ondřej Surý’nin depoları, RHEL tabanlı sistemler için Remi deposu) kurulan sürümlerde bu geri taşımayı beklemeyin. Önce paketin nereden geldiğine bakın. Sonra karar verin.

Güvenlik dışındaki gerekçe bağımlılık zinciridir: WordPress çekirdeği, eklentiler ve Composer bağımlılıkları zamanla eski PHP sürümlerinin desteğini bırakır. Eski PHP’de kalan site, bir noktada güvenlik düzeltmesi içeren eklenti sürümünü de kuramaz hale gelir. Bu zinciri WordPress güncelleme politikası ile birlikte planlayın.

Uyumluluk analizi ve statik tarama

Amaç, geçişten önce “hangi kod yeni sürümde kırılır?” sorusuna olabildiğince kesin yanıt vermek. İki tamamlayıcı yöntem kullanılır: statik tarama ve çalışma zamanı gözlemi. Biri diğerinin yerini tutmaz.

Envanter

Önce taranacak kodun envanterini çıkarın: özel tema ve eklentiler, mu-plugins, sunucudaki cron betikleri, Composer ile gelen kütüphaneler. Sahada en sık unutulan kalem, yıllar önce birinin /root veya ev dizinine bıraktığı ve crontab’dan çağrılan tek dosyalık PHP betikleridir. Kamuya açık eklentilerde ilk kontrol, güncel sürümün hedef PHP sürümünü desteklediğini belirtip belirtmediği ve aktif bakım görüp görmediğidir; uzun süredir güncellenmeyen bir eklenti, tarama sonucundan bağımsız olarak risklidir. Eklenti envanterinin nasıl tutulacağını WordPress eklenti seçimi ve envanter yönetimi yazısında anlattık.

PHPCompatibility ile tarama

PHPCompatibility, PHP_CodeSniffer için yazılmış bir kural setidir; kodda hedef sürümde kaldırılmış veya davranışı değişmiş yapıları arar. WordPress projeleri için, WordPress’in kendi uyumluluk katmanlarını hesaba katan PHPCompatibilityWP paketi vardır:

composer require --dev phpcompatibility/phpcompatibility-wp:"*"

vendor/bin/phpcs -p wp-content/themes/kurumsal-tema \
    wp-content/plugins/ozel-eklenti \
    --standard=PHPCompatibilityWP \
    --runtime-set testVersion 8.3- \
    --extensions=php \
    --report=summary

testVersion 8.3-, kodun PHP 8.3 ve sonrasıyla uyumlu olup olmadığını denetler. Önemli sınırlama: PHPCompatibility’nin kapsadığı PHP sürümleri, kullandığınız PHPCompatibility sürümüne bağlıdır. Uzun süre kararlı hat olarak kalan 9.x serisi ağırlıklı olarak PHP 7.4’e kadarki değişiklikleri denetler; PHP 8.x kontrolleri 10.x hattıyla gelmektedir. Kurduğunuz sürümün hedef PHP değişikliklerini kapsayıp kapsamadığını proje sayfasından kontrol edin. Kapsamıyorsa “temiz” sonuç yanıltıcıdır.

Statik tarama, değişken türüne bağlı hataları yakalayamaz; bir fonksiyona çalışma zamanında null gelip gelmeyeceği koddan her zaman anlaşılmaz. İkinci adım, staging’de uygulamayı yeni sürümle çalıştırıp hataları kaydetmektir:

; staging php.ini (veya havuz yapılandırmasında php_admin_value)
error_reporting = E_ALL
display_errors  = Off
log_errors      = On
error_log       = /var/log/php/staging-php83.log

Ardından kritik akışları (form gönderimi, sipariş, arama, yönetim paneli işlemleri, içe/dışa aktarma) elle veya otomatik testlerle çalıştırın ve logu okuyun. Deprecated uyarıları bugün bir şey kırmaz; ama bir sonraki ana sürümde hataya dönüşecek noktaların listesidir.

Sık karşılaşılan uyumsuzluklar

PHP 7.x’ten 8.x’e geçişte çıkan sorunların büyük bölümü birkaç gruba girer. Tablo eksiksiz değildir; her ana sürüm için php.net kılavuzundaki geçiş (migration) bölümlerini esas alın.

Sürüm	Değişiklik	Tipik belirti
8.0	each(), create_function() kaldırıldı	Eski tema/eklentide fatal error
8.0	Birçok uyarı TypeError/ValueError istisnasına dönüştü (ör. sayılamayan değere count())	Önceden uyarıyla geçen kod durur
8.0	Sayı ile sayısal olmayan dize karşılaştırması değişti (0 == "abc" artık false)	Koşullarda sessiz mantık farkı
8.1	Yerleşik fonksiyonların null kabul etmeyen parametrelerine null geçmek kullanımdan kaldırıldı	Loglarda yoğun Deprecated uyarısı
8.2	Dinamik özellik (tanımsız property) oluşturma kullanımdan kaldırıldı	Eski sınıflarda Deprecated uyarısı
8.4	Örtük nullable parametre türleri kullanımdan kaldırıldı	Varsayılanı null olan tipli parametrelerde uyarı

Sayı–dize karşılaştırması en sinsi olanıdır. Hata vermez; yalnız koşulun sonucu değişir. Statik tarama bu satırları her zaman işaretleyemez. Gevşek karşılaştırma (==) kullanan form doğrulama, yetki kontrolü ve fiyat hesaplama kodunu elle gözden geçirin.

Uyumsuzluğun bir kaynağı da sunucunun kendisidir. Yeni sürüm için PHP eklentilerinin (mbstring, intl, gd, imagick, redis vb.) ayrıca kurulması gerekir; özel php.ini ayarları yeni sürümün yapılandırma dizinine aktarılmalıdır. Eski dosyayı olduğu gibi kopyalamayın; yalnız değiştirilmiş değerleri taşıyın, yeni sürümün varsayılanları korunsun. Eksik modül, “site beyaz ekran verdi” şikâyetinin en sık nedenlerinden biridir ve tek komutla görülür:

# İki sürüm arasındaki yüklü modül farkı
diff <(php8.1 -m | sort) <(php8.3 -m | sort)

Aynı sunucuda çoklu PHP sürümü

PHP-FPM’de her sürüm ayrı bir servis olarak çalışır ve kendi soketini açar. Bu sayede aynı sunucuda siteleri tek tek yeni sürüme taşıyabilirsiniz. Debian/Ubuntu’da yaygın düzen:

apt install php8.3-fpm php8.3-mysql php8.3-mbstring php8.3-xml \
            php8.3-curl php8.3-gd php8.3-intl php8.3-zip

systemctl status php8.1-fpm php8.3-fpm
ls /run/php/
# php8.1-fpm.sock  php8.3-fpm.sock

Site bazında sürümü, web sunucusunun PHP isteklerini hangi sokete ilettiği belirler. Nginx’te ilgili server bloğunda fastcgi_pass unix:/run/php/php8.3-fpm.sock;, Apache’de mod_proxy_fcgi ile şu tanım kullanılır:

<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
</FilesMatch>

Her site için kendi kullanıcısı ve soketiyle ayrı havuz tanımlamak, hem izolasyon hem sürüm geçişi açısından en temiz yapıdır. Virtualmin gibi paneller bu havuzları site bazında yönetir; bu düzeni Virtualmin ile çok siteli sunucu yönetimi yazısında anlattık.

Kademeli geçiş ve test

Birden fazla kurumsal web sitesinin bulunduğu bir sunucuda geçişi en düşük riskli siteden en kritik siteye doğru sıralayın. Her site için akış aynıdır:

1. Tarama: Özel kod PHPCompatibility ile taranır, bulgular düzeltilir; kamuya açık eklentiler güncel sürüme çekilir.
2. Staging testi: Site, üretimle eşdeğer bir staging ortamında yeni PHP sürümüyle çalıştırılır; kritik akışlar test edilir, hata logu incelenir.
3. Yedek: Geçişten hemen önce dosya ve veritabanı yedeği alınır.
4. Geçiş: Sitenin soketi veya havuzu yeni sürüme çevrilir, web sunucusu ve PHP-FPM reload edilir. Restart değil reload; mevcut istekler tamamlansın.
5. Doğrulama: Aktif sürümü phpinfo() içeren geçici bir dosyayla değil, web üzerinden çalışan sürümü gösteren bir ekranla (WordPress’te Araçlar > Site Sağlığı > Bilgi > Sunucu bölümü) doğrulayın. wp --info komut satırı sürümünü gösterdiği için bu kontrole uygun değildir; geçici test dosyalarını da sunucuda bırakmayın.
6. Gözlem: İlk saatlerde ve ilk günlerde hata logu, 5xx oranı ve yanıt süresi izlenir. Haftalık veya aylık çalışan cron işleri ilk çalışmalarında ayrıca kontrol edilir.

OPcache ayarlarını da kontrol edin: yeni sürümün yapılandırma dizinindeki (ör. Debian/Ubuntu’da /etc/php/8.3/fpm/conf.d/) opcache.memory_consumption ve opcache.max_accelerated_files değerleri eski sürümle aynı değilse, geçiş sonrası performans düşüşü uyumsuzluk sanılır ve yanlış yerde arıza aranır.

Geri dönüş planı ve izleme

Çoklu sürüm düzeninin en büyük kazancı geri dönüşün basitliğidir. Eski sürümün FPM servisi çalıştığı sürece sitenin soketini eski sürüme çevirip reload etmek saniyeler içinde geri dönüş sağlar. Bu yüzden eski sürüm paketlerini, son site geçişinden sonra gözlem süresi dolana kadar kaldırmayın.

Ama geri dönüş yalnız PHP tarafını geri alır. Geçişle birlikte bir eklenti veya uygulama sürümü de yükseltildiyse ve bu sürüm veritabanı şemasını değiştirdiyse, eski PHP sürümüne dönmek eski eklenti sürümünü geri getirmez. PHP geçişini eklenti ve çekirdek güncellemeleriyle aynı bakım penceresine koymayın. Bir pencerede tek değişken.

Geri dönüş ölçütlerini baştan yazın: hangi hata türü (fatal error, kritik akışta başarısızlık) hemen geri dönüşü tetikler, hangisi (Deprecated uyarıları) yerinde düzeltmeyle çözülür. Gözlem süresi bitince eski sürüm servisini durdurun, paketleri kaldırın ve sunucu envanterini güncelleyin.

Birden fazla sitenin bulunduğu sunucularda PHP geçişini Linux VPS ve Virtualmin yönetimi kapsamında planlıyor ve uyguluyoruz; WordPress sitelerinde eklenti ve tema uyumunun takibini WordPress güvenlik, güncelleme ve bakım süreciyle birlikte yürütüyoruz. Uyumsuzluk listesi çok uzun çıkan eski uygulamalarda yamalamaya devam etmek yerine modernizasyon seçeneğini değerlendirmek daha sürdürülebilir olabilir.

Sık sorulan sorular

PHPCompatibility taraması temiz çıktıysa geçiş güvenli midir?

Hayır. Temiz sonuç yalnız statik olarak tespit edilebilen sorunların olmadığını gösterir. Çalışma zamanında gelen null değerler, sonucu değişen gevşek karşılaştırmalar ve dinamik çağrılar taramada görünmeyebilir. Staging’de E_ALL hata raporlamasıyla kritik akışları çalıştırmanız gerekir.

Deprecated uyarıları siteyi bozar mı?

Bozmaz; kod çalışmaya devam eder. Ama bu uyarılar ilgili yapının gelecekteki bir ana sürümde kaldırılabileceğini gösterir ve loglarda yoğun kayıt üretebilir. Üretimde display_errors kapalı olmalı; uyarıları loglayın ve sonraki geliştirme döngüsünde düzeltin.

Aynı sunucuda kaç PHP sürümü çalıştırabilirim?

Her sürüm ayrı bir PHP-FPM servisi olduğu için teknik olarak birden fazlası birlikte çalışır. Pratikte her sürümün güncellemesi, eklenti kurulumu ve izlenmesi ayrı iş yüküdür; geçiş dönemi dışında sürüm sayısını en aza indirin.

WordPress sitesinde PHP sürümünü değiştirince WP-CLI neden eski sürümü gösteriyor?

WP-CLI web sunucusundan değil, komut satırındaki varsayılan php ikilisinden çalışır. Site bazında yeni sürümü kullanmak için WP-CLI’yi /usr/bin/php8.3 /usr/local/bin/wp biçiminde açık PHP yoluyla çalıştırın ya da sistemin varsayılan php sürümünü bilinçli olarak değiştirin.