Kontrol panelinde PHP sürümü seçeneği genellikle birkaç tıklık bir ayardır; ancak yanlış seçim siteyi beyaz ekrana düşürür, doğru seçim ise aynı sunucuda belirgin hız kazancı ve güvenlik güncellemeleri sağlar. Bu yazı sürüm yaşam döngüsünü, WordPress ve eklenti uyumluluğunu nasıl kontrol edeceğinizi, panelden geçişin adımlarını, uyumsuzluk belirtilerini ve sorun çıktığında geri alma yolunu anlatır.
Sürüm yaşam döngüsü
PHP her yıl yeni bir ana ya da ara sürüm yayımlar ve her sürüm üç aşamadan geçer:
- Aktif destek: Hata düzeltmeleri ve güvenlik yamaları düzenli gelir. Yeni site için tercih edilmesi gereken aşamadır.
- Yalnızca güvenlik desteği: Yeni özellik ve küçük hata düzeltmesi gelmez, yalnızca güvenlik açıkları kapatılır. Çalışan bir site için kabul edilebilir ama geçiş planlanmalıdır.
- Destek sonu (EOL): Hiçbir yama gelmez. Bilinen bir açık ortaya çıktığında site savunmasız kalır; bazı barındırma firmaları bu sürümleri panelden kaldırır ya da ek ücretle sunar.
Hangi sürümün hangi aşamada olduğunu php.net'teki destekli sürümler sayfası tarih tarih gösterir; bu yazıda tarih vermiyoruz çünkü her yıl değişir. Pratik kural: aktif destekteki en yeni ya da bir önceki sürümü kullanın; “yalnızca güvenlik” aşamasına giren sürümden bir yıl içinde ayrılın. Destek sonu gelmiş sürümleri (tüm 7.x sürümleri ile 8.0 ve 8.1 dahil) panelde görseniz bile yalnızca eski bir uygulamayı taşıma sürecinde geçici olarak seçin.
Barındırma firmaları genellikle CloudLinux PHP Selector, cPanel MultiPHP ya da Plesk'in çoklu sürüm desteğiyle aynı sunucuda birkaç sürümü yan yana sunar. Panelde kaç sürümün bulunduğu ve yeni sürümün ne kadar sürede eklendiği, firmanın bakım disiplini hakkında somut bir ipucudur.
Sürüm numarasını okumak
Numaralar üç parçadan oluşur: 8.3.12 örneğinde 8 ana sürüm, 3 ara sürüm, 12 yama sürümüdür. Yama güncellemeleri yalnızca hata ve güvenlik düzeltmesi içerir, barındırma firması tarafından sessizce uygulanır ve genellikle uyumluluğu bozmaz; sizin seçtiğiniz şey ana ve ara sürümdür. Eklenti sayfalarındaki “PHP 7.4 veya üstü gerekir” gibi ifadeler de bu ikiliyi kasteder. Ana sürüm geçişleri (7'den 8'e gibi) en çok kodu kıran adımdır; ara sürümler arasında geçiş genellikle daha az sorun çıkarır, ama her ara sürüm bazı özellikleri kullanımdan kaldırılacak (deprecated) olarak işaretler ve küçük davranış değişiklikleri içerebilir.
WordPress ve eklenti uyumluluğu
WordPress çekirdeği, sistem gereksinimleri sayfasında bir asgari sürüm ve bir önerilen sürüm açıklar; çekirdeğin hangi PHP 8.x sürümleriyle uyumlu olduğu WordPress belgelerinde sürüm bazında açıklanır. Asıl risk eklentiler ve temalardadır:
- Yönetici panelinde Eklentiler listesini açın; her eklentinin WordPress.org sayfasında gereken asgari PHP sürümü ve eklentinin test edildiği son WordPress sürümü yer alır; PHP için üst sınır çoğu zaman yazmaz.
- Uzun süredir güncellenmeyen eklentiler (bir yıldan fazla) ilk şüphelilerdir; alternatifini aramaya baştan başlayın.
- Site Sağlığı aracı (Araçlar → Site Sağlığı) sunucudaki sürümü gösterir ve eski sürüm için uyarı verir.
- Özel yazılmış tema ya da eklenti varsa geliştiricisine hangi sürümlerde test ettiğini sorun; kaynak kodda
create_function, each() ve mysql_ ile başlayan fonksiyonlar 8.x'te çalışmaz. - Hazır tarama için kod analiz araçları (PHPCompatibility kural setiyle PHP_CodeSniffer) ya da bu işi paketleyen eklentiler, dosyaları tarayıp uyumsuz satırları listeler. Yanlış pozitif verebilir ama nereye bakılacağını gösterir.
Diğer uygulamalar (Laravel, Joomla, PrestaShop, OpenCart) için aynı mantık geçerlidir; her birinin belgelerinde desteklenen sürüm aralığı yazar ve eski uygulama sürümleri yeni yorumlayıcıyla çalışmayabilir.
Panelden sürüm değiştirme
| Panel | Nerede | Not |
|---|
| cPanel | Yazılım → MultiPHP Manager; CloudLinux varsa Select PHP Version | MultiPHP alan adı bazında seçer; Selector uzantıları ve php.ini değerlerini de yönetir |
| Plesk | Web Siteleri ve Alan Adları → alan adı → PHP Ayarları | Sürümle birlikte çalıştırma modu (FPM, FastCGI) ve ini değerleri aynı ekranda |
| DirectAdmin | Alan Adı Kurulumu → PHP sürümü seçimi | Sunucu yöneticisinin sunduğu sürümlerle sınırlı |
| Panelsiz VPS | Birden fazla paket kurulup PHP-FPM havuzu ya da update-alternatives ile seçilir | Her site için ayrı FPM havuzu önerilir |
Geçişin güvenli sırası:
- Tam yedek alın (dosyalar + veritabanı). Panelin yedek aracı yetmiyorsa eklenti ya da elle dışa aktarım kullanın.
- Mümkünse kopya (staging) sitede önce deneyin; birçok panel tek tıkla kopya oluşturur.
- Hata günlüğünü açın: WordPress'te wp-config.php dosyasına
WP_DEBUG ve WP_DEBUG_LOG tanımlarını ekleyin, panelden error_log görüntülemeyi etkinleştirin. - Panelden yeni sürümü seçin; değişiklik saniyeler içinde uygulanır, çoğu panelde sunucu yeniden başlatılmaz.
- Ana sayfa, bir iç sayfa, yönetici paneli, form gönderimi, ödeme ve arama gibi kritik akışları elle test edin; önbelleği temizlemeyi unutmayın, aksi hâlde eski sayfaları görürsünüz.
- Hata günlüğünü bir iki gün izleyin; “Deprecated” uyarıları çalışmayı bozmaz ama gelecekte kaldırılacak kodu işaret eder.
- OPcache açık olduğundan emin olun; sürüm değişikliğinde önbelleğin sıfırlanması normaldir, ilk istekler biraz yavaş gelebilir.
Sürümle birlikte ini değerlerini de gözden geçirin: memory_limit, upload_max_filesize, post_max_size, max_execution_time. Panellerde bunlar sürüm seçicinin yanındaki ayarlar sekmesinde durur; yeni sürüme geçerken bazı firmalar varsayılanları sıfırlar.
Uyumsuzluk belirtileri
- Beyaz ekran ya da HTTP 500: Çoğunlukla bir eklentinin ölümcül hatası. Hata günlüğünde “Fatal error: Uncaught Error: Call to undefined function” satırı hangi dosyanın sorumlu olduğunu söyler.
- “Parse error: syntax error, unexpected …”: Çoğu zaman tersi durum; yeni sözdizimi kullanan eklenti eski yorumlayıcıda çalışmıyordur. Bu durumda sürümü yükseltmek çözer.
- Yönetici paneline girilemiyor, site açılıyor: Bir oturum ya da güvenlik eklentisi uyumsuz olabilir; FTP ile eklenti klasörünü geçici olarak yeniden adlandırarak devre dışı bırakın.
- Deprecated uyarıları sayfada görünüyor: Çalışma bozulmamıştır; display_errors kapatılmalı ve uyarı veren eklenti güncellenmelidir.
- Form ya da ödeme adımı sessizce başarısız oluyor: Tür dönüşümü ya da kaldırılmış bir fonksiyon; günlükte uyarı olarak görünür, kullanıcıya hata göstermez.
- Beklenmedik yavaşlama: OPcache ya da bir uzantı (örneğin imagick, intl, mbstring) yeni sürümde etkin değildir; sürüm seçicinin uzantı listesini kontrol edin.
Geri alma
Panelden yapılan sürüm değişikliği aynı yoldan geri alınır: eski sürümü seçin, önbelleği temizleyin, siteyi kontrol edin. Dosya ve veritabanı değişmediği için geri dönüş dakikalar sürer. Geri aldıktan sonra sorunu kaydedin: hangi eklenti, hangi hata. Eklentiyi güncelleyin ya da değiştirin, sonra geçişi tekrarlayın. Yeni sürümde çalıştıktan sonra eklenti güncellemeleri ya da veritabanı şema değişiklikleri yaptıysanız geri dönüş her zaman temiz olmayabilir; bu yüzden ilk adımdaki yedek önemlidir.
Değişikliği uzun süre ertelemek doğru değildir: destek sonu gelen bir sürümde kalmak, güncellenmeyen bir eklentiyi korumak uğruna tüm siteyi riske atmaktır. Uyumsuz eklentinin işlevi genellikle bakımı süren bir alternatifle karşılanır.
Paket seçerken sürüm desteğine bakmak
Paket sayfasında yalnızca “PHP desteği” yazması yeterli bilgi değildir. Hangi sürümlerin sunulduğunu, yeni sürümün yayımlandıktan ne kadar sonra panele eklendiğini ve eski sürümlerin ne zaman kaldırıldığını sorun. Birden fazla sürümü yan yana sunan, OPcache ve yaygın uzantıları hazır veren, ini değerlerini kullanıcıya açan bir paket, sürüm geçişlerini kolaylaştırır. Bu özelliklerin yer alıp almadığını WordPress hosting ve paylaşımlı hosting kategorilerindeki paket açıklamalarında kontrol edebilir, panellerin sürüm yönetimi arasındaki farkı cPanel mi, Plesk mi? yazısında okuyabilirsiniz. Kendi VPS'inizde sürümleri siz yönetirsiniz; VPS sunucu kategorisindeki seçeneklerde panelli ve panelsiz teklifleri ayrı ayrı değerlendirin.