PHP 8.2: Apa Artinya untuk WordPress, Plugin, dan Pengembang?

Diterbitkan: 2022-12-14

PHP 8.2.0 memulai debutnya pada 8 Desember 2022. Sebagai pembaruan besar, PHP 8.2.0 menghadirkan peningkatan kinerja, sintaks yang lebih sederhana, dan keamanan tipe yang lebih baik dengan null , false , dan true sebagai tipe mandiri. Salah satu perubahan terbesar yang mungkin menantang pengembang WordPress adalah pengenalan kelas readonly , yang melarang properti dinamis.

Properti dinamis tidak digunakan lagi dan akan menghasilkan kesalahan fatal di PHP 9 atau mungkin PHP 10. Meskipun berpotensi menyakitkan — terutama untuk inti WordPress — penghentian adalah fitur utama dan hadiah bagi pengembang dari PHP.

Mari kita lihat evolusi PHP baru-baru ini dan juga bagaimana pengembang WordPress mempertahankan kompatibilitas ke belakang sambil memanfaatkan fitur-fitur baru ketika mereka paling menguntungkan pengguna akhir.

Mengikuti Pengembangan PHP di WordPress

Karena inti WordPress mempertahankan kompatibilitas mundur yang signifikan tanpa tanggal akhir masa pakai yang direncanakan saat versi lama tidak didukung, bisnis WordPress bertanggung jawab untuk menentukan siklus hidup produk atau layanan mereka sendiri dan versi PHP yang akan mereka dukung.

Berbeda dengan WooCommerce, yang membutuhkan minimal PHP 7.4, inti WordPress saat ini hanya merekomendasikan PHP 7.4 atau lebih tinggi. Ini “juga berfungsi dengan” PHP 5.6.20, yang mencapai tanggal akhir masa pakainya pada akhir 2018. Proyek WordPress mencatat hal ini dan memperingatkan bahwa menggunakan versi PHP yang tidak didukung “dapat mengekspos situs Anda ke kerentanan keamanan.” (Persyaratan WordPress.org)

Untungnya, hanya 5,1% dari semua situs WordPress yang saat ini menggunakan PHP 5.6, dan hanya 2% yang menggunakan versi lama. 20% menggunakan PHP 7.0 hingga 7.3, dan kelompok terbesar (56,7%) menggunakan PHP 7.4. (Statistik WordPress.org)

Sayangnya, PHP 7.4 baru saja mencapai tanggal EOL-nya pada akhir November 2022. PHP 8.0 memiliki waktu kurang dari satu tahun untuk mendapatkan dukungan keamanan resmi hingga sebagian besar tahun 2023. Versi saat ini dan didukung secara aktif, PHP 8.1, akan habis masa berlakunya pada akhir tahun 2024. PHP 8.2, yang baru saja rilis stabil pertama, akan mendapat dukungan keamanan hingga Desember 2025.

Ini adalah siklus rilis yang cepat, dan tidak mengherankan jika ekosistem WordPress berjuang untuk mengikutinya. Dengan lebih dari separuh web berjalan di WordPress, ini adalah kapal besar yang tidak dapat berputar dengan cepat. Ini jauh lebih merupakan tindakan penyeimbangan daripada perlombaan menuju ujung tombak. Namun, lompatan ke PHP 8 memiliki banyak manfaat, dengan fitur peningkatan kinerja yang besar seperti kompilasi PHP Just-in-Time (JIT) saat runtime untuk eksekusi lebih cepat dengan penggunaan memori yang lebih sedikit.

Pengorbanan Antara Kompatibilitas Mundur dan Stabilitas, Pemikiran Maju dan Inovasi

Pertukaran antara melayani audiens pengguna seluas mungkin dan mempertahankan mata uang dengan PHP selalu menimbulkan dilema bagi pengembang, host, dan perusahaan produk WordPress. Agensi dan pekerja lepas dengan klien jangka panjang dan situs lama menghadapi masalah yang sama: memperbarui persyaratan minimum dapat memaksa pelanggan yang sudah ada untuk membuat perubahan signifikan pada situs mereka atau melihatnya rusak.

Di satu sisi, manfaat tetap up to date dengan PHP adalah peningkatan keamanan dan kinerja serta konsep dan kemampuan pemrograman terbaru untuk pengembang. Di sisi lain, manfaat utama dari penundaan minimum PHP yang dibutuhkan adalah basis pelanggan yang senang (walaupun puas) dan luas. Ini adalah situasi "bayar saya sekarang atau bayar saya nanti". Pada titik tertentu, Anda harus merobek bandaid.

Data dan telemetri yang baik tentang lingkungan pengguna dapat membantu menentukan waktu yang paling tidak mengganggu untuk meningkatkan persyaratan versi PHP minimum. Sebagian besar pengembang plugin mengawasi angka-angka itu dengan alat mereka sendiri, karena ini bukan bagian dari data pemasangan aktif repositori plugin WordPress.org. Tak pelak lagi, setiap perubahan yang berpotensi merusak yang berdampak pada banyak orang dijamin akan menghasilkan banyak tiket dukungan.

Memprioritaskan kompatibilitas ke belakang melibatkan pekerjaan pemeliharaan yang tinggi juga. Mendukung basis pengguna yang sangat besar dan beragam sangat bagus untuk pengguna akhir, tetapi itu berarti pengembang harus menjaga agar kode mereka tetap berfungsi dengan banyak lingkungan berbeda. “Saya suka mendukung versi PHP yang lebih lama karena fitur baru ditambahkan,” — kata tidak ada pengembang, pernah!

Bukan hanya PHP lawas yang harus mereka khawatirkan — ini juga basis data lawas dan lusinan variasi lainnya di tumpukan WordPress. Kasus tepi muncul dan membingungkan bahkan para ahli ketika ada spektrum yang luas dari lingkungan server WordPress dengan elemen usang.

Waktu Terbaik untuk Meningkatkan Persyaratan PHP Minimum Anda

Rilis iThemes Security Pro 7.2 adalah contoh bagus dalam meningkatkan persyaratan PHP minimum produk WordPress untuk menghadirkan inovasi dan stabilitas bagi pelanggan yang sudah ada.

Pada rilis versi 7.2, iThemes Security Pro membutuhkan PHP 7.3 atau lebih tinggi dan mendukung hingga 8.1. Keputusan untuk memperbarui persyaratan PHP untuk iThemes Security Pro dibuat untuk mengimplementasikan kerangka kerja WebAuthn. Implementasinya membutuhkan pustaka yang membutuhkan PHP 7.3+ untuk mengelola enkripsi dan kunci publik. Fitur login 2FA, kunci sandi, dan biometrik yang diperkenalkan di iThemes Security Pro 7.2 adalah akibat langsung dari keputusan ini. Pada saat kata sandi yang jelas dilanggar, tim Keamanan iThemes menghadirkan login tanpa kata sandi ke WordPress untuk pertama kalinya sebagai pengalaman otentikasi pengguna utama.

Dimungkinkan untuk membangun fitur ini dengan menulis ulang pustaka WebAuthn agar kompatibel dengan versi PHP yang lebih lama. Tentu saja, itu akan jauh lebih berhasil dan membuat kode tambahan untuk dipelihara. Jalan yang lebih bijak adalah mengikuti komunitas PHP dengan kecepatan sedang dengan mengadopsi dependensi yang membutuhkan PHP 7.3 atau lebih tinggi. Sebagian besar pengguna mereka sudah ada di sana. Itu sebabnya tim pengembangan Keamanan iThemes memutuskan untuk menaikkan persyaratan PHP minimum untuk pengguna baru dan yang sudah ada.

Untuk produk WordPress yang banyak berinvestasi di editor blok Gutenberg, seperti GiveWP, mengelola perubahan bisa menjadi lebih menantang. Stabilitas dan laju perubahan yang lambat pada inti WordPress mungkin membuat frustrasi pengembang PHP back-end, tetapi ini memungkinkan pengembang JavaScript/React front-end untuk mendorong platform ke depan.

Jason Adams, Manajer Pengembangan GiveWP, mencatat bahwa mereka tidak harus kompatibel ke belakang karena mereka dapat memigrasikan pengguna lintas versi saat editor situs berkembang. Namun, “Tidak ada yang namanya migrasi untuk PHP,” komentarnya. Akhirnya, mereka harus beradaptasi dengan arsitektur PHP 9 dan jauh dari fitur baru yang tidak digunakan lagi di PHP 8.2.

Tidak ada satu pun “waktu yang tepat” untuk setiap produk di seluruh ekosistem WordPress untuk memperbarui persyaratan minimum PHP. "Ini bukan masalah yang bisa Anda selesaikan secara filosofis," kata Adams kepada saya. Itu benar-benar tergantung pada panggilan penilaian berdasarkan berapa banyak pengguna yang akan terpengaruh oleh perubahan tersebut. Jika 90% atau lebih menggunakan PHP 7.2 atau 7.4, menaikkan persyaratan minimum ke level tersebut dapat dilakukan.

Angka-angka itu dapat sangat bervariasi tergantung pada basis pengguna spesifik suatu produk, kata Adams. Produk yang digunakan oleh pelanggan yang lebih mahir secara teknis akan cenderung lebih dekat dengan versi PHP yang didukung saat ini. Produk seperti GiveWP, dengan banyak organisasi nirlaba yang menggunakannya, perlu memberi bobot lebih pada kompatibilitas ke belakang. Cara lain untuk maju adalah membiarkan kode lama dan penggunanya bercabang dalam rilis jangka panjang yang akan didukung tetapi tidak melihat fitur baru ditambahkan. Saat pengguna siap melakukan pemutakhiran, mereka dapat bermigrasi ke rilis utama baru yang dibuat untuk kompatibilitas PHP di masa mendatang.

Pemberitahuan Penghentian Mendorong Pengembangan ke Depan

WordPress.com baru saja meluncurkan PHP 8.2 sebagai opsi untuk paket Bisnis dan E-niaga dengan mengaktifkan fitur hosting, dan dalam ekosistem WordPress.org, kode lama yang direkayasa dengan baik tidak mungkin rusak atau menjadi tidak aman dengan versi PHP utama berikutnya melepaskan. Meskipun basis kode inti WordPress.org secara resmi hanya menawarkan dukungan "beta" untuk PHP 8.0, umumnya bekerja dengan baik dengan versi PHP terbaru, dan begitu juga dengan plugin yang didukung dengan baik. Mereka tidak akan melempar kesalahan fatal atau parse. Anda bahkan tidak akan melihat banyak peringatan dengan debug diaktifkan. Anda mungkin melihat banyak pemberitahuan fungsi yang tidak digunakan lagi, yang bukan merupakan kesalahan — belum.

Frustrasi dari siklus rilis PHP yang cepat banyak berkaitan dengan pengembang yang terjebak dalam gulma yang memfaktorkan ulang kode mereka dan mengejar ketinggalan dengan aspek PHP yang sudah tidak digunakan lagi. Pekerjaan kritis ini dapat membuat mereka memiliki lebih sedikit waktu untuk mengeksplorasi dan berinovasi dengan konsep dan kemampuan baru yang dibawa oleh versi PHP terbaru.

Ada cara lain untuk melihat situasi ini. Berurusan dengan fitur usang dari PHP sebenarnya berwawasan ke depan dan memaksa pengembang untuk menjadi fasih dalam iterasi berikutnya dari bahasa yang sedang berkembang. Tanpa latihan yang agak dipaksakan ini, pengetahuan yang ada akan lebih mudah menjadi kebiasaan lama yang akan menjadi kebiasaan buruk ketika sudah usang.

Pemberitahuan penghentian menunjukkan hal-hal yang berfungsi sekarang tetapi akan rusak di versi PHP yang akan datang. Ini bagus untuk Anda jika Anda seorang pengembang, seperti yang dijelaskan Brent Roose. Jika pengembang memperhatikan pemberitahuan tersebut, mereka akan memiliki banyak waktu untuk mengetahui kode yang tidak digunakan lagi. Dan itu seharusnya tidak menjadi pemblokir pembaruan versi minor.

Timothy Jacobs, Pengembang Pemimpin Keamanan iThemes dan WordPress Core Committer, mengatakan ada baiknya memiliki peringatan penghentian penggunaan. Mereka mendorong pengembang maju untuk merangkul kode yang "lebih benar" dan "kurang rapuh" yang akan semakin aman, berkinerja, anti kesalahan, dan lebih mampu mengatasi kasus-kasus ekstrem. Dalam tampilan ini, pemberitahuan E_DEPRECATED yang mengisi log kesalahan Anda adalah "seperti sistem peringatan dini bahwa hal-hal akan rusak di masa mendatang, tetapi tidak rusak sekarang".

Melakukan Tanpa Properti Dinamis Setelah PHP 8.2

Alasan Nikita Popov untuk menghapus properti dinamis di PHP 9 adalah contoh yang baik dari dorongan evolusioner PHP menuju kode dan konvensi pemrograman yang lebih tangguh:

Motivasi untuk perubahan ini ada dua: Untuk mencegah kesalahan (karena kesalahan ketik atau penggantian nama) dalam kasus umum, dan untuk membuat penggunaan yang disengaja menjadi eksplisit. Masalah intinya adalah membaca dari properti yang tidak ada mengeluarkan diagnostik yang membuat masalah segera terlihat, sementara menulis ke properti yang tidak ada sama sekali diam. PHP tidak memberikan indikasi apapun bahwa programmer telah melakukan kesalahan.

Video dua menit Brent Roose tentang evolusi dari PHP 5.6 ke 8.2 adalah ilustrasi visual yang brilian dan sederhana tentang seberapa jauh perkembangan PHP dari tahun 2014 hingga saat ini. Menggunakan contoh objek transfer data sederhana, Roose menunjukkan bagaimana kode PHP 5.6 menyusut secara dramatis menjadi blok kode yang jauh lebih sederhana, lebih ramping, dan secara keseluruhan lebih elegan menuju PHP 8.2.

Seperti catatan Roose dalam tipnya untuk menangani properti dinamis (yang tidak digunakan lagi di PHP 8.2), pengembang harus memiliki banyak landasan untuk memperbarui kode yang ada sebelum peringatan penghentian berubah menjadi kesalahan fatal. Landasan pacu itu akan berkurang dengan cepat, dan WordPress adalah kasus khusus. Tonya Mork memiliki proposal yang diterima di Trac untuk menangani penghentian properti dinamis yang tidak diketahui di inti WordPress. Dia dan Juliette Reinders Folmer khawatir bahwa pengembang WordPress tidak akan memiliki cukup waktu untuk memperbaiki kode mereka, belum lagi tantangan khusus untuk mempertahankan kompatibilitas ke depan untuk proyek berusia dua puluh tahun. Mork, Reinders Folmer, dan Sergey Biryukov telah menjadi pahlawan tanpa tanda jasa dari tugas yang menakutkan ini.

Dalam diskusi mereka tentang Properti Dinamis dan Metode Ajaib di PHP 8.2, Mork dan Reinders Folmer menunjukkan bahwa akar WordPress di PHP 3 dan 4 menyimpannya dalam dunia pemrograman prosedural yang solid sementara PHP terus maju sebagai bahasa berorientasi objek. Pengembang inti perlu mencari cara untuk mempertahankan perilaku kode lama di PHP saat ini tanpa merusak kompatibilitas ke belakang "dan tetap membuat kode lebih baik dan lebih aman serta mengurangi penghentian properti dinamis PHP 8.2," seperti yang dikatakan Reinders Folmer. “Kami benar-benar membuat hidup kami sendiri sangat sulit dengan aturan [inti WordPress] tidak ada [kompatibilitas mundur],” catatnya dalam video.

“Ada alasan bagus untuk itu,” jawab Mork – “itu untuk pengguna. Pengguna memiliki keyakinan bahwa mereka dapat menekan tombol itu dan memutakhirkan, dan bahwa kami telah memikirkan tentang kompatibilitas ke belakang, bahwa kami telah memprioritaskannya. Ini merupakan landasan bagi kami … sehingga pengguna dapat memiliki kepercayaan diri untuk meningkatkan.”

Semua Pengembangan adalah Pemeliharaan…

Ini adalah tantangan unik untuk mencoba mendukung PHP "modern" untuk bekerja dengan dua versi utama PHP sebelumnya demi mempertahankan kompatibilitas mundur di inti WordPress. Pengembang plugin memiliki tugas yang jauh lebih mudah untuk memperbarui kode mereka dengan cara yang dapat memanfaatkan fitur baru, seperti kelas readonly PHP 8.2 dan penghentian properti dinamis. Banyak dari pekerjaan ini sebagian besar merupakan bentuk pemeliharaan juga.

Secara arsitektural, perubahan PHP 8+ membawa fokus pada konsep pemrograman seperti kekekalan. Struktur data yang tidak dapat diubah “tidak secara inheren memperbaiki masalah keamanan,” tetapi mereka membantu kode pengembang menjadi lebih sedikit rawan kesalahan dan lebih benar, menurut Jacobs:

Saya tidak akan mengatakan bahwa struktur data yang tidak dapat diubah secara bawaan aman, dan struktur data yang dapat diubah tidak aman. Sebaliknya, struktur data yang tidak dapat diubah dapat membantu menghilangkan kesalahan pemrograman yang dapat menyebabkan masalah keamanan. Dengan mengurangi jumlah status berbeda di mana kode kita dapat ada, kita dapat mengurangi kerumitan kode kita, dan karenanya mengurangi kemungkinan membuat kesalahan.

Alasan terbaik untuk mempertahankan kode ke standar versi PHP yang didukung secara aktif adalah untuk pengurangan risiko keamanan. PHP 8.2 menghadirkan kemudahan yang bermanfaat dan "pagar pengaman" dalam pandangan Adams, tetapi sedikit yang akan menggairahkan pemrogram atau dilihat sebagai pengubah permainan. Sesuatu seperti atribut #[\SensitiveParameter] mungkin lebih signifikan secara praktis karena memungkinkan data sensitif disaring dari pelacakan tumpukan yang sering masuk ke layanan pihak ketiga. Diperkenalkan di PHP 8, atribut adalah pilihan Adams untuk inovasi terakhir yang menarik perhatiannya karena memungkinkan sesuatu yang tidak dapat Anda lakukan sebelumnya: "jelaskan sesuatu [seperti kelas, variabel, metode, dll.] dari perspektif meta."

Memanfaatkan fitur-fitur baru di PHP 8.0 hingga 8.2 dan rilis mendatang adalah tempat kreativitas pengembang dapat bersinar, tetapi hanya mendukung versi tersebut, sehingga plugin dan inti WordPress tidak merusaknya, praktis dan vital.

… Dan Semua Pemeliharaan adalah Seni

Jeff Atwood memiliki posting blog lama tapi luar biasa berjudul "The Noble Art of Maintenance Programming" yang saya baca baru-baru ini, terima kasih kepada Kale Davis's Hacker Newsletter. “Pemrograman pemeliharaan secara luas dipandang sebagai pekerjaan kebersihan,” tulis Atwood. Ini mengingatkan saya pada seniman Mirele Laderman Ukeles, yang “Maintenance Art Manifesto”-nya selalu menurut saya sangat relevan dengan pemrograman dan pengembangan web:

Dua sistem dasar: Pengembangan dan Pemeliharaan. Bola asam dari setiap revolusi: setelah revolusi, siapa yang akan memungut sampah pada Senin pagi? […] Sistem pengembangan adalah sistem umpan balik parsial dengan ruang besar untuk perubahan. Sistem pemeliharaan adalah sistem umpan balik langsung dengan sedikit ruang untuk perubahan.

Laderman Ukeles adalah seorang seniman muda dan ibu baru pada tahun 1969 ketika dia menulis manifesto dan menyatakan Maintenance is Art. Dia frustrasi dengan bagaimana karya seni mutakhir dan pekerja berstatus tinggi dipisahkan dari pekerjaan yang memungkinkannya: mengasuh anak, mengajarkan keterampilan dan tradisi artistik, atau sekadar mengadakan pertunjukan seni. Dia melakukan pameran yang tak terlupakan berdasarkan dirinya bertindak sebagai petugas kebersihan museum. Kemudian dia menghabiskan sebagian besar karirnya (sedang berlangsung) sebagai artis-in-residence Departemen Sanitasi Kota New York. Proyek pertamanya dalam peran itu secara pribadi berterima kasih kepada 8.500 pekerja sanitasi "karena menjaga New York tetap hidup".

Atwood memiliki pandangan yang sama tentang pemrograman. Dia mengutip beberapa tokoh besar dalam rekayasa perangkat lunak yang mengatakan fitnah pekerjaan pemeliharaan semuanya salah. Robert L. Glass merasa “Pemeliharaan adalah tantangan intelektual yang signifikan serta solusi dan bukan masalah,” sehingga harus dianggap sebagai tugas penting bagi orang yang paling terampil. Joel Spolsky sudah lama menulis bahwa pengembang itu malas, dan alasan mereka "selalu ingin membuang kode dan memulai kembali" adalah karena "membaca kode lebih sulit daripada menulisnya".

Dalam percakapan dengan Andy Hunt, Dave Thomas berpendapat, “Semua pemrograman adalah pemrograman pemeliharaan karena Anda jarang menulis kode asli. …. Anda menghabiskan sebagian besar waktu Anda dalam mode pemeliharaan. Jadi sebaiknya Anda gigit saja dan berkata, "Saya mempertahankannya sejak hari pertama." Disiplin yang berlaku untuk pemeliharaan harus berlaku secara global.” Hunt setuju, “Hanya 10 menit pertama kode menjadi asli saat Anda mengetiknya untuk pertama kali. Itu dia."

Atwood pada akhirnya condong ke sudut pandang ini tetapi menggemakan perspektif umum pengembang WordPress yang saya dengar dari Jason Adams dan Timothy Jacobs. Seni khusus pengembangan/pemeliharaan WordPress?

"Ini tindakan penyeimbang."

Plugin Keamanan WordPress Terbaik untuk Mengamankan & Melindungi WordPress kini diskon 35%!

WordPress saat ini menguasai lebih dari 40% dari semua situs web, sehingga telah menjadi sasaran empuk bagi peretas dengan niat jahat. Plugin iThemes Security Pro menghilangkan dugaan keamanan WordPress untuk memudahkan mengamankan & melindungi situs web WordPress Anda. Ini seperti memiliki staf ahli keamanan penuh waktu yang terus-menerus memantau dan melindungi situs WordPress Anda untuk Anda.

Hemat 35% sekarang!