PHP 8.2 desteği 31 Aralık'ta bitiyor: WordPress sitenizi PHP 8.3 ya da 8.4'e güvenle geçirmek

31 Aralık 2026 gecesi PHP 8.2 için son güvenlik yaması yayımlanmış olacak. O tarihten sonra bu sürümde bulunan yeni bir açık için hiçbir düzeltme gelmeyecek. Siteniz çalışmaya devam eder ama artık kilidi değiştirilmeyen bir kapının arkasında durur.

Hosting destekte her yıl aynı tabloyu görüyorum: Son haftaya kalan sürüm geçişleri, aceleyle değiştirilen PHP sürümü, ardından gelen "sitem beyaz ekran verdi" çağrıları. Önümüzde hâlâ yaklaşık yedi hafta var. Bu yazıda geçişi sakin ve geri dönülebilir şekilde nasıl yapacağınızı anlatıyorum.

PHP sürümlerinin destek takvimi

Her PHP sürümü yayımlandıktan sonra iki yıl "aktif destek" (hata ve güvenlik düzeltmeleri), ardından bir yıl daha yalnızca güvenlik düzeltmeleri alır. Güvenlik desteğinin bittiği tarihler:

• PHP 8.1: 31 Aralık 2025 (desteği bitti)
• PHP 8.2: 31 Aralık 2026
• PHP 8.3: 31 Aralık 2027
• PHP 8.4: 31 Aralık 2028
• PHP 8.5: 31 Aralık 2029

Kısacası bugün yeni bir geçiş yapacaksanız hedefiniz PHP 8.3 ya da 8.4 olmalı. 8.4 size bir yıl daha fazla zaman kazandırır; eklentileriniz hazırsa doğrudan ona geçmek mantıklıdır.

Not: Red Hat, AlmaLinux gibi dağıtımlar ve CloudLinux gibi bazı hosting altyapıları eski sürümlere kendi yamalarını taşımaya devam edebilir. Bu bir istisnadır; paylaşımlı hostingde seçtiğiniz "PHP 8.2" büyük ihtimalle resmî sürümdür ve desteği yılsonunda biter.

Hangi sürümü kullandığınızı öğrenin

WordPress'te en kolay yol: Araçlar → Site Sağlığı → Bilgi → Sunucu bölümünde "PHP sürümü" satırı. Site Sağlığı ekranı eski bir sürüm kullanıyorsanız zaten uyarı da gösterir.

cPanel kullanıyorsanız MultiPHP Yöneticisi ya da PHP Sürümünü Seç ekranında her alan adının sürümü yazar. Komut satırına erişiminiz varsa:

php -v

Dikkat: Komut satırındaki php ile sitenin kullandığı PHP aynı olmayabilir. Kesin bilgi için WordPress'in Site Sağlığı ekranına ya da panelinize bakın.

Sitenizin sunucu başlıklarında PHP sürümünü dışarıya söyleyip söylemediğini Site Röntgeni ile de görebilirsiniz; desteği biten bir sürüm görürse ayrıca uyarır.

Geçişte neler bozulabilir?

PHP 7'den 8'e geçiş birçok siteyi zorlamıştı. 8.2'den 8.3 ya da 8.4'e geçiş çok daha yumuşaktır, ama sorunsuz değildir:

• Eski ve güncellenmeyen eklentiler. Asıl risk WordPress çekirdeği değil, yıllardır güncelleme almamış eklenti ve temalardır.
• Kullanımdan kaldırma (deprecation) uyarıları. PHP 8.4, örneğin varsayılan değeri null olan bir parametreyi tür belirtmeden "null olabilir" saymayı kullanımdan kaldırdı. Bunlar siteyi durdurmaz ama debug.log dosyasını şişirir; ekranda hata gösterimi açıksa ziyaretçi uyarıları görür.
• Şifrelenmiş (ionCube) eklenti ve betikler. Kodu ionCube ile şifrelenmiş ticari eklentiler, yeni PHP sürümü için yazılmış loader yoksa hiç çalışmaz. Bu tür bir eklentiniz varsa üreticinin yeni sürümü desteklediğini önceden doğrulayın.
• Eksik PHP eklentileri. Yeni sürümde intl, imagick, sodium gibi eklentiler panelde ayrıca işaretlenmemiş olabilir.

Adım adım güvenli geçiş

1. Önce her şeyi güncelleyin. WordPress çekirdeği, tema ve eklentiler güncel olmalı. Geliştiricilerin büyük çoğunluğu uyumluluk düzeltmelerini çoktan yayımladı; çoğu sorun yalnızca bu adımla çözülür. Güncellemeyi de bozmadan yapmak için test ortamı (staging) ve güvenli güncelleme sırası yazısına bakabilirsiniz.

2. Terk edilmiş eklentileri ayıklayın. WordPress.org'da "son güncelleme: 2 yıl önce" yazan, ya da "WordPress'in son 3 ana sürümüyle test edilmemiştir" uyarısı olan eklentiler için alternatif arayın.

3. Tam yedek alın. Dosyalar ve veritabanı birlikte. Panelinizin yedekleme aracı ya da bir yedekleme eklentisi yeterlidir; önemli olan yedeğin sunucudan başka bir yerde de durması.

4. Hata günlüğünü açın, ekranı kapatın. wp-config.php dosyasında:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Böylece hatalar ziyaretçiye görünmez ama wp-content/debug.log dosyasına yazılır.

5. Mümkünse önce test ortamında deneyin. Sitenin bir kopyasında PHP sürümünü değiştirip sayfaları gezin, formları ve ödeme adımını deneyin.

6. Canlı sitede sürümü değiştirin. cPanel'de MultiPHP Yöneticisi'nden alan adını seçip 8.3 ya da 8.4'ü uygulayın. Değişiklik saniyeler içinde geçerli olur.

7. İlk saat kontrolü. Ana sayfa, bir yazı, iletişim formu, varsa sepet ve ödeme sayfası, yönetim paneli. Ardından debug.log dosyasına bakın. Ölümcül hata (PHP Fatal error) varsa hangi eklentiden geldiği satırda yazar.

8. Sorun çıkarsa geri dönün. Sürüm değişikliği tek tıkla geri alınabilir. Paniğe gerek yok: eski sürüme dönün, sorunlu eklentiyi güncelleyin ya da değiştirin, tekrar deneyin. Her şey yolundaysa birkaç gün sonra WP_DEBUG ayarını false yapın.

Geliştiriciler için: kodu önceden taramak

Kendi tema ya da eklentiniz varsa, PHP_CodeSniffer ile birlikte kullanılan PHPCompatibility kuralları kodunuzu belirli bir sürüme göre tarar:

composer require --dev phpcompatibility/phpcompatibility-wp:"*"
vendor/bin/phpcs -p wp-content/themes/temam --standard=PHPCompatibilityWP --runtime-set testVersion 8.3-

Statik tarama her şeyi yakalamaz ama en sık sorunları geçiş öncesinde gösterir. PHP 8 ile gelen yeniliklerden yararlanmak isterseniz PHP 8 ile gelen ve kodu sadeleştiren özellikler yazısına da göz atabilirsiniz.

Kısa kontrol listesi

• Site Sağlığı'ndan PHP sürümünü öğrendim
• Çekirdek, tema ve eklentileri güncelledim
• Terk edilmiş eklentileri değiştirdim
• Dosya + veritabanı yedeği aldım
• Hata günlüğünü açtım, ekranda göstermeyi kapattım
• PHP 8.3 ya da 8.4'e geçtim, sayfaları ve formları denedim
• debug.log dosyasını kontrol ettim

Bunu Aralık'ın son haftasına bırakmayın. Bir sorun çıktığında çözmek için zamanınız olsun; geçişi bu ay, sakin bir günde yapın.