Dört Adımda PHP 8.x'e Geçiş – Juliette Reinders Folmer ile Söyleşi

Bir WordPress sitesini, eklentisini veya temasını PHP'nin yeni bir sürümüne yükseltmek, düzenli olarak yinelenen bir görevdir. Ancak bunu olabildiğince verimli bir şekilde nasıl yaparsınız? Hiçbir şeyi gözden kaçırmayacağınızı nereden biliyorsunuz? Bunun için bir yol haritası var mı?

Bu makalede, bu soruları (ve daha fazlasını) ele alacağız ve bir yol haritası da dahil olmak üzere WordPress siteniz, eklentiniz veya temanız için PHP 8.x'e sorunsuz bir geçişin neler içerdiğine bakacağız.

Bunu PHP uzmanı Juliette Reinders Folmer ile yaptığımız bir röportaja dayanarak yapacağız. Günlük hayatının çoğunu programlamaya ve onun etrafındaki her şeye ayırıyor ve esas olarak WordPress de dahil olmak üzere açık kaynaklı projelere odaklanıyor.

Siz de sorunsuz geçiş yapmaya hazır mısınız? Adım adım planımızı merak mı ediyorsunuz? O zaman hemen dalalım!

PHP 8.x — Neler Değişti?

Değişikliklere genel bir bakış için aşağıdaki makaleleri öneririz:

• PHP 8.0 ve PHP 8.1 için sürüm notları
• PHP 8.0 ve PHP 8.1 için geçiş kılavuzu
• WordPress ve PHP 8.0 ve mevcut durum
• PHP 8.0 ve PHP 8.1'deki Yenilikler

Bu makaleleri okuduktan sonra, PHP 8.x'te nelerin değiştiği ve PHP projelerinizin sorunsuz çalışması için yapmanız gerekenler konusunda tamamen güncellenmiş olacaksınız.

Başlamanın en iyi yolunun ne olduğundan emin değilseniz, sorun değil. Juliette ile yaptığımız görüşmede bunu ayrıntılı olarak tartıştık ve bu makalede size PHP 8.x'e nasıl geçebileceğinizi olabildiğince ayrıntılı olarak açıklayacağız.

Ayrıca, tüm WordPress siteleriniz, uygulamalarınız ve veritabanlarınız için özel kontrol panelimiz olan MyKinsta'da çeşitli işlemlerin nasıl gerçekleştirileceğini bilgilendirici kutularda açıklayacağız.

PHP 8.x'e Geçiş: Nasıl Başlanır?

PHP 8.x'e geçiş kulağa basit geliyor ve teknik olarak öyle. Birçok ana bilgisayar, yönetici panelinde web siteniz için hangi PHP sürümünü kullanmak istediğinizi belirtmenize izin verir. Kinsta'da PHP sürümünün değiştirilmesi, MyKinsta kontrol panelinde tek bir tıklama ile yapılabilir.

Ancak bunu yapmadan önce, emin olmanız gereken bazı şeyler var. Bilgi ve deneyim seviyenize bağlı olarak aşağıdakileri öneririz:

• Çok fazla PHP bilgisine sahip olmadan standart temalar ve eklentilerle kendi WordPress sitenizi oluşturduysanız, sitenizin PHP 8.x'te çalışmaya uygun olup olmadığını araştırması için bir geliştirici veya ajansla çalışın. Bu konuda size yardımcı olabilecek üçüncü bir taraf mı arıyorsunuz? Ardından, size yardımcı olabilecek birkaç güvenilir şirketi listeleyen Ortaklar sayfamıza bakın.
• WordPress siteniz harici bir taraf, geliştirici veya ajans tarafından oluşturulduysa, sitenizin PHP 8.x üzerinde çalışıp çalışamayacağını sormak için onlarla iletişime geçin.
• Örneğin, kendi özel temanızla veya kendi geliştirdiğiniz eklentilerle WordPress sitenizi oluşturduysanız, aşağıda sizin için bir yol haritamız var.

Siteniz ilk iki kategoriden birine giriyorsa, sizi kesinlikle makalenin geri kalanını okumaya davet ediyoruz, ancak sitenizi PHP 8 uyumluluğu için kendiniz test etmeye başlamanızı önermiyoruz. Profesyonellere bırakın.

Hangisini seçerseniz seçin, canlı sitenizi öylece PHP 8'e geçirip "işe yarayıp yaramadığını görmemenizi" tavsiye ederiz. Sitenizin nasıl görüneceğini merak ediyor ve PHP 8'de çalıştığını görmek için sabırsızlanıyor musunuz? Ardından, bir hazırlama ortamında test etmeye başlayın. İyi bir ev sahibi, bir hazırlama ortamını kolayca kurmanıza olanak tanır.

Hazırlama ortamında, PHP 8.x'i etkinleştirebilir ve bu güncellemenin sitenizde iyi çalışıp çalışmadığını görebilirsiniz. Sitenizin yerel bir kopyası ile çalışmak da mümkündür. Ücretsiz DevKinsta geliştirme aracımızla sitenizi MyKinsta kontrol panelinden kolayca içe aktarabilir ve ardından PHP sürümünü 8.0 veya 8.1 olarak değiştirebilirsiniz.

Hazırlama ortamında herhangi bir sorun görmemeniz, aslında herhangi bir sorun olmadığı anlamına gelmez. Aşağıdaki yol haritası size nedenini söyleyecektir.

PHP 8.x Uyumluluk Testi: Yol Haritası

Test: iyi yazılım için anahtar kelime. WordPress web siteleri ve temalar, eklentiler ve WordPress çekirdeği gibi bileşenleri için bile test etmek, olmasını istemediğiniz şeylerin olmamasını sağlamanın bir yoludur.

Bir yazılım geliştirme projesi büyük ölçüde testlerden oluşur. Bu makalede, PHP 8.x'e sorunsuz geçiş yapmanıza yardımcı olabilecek testlere özel olarak bakıyoruz. DevOps Araçları ile ilgili makalemizde, kullanabileceğiniz bir araç koleksiyonu içeren bir bölüm bulacaksınız.

Bu blog gönderisinde aşağıdaki test türleri ele alınmaktadır:

Yapabileceğimiz farklı test türlerine daha yakından bakalım.

Statik Analiz (veya Statik Test)

Bir PHP geliştiricisi olarak atabileceğiniz ilk adım, çeşitli araçlarla kodunuzun statik bir analizini yapmaktır. Statik analiz, kodu çalıştırmadan yazılımı analiz etme işlemidir. Statik analiz ile hataları tespit etmek, PHP 8.x uyumluluğu ile ilgili sorunları tespit etmek, kodlama standartlarını uygulamak (örneğin, WordPress Kodlama Standartları) ve hatta kodu değiştirmek ve temizlemek mümkündür.

Statik Analiz Araçları

Aşağıdakiler gibi çeşitli araçlarla statik bir analiz gerçekleştirebilirsiniz:

• PHP Uyumluluğu
• Mezmur
• PHPStan

Yazma sırasında, en son PHPCompatibility sürümünde tüm PHP 8.1 kontrolleri desteklenmemektedir. PHP 8.1 kontrolleri geliştirme sürümünde olabilir, bu nedenle projenizi analiz etmek ve hangi hataların/önerilerin olduğunu görmek için PHPCompatibility kullanırken bunları (şimdilik) kullandığınızdan emin olun.

PHP 8.1 kontrolleri yakında yeni bir ana sürümde yayınlanacak. Bu konuda güncel bilgiler almak istiyorsanız ve bir GitHub hesabınız varsa, PHPCompatibility'nin GitHub deposunu açın ve Watch -> Custom -> Releases bölümüne gidin, burada yeni bir sürüm yayınlandığında bilgilendirilmeyi seçebilirsiniz.

PHP'nin yalnızca belirli bir sürümü (veya sürüm aralığı) için uyumluluğu test eden PHPCompatibility'nin kurulumu kolaydır. En iyi sonuçları PHPCompatibility içinde bir testVersion — örneğin 8.0+ (8.0 ve üzeri) — çalıştırırsanız alırsınız.

Kullanımdan kaldırılmış veya silinmiş işlevlere, işlev parametrelerinin varsayılan değerlerinin değiştirilmesine, concat'in parantezsiz kullanılıp kullanılmayacağına, match'in işlev adı olarak kullanılıp kullanılmayacağına (PHP 8.0'dan beri rezerve edildiğinden beri) bakmalısınız.

Mezmur ve PHPStan iyi eklemelerdir ve değişken türleriyle ilgili ek kontroller yaparak size yardımcı olabilir. Bu araçların dezavantajı, PHP 8.0 ve 8.1 hakkında rapor almak için çok fazla yapılandırma gerektirmesidir. Başarılı olsalar bile, birçok yanlış pozitif bekleyebilirsiniz. Yanlış pozitifler, statik analizin sınırlamalarından kaynaklanan yanlış verilen bildirimlerdir.

Bu iki aracın sonuçlarını doğru bir şekilde yorumlamak için sağlam bilgi gereklidir, ancak bu bilgi PHPCompatibility'nin bulamadığı ek uyumsuzlukları belirlemenize yardımcı olabilir. Onlar hakkında daha fazla bilgi edinmek istiyorsanız Mezmur ve PHPStan belgelerine bakın.

Özet:

• PHPCompatibility, Psalm, PHPStan ile statik analiz gerçekleştirin
• Tüm yasal sorunları çözün

Birim Testi

Süreçteki bir sonraki adım birim testidir. Birim testi, kod parçalarını ayrı ayrı test etme yöntemidir. Birim testinde, her birim için belirli hedefli testler geliştirilecektir. Bu, farklı senaryolardan geçmeyi içerecektir. Testlerin birbirinden bağımsız olması için tercihen her senaryo diğerlerinden ayrı olarak test edilir.

Tek başına birim testlerinin olması elbette yeterli değildir. Ayrıca çalıştırılmaları gerekiyor. Birim testleri en iyi şekilde Jenkins, GitHub Actions veya Travis gibi CI (sürekli entegrasyon) araçları kullanılarak otomatikleştirilir.

Birden Çok PHP Sürümünü Destekleme

Bir eklenti oluşturucu olarak, birden fazla PHP sürümünü desteklemek istiyorsanız, CI'deki testlerin desteklediğiniz tüm PHP sürümlerine karşı yapıldığından emin olun.

Elbette yalnızca daha yeni sürümleri de destekleyebilirsiniz, seçim tamamen size kalmış.

Birden çok PHP sürümüyle test yapmak, PHP sürümüne bağlı olarak birden çok PHPUnit sürümü kullanmanızı gerektirir. PHPUnit, yıllar içinde testlerin yazılmasını etkileyen çeşitli değişiklikler getirdiğinden, bu kısım aldatıcı olabilir.

Bunu aşmak için PHPUnit Polyfills'i (Juliette tarafından yazılmış ve Yoast sponsorluğunda) kullanabilirsiniz. Bu, PHPUnit 9 için resmi olarak desteklenmeyen (ve dolayısıyla PHP 8.x üzerinde çalışabilen) testler yazmanıza izin verir. Polyfill'ler daha sonra testlerinizin PHPUnit 4.x - 9.x ve PHP 5.4 - PHP 8.1 (şu andan itibaren) ile çalışmasını sağlar.[/notice]

Artık testleri çalıştırdığınıza göre, bir sonraki adım testlerde bulunan sorunların giderildiğinden emin olmaktır.

Kod kapsamı

Bu testleri çalıştırmak, sürümler arası uyumsuzlukları bulmanın en güvenilir yoludur.

Bunu yaparken, testlerinizin kod kapsamına dikkat edin:

• Bir A fonksiyonunuz olduğunu ve bunun için bir test yazdığınızı ve fonksiyondaki mantığın bir parçası olarak A fonksiyonunun B, C ve D fonksiyonlarını çağırdığını varsayalım.
• A işlevi testi, A işlevinin mantığını test etmek için yazılır, ancak test sırasında B, C ve D işlevlerini de çağırır. B, C ve D işlevleri için, o zaman genellikle yalnızca "mutlu yolu" - her şeyin yolunda gittiği durumu - test edersiniz ve bu nedenle, bu işlevlerdeki kodun (bir kısmı) olmasına rağmen, bu işlevler de henüz tam olarak test edilmemiştir. A fonksiyonunun testi sırasında yürütülür.
• Testlerinizin her biri için, özellikle hangi kodun test edildiğini belirtin. Bunu, her teste bir @covers vererek yaparsınız. Bu şekilde B, C ve D, kod kapsamı hesaplamasında "sayılmaz", bu da kodunuzun hangi bölümünün testlerle kapsandığını görmenizi sağlar.

Çoğu zaman geliştiriciler "mutlu yol" için - bazen bilmeden bile - yazar ve test eder. Bu durumlarda, beklenmeyen veriler bir işleve iletildiğinde ne olduğunun test edilmesi de gereklidir. Yalnızca beklenen değerler/türler ile test etmek yeterli değildir .

"Test yaparken, bir fonksiyonun yapması gerekeni yaptığından ve aynı zamanda yapmaması gerekeni yapmadığından emin olmanız gerekir." - Juliette Reinders Folmer Tweet için Tıklayın

Yukarıdaki alıntının ikinci kısmı, belki de ilk kısımdan daha önemli olduğu halde, genellikle unutulur. Yanlış bir tür iletirseniz ne olur? Hata mesajı alıyor musunuz? Yoksa işlev normal olarak devam ederken değişken dökümü mü? İşleve beklenmeyen bir değer iletilirse ne olur?

Beklenmeyen değişkenler, türler ve değerlerle işlevlerinizi test ettiğinizden emin olun. Ancak o zaman, yeni bir PHP sürümünün neden olabileceği sorunları bulmak için testlerinize güvenebilirsiniz.

PHP Daha Katılaşıyor

PHP, dinamik özellikler gibi şeylerin yanı sıra PHP'nin kendi işlevleri için "türleri" nasıl ele aldığı konusunda daha kesin (katı) hale geliyor. Bu değişiklikler genellikle geliştiricilerin hatasız kod (yani, daha az hata içeren kod) sunmasına yardımcı olmayı amaçlamaktadır. Ancak bu, PHP'nin "eski" ilkelerine dayalı olarak yazılmış önceden var olan kod için oldukça büyük bir yükseltme engeli oluşturabilir.

PHP'de daha yararlı hata mesajları için bu sürücü sayesinde, mevcut kodu yeni PHP sürümlerine uygun hale getirmenin giderek daha fazla zaman aldığını görebilirsiniz. PHP 5.6'da çalışan bir kodu PHP 7.0'a uygun hale getirmek, kodu PHP 8.1'e uygun hale getirmek için yükseltmeye kıyasla çoğu durumda yalnızca çok kısa bir süre aldı. Ve bu, PHP 7.0'ın "ana" sürüm olmasına ve PHP 8.1'in "küçük" olmasına rağmen.

Birçok durumda, test etme, yeni bir sürümü desteklemek için nelerin değiştirilmesi gerektiğini belirlemenin tek güvenilir yoludur.

Birim testi, aşağıdakiler de dahil olmak üzere çeşitli araçlarla mümkündür:

• PHPUnit
• alay
• behat,
• hikaye oyuncusu

Bu araçların birçoğu PHPUnit'e dayalı olarak veya PHPUnit ile birlikte oluşturulmuştur.

Sonuçta, hangi araçları kullandığınız önemli değil. En önemli şey, test etmeniz ve testlerin yeni PHP sürümlerinde çalışmasını sağlamanızdır. Bu adım bazen çok zor olabilir ama neyse ki daha önce de belirtildiği gibi bunun için PHPUnit Polyfills gibi araçlar var.

Entegrasyon Testi

Entegrasyon testi, statik analiz ve birim testinden sonra gerçekleştireceğimiz bir sonraki adımdır. Bir entegrasyon testi, gerçek hayattaki durumların yalnızca bir "kod biriminden" daha geniş bir bağlamda test edildiği yerdir. Bunlar, yalnızca iki örnek vermek gerekirse, etkin (test) bir veritabanıyla veya harici bir API ile test etmeyi içerir.

Dolayısıyla, bir eklentinin veya temanın kodunu WordPress bağlamında test ettiğinizde ve gerçek bir sürüm kullandığınızda, bunlar tanım gereği entegrasyon testleridir.

WP Test Utils (yine Juliette tarafından yazılmış ve Yoast sponsorluğunda), entegrasyon testi için mükemmel bir araçtır. WP Test Utils, WordPress'in Brainmonkey ve Mockery kullanılarak "örneklendiği", WordPress kodunu değil kendi kodunuzu test etmeniz için yaygın olarak kullanılan WordPress işlevlerinin "sahte" olduğu entegrasyon ve birim testleri yazmak için araçlar sağlar.

WordPress ile entegrasyon testi, WordPress ve WordPress'in test paketi ile entegrasyonu içerdiğinden daha karmaşık bir hikaye. Bir eklentinin veya temanın hangi WordPress sürümlerini desteklediğine bağlı olarak, testleri farklı PHP sürümlerinde çalıştırmak için hangi PHPUnit sürümlerinin WordPress tarafından desteklendiğini göz önünde bulundurmalısınız.

Örneğin, WordPress 5.6 - 5.8, PHP 5.6 - PHP 8.0'ı test etmek için PHPUnit 5 - 7'yi kullanır, ancak WordPress 5.9'dan itibaren WordPress'in kendisi de daha geniş destek için PHPUnit Polyfills kullanır. WP Test Utils, tüm bu farklılıkların üstesinden gelmek için bir köprü görevi görür.

WordPress 5.9 ve üstü dahil olmak üzere WordPress'in birden çok farklı sürümünde entegrasyon testlerinin nasıl çalıştırılacağı hakkında daha fazla bilgi edinmek ister misiniz? Ardından, WordPress'in web sitesinde bu konuyu okuyun.

Manuel Test

Birim testi ve entegrasyon testinden geçtiğiniz ve bulduğunuz tüm sorunları düzelttiğinize göre artık manuel test yapma zamanı. Siteniz çalışıyor ve kendi kodunuz çalışıyor ama aynı zamanda A, B ve C eklentilerini de kullanıyorsunuz. Bu eklentilerin uyumlu olup olmadığını biliyor musunuz?

Örneğin, bunu eklentinin yazarlarıyla kontrol edin ve PHP 8.x uyumlu olup olmadığını belirtin. O zaman soru, elbette, eklentinin nasıl test edildiğidir. Genellikle buradaki cevap şudur: izolasyonda. Eklentinin işlevleri genellikle diğer aktif eklentiler olmadan yalnızca WordPress ile birlikte test edilmiştir. Ve bu testlerde başka eklentiler kullanılmış olsa bile, kullandığınız tüm eklentilerin testin bir parçası olma olasılığı yüksektir, bu nedenle böyle bir uyumluluk bildirimini biraz şüpheyle alın.

Örneğin, 3 eklentiye (A, B ve C) sahip bir WordPress sitesi. Örneğin B eklentisinin, aynı filtreyi kullanan C eklentisinin birlikte çalışmak istediği bir filtre aracılığıyla yanlış bir değişken türü döndürmesi mümkündür. Bu, tür artık beklendiği gibi olmadığı için önemli bir hataya neden olabilir. Eklenti C, gerçek suçlu eklenti B olmasına rağmen, hata mesajının suçlusu olarak görülür.

Eklenti birlikte çalışabilirliği-uyumsuzluklarını, tek başına test ederken keşfetmek imkansızdır. Eklentiler ne kadar aktif olursa, bir şeylerin ters gitme olasılığı o kadar artar. Örneğin, gerçekte neyin yanlış gittiğini keşfetmek için canlı bir web sitesinden sayfa isteklerini hazırlama ortamına (hata günlüğü etkinken) iletmek çok faydalı olacaktır.

Bu tür bir sorunda, sorunun nedeni C eklentisi olmasa da, bir site sahibi genellikle yalnızca son yürütülen kodda (bu durumda, C eklentisinden) bir hata olduğuna dair bir mesaj görecektir.

Çoğu durumda, çok fazla manuel, insan işi söz konusudur ve bu sorunları tespit etmek ve düzeltmek için sağlıklı miktarda dirsek yağı gerekir. Bu, uçtan uca test kullanılarak otomatikleştirilebilir , ancak bunun WordPress'te olduğunu pek görmüyoruz.

Kullanılan Eklentiler için Kullanılabilirliği Test Edin

Geliştiriciler ve geliştirme ekipleri için: Kodu yalnızca testler mevcut olduğunda kabul edin. Bu şekilde, size çok zaman kazandıran daha az manuel test yapılmasını sağlarsınız.

Ticari bir eklenti veya tema satın almak istiyorsanız test stratejisini sorgulayın. Bu şekilde, WordPress topluluğundaki geliştiriciler/geliştirme ekipleri arasında gündemde daha üst sıralarda yer almak için topluca farkındalık yaratırız ve hepimiz bundan faydalanırız.

Test, gerçekte paradan tasarruf ederken, genellikle - haksız bir şekilde - bir maliyet olarak görülür. Test yazmak için gereken ekstra yatırım, önemli ölçüde daha az hata raporu ve hataları düzeltmek için daha az zaman harcanması şeklinde kendini amorti eder. Ek olarak, otomatik yazılım testi ile uzantılar ve değişiklikler daha hızlı yapılabilir çünkü testler mevcut işlevselliğin çalışmaya devam ettiğini hızlı bir şekilde doğrulayabilir.

''Gelecekteki halinize karşı nazik olun lütfen ;-)'' - Juliette Reinders Folmer Tweet için Tıklayın

WordPress Ana Bilgisayarlarının ve PHP 8.x'in Rolü

Ortalama bir site sahibi için, barındırıcınızın rehberliği son derece arzu edilir. Aşağıdakileri göz önünde bulundur:

• Müşteriler için WordPress Core, eklentiler ve/veya temaların (bazı durumlarda) PHP çapraz sürüm uyumlu olmadığına dair belgeler ve güncellemeler
• Test seçenekleri (bir hazırlama ortamıyla çalışmak gibi)
• Hata raporlama ve destekle iletişim kurma yöntemleri

Bu aynı zamanda bir web barındırıcısına da fayda sağlar, çünkü site sahipleri genellikle sorunlar ortaya çıktığında yardım için ana bilgisayarla iletişim kurar. PHP 8.0 veya 8.1'e geçiş durumunda, olası sorunlardan site sahibi sorumludur ve geçiş için uygun şekilde hazırlamak için sahibi ne kadar fazla bilgiye sahip olursa o kadar iyidir.

PHP 8.0 veya 8.1'i bir web barındırıcısı olarak müşterilerin kullanımına sunmak bir şeydir, ancak bunu yaparken, sorunların ortaya çıkabileceğinin farkında olmaları için müşteriler arasında farkındalık yarattıklarından emin olmaları gerekir. Sitenizi, canlı sürümden farklı bir sürüme sahip bir hazırlık ortamında test etmeniz önerilir. (PHP sürümlerinin seçilmesi varsayılan olarak Kinsta'da mevcuttur.)

WordPress için Minimum PHP Sürümü

Şu anda tüm web sitelerinin %15'inden fazlası PHP sürüm 7.0 veya daha düşük bir sürümü kullanıyor. Bu, resmi WordPress istatistiklerinde görülebilir. Tüm WordPress sitelerinin yaklaşık %83'ü şu anda PHP 7.4 veya daha düşük bir sürüm kullanıyor. Lütfen 7.4 sürümünden daha düşük veya buna eşit herhangi bir sürümün şu anda PHP tarafından artık desteklenmediğini unutmayın. PHP'nin ömrünü tamamlamış sürümlerini kullanmak, güvenlik güncellemeleri artık yayınlanmadığından sorunlara neden olabilir.

Sorunlardan kaçınmak için, WordPress site sahiplerinin, sitelerinin güvenli bir şekilde çalışmasını sağlayacak minimum PHP sürümünü bilmeleri ve bu sürüm hakkında bilgi sahibi olmaları önemlidir. Site sahipleri kendi paylarına PHP sürümünü kendileri değiştirebilirler (Kinsta'da tüm paketler için mümkündür) veya sunucularından siteyi daha yeni bir PHP sürümüne güncellemelerini isteyebilirler. Aşırı durumlarda, bu yeni sürümleri destekleyen bir ana bilgisayara geçebilirsiniz.

WordPress yalnızca minimum 7.4 sürümünü gerektirdiğinden, birçok ana bilgisayar ve web sitesi sahibinin sitelerini güncelleme motivasyonu yetersizdir. Ve bu, PHP 7.4'ün Kasım 2022'de ömrünün sonuna gelmesine rağmen.

WordPress minimum PHP sürümünü yükseltirse, bu, birçok sitenin artık en son WordPress sürümüne yapılan bir güncellemeyle uyumlu olmayacağı anlamına gelebilir. Ancak, bu eski sürümler için güvenlik güncellemeleri oldukça uzun bir süre daha yayınlanmaya devam edecektir.

Özet

Web sitenizde PHP 8.0 veya üstüne geçmek için sizin veya geliştiricinizin gerçekleştirmesi gereken birkaç adım vardır. Önemli adımlar şunları içerir:

• statik analiz
• Birim testi
• Entegrasyon testi
• Manuel test

PHP 8.x'e geçerken her şeyin doğru şekilde test edildiğinden emin olun. Bu, sitenizin daha yeni bir PHP sürümünde düzgün, hızlı ve güvenli bir şekilde çalışacağını garanti etmenin tek yoludur.

Juliette'e bu makaleye katıldığı ve bahsedilen aletler üzerindeki tüm çalışmaları için çok teşekkür ederiz!

Jip Moors tarafından çekilen ve izin alınarak kullanılan Juliette'in fotoğrafı.