PHP 8.2 desteği bitiyor, temanızın son sürümü yeni PHP’yi gördü mü

PHP 8.2 dalı 31 Aralık 2026’dan sonra güvenlik düzeltmesi almayacak. Barındırma firmanız sunucuyu 8.3, 8.4 ya da 8.5’e taşıdığında sitenizdeki temanın bu sürümlerde hiç denenmemiş olması mümkün. 20 Ekim 2026 verimize göre alt tema olmayan ve 1.000’den fazla etkin kurulumu bulunan 538 WordPress.org temasının 93’ü son sürümünü PHP 8.3 yayımlanmadan önce çıkardı. Bu yazıda PHP takvimini, bu tarihlerin temalarla nasıl kesiştiğini ve kendi sitenizde bir deneme kopyasıyla nasıl kontrol yapacağınızı anlatıyoruz.

PHP dallarının destek takvimi

PHP projesi her dalı iki aşamada destekler. php.net’in tanımına göre aktif destek döneminde bildirilen hatalar ve güvenlik sorunları düzeltilir, düzenli ara sürümler çıkar. Ardından gelen yalnızca güvenlik döneminde sadece kritik güvenlik sorunları kapatılır ve sürüm ancak gerektiğinde yayımlanır. Her dal iki yıl aktif, iki yıl da yalnız güvenlik desteği alır.

php.net’in desteklenen sürümler sayfasında 20 Ekim 2026 itibarıyla dört dal var:

Tablodan iki şey çıkıyor. 8.2 zaten iki yıla yakın süredir yalnız güvenlik düzeltmesi alıyor ve bu dönem de iki buçuk ay sonra kapanıyor. 8.1 artık listede yok. Yani bugün PHP 8.1 ya da daha eski bir sürümle çalışan bir sunucu, PHP projesinin hiçbir desteğini almıyor.

WordPress’in tarafı

WordPress.org’un gereksinimler sayfası (son değişiklik 7 Mayıs 2026) PHP 8.3 veya üzerini öneriyor. Aynı sayfa WordPress’in eski ortamlarda PHP 7.4 ve üzeriyle de çalıştığını, ancak bu sürümlerin resmî ömrünü tamamladığını ve sitenizi güvenlik açıklarına maruz bırakabileceğini yazıyor. WordPress.org sürüm denetimi servisi de güncel 7.1.3 sürümü için en düşük PHP değerini 7.4 olarak veriyor.

Yani çekirdek tarafında tablo net: WordPress 8.3’ü öneriyor, 8.4 ve 8.5 de destekleniyor. Belirsiz olan taraf temalar.

Temanın beyanı neden yetmiyor

Her tema style.css başlığında “Requires PHP” alanıyla desteklediği en eski PHP sürümünü bildirir. Bu bir taban değeridir; temanın hangi yeni PHP sürümünde denendiğini söyleyen bir alan yoktur. Havuzumuzdaki 538 temanın 274’ü taban olarak 5 serisinden bir değer yazıyor, yalnızca 4 tema PHP 8.0 ve üzerini istiyor. “Requires PHP: 5.6” yazan bir tema PHP 8.4’te sorunsuz da çalışabilir, uyarı da üretebilir; alan bu konuda bilgi vermez.

Yeni PHP sürümünde denendiğine dair dolaylı tek işaret, temanın o PHP sürümü çıktıktan sonra güncellenmiş olmasıdır. Geliştirici yeni bir sürüm hazırlarken kendi ortamını da büyük olasılıkla güncellemiştir. Bunun garantisi yoktur, ama tersini kesin olarak biliriz: PHP 8.3 çıkmadan paketlenmiş bir tema sürümü PHP 8.3’te denenmiş olamaz.

Son güncelleme ile PHP sürümlerini yan yana koyduk

Havuzdaki her temanın son güncelleme tarihini, PHP dallarının ilk sürüm tarihiyle karşılaştırdık:

182 tema, havuzun %33,8’i ediyor. Bu temaların en son sürümü PHP 8.5 yayımlanmadan önce çıktı. PHP 8.3 öncesinde kalan 93 temanın etkin kurulum alt sınırlarının toplamı 178.000. Bu 93 temanın tamamı bakım sınıflamamızda 2 yıldır güncellenmemiş grubunda yer alıyor; 8.5 öncesinde kalan 182 temanın geri kalanı ise durgun ve seyrek gruplarından geliyor.

Ayrı sayfası olan temalardan PHP 8.3 öncesinde kalan 13 tema var. Birkaç örnek:

• Hemingway, 10.000+ kurulum, son güncelleme 23 Aralık 2022.
• NewsMag, 7.000+ kurulum, son güncelleme 30 Eylül 2021.
• Hitchcock, 6.000+ kurulum, son güncelleme 23 Aralık 2022.
• Pinboard, 4.000+ kurulum, son güncelleme 17 Ocak 2015.

Bu liste bir hata listesi değil. Bu temaların PHP 8.3, 8.4 ya da 8.5’te ne yaptığını bilmiyoruz; bildiğimiz, son sürümlerinin bu PHP dallarından önce paketlendiği.

Eski kodu etkileyebilecek değişiklikler

PHP her dalda bazı kullanımları “deprecated”, yani kullanımdan kaldırılacak olarak işaretler. Bu aşamada kod çalışmaya devam eder, ama PHP bir uyarı üretir; ileriki bir ana sürümde aynı kullanım hataya dönüşebilir. Eski temalarda sık rastlanan örnekler PHP kılavuzunda şöyle geçiyor:

• Dinamik özellikler (PHP 8.2). Bir sınıfta tanımlanmamış bir özelliğe değer atamak, sınıf #[\AllowDynamicProperties] niteliğini taşımıyorsa kullanımdan kaldırıldı. Yıllar önce yazılmış tema seçenek sınıflarında bu kalıp yaygındır.
• "${var}" biçiminde metin içi değişken (PHP 8.2). Yerine "$var" ya da "{$var}" kullanılması isteniyor.
• utf8_encode() ve utf8_decode() (PHP 8.2). İkisi de kullanımdan kaldırıldı.
• Örtük olarak null kabul eden parametreler (PHP 8.4). Varsayılan değeri null olan ama türünde null bulunmayan parametreler artık uyarı veriyor; tür ?T biçiminde açıkça yazılmalı.

Bir de daha ağır durum var: temanın PHP’de ölümcül hata (fatal error) vermesi. WordPress.org Themes Team’in askıya alma kurallarında, etkinleştirildiğinde ölümcül hata veren ya da PHP 7 ve sonrasıyla veya yakın WordPress sürümleriyle uyumsuz temaların dizinden hemen geçici olarak askıya alındığı yazıyor. Dizinde duran bir temanın bu tür bir sorunla uzun süre kalması bu yüzden düşük ihtimal; asıl karşılaşacağınız şey uyarılar ve tek tek bozulan sayfa parçaları.

Kendi sitenizde nasıl denersiniz

Bunu canlı sitede yapmayın. WordPress’in hata ayıklama belgesi de hata ayıklama araçlarının canlı sitelerde değil, yerel kurulumlarda ve deneme (staging) kopyalarında kullanılmasını öneriyor. Çoğu barındırma panelinde sitenin bir kopyasını açma ve kopyanın PHP sürümünü ayrı seçme imkânı vardır.

1. Sitenin dosyalarıyla veritabanının bir kopyasını çıkarın ve deneme ortamına kurun.
2. Deneme kopyasında PHP sürümünü hedeflediğiniz dala (ör. 8.4) yükseltin.
3. wp-config.php dosyasında “That’s all, stop editing” satırından önce şu satırları ekleyin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Bu ayarla hatalar sayfada görünmez, wp-content/debug.log dosyasına yazılır. Belgeye göre WP_DEBUG açıkken kullanımdan kaldırılmış fonksiyon ve argüman bildirimleri de kayda düşer ve çoğu zaman yerine ne kullanılacağı da yazar.

4. Sitede gerçekten kullanılan sayfa türlerini tek tek açın: ana sayfa, tek yazı, kategori arşivi, arama sonucu, 404 sayfası, iletişim formu, varsa mağaza ve sepet sayfaları. Yönetim panelinde temanın ayar ekranını ve Özelleştir ekranını da açın.
5. debug.log dosyasını okuyun. Satırlarda geçen dosya yoluna bakın. wp-content/themes/<tema-klasörü>/ ile başlayan satırlar temadan, wp-content/plugins/ ile başlayanlar eklentilerden geliyor.

Kayıttaki satırları üç gruba ayırmak işinizi kolaylaştırır. “Deprecated” bugün bir şey bozmaz, gelecekteki bir PHP sürümü için uyarıdır. “Warning” çoğu zaman sayfanın bir parçasının eksik ya da yanlış çalıştığını gösterir. “Fatal error” sayfanın tamamen durduğu anlamına gelir ve canlıya geçişi engeller.

Kayıtta tema kaynaklı satır görürseniz

İlk bakılacak yer temanın son sürüm tarihi. Temanın kendi sayfamızda sürüm geçmişi, son 12 aydaki sürüm sayısı ve “Tested up to” değeri bir arada duruyor; uyumluluk sayfasında da tüm havuzun WordPress ve PHP tablosunu görebilirsiniz.

Tema düzenli güncelleniyorsa kullandığınız sürümün en yenisi olup olmadığına bakın; uyarı yeni sürümde giderilmiş olabilir. Değilse temanın WordPress.org destek forumunda kayıttaki satırı paylaşarak geliştiriciye bildirebilirsiniz. Tema iki yıldır güncellenmiyorsa düzeltmenin gelme ihtimali düşüktür. Bu durumda seçenekler, sorunu bir alt temada kendi kodunuzla çözmek ya da başka bir temaya planlı biçimde geçmektir. Geçiş adımlarını bakımsız temadan geçiş yazısında ayrıca ele aldık.

Son bir not: PHP sürümünü yükseltmek tek başına temayı ilgilendirmez. Aynı deneme kopyasında eklentilerinizin satırları da kayda düşecek. Kayıt temiz çıktığında canlı siteyi yükseltmeden önce bir yedek almak, sorun çıkarsa barındırma panelinden eski PHP sürümüne dönmenin yolunu açık tutar.