# PHP Sürüm Yükseltme: 8.1'den 8.5'e Tabutta Rövaşata - Yazar: [Halit Yeşil](https://halityesil.com/) - Yayın tarihi: 2026-09-26 - Dil: Türkçe - Kaynak adres: https://halityesil.com/php-surum-yukseltme-8-1-den-8-5-e/ - İngilizce sürümü: https://halityesil.com/en/php-8-5-upgrade-from-8-1.md - Kategori: PHP - Etiketler: Apache, CWP, deprecation, PHP 8.1, PHP 8.5, PHP-FPM, sürüm yükseltme, WordPress - Lisans: https://creativecommons.org/licenses/by-nc/4.0/ - Atıf: Halit Yeşil. “PHP Sürüm Yükseltme: 8.1'den 8.5'e Tabutta Rövaşata”. halityesil.com, 2026-09-26. https://halityesil.com/php-surum-yukseltme-8-1-den-8-5-e/ --- 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](https://endoflife.date/php). 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: ```bash # 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/CentOS ``` Paket 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ı](https://make.wordpress.org/core/2026/05/22/php-support-clarification-2026/) 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](https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/) ü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):
EklentiSon güncellemeRisk
Yoast SEO6 gün önceDüşük
MonsterInsights2 gün önceDüşük
Polylang2 hafta önceDüşük
Software License Manager1 ay önceDüşük
CodePen Embed Block1 ay önceDüşük
reCaptcha (BestWebSoft)5 ay önceOrta
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()` ve `curl_share_close()` (artık no-op) - `socket_set_timeout()` → `stream_set_timeout()` - Tüm `MHASH_*` sabitleri - Dizi indisi olarak `null` kullanmak — 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](https://halityesil.com/php/gelistirici-kafasinda-php-8-4-yeni-ozellikler-ve-kesifler/) 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: ```bash mysqli pdo_mysql mbstring curl gd exif zip intl dom xml simplexml json opcache fileinfo ``` **imagick'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: ```bash 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: ```php 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](https://developer.wordpress.org/reference/functions/wp_debug_mode/), 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: ```php E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR ``` Listede `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: ```php 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: ```bash 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 135 ``` Tahminim 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: ```bash 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: ```apacheconf ========================================================== # 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](https://halityesil.com/linux/centos/centos-8-apache-virtual-host-kurulumu/) 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 1. **Yedek.** Dosya + `mysqldump`. PHP sürümü geri alınabilir, bozuk veritabanı alınamaz. 2. **Extension listesi.** `php -m` çıktısını yükseltme öncesi ve sonrası karşılaştırın. 3. **OPcache temizliği ve FPM restart.** `php.ini` değişiklikleri her zaman yeniden başlatma ister. 4. **Gerçek rota testi.** Ana sayfa, bir yazı, form içeren bir sayfa, yönetim paneli, besleme, site haritası. 5. **48 saat log.** Sonra `WP_DEBUG`'ı kapatın ama `log_errors` ile `error_log`'u `php.ini`'de bırakın — fatal ve warning'ler kalıcı loglanır, deprecation'lar susar. 6. **Canlıda `display_errors = Off`.** Açıkça yazın, mirasa bırakmayın. Kalıcı düzen için ini tarafı şöyle olmalı: ```ini display_errors = Off log_errors = On error_log = /home/kullanici/logs/php-error.log ``` Bu üç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](https://halityesil.com/php/php-neden-olmez-hayatta-kalmanin-sirlari/) 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.