PHP 8.2: WordPress, Eklentiler ve Geliştiriciler için Ne Anlama Geliyor?

PHP 8.2.0 ilk çıkışını 8 Aralık 2022'de yaptı. Büyük bir güncelleme olarak performans iyileştirmeleri, daha basit sözdizimi ve bağımsız türler olarak null , false ve true ile daha fazla tür güvenliği getiriyor. WordPress geliştiricilerini zorlaması muhtemel en büyük değişikliklerden biri, dinamik özelliklere izin vermeyen salt okunur sınıfların tanıtılmasıdır.

Dinamik özellikler kullanımdan kaldırılmıştır ve PHP 9 veya muhtemelen PHP 10'da önemli bir hataya neden olacaktır. Potansiyel olarak acı verici olsa da - özellikle WordPress çekirdeği için - kullanımdan kaldırma, önemli bir özelliktir ve PHP geliştiricilerine bir hediyedir.

PHP'nin son zamanlardaki gelişimine ve ayrıca WordPress geliştiricilerinin, son kullanıcılara en çok fayda sağlayacakları yeni özelliklerden yararlanırken geriye dönük uyumluluğu nasıl sürdürdüklerine bir göz atalım.

WordPress'te PHP Gelişimine Ayak Uydurmak

WordPress çekirdeği, eski sürümlerin desteklenmeyeceği planlanmış bir kullanım ömrü sonu tarihi olmaksızın önemli ölçüde geriye dönük uyumluluk sağladığından, kendi ürün veya hizmet yaşam döngülerini ve destekleyecekleri PHP sürümlerini belirlemek WordPress işletmelerine düşer.

Minimum PHP 7.4 gerektiren WooCommerce'in aksine, WordPress çekirdeği şu anda yalnızca PHP 7.4 veya üstünü önermektedir. Ayrıca, 2018 sonunda kullanım ömrünün sonuna ulaşan PHP 5.6.20 ile de çalışır. WordPress projesi bunu not eder ve desteklenmeyen PHP sürümlerini kullanmanın "sitenizi güvenlik açıklarına maruz bırakabileceği" konusunda uyarır. (WordPress.org Gereksinimleri)

Neyse ki, şu anda tüm WordPress sitelerinin yalnızca %5,1'i PHP 5.6 kullanıyor ve yalnızca %2'si daha da eski bir sürüm kullanıyor. %20'si PHP 7.0 ila 7.3 kullanıyor ve en büyük grup (%56.7) PHP 7.4 kullanıyor. (WordPress.org İstatistikleri)

Ne yazık ki PHP 7.4, Kasım 2022'nin sonunda EOL tarihine ulaştı. PHP 8.0'ın 2023'ün büyük bölümünde resmi güvenlik desteği için bir yıldan az bir süre kaldı. Mevcut ve aktif olarak desteklenen sürüm PHP 8.1, sonunda eskiyecek 2024'ün ilk kararlı sürümü olan PHP 8.2, Aralık 2025'e kadar güvenlik desteğine sahip olacak.

Bu, hızlı bir sürüm döngüsüdür ve WordPress ekosisteminin buna ayak uydurmak için mücadele etmesi şaşırtıcı değildir. Web'in yarısından fazlasının WordPress üzerinde çalıştığı düşünülürse, bu, hızlı bir şekilde dönemeyen büyük bir gemidir. Kanayan kenara doğru bir yarıştan çok daha fazla dengeleyici bir hareket. Bununla birlikte, PHP 8'e geçiş, daha az bellek kullanımıyla daha hızlı yürütme için çalışma zamanında Tam Zamanında (JIT) PHP derlemesi gibi büyük performans artırıcı özelliklerle birçok avantaj sağlar.

Geriye Dönük Uyumluluk ile İstikrar, İleriye Dönük Düşünme ve İnovasyon Arasındaki Denge

Mümkün olan en geniş kullanıcı kitlesine hitap etmek ile PHP ile para birimini korumak arasındaki ödünleşim, WordPress geliştiricileri, barındırıcıları ve ürün şirketleri için her zaman bir ikilem oluşturmuştur. Uzun vadeli müşterileri ve eski siteleri olan ajanslar ve serbest çalışanlar aynı sorunla karşı karşıyadır: minimum gereksinimleri güncellemek, mevcut müşterileri sitelerinde önemli değişiklikler yapmaya veya sitelerinin çökmesine neden olabilir.

Bir yandan, PHP ile güncel kalmanın faydaları, gelişmiş güvenlik ve performans ve geliştiriciler için en son programlama kavramları ve yetenekleridir. Öte yandan, gerekli minimum PHP'yi geciktirmenin ana yararı, mutlu (kendinden memnun olsa da) ve geniş bir müşteri tabanıdır. Bu bir "şimdi öde ya da sonra öde" durumu. Bir noktada, yara bandını yırtmanız gerekir.

Kullanıcı ortamlarıyla ilgili iyi veriler ve telemetri, minimum PHP sürümü gereksinimini yükseltmek için en az kesintiye uğrayan sürenin belirlenmesine yardımcı olabilir. Çoğu eklenti geliştiricisi, WordPress.org eklenti havuzunun aktif yükleme verilerinin bir parçası olmadığından, bu sayıları kendi araçlarıyla takip eder. Kaçınılmaz olarak, birçok kişiyi etkileyen potansiyel olarak önemli bir değişikliğin, bir destek biletleri telaşıyla sonuçlanması garanti edilir.

Geriye dönük uyumluluğa öncelik vermek, yüksek düzeyde bakım çalışması gerektirir. Çok geniş ve çeşitli bir kullanıcı tabanını desteklemek, son kullanıcı için harikadır, ancak bu, geliştiricilerin kodlarını birçok farklı ortamda çalışır durumda tutmaları gerektiği anlamına gelir. Hiçbir geliştirici, "Yeni özellikler eklendikçe eski PHP sürümlerini desteklemeyi seviyorum" demedi!

Endişelenmeleri gereken sadece eski PHP değil, aynı zamanda eski veritabanları ve WordPress yığınındaki düzinelerce başka varyasyon. Eski öğeler içeren geniş bir WordPress sunucu ortamı yelpazesi olduğunda uç vakalar ortaya çıkar ve uzmanların bile kafasını karıştırır.

Minimum PHP Gereksiniminizi Artırmak İçin En İyi Zaman

iThemes Security Pro 7.2 sürümü, mevcut müşteriler için hem yenilik hem de kararlılık sağlamak üzere bir WordPress ürününün minimum PHP gereksinimini yükseltmenin iyi bir örneğidir.

7.2 sürümünden itibaren iThemes Security Pro, PHP 7.3 veya üzerini gerektirmiştir ve 8.1'e kadar destekler. iThemes Security Pro için PHP gereksinimini güncelleme kararı, WebAuthn çerçevesini uygulamak için verildi. Uygulama, şifrelemeyi ve genel anahtarları yönetmek için PHP 7.3+ sürümüne ihtiyaç duyan kitaplıklar gerektiriyordu. iThemes Security Pro 7.2'de tanıtılan 2FA, geçiş anahtarı ve biyometrik oturum açma özellikleri bu kararın doğrudan bir sonucudur. Açık parolalarının kırıldığı bir zamanda, iThemes Security ekibi, birincil kullanıcı kimlik doğrulama deneyimi olarak WordPress'e ilk kez parolasız oturum açma özelliğini getirdi.

PHP'nin eski sürümleriyle uyumluluk için WebAuthn kitaplıklarını yeniden yazarak bu özellikleri oluşturmak mümkün olabilirdi. Tabii ki, bu çok daha fazla iş olur ve bakımı için ek kod oluşturur. Daha akıllıca olan yol, PHP 7.3 veya üstünü gerektiren bağımlılıkları benimseyerek PHP topluluğuna makul bir hızda ayak uydurmaktı. Kullanıcılarının çoğu zaten oradaydı. Bu nedenle iThemes Security geliştirme ekibi, yeni ve mevcut kullanıcılar için minimum PHP gereksinimini artırmaya karar verdi.

GiveWP gibi Gutenberg blok düzenleyicisine büyük yatırım yapılan WordPress ürünleri için değişikliği yönetmek daha da zor olabilir. WordPress çekirdeğindeki kararlılık ve yavaş değişim oranı, arka uç PHP geliştiricileri için sinir bozucu olabilir, ancak ön uç JavaScript/React geliştiricilerinin platformu ileriye götürmesine izin veriyor.

GiveWP'nin Geliştirme Müdürü Jason Adams, site düzenleyici geliştikçe kullanıcıları sürümler arasında taşıyabilecekleri için geriye dönük uyumlu olmaları gerekmediğini belirtiyor. Ancak, “PHP için geçiş diye bir şey yoktur” yorumunu yaptı. Sonunda, PHP 9 mimarisine ve PHP 8.2'deki yeni kullanımdan kaldırılan özelliklerden uzaklaşmaya uyum sağlamaları gerekecek.

Minimum PHP gereksinimlerini güncellemek için WordPress ekosistemindeki her ürün için tek bir "doğru zaman" yoktur. Adams, "Bu felsefi olarak çözebileceğin bir sorun değil," dedi. Bu gerçekten, değişiklikten kaç kullanıcının olumsuz etkileneceğine dayalı bir karar çağrısına bağlıdır. %90 veya daha fazlası PHP 7.2 veya 7.4'teyse, minimum gereksinimi bu düzeye çıkarmak uygundur.

Adams, bu sayıların bir ürünün belirli kullanıcı tabanına bağlı olarak büyük ölçüde değişebileceğini söylüyor. Teknik olarak daha becerikli müşteriler tarafından kullanılan bir ürün, şu anda desteklenen PHP sürümlerine daha yakın olma eğiliminde olacaktır. Birçok kar amacı gütmeyen kuruluşun kullandığı GiveWP gibi bir ürünün geriye dönük uyumluluğa daha fazla ağırlık vermesi gerekecektir. İlerlemenin bir başka yolu da, eski kodun ve kullanıcılarının, desteklenecek ancak yeni özelliklerin eklenmeyeceği uzun vadeli bir sürümde kollara ayrılmasına izin vermektir. Kullanıcılar yükseltme yapmaya hazır olduklarında, gelecekteki PHP uyumluluğu için oluşturulmuş yeni bir ana sürüme geçebilirler.

Kullanımdan Kaldırma Bildirimleri Geliştirmeyi İleriye Taşıyor

WordPress.com, PHP 8.2'yi barındırma özellikleri etkinleştirilerek İş ve E-ticaret planları için bir seçenek olarak piyasaya sürdü ve WordPress.org ekosisteminde, oldukça iyi tasarlanmış eski kodun bir sonraki ana PHP sürümüyle kırılması veya güvensiz hale gelmesi pek olası değil. serbest bırakmak. WordPress.org temel kod tabanı resmi olarak PHP 8.0 için yalnızca "beta" desteği sunsa da, genellikle PHP'nin en son sürümleriyle ve iyi desteklenen eklentilerle gayet iyi çalışır. Ölümcül veya ayrıştırma hataları atmazlar. Hata ayıklama açıkken pek çok uyarı bile görmemelisiniz. Henüz hata olmayan, kullanımdan kaldırılmış birçok işlev bildirimi görebilirsiniz.

Hızlı bir PHP sürüm döngüsünün yarattığı hayal kırıklıklarının, geliştiricilerin kodlarını yeniden düzenleme ve PHP'nin kullanımdan kaldırılmış yönleriyle yakalama oyunu oynama arasında saplanıp kalmasıyla çok ilgisi vardır. Bu kritik çalışma, onlara en son PHP sürümünün getirdiği yeni kavramlar ve yeteneklerle keşfetmek ve yenilik yapmak için daha az zaman bırakabilir.

Bu duruma bakmanın başka bir yolu var. PHP'nin kullanımdan kaldırılan özellikleriyle uğraşmak aslında ileriye dönüktür ve geliştiricileri gelişen bir dilin sonraki yinelemelerinde akıcı olmaya zorlar. Bu biraz zorunlu egzersiz olmadan, mevcut bilgi, eskidiğinde kötü alışkanlıklar haline gelecek olan eski alışkanlıklara daha kolay yerleşir.

Kullanımdan kaldırma bildirimleri, şu anda çalışan ancak PHP'nin gelecekteki sürümlerinde bozulacak şeylere işaret ediyor. Brent Roose'un açıkladığı gibi, bir geliştiriciyseniz bu sizin için iyidir. Geliştiriciler bu bildirimlere dikkat ederse, kullanımdan kaldırılan herhangi bir kodun üstesinden gelmek için bolca zamanları olacaktır. Ve küçük sürüm güncellemelerini engelleyici olmamalıdır.

iThemes Güvenlik Baş Geliştiricisi ve WordPress Temel Sorumlusu Timothy Jacobs, kullanımdan kaldırma uyarılarının olmasının iyi olduğunu söylüyor. Geliştiricileri, giderek daha güvenli, performanslı, hatasız olacak ve uç durumlarla daha iyi başa çıkabilecek "daha doğru" ve "daha az kırılgan" kodu benimsemeye itiyorlar. Bu görünümde, hata günlüğünüzü dolduran E_DEPRECATED bildirimleri, "ileride bir şeylerin bozulacağına dair bir erken uyarı sistemi gibidir, ancak şu anda bozulmamıştır."

PHP 8.2'den Sonra Dinamik Özellikler Olmadan Yapmak

Nikita Popov'un PHP 9'da dinamik özellikleri aşamalı olarak kaldırma gerekçesi, PHP'nin daha esnek kod ve programlama kurallarına doğru evrimsel yöneliminin iyi bir örneğidir:

Bu değişikliğin motivasyonu iki yönlüdür: Ortak durumda hataları (yazım hataları veya yeniden adlandırmalardan kaynaklanan) önlemek ve kasıtlı kullanımları açık hale getirmek. Temel sorun, var olmayan bir özellikten okumanın, sorunu hemen görünür kılan bir tanılama yayınlaması, var olmayan bir özelliğe yazmanın ise tamamen sessiz olmasıdır. PHP, programcının bir hata yaptığına dair hiçbir belirti vermez.

Brent Roose'un PHP 5.6'dan 8.2'ye evrimiyle ilgili iki dakikalık videosu, PHP'nin 2014'ten günümüze ne kadar ilerlediğinin parlak ve basit bir görsel gösterimidir. Roose, basit bir veri aktarım nesnesi örneğini kullanarak, PHP 5.6 kodunun PHP 8.2'ye giderken nasıl dramatik bir şekilde çok daha basit, daha yalın ve genel olarak daha zarif bir kod bloğuna dönüştüğünü gösteriyor.

Roose'un dinamik özelliklerle (PHP 8.2'de kullanımdan kaldırılmıştır) başa çıkmayla ilgili ipuçlarında belirttiği gibi, geliştiricilerin kullanımdan kaldırma uyarıları ölümcül hatalara dönüşmeden önce mevcut kodlarını güncellemek için bolca yolu olmalıdır. Ancak bu pist hızla azalacak ve WordPress özel bir durum. Tonya Mork, WordPress çekirdeğindeki bilinmeyen dinamik özelliklerin kullanımdan kaldırılmasını ele almak için Trac'ta kabul edilmiş bir teklife sahiptir. O ve Juliette Reinders Folmer, WordPress geliştiricilerinin kodlarını yeniden düzenlemek için yeterli zamana sahip olmayacağından endişe ediyor, yirmi yıllık bir proje için ileriye dönük uyumluluğu sürdürmenin özel zorluklarından bahsetmiyorum bile. Mork, Reinders Folmer ve Sergey Biryukov, bu göz korkutucu görevin büyük ölçüde isimsiz kahramanları oldular.

Mork ve Reinders Folmer, PHP 8.2'deki Dinamik Özellikler ve Sihirli Yöntemler tartışmalarında, WordPress'in PHP 3 ve 4'teki köklerinin, PHP'nin nesne yönelimli bir dil olarak ilerlemeye devam ederken onu sağlam bir prosedürel programlama evreninde tuttuğuna dikkat çekiyor. Reinders Folmer'ın belirttiği gibi, temel geliştiricilerin geriye dönük uyumluluğu bozmadan günümüzün PHP'sindeki eski kodun davranışını sürdürmenin ve "kodu daha iyi ve daha güvenli hale getirmenin ve PHP 8.2 dinamik özelliklerinin kullanımdan kaldırılmasını azaltmanın" bir yolunu bulması gerekiyor. Videoda, "Aslında [WordPress çekirdeğinin] [geriye dönük uyumluluk] kesinti yok kuralıyla kendi hayatımızı çok zorlaştırıyoruz" diyor.

Mork, "Bunun için iyi bir neden var," diye yanıtlıyor - "bu, kullanıcılar için. Kullanıcılar, bu düğmeye basıp yükseltebileceklerine ve geriye dönük uyumluluğu düşündüğümüze ve buna öncelik verdiğimize güvenirler. Bu bizim için bir mihenk taşı… böylece kullanıcılar yükseltme yapma konusunda kendilerine güvenebilirler.”

Tüm Geliştirme Bakımdır…

WordPress çekirdeğinde geriye dönük uyumluluğu korumak adına PHP'nin önceki iki ana sürümüyle çalışmak için "modern" PHP'yi desteklemeye çalışmak benzersiz bir zorluktur. Eklenti geliştiricileri, PHP 8.2'nin salt okunur sınıfları ve dinamik özelliklerin kullanımdan kaldırılması gibi yeni özelliklerden yararlanabilecek şekilde kodlarını güncellemek gibi çok daha kolay bir göreve sahiptir. Bu çalışmanın çoğu, büyük ölçüde bir bakım biçimidir.

Mimari olarak, PHP 8+ sürümündeki değişiklikler değişmezlik gibi programlama kavramlarına odaklanıyor. Jacobs'a göre değişmez veri yapıları "doğası gereği güvenlik sorunlarını çözmez" ancak geliştiricilerin kodunun hataya daha az açık ve daha doğru olmasına yardımcı olurlar:

Değişmez bir veri yapısının doğası gereği güvenli olduğunu ve değişken bir veri yapısının güvensiz olduğunu söyleyemem. Bunun yerine değişmez veri yapıları, güvenlik sorunlarına yol açabilecek programlama hatalarını ortadan kaldırmaya yardımcı olabilir. Kodumuzun var olabileceği farklı durumların sayısını azaltarak, kodumuzun karmaşıklığını azaltabilir ve dolayısıyla hata yapma şansını azaltabiliriz.

Kodu aktif olarak desteklenen PHP sürümleri standardında tutmanın en iyi nedeni güvenlik riskini azaltmaktır. Adams'ın görüşüne göre PHP 8.2 yararlı kolaylıklar ve “korkuluklar” getiriyor, ancak programcıları heyecanlandıracak veya oyunun kurallarını değiştirecek çok az şey var. #[\SensitiveParameter] özniteliği gibi bir şey, hassas verilerin genellikle üçüncü taraf hizmetlere giden yığın izlerinden filtrelenmesine izin verdiği için pratikte daha önemli olabilir. PHP 8'de tanıtılan nitelikler, Adams'ın daha önce yapamadığınız bir şeyi mümkün kılmak için dikkatini çeken son yenilik için yaptığı seçimdir: "bir şeyi [sınıflar, değişkenler, yöntemler vb. gibi] bir meta perspektiften tanımlayın."

PHP 8.0 ila 8.2'deki ve gelecekteki sürümlerdeki yeni özelliklerden yararlanmak, geliştiricilerin yaratıcılığının parlayabileceği yerdir, ancak bu sürümleri desteklemek, böylece eklentiler ve WordPress çekirdeği bunları bozmaz, hem pratik hem de hayati önem taşır.

…Ve Tüm Bakım Sanattır

Jeff Atwood'un yakın zamanda Kale Davis'in Hacker Bülteni sayesinde okuduğum “The Noble Art of Maintenance Programming” adlı eski ama seçkin bir blog yazısı var. Atwood, "Bakım programlaması yaygın olarak temizlik işi olarak görülüyor" diye yazıyor. Bu bana, "Maintenance Art Manifesto"su programlama ve web geliştirmeyle çok ilgili olduğunu düşündüğüm sanatçı Mirele Laderman Ukeles'i hatırlattı:

İki temel sistem: Geliştirme ve Bakım. Her devrimin ekşi topu: devrimden sonra Pazartesi sabahı çöpü kim toplayacak? […] Geliştirme sistemleri, büyük değişim alanı olan kısmi geri bildirim sistemleridir. Bakım sistemleri, değişiklik için çok az yer olan doğrudan geri bildirim sistemleridir.

Laderman Ukeles, 1969'da manifestoyu yazıp Bakım Sanattır ilan ettiğinde genç bir sanatçı ve yeni anneydi. Son teknoloji sanat eserlerinin ve yüksek statülü emeğin onları mümkün kılan işten nasıl ayrıldığı konusunda hüsrana uğradı: ebeveynlik, sanatsal beceriler ve gelenekler öğretmek ya da sadece bir sanat gösterisi yapmak. Bir müze kapıcısı olarak hareket etmesine dayanan unutulmaz bir sergi yaptı. Daha sonra (devam eden) kariyerinin çoğunu New York Şehri Sanitasyon Departmanı'nın konuk sanatçısı olarak geçirdi. Bu roldeki ilk projesi, "New York'u hayatta tuttukları için" 8.500 sağlık çalışanına kişisel olarak teşekkür etmekti.

Atwood'un programlama konusunda benzer bir yaklaşımı var. Bakım işini kötülemenin tamamen yanlış olduğunu söyleyen yazılım mühendisliğindeki birkaç önemli figürden alıntı yapıyor. Robert L. Glass, "Bakım önemli bir entelektüel zorluk ve aynı zamanda bir sorun değil, bir çözümdür" diye düşündü, bu nedenle en yetenekli insanlar için önemli bir görev olarak görülmelidir. Joel Spolsky uzun zaman önce geliştiricilerin tembel olduğunu ve "her zaman kodu atıp baştan başlamak istemelerinin" nedeninin "kodu okumaktan yazmaktan daha zor olması" olduğunu yazmıştı.

Andy Hunt ile yaptığı bir sohbette Dave Thomas, "Tüm programlama bakım programlamasıdır çünkü nadiren orijinal kod yazıyorsunuz. …. Zamanınızın çoğunu bakım modunda geçiriyorsunuz. Bu yüzden, mermiyi ısırıp "İlk günden beri devam ediyorum" diyebilirsiniz. Bakım için geçerli olan disiplinler küresel olarak uygulanmalıdır.” Hunt, "Kodu ilk kez yazdığınızda yalnızca ilk 10 dakika orijinal oluyor. Bu kadar."

Atwood nihayetinde bu bakış açısına doğru eğiliyor, ancak Jason Adams ve Timothy Jacobs'tan duyduğum ortak WordPress geliştirici bakış açısını yansıtıyor. Özel WordPress geliştirme/bakım sanatı?

"Bu bir denge hareketi."

WordPress'i Korumak ve Korumak için En İyi WordPress Güvenlik Eklentisi şimdi %35 indirimli!

WordPress şu anda tüm web sitelerinin %40'ından fazlasına güç veriyor, bu nedenle kötü niyetli bilgisayar korsanları için kolay bir hedef haline geldi. iThemes Security Pro eklentisi, WordPress web sitenizi güvenli hale getirmeyi ve korumayı kolaylaştırmak için WordPress güvenliğinin varsayımlarını ortadan kaldırır. Bu, WordPress sitenizi sizin için sürekli izleyen ve koruyan tam zamanlı bir güvenlik uzmanına sahip olmak gibidir.

Şimdi %35 tasarruf edin!

Dan Knauss

Dan Knauss, StellarWP'nin Teknik İçerik Uzmanıdır. 1990'ların sonlarından beri açık kaynakta ve 2004'ten beri WordPress ile çalışan bir yazar, öğretmen ve serbest çalışan.