WordPress PHP uyumluluğu WCUS 2026’da yeniden masada

🇬🇧 English: Read this in English →

WordPress projesi birkaç yılda bir aynayla göz göze gelir ve şu tuhaf soruyu kendine sorar: biz bir PHP projesi miyiz, yoksa tesadüfen PHP ile yazılmış bir WordPress projesi mi? Bu yığında site çıkardığım yirmi yılın büyük bölümünde dürüst cevap ikincisiydi. Bunu bir eleştiri olarak söylemiyorum — WordPress’i bizim çalıştığımız kurumsal müşteriler için ayakta tutan da tam olarak bu tavır. Asıl mesele, 2026’da bu cevabın hâlâ bize hizmet edip etmediği.

WordCamp US 2026’da, göze batmadan yapılan küçük bir konuşma tam da bu noktayı deşti. Oturum Chatham House kuralıyla yapıldı; normalde bu, ilginç kısımların hiçbir zaman yazıya dökülmediği anlamına gelir. Bu seferki farklı — Anne McCarthy, Make/Core’da bir özet yayımladı ve bence iki kez okumaya değer, çünkü WordPress-PHP ilişkisinin gerçekte nerede tıkandığını yıllar sonra ilk kez bu kadar net anlatan bir metin.

Sana konuşulanları, üretimde site işletenler için ne anlama geldiğini ve ajans tarafında ben olsam ne yapardım kısmını anlatmak istiyorum — çünkü internette dolaşan “PHP 7.4 problemi” tavsiyelerinin çoğu, Salı sabahı müşteriye hosting geçişi anlatmak zorunda kalmayan insanlar tarafından yazılıyor.

Gerçekten yeni olan ne

3 Eylül 2026’da Anne McCarthy, Make/Core’da “WordCamp US 2026: PHP conversation” başlıklı bir özet yayımladı. Katılımcı listesi çekirdek koda gerçekten commit atan isimlerden oluşuyor — @jorbin, @johnbillion, @obenland, @griffbrad, @joemcgill, @dmsnell, @jason_the_adams, @desrosj, @mdawaffe, @4thhubbard, @westonruter, @annezazu — ve konu WordPress ile PHP topluluklarının neden birbirinin dilinden anlamadığıydı.

İşin manşet rakamı şu: web sitelerinin yaklaşık %18’i hâlâ PHP 7.4 üzerinde koşuyor. Geri kalan her şey bu kısıtlamanın gölgesinde. PHP 7.4 Kasım 2022’de resmi güvenlik desteğini kaybetti; geniş PHP ekosistemi — Composer paketleri, test çatıları, Symfony bileşenleri — çoktan yoluna devam etti. WordPress etmedi, çünkü modern bir yazılıma göre alışılmadık derecede uzun bir destek penceresi tutuyor ve eklenti ekosistemi de istese de istemese de bu pencereyi devralıyor.

Özet, ajans işi yapan herkesin tanıyacağı üç somut sancıya parmak basıyor. Birincisi: Gutenberg’in otomatik araçları ile Core’un otomatik araçları “PHP 7.4 uyumlu” konusunda aynı fikirde değil. Bu yüzden Gutenberg boru hattından sorunsuz geçen bir söz dizimi ara sıra Core’a düşüp eski sunucuları kırıyor. Sniff kapsamı iyileştirilmiş yeni bir PHP_CodeSniffer sürümünün bu boşluğu daraltması bekleniyor. İkincisi: yerel Core testleri için gecelik bir PHP Docker konteyneri önerildi; ilk çalışma Trac #65904‘te takip ediliyor. Üçüncüsü — ve bence en heyecan verici olanı — WordPress’in HTML API çalışmalarını ve buna yakın URL ile HTTP başlığı ayrıştırma işlerini doğrudan PHP’nin içine taşıma isteği yeniden gündemde. Dennis Snell’in ekibi, pratikte spec-uyumlu bir HTML5 ayrıştırıcısını kullanıcı katmanı PHP’sinde yazmış durumda; bu ilkelleri dilin kendisine koymak yalnızca WordPress’in değil, her PHP çatısının işine yarar.

Diğer ciddi fikir ise WASM. “WordPress’i tarayıcıda koşsun diye çapraz derleyelim” değil — o zaten Playground olarak var. Buradaki öneri tam tersi: çalışan bir PHP sürecinin sanal kum havuzunda WebAssembly modüllerini yükleyip çalıştırmasına izin veren resmi bir PHP eklentisi. Ana makinede ImageMagick veya GD kurulu olmadan görsel işleme yapıldığını, ya da güvenilmez girdiyi ayrıştıran sürüm-sabitli modüller kullanıldığını düşün. Henüz erken aşama — özet bunu bir karar olarak değil, başlatılacak bir konuşma olarak tanımlıyor — ama çerçeveleme yıllardır WordPress-PHP ekseninde gördüğüm en sağlıklısı: içerik yönetim sistemini değil, dili tamir edelim.

WordPress ve WooCommerce dünyası için neden önemli

Bu iş için site kuruyorsan, konu hiç de soyut değil. %18’lik pay senin uzun kuyruğun — 2019’da kurulmuş bir cPanel hostta duran, aylık 200 TL ödeyen, tesadüfen ayda 1,5 milyon TL WooCommerce cirosu döndüren müşterin. Bu satırları okuyan her eklenti geliştiricisinin issue kuyruğunda “lütfen PHP 7.4’ü sonsuza kadar destekleyin” yorumları var; her hosting şirketinin destek kutusunda da “güncelleme sitemi neden bozdu” biletleri. Sorunun şekli bu.

WCUS’ta konuşulanların pratik sonuçları, takip eylemleri yerine oturursa, tek başına küçük ama toplamda büyük. PHP_CodeSniffer’da daha iyi sniff kapsamı, Core yama sürümlerine sızan PHP 7.4 regresyonlarının azalması demek. Gecelik PHP Docker konteyneri, Core katkıcılarının hostinglerden gelen raporları gerçekten yeniden üretebilmesi demek. HTML API ilkelerinin doğal PHP’ye taşınması ise Gutenberg’in sunucu tarafı render performansındaki kalıcı tavanlardan birini kaldırır — her blok render’ında etiket ağacını kullanıcı katmanı PHP’sinde dolaşmak zorunda kalmazsın.

Ekosistemin kirasını ödeyen dükkân WooCommerce, dolayısıyla ikinci dereceden etkiler orada en çok görülür. WooCommerce 11.x, PHP 8.1+ üzerinde rahat; dual API çalışması tip imzalarını temiz derleyebilmek için bile modern PHP’ye ihtiyaç duyuyor. PHP 7.4 kuyruğunu daraltan her hamle, Woo’nun mağazaları ortada bırakmadan tabanı yükseltmesi için doğrudan pist açar.

Ben olsam ne yapardım (ya da yapmazdım)

Tek bir WordPress veya WooCommerce siten varsa: önce staging’de olmak üzere hemen PHP 8.2 ya da 8.3’e geç ve konuyla ilgili fikir yazılarını okumayı bırak. Çoğu sitenin kullanmadığı en büyük tek performans ve güvenlik kaldıracı hâlâ PHP sürümü. Bizim müşterilerde bir Woo mağazasını 7.4’ten 8.2’ye taşımak, tek satır kod değiştirmeden sepet ve ödeme sayfalarında backend cevap süresinden tipik olarak %30-40 kırpıyor. Bu, her ölçekteki mağaza için gerçek para demek.

Ajans işletiyorsan: önümüzdeki hafta portföyünü tara. Siteleri PHP sürümüne ve hosting sağlayıcısına göre grupla. Rahatsız edici gerçek şu ki 2026’da PHP 7.4’te olan sitelerin çoğu kod öyle istediği için değil, kimse hosting sözleşmesini yeniden müzakere etmediği veya eklenti uyum matrisini çalıştırmadığı için orada. Site başına iki saatlik bir iş, yeniden kurulum değil. Bu çeyrek retainer’ına ekle, WordPress 7.2 / WooCommerce 12.x tabanı seni gafil avlamaz.

Eklenti geliştiriyorsan: özeti okuduktan sonra kendi composer.json‘unu aç. WooCommerce ekibinin izlediği örüntüyü uygula — WordPress’in önerdiği sürümle hizalanmış sert bir asgari ve readme’de belgelenmiş bir yumuşak asgari. Vicdan azabından PHP 7.4 desteğini taşıma. Buna ihtiyaç duyan kullanıcılar neredeyse her zaman bir sonraki eklenti güncellemesinde fatal error alacak kullanıcılar; kod tabanını onları korumak için geride tutmak, göründüğü kadar iyilik değil.

Yapmayacağım şey ise şu: WASM eklentisi fikrini bugün bir müşteri projesine sokmam. İyi bir konuşma, kargolanan bir özellik değil. HTML API’nin upstream’e taşınması da öyle — yıllar alacak; kullanıcı katmanındaki WP_HTML_Tag_Processor 2026’da hâlâ karşı tarafına kod yazılacak doğru araç.

Özetin en çok hoşuma giden yanı sesizdi. WordPress’in uzun destek penceresinin bir hata değil, bir özellik olduğunu; çözümün bu pencereyi kısaltmak değil, pencereyi ucuza tutmayı sağlayan otomasyona daha çok yatırım yapmak olduğunu kabul etmesiydi. Bu olgun bir çerçeveleme ve X’te sana projenin PHP 7’yi bırakıp yoluna devam etmesi gerektiğini söyleyen iyi niyetli bir geliştiriciyle bir sonraki karşılaşmanda aklında tutmak istediğim şey de bu.