Kendi blogumun Site Sağlığı ekranında PHP 8.1.2 yazıyordu. 2022 başından kalma bir yama seviyesi, 2026 Eylül’ünde, internete açık bir sunucuda. PHP sürüm yükseltme işini yıllardır “sonra bakarım” diye ertelemiştim; ertelediğim şeyin adı artık sadece eskilik değil, yamasızlık.
Bir günde 8.5.9’a geçtim. Kırılan bir şey olmadı — ama yolda beş tane tuzak vardı ve üçüne bastım. Gelin sırayla bakalım: emekli bir sürümü vardiyada tutmanın gerçek maliyeti, panelin size söylemedikleri, ve sitemi bir buçuk dakikalığına komple düşüren tek bir eksik karakter.
PHP 8.1 Ne Zaman Emekli Oldu?
PHP’nin sürüm takvimi net: her dal iki yıl aktif destek (hata + güvenlik), ardından iki yıl sadece güvenlik alır, sonra biter. PHP 8.1’in güvenlik desteği 31 Aralık 2025‘te sona erdi. Yani sekiz aydır 8.1 için yeni bir açık bulunduğunda upstream’den yama gelmiyor.
Burada işin sinsi tarafı şu: sürüm numarası tek başına yalan söyleyebilir. Debian veya Ubuntu’nun depo paketini kullanıyorsanız dağıtım güvenlik yamalarını eski sürüm numarasının üstüne geri taşır (backport); 8.1.2 yazar ama içinde 2025 yamaları olabilir. Ama panelin kendi derlediği PHP’yi kullanıyorsanız — CWP, cPanel’in EasyApache’i, benzerleri — o binary panelin derlediği gündeki koddur. Geri taşıma yok.
Acı Gerçek: Ben CWP’nin PHP-FPM seçicisini kullanıyordum. Yani o 8.1.2, gerçekten 8.1.2’ydi.
Hangi durumda olduğunuzu anlamak için önce nereden geldiğine bakın:
# Dağıtım paketi mi, panel derlemesi mi?
php -v
which php
dpkg -l | grep -i php8 # Debian/Ubuntu
rpm -qa | grep -i php # RHEL/AlmaLinux/CentOSPaket yöneticisi PHP’yi tanımıyorsa, o PHP panelin. Ve panelin derlediği emekli sürüm gerçekten emekli.
“Requires PHP 7.4” Ne Anlama Gelmiyor?
Yükseltmeden önceki asıl soru uyumluluktu. WordPress tarafı temizdi: Core ekibi Mayıs 2026’da “beta destek” etiketini tamamen kaldırdı ve WordPress 6.9 ile 7.0 için PHP 8.5’i tam destekli ilan etti.
Eklentiler tarafında ise herkesin düştüğü bir okuma hatası var. Eklenti sayfasındaki “Requires PHP: 7.4 or higher” ifadesi bir taban değeridir, tavan değil. WordPress’in readme formatında üst sınır alanı diye bir şey yok. O satır size “8.5’te çalışır” demiyor; “7.4’ün altında çalışmaz” diyor. İkisi aynı cümle değil.
Gerçek sinyal başka yerde: son güncelleme tarihi ve geliştiricinin aktifliği. Kendi yedi eklentimi bu gözle tabloladım (değerler 21 Eylül 2026 itibarıyla):
| Eklenti | Son güncelleme | Risk |
|---|---|---|
| Yoast SEO | 6 gün önce | Düşük |
| MonsterInsights | 2 gün önce | Düşük |
| Polylang | 2 hafta önce | Düşük |
| Software License Manager | 1 ay önce | Düşük |
| CodePen Embed Block | 1 ay önce | Düşük |
| reCaptcha (BestWebSoft) | 5 ay önce | Orta |
| Code Syntax Block | 2 yıl önce | Terk edilmiş |
Gizli Hazine: Bu tabloyu çıkarırken fark ettim — Code Syntax Block, Nisan 2025’te WordPress.org dizininden kaldırılmış. Panelim onu iki yıldır “güncel” gösteriyordu. Mantıklı aslında: kapatılmış bir eklenti hiçbir zaman güncelleme bildirmez, dolayısıyla sonsuza kadar güncel görünür. Güncelleme ekranına bakıp içiniz rahat etmesin.
PHP 8.5 Aslında Neyi Kırıyor?
“8.1’den 8.5’e” kulağa dört basamaklık bir sıçrama gibi geliyor ve insanı korkutuyor. Gerçek şu ki 8.5’in yıkıcı değişiklik listesi utanç verecek kadar kısa. Tamamen kaldırılan tek şey CLI’daki -z / --zend-extension seçeneği. Web uygulamanızı ilgilendirmiyor.
Geri kalan her şey deprecation, yani E_DEPRECATED üretir, fatal vermez:
- Kanonik olmayan tip cast’leri:
(boolean),(integer),(double),(binary)→(bool),(int),(float),(string) mysqli_execute()→mysqli_stmt_execute()curl_close()vecurl_share_close()(artık no-op)socket_set_timeout()→stream_set_timeout()- Tüm
MHASH_*sabitleri - Dizi indisi olarak
nullkullanmak — bunu aklınızda tutun, birazdan geri geleceğiz
Asıl kanlı geçiş 8.0 ve 8.1’di. O köprüyü zaten geçmişseniz 8.5 sandığınızdan sakin. Yeni özellikler tarafını merak ediyorsanız PHP 8.4 yazısında bir önceki dalganın neler getirdiğini yazmıştım; 8.5 onun üstüne kuruluyor.
CWP’de Yükseltme ve Extension Tuzağı
Panelde yeni sürümü derleyip alan adına atamak on dakikalık iş. Tuzak şurada: PHP eklentileri yeni sürüme otomatik taşınmaz. Her PHP minor sürümü kendi extension’larını ayrı derler. Derleme ekranında listeyi işaretlemezseniz yeni PHP tertemiz ve yalnız gelir.
WordPress için asgari liste:
mysqli pdo_mysql mbstring curl gd exif zip
intl dom xml simplexml json opcache fileinfoimagick’e ayrıca dikkat. PECL üzerinden geldiği için çoğu derleme şablonunda varsayılan olarak işaretli değildir. Yoksa WordPress sessizce GD’ye düşer; görseller çalışır, ama WebP/AVIF ve kalite tarafı zayıflar. Benim derlememde geldi, kontrol ettim:
php -m | sort
php -r 'var_dump(extension_loaded("imagick"), extension_loaded("intl"));'Geçişten sonra Site Sağlığı’nın “önerilen modül eksik” uyarısını tekrar okuyun. Liste yükseltmeden önceki halinden uzunsa bir şey düşmüştür.
Bir de sunucu genelinde değil, alan adı bazında geçin. Aynı hesapta Phalcon gibi C extension’a bağlı bir uygulamanız varsa — Phalcon her PHP minor sürümü için ayrı derlenmiş binary ister — sunucu genelinde sürüm değiştirmek o uygulamayı “extension not loaded” ile tek hamlede düşürür.
Log’u Açtım, Hiçbir Şey Yazmıyor
Geçişin tek amacı deprecation’ları görmekti. wp-config.php‘ye şunu yazdım ve bekledim:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', true );Saatlerce tek satır düşmedi. Çünkü bu iki satır birlikte hiçbir şey yapmıyor.
Teknik Detay: WordPress çekirdeğinde wp_debug_mode() fonksiyonu, log yapılandırmasının tamamını if ( WP_DEBUG ) bloğunun içinde tutar. WP_DEBUG false olduğunda WP_DEBUG_LOG hiç okunmaz — resmi dokümantasyonun kendi ifadesiyle, WP_DEBUG true değilse bu sabitler hiçbir işlev görmez. Üstelik false dalında WordPress error_reporting‘i şu daraltılmış maskeye çeker:
E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR
| E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING
| E_RECOVERABLE_ERRORListede E_DEPRECATED yok. Yani görmek istediğim tek şey, tam olarak göremeyeceğim şeydi.
Geçiş penceresi için doğrusu şu — ve log yolunu web kökünün dışına alın, varsayılan wp-content/debug.log tarayıcıyla okunabilecek bir yerdedir:
define( 'WP_DEBUG', true ); // error_reporting( E_ALL )
define( 'WP_DEBUG_DISPLAY', false ); // ziyaretçi hiçbir şey görmez
define( 'WP_DEBUG_LOG', '/home/kullanici/logs/wp-debug.log' );
define( 'SCRIPT_DEBUG', false );
@ini_set( 'display_errors', 0 ); // kemer + askıWP_DEBUG‘ı canlıda açmak, WP_DEBUG_DISPLAY false olduğu sürece güvenlidir; yaptığı tek şey error_reporting‘i yükseltmek. Ama süreli kullanın: iş bitince kapatın.
568 Satır Deprecation, Tek Kaynak
Log akmaya başlayınca yarım saatte 568 satır birikti. Hepsi aynı cümle:
PHP Deprecated: Using null as an array offset is deprecated,
use an empty string instead in .../plugins/wordpress-seo/src/
memoizers/meta-tags-context-memoizer.php on line 135Tahminim eskimiş bir eklentiydi. Yanıldım: Yoast SEO. Blogdaki en güncel, en bakımlı, modern PSR-4 yapılı eklenti. İki memoizer sınıfı önbellek anahtarını null olabilen bir değerden kuruyor; PHP bunu eskiden sessizce boş dizgeye çeviriyordu, 8.5’te uyarıyor. İşlevsel etkisi yok, önbellek yine çalışıyor.
Satır numaralarını arattım: WordPress.org destek forumunda birebir aynı dosya ve satırlarla iki ayrı konu açılmış. Yoast’ın resmi yanıtı, deprecation’ların işlevselliği bozmadığı ve güvenle yok sayılabileceği, düzeltmenin ilerleyen süreçte yapılacağı yönünde. Sürüm veya tarih taahhüdü yok.
Sonuç: En güncel sürümdesiniz ve yapabileceğiniz bir şey yok. Ekosistemin yeni PHP sürümlerine neden geç adapte olduğunun canlı örneği bu: kırılma değil, kimsenin acele etmediği bir gürültü.
Denetimin amacı zaten Yoast’ı bulmak değildi, başka ne var onu görmekti. Baskın kaynağı eleyip okuyun:
LOG=/home/kullanici/logs/wp-debug.log
# Gürültüyü çıkar, kalanı eklenti bazında say
grep "Deprecated:" "$LOG" | grep -v "plugins/wordpress-seo/" \
| grep -oP '(plugins|themes)/\K[a-z0-9-]+' | sort | uniq -c | sort -rn
# Asıl bakılacaklar: deprecation olmayanlar
grep -E "PHP (Fatal error|Parse error|Warning|Recoverable)" "$LOG" \
| sed 's/on line [0-9]*/on line N/' | sort | uniq -c | sort -rnİkinci komut bende boş döndü. Yedi eklenti, iki dil, bir tema — tek fatal, tek warning yok. Dört basamaklık sıçramanın faturası bu kadardı.
Bir Eksik Karakter Yüzünden Düşen Site
Yükseltme bitince sıra sertleştirmeye geldi: güvenlik başlıkları, readme.html kapatma, xmlrpc.php engelleme. Hazırladığım bloğu .htaccess‘e yapıştırdım. Sonra site komple 500 vermeye başladı.
Ana sayfa, giriş ekranı, besleme — hepsi. Hatta statik CSS dosyası bile.
İlk refleksim PHP’yi suçlamak oldu, sonra yükseltmeyi. İkisi de değildi. Statik bir .css dosyasının 500 vermesi PHP’nin devrede bile olmadığını söylüyordu — bu Apache’nin yapılandırmayı okuyamamasıydı. Sebep:
==========================================================
# SERTLEŞTİRME
# ==========================================================İlk satırdaki # kopyalarken düşmüş. Apache o satırı yorum değil yönerge olarak okuyor, ========== diye bir komut olmadığı için dosyanın tamamını reddediyor ve o dizindeki her isteğe 500 dönüyor.
Ders: Statik dosyalar da düşüyorsa PHP’yi, veritabanını, eklentiyi bırakın. Web sunucusu yapılandırmasına bakın. Ve .htaccess düzenlemeden önce yedeğini alın; bu dosyada sözdizimi hatası tek bir isteği değil, tüm dizini götürür. Apache tarafıyla uğraşırken vhost yapılandırması üzerine yazdıklarım hâlâ geçerli — o yazıdaki CentOS 8 artık kendisi emekli oldu, ki bu da başka bir yazının konusu.
Yükseltme Sonrası Kontrol Listesi
- Yedek. Dosya +
mysqldump. PHP sürümü geri alınabilir, bozuk veritabanı alınamaz. - Extension listesi.
php -mçıktısını yükseltme öncesi ve sonrası karşılaştırın. - OPcache temizliği ve FPM restart.
php.inideğişiklikleri her zaman yeniden başlatma ister. - Gerçek rota testi. Ana sayfa, bir yazı, form içeren bir sayfa, yönetim paneli, besleme, site haritası.
- 48 saat log. Sonra
WP_DEBUG‘ı kapatın amalog_errorsileerror_log‘uphp.ini‘de bırakın — fatal ve warning’ler kalıcı loglanır, deprecation’lar susar. - Canlıda
display_errors = Off. Açıkça yazın, mirasa bırakmayın.
Kalıcı düzen için ini tarafı şöyle olmalı:
display_errors = Off
log_errors = On
error_log = /home/kullanici/logs/php-error.logBu üçlü WP_DEBUG‘dan bağımsız çalışır, çünkü WordPress false dalında log_errors ve error_log ini değerlerine dokunmaz. Bonus olarak WordPress yüklenmeden önce oluşan hatalar da aynı dosyaya düşer.
Emekliyi Vardiyada Tutmanın Bedeli
PHP 8.5, 20 Kasım 2025’te çıktı; aktif desteği 31 Aralık 2027’ye, güvenlik desteği 31 Aralık 2029’a kadar sürüyor. Yani bugün geçerseniz üç yıl boyunca bu konuyu bir daha açmıyorsunuz. Ertelerseniz aynı işi, aradan geçen her ay biraz daha yaşlanmış bir kod tabanıyla yapacaksınız.
Bir günlük işin sonunda elimde kalan şey şuydu: dört basamak atladım, tek fatal almadım, tek bulgum bir eklentinin kozmetik gürültüsü oldu. Beni gerçekten düşüren şey PHP değildi — bir yorum satırının başındaki kayıp bir karakterdi. PHP’nin neden ölmediğini yazmıştım; ölmeyen dili emekliye ayırmamak da bize düşüyor.
Sunucunuzdaki sürümü kontrol edin. Panelin derlemesi mi, dağıtımın paketi mi öğrenin. Ve yükseltmeyi log açıkken yapın — göremediğiniz şeyi düzeltemezsiniz.
Sıradaki emekli bende belli: aynı sunucuda MariaDB 10.4.34 çalışıyor. 10.4’ün desteği 18 Haziran 2024’te bitti ve 10.4.34 o serinin son sürümü. Yani yığındaki en eski parça artık veritabanı. Onun hikâyesi de ayrı bir yazı.
Teknolojiyle kalın, sürümlerinizi taze tutun.