Beralih ke PHP 8.x dalam Empat Langkah – Wawancara dengan Juliette Reinders Folmer

Memutakhirkan situs, plugin, atau tema WordPress ke versi baru PHP adalah tugas yang berulang secara berkala. Tetapi bagaimana Anda melakukan ini seefisien mungkin? Bagaimana Anda tahu Anda tidak akan mengabaikan apa pun? Apakah ada peta jalan untuk itu?

Pada artikel ini, kami akan menjawab pertanyaan-pertanyaan ini (dan lebih banyak lagi) dan melihat apa yang terlibat dalam kelancaran transisi ke PHP 8.x untuk situs, plugin, atau tema WordPress Anda, termasuk roadmap.

Kami akan melakukan ini berdasarkan wawancara yang kami lakukan dengan pakar PHP Juliette Reinders Folmer. Dia mengabdikan sebagian besar kehidupan sehari-harinya untuk pemrograman dan segala sesuatu di sekitarnya, terutama berfokus pada proyek sumber terbuka, termasuk WordPress.

Apakah Anda siap untuk beralih dengan lancar juga? Ingin tahu tentang rencana langkah demi langkah kami? Lalu mari selami!

PHP 8.x — Apa yang Berubah

Untuk ikhtisar perubahan, kami merekomendasikan artikel di bawah ini:

• Catatan rilis untuk PHP 8.0 dan PHP 8.1
• Panduan migrasi untuk PHP 8.0 dan PHP 8.1
• WordPress dan PHP 8.0 dan status saat ini
• Apa yang Baru di PHP 8.0 dan PHP 8.1

Setelah membaca artikel ini, Anda akan benar-benar diperbarui tentang apa yang telah berubah di PHP 8.x dan apa yang perlu Anda lakukan agar proyek PHP Anda berjalan tanpa masalah.

Jika Anda tidak yakin apa cara terbaik untuk memulai, tidak masalah. Dalam percakapan dengan Juliette, kami membahas ini secara mendetail, dan kami akan menjelaskan kepada Anda di artikel ini semaksimal mungkin bagaimana Anda dapat beralih ke PHP 8.x.

Kami juga akan menjelaskan dalam kotak informatif bagaimana melakukan berbagai operasi di MyKinsta, panel kontrol eksklusif kami untuk semua situs, aplikasi, dan database WordPress Anda.

Beralih ke PHP 8.x: Cara Memulai

Beralih ke PHP 8.x terdengar sederhana, dan secara teknis memang demikian. Banyak host memungkinkan Anda menentukan versi PHP mana yang ingin Anda gunakan untuk situs web Anda di panel admin. Di Kinsta, beralih versi PHP dapat dilakukan dengan satu klik di dasbor MyKinsta.

Tetapi sebelum Anda melakukannya, ada beberapa hal yang perlu Anda pastikan. Bergantung pada tingkat pengetahuan dan pengalaman Anda, kami merekomendasikan hal berikut:

• Jika Anda telah membangun situs WordPress Anda sendiri dengan tema dan plugin standar, tanpa memiliki banyak pengetahuan tentang PHP, pekerjakan pengembang atau agensi untuk menyelidiki apakah situs Anda cocok untuk dijalankan di PHP 8.x. Apakah Anda mencari pihak ketiga yang dapat membantu Anda dalam hal ini? Kemudian lihat halaman Mitra kami yang mencantumkan beberapa perusahaan tepercaya yang dapat membantu Anda.
• Jika situs WordPress Anda dibuat oleh pihak eksternal, pengembang, atau agensi, hubungi mereka untuk menanyakan apakah situs Anda dapat berjalan di PHP 8.x.
• Jika Anda telah membangun situs WordPress Anda — dengan tema khusus Anda sendiri, misalnya, atau plugin yang dikembangkan sendiri — kami memiliki peta jalan untuk Anda di bawah ini.

Jika situs Anda termasuk dalam salah satu dari dua kategori pertama, kami tentu saja mengundang Anda untuk membaca artikel selanjutnya, tetapi kami tidak menyarankan Anda mulai menguji situs Anda untuk kompatibilitas PHP 8 sendiri. Serahkan pada para profesional.

Apa pun yang Anda pilih, kami menyarankan Anda untuk tidak hanya mengalihkan situs langsung Anda ke PHP 8 dan "melihat apakah berhasil". Apakah Anda ingin tahu seperti apa tampilan situs Anda, dan Anda tidak sabar untuk melihatnya berjalan di PHP 8? Kemudian mulailah menguji dalam lingkungan pementasan. Tuan rumah yang baik akan memungkinkan Anda mengatur lingkungan pementasan dengan mudah.

Di lingkungan pementasan, Anda dapat mengaktifkan PHP 8.x dan melihat apakah pembaruan ini berfungsi baik dengan situs Anda. Dimungkinkan juga untuk bekerja dengan salinan lokal situs Anda. Dengan alat pengembangan DevKinsta gratis kami, Anda dapat dengan mudah mengimpor situs Anda dari dasbor MyKinsta, setelah itu Anda dapat mengubah versi PHP menjadi 8.0 atau 8.1.

Jika Anda tidak melihat masalah apa pun di lingkungan pementasan, bukan berarti sebenarnya tidak ada masalah. Peta jalan di bawah ini akan memberi tahu Anda alasannya.

Pengujian Kompatibilitas PHP 8.x: Peta Jalan

Pengujian: kata kunci untuk perangkat lunak yang baik. Bahkan untuk situs web WordPress dan komponennya, seperti tema, plugin, dan inti WordPress, pengujian adalah cara untuk memastikan bahwa hal-hal yang tidak Anda inginkan tidak terjadi.

Proyek pengembangan perangkat lunak sebagian besar terdiri dari pengujian. Pada artikel ini, kami melihat secara khusus pengujian yang dapat membantu Anda melakukan transisi ke PHP 8.x dengan lancar. Dalam artikel kami tentang Alat DevOps, Anda akan menemukan bagian dengan kumpulan alat yang dapat Anda gunakan.

Jenis tes berikut dibahas dalam posting blog ini:

Mari kita lihat lebih dekat berbagai jenis pengujian yang dapat kita lakukan.

Analisis Statis (atau Pengujian Statis)

Langkah pertama yang dapat Anda ambil sebagai pengembang PHP adalah melakukan analisis statis terhadap kode Anda dengan berbagai alat. Analisis statis adalah proses menganalisis perangkat lunak tanpa mengeksekusi kode. Dengan analisis statis, dimungkinkan untuk mendeteksi kesalahan, mendeteksi masalah dengan kompatibilitas PHP 8.x, menegakkan standar pengkodean (misalnya, Standar Pengkodean WordPress), dan bahkan memodifikasi dan membersihkan kode dimungkinkan.

Alat untuk Analisis Statis

Anda dapat melakukan analisis statis dengan berbagai alat, seperti:

• Kompatibilitas PHP
• Mazmur
• PHPStan

Pada saat penulisan, tidak semua pemeriksaan PHP 8.1 didukung dalam rilis terbaru PHPCompatibility. Pemeriksaan PHP 8.1 bisa dalam rilis pengembangan, jadi pastikan Anda menggunakannya (untuk saat ini) saat menggunakan PHPCompatibility untuk menganalisis proyek Anda dan melihat kesalahan/rekomendasi apa yang ada.

Pemeriksaan PHP 8.1 akan segera dirilis dalam versi utama baru. Jika Anda ingin selalu mengetahui hal ini, dan Anda memiliki akun GitHub, buka repositori GitHub dari Kompatibilitas PHP dan arahkan ke Watch -> Custom -> Releases , tempat Anda dapat memilih untuk diberi tahu saat versi baru dirilis.

PHPCompatibility, yang hanya menguji kompatibilitas untuk versi tertentu (atau rentang versi) PHP, mudah diatur. Anda mendapatkan hasil terbaik jika menjalankan testVersion — misalnya, 8.0+ (8.0 dan lebih tinggi) — dalam PHPCompatibility.

Anda harus mencari fungsi yang tidak digunakan lagi atau dihapus, mengubah nilai default parameter fungsi, apakah akan menggunakan concat tanpa tanda kurung, apakah akan menggunakan match sebagai nama fungsi (karena telah dicadangkan sejak PHP 8.0), dll.

Psalm dan PHPStan adalah tambahan yang bagus dan dapat membantu Anda dengan melakukan pemeriksaan tambahan terkait dengan tipe variabel. Kelemahan dari alat ini adalah dibutuhkan banyak konfigurasi untuk mendapatkan laporan tentang PHP 8.0 dan 8.1. Bahkan jika berhasil, Anda dapat mengharapkan banyak kesalahan positif. Positif palsu adalah pemberitahuan yang diberikan secara salah, yang disebabkan oleh keterbatasan analisis statis.

Pengetahuan yang baik diperlukan untuk menginterpretasikan hasil dari kedua alat ini dengan benar, tetapi pengetahuan tersebut dapat membantu Anda mengidentifikasi inkompatibilitas tambahan yang tidak dapat ditemukan oleh Kompatibilitas PHP. Lihatlah dokumentasi untuk Psalm dan PHPStan jika Anda ingin mempelajarinya lebih lanjut.

Ringkasan:

• Lakukan analisis statis dengan PHPCompatibility, Psalm, PHPStan
• Selesaikan semua masalah yang sah

Pengujian Unit

Langkah selanjutnya dalam proses ini adalah pengujian unit. Pengujian unit adalah metode pengujian potongan kode secara individual. Dalam pengujian unit, pengujian khusus yang ditargetkan akan dikembangkan untuk setiap unit. Ini akan melibatkan menjalankan melalui skenario yang berbeda. Sebaiknya, setiap skenario diuji secara terpisah dari yang lain sehingga pengujian tersebut independen satu sama lain.

Memiliki tes unit saja, tentu saja, tidak cukup. Mereka juga perlu dijalankan. Tes unit paling baik diotomatisasi menggunakan alat CI (integrasi berkelanjutan) seperti Jenkins, GitHub Actions, atau Travis.

Mendukung Banyak Versi PHP

Sebagai pembuat plugin, jika Anda ingin mendukung beberapa versi PHP, pastikan pengujian dalam CI dijalankan terhadap semua versi PHP yang Anda dukung.

Tentu saja, Anda juga hanya dapat mendukung versi yang lebih baru, pilihan sepenuhnya ada di tangan Anda.

Pengujian dengan beberapa versi PHP mengharuskan Anda menggunakan beberapa versi PHPUnit, bergantung pada versi PHP. Karena PHPUnit telah memperkenalkan beberapa perubahan selama bertahun-tahun yang memengaruhi cara pengujian ditulis, bagian ini bisa jadi rumit.

Untuk mengatasinya, Anda dapat menggunakan PHPUnit Polyfills (ditulis oleh Juliette dan disponsori oleh Yoast). Ini memungkinkan Anda menulis tes yang secara resmi tidak didukung untuk PHPUnit 9 (dan dengan demikian dapat berjalan di PHP 8.x). Polyfill kemudian membuat pengujian Anda berfungsi di PHPUnit 4.x hingga 9.x dan dengan PHP 5.4 hingga PHP 8.1 (seperti sekarang).[/notice]

Sekarang setelah Anda menjalankan pengujian, langkah selanjutnya adalah memastikan masalah yang ditemukan dalam pengujian telah diperbaiki.

Cakupan Kode

Menjalankan tes ini adalah cara paling andal untuk menemukan ketidakcocokan lintas versi.

Saat melakukannya, perhatikan cakupan kode pengujian Anda:

• Misalkan Anda memiliki fungsi A dan telah menulis tes untuknya, dan fungsi A memanggil fungsi B, C, dan D sebagai bagian dari logika dalam fungsi tersebut.
• Tes untuk fungsi A ditulis untuk menguji logika fungsi A, tetapi juga akan memanggil fungsi B, C, dan D selama pengujian. Untuk fungsi B, C, dan D, Anda biasanya hanya menguji "jalur bahagia" — situasi di mana semuanya berjalan dengan baik — dan dengan demikian, fungsi tersebut juga belum sepenuhnya diuji, meskipun (bagian dari) kode dalam fungsi tersebut adalah dieksekusi selama pengujian fungsi A.
• Untuk setiap pengujian Anda, tunjukkan kode mana yang sedang diuji secara khusus. Anda melakukan ini dengan memberikan setiap pengujian a @covers Dengan cara ini, B, C, dan D tidak "dihitung" dalam perhitungan cakupan kode, yang memungkinkan Anda melihat bagian mana dari kode Anda yang dicakup oleh pengujian.

Seringkali pengembang menulis dan menguji — terkadang bahkan tanpa disadari — untuk “jalan bahagia”. Dalam kasus ini, pengujian apa yang terjadi saat data tak terduga diteruskan ke suatu fungsi juga diperlukan. Menguji hanya dengan nilai/tipe yang diharapkan tidaklah cukup .

''Dalam pengujian Anda perlu memastikan bahwa suatu fungsi melakukan apa yang seharusnya dilakukan, tetapi juga bahwa suatu fungsi tidak melakukan apa yang tidak seharusnya.'' - Juliette Reinders Folmer Klik untuk Tweet

Bagian kedua dari kutipan di atas sering dilupakan, bahkan mungkin lebih penting daripada bagian pertama. Apa yang terjadi jika Anda melewatkan jenis yang salah? Apakah Anda mendapatkan pesan kesalahan? Atau apakah variabel dilemparkan dengan fungsi berlanjut seperti biasa? Bagaimana jika nilai tak terduga diteruskan ke fungsi?

Pastikan untuk menguji fungsi Anda dengan variabel, tipe, dan nilai yang tidak diharapkan. Hanya dengan begitu Anda dapat mengandalkan pengujian Anda untuk menemukan masalah yang mungkin disebabkan oleh versi PHP baru.

PHP Semakin Ketat

PHP menjadi lebih tepat (ketat) dalam cara menangani "tipe" untuk fungsi PHP sendiri, serta hal-hal seperti properti dinamis. Perubahan ini umumnya dimaksudkan untuk membantu pengembang memberikan kode bebas kesalahan (yah, kode dengan lebih sedikit kesalahan). Tapi ini bisa menghadirkan rintangan pemutakhiran yang cukup untuk kode yang sudah ada sebelumnya yang ditulis berdasarkan prinsip "lama" PHP.

Karena drive ini untuk pesan kesalahan yang lebih bermanfaat di PHP, Anda dapat melihat bahwa membuat kode yang ada sesuai dengan versi PHP yang baru membutuhkan lebih banyak waktu. Membuat kode yang berfungsi pada PHP 5.6 cocok untuk PHP 7.0 hanya membutuhkan waktu yang sangat singkat dalam banyak kasus dibandingkan dengan memutakhirkan kode agar sesuai untuk PHP 8.1. Dan terlepas dari kenyataan bahwa PHP 7.0 adalah rilis "utama", sedangkan PHP 8.1 adalah "minor".

Dalam banyak kasus, pengujian masih merupakan satu-satunya cara yang dapat diandalkan untuk menentukan apa yang perlu dimodifikasi untuk mendukung versi baru.

Pengujian unit dimungkinkan dengan berbagai alat, termasuk:

• PHPUnit
• Ejekan
• Perilaku,
• Pemain cerita

Banyak dari alat ini dibuat berdasarkan, atau bersamaan dengan, PHPUnit.

Pada akhirnya, tidak masalah alat apa yang Anda gunakan. Yang paling penting adalah Anda menguji, dan menjalankan pengujian pada versi PHP baru. Langkah ini terkadang sangat rumit, tetapi untungnya, seperti yang disebutkan sebelumnya, ada alat untuk ini, seperti PHPUnit Polyfills.

Tes integrasi

Pengujian integrasi adalah langkah selanjutnya yang akan kami lakukan, setelah analisis statis dan pengujian unit. Tes integrasi adalah saat situasi kehidupan nyata diuji dalam konteks yang lebih besar dari sekadar "unit kode". Ini termasuk pengujian dengan database (pengujian) aktif atau pengujian dengan API eksternal, untuk memberikan dua contoh saja.

Jadi, saat Anda menguji kode plugin atau tema dalam konteks WordPress dan menggunakan versi sebenarnya, ini adalah, menurut definisi, tes integrasi.

WP Test Utils (sekali lagi ditulis oleh Juliette dan disponsori oleh Yoast) adalah alat yang sangat baik untuk pengujian integrasi. WP Test Utils menyediakan alat untuk menulis tes integrasi dan unit, di mana WordPress “dipermainkan” menggunakan Brainmonkey dan Mockery, di mana fungsi WordPress yang umum digunakan “dipalsukan” sehingga Anda menguji kode Anda sendiri dan bukan kode WordPress.

Pengujian integrasi dengan WordPress adalah cerita yang lebih rumit karena melibatkan integrasi dengan WordPress dan rangkaian pengujian WordPress. Bergantung pada versi WordPress mana yang didukung plugin atau tema, Anda harus mempertimbangkan versi PHPUnit mana yang didukung oleh WordPress itu sendiri untuk menjalankan tes pada versi PHP yang berbeda.

Misalnya, WordPress 5.6 hingga 5.8 menggunakan PHPUnit 5 hingga 7 untuk menguji PHP 5.6 hingga PHP 8.0, tetapi pada WordPress 5.9, WordPress sendiri juga menggunakan PHPUnit Polyfills untuk dukungan yang lebih luas. WP Test Utils bertindak sebagai jembatan untuk mengatasi semua perbedaan tersebut.

Ingin mempelajari lebih lanjut tentang cara menjalankan tes integrasi terhadap beberapa versi WordPress yang berbeda, termasuk WordPress 5.9 dan yang lebih baru? Kemudian baca tentang itu di situs web WordPress.

Pengujian Manual

Sekarang setelah Anda melalui pengujian unit dan pengujian integrasi dan telah memperbaiki semua masalah yang Anda temukan, saatnya melakukan pengujian manual. Situs Anda berjalan, dan kode Anda berfungsi, tetapi Anda juga menggunakan plugin A, B, dan C. Tahukah Anda jika plugin tersebut kompatibel?

Misalnya, periksa ini dengan pembuat plugin dan lihat apakah mereka menunjukkan bahwa itu kompatibel dengan PHP 8.x. Pertanyaannya, tentu saja, adalah bagaimana plugin itu diuji. Seringkali jawabannya di sini adalah: dalam isolasi. Fungsi plugin biasanya telah diuji bersama dengan WordPress saja, tanpa plugin aktif lainnya. Dan bahkan jika plugin lain digunakan dalam pengujian ini, kemungkinan besar tidak semua plugin yang Anda gunakan adalah bagian dari pengujian, jadi ambil pernyataan kompatibilitas seperti itu dengan sebutir garam.

Misalnya, situs WordPress dengan 3 plugin (A, B, dan C). Ada kemungkinan bahwa plugin B, misalnya, mengembalikan jenis variabel yang salah melalui filter, yang ingin digunakan oleh plugin C, menggunakan filter yang sama. Ini kemudian dapat menyebabkan kesalahan fatal karena jenisnya tidak lagi seperti yang diharapkan. Plugin C kemudian dilihat sebagai pelaku pesan kesalahan, meskipun plugin B adalah pelaku sebenarnya.

Interoperabilitas-inkompatibilitas plugin tidak mungkin ditemukan saat menguji secara terpisah. Semakin banyak plugin yang aktif, semakin besar kemungkinan terjadi kesalahan. Misalnya, akan sangat bermanfaat untuk meneruskan permintaan halaman dari situs web langsung ke lingkungan pementasan (dengan log kesalahan diaktifkan) untuk menemukan apa yang sebenarnya salah.

Dengan jenis masalah ini, pemilik situs biasanya hanya akan melihat pesan bahwa ada kesalahan dengan kode yang terakhir dieksekusi (dalam hal ini dari plugin C), padahal plugin C belum tentu menjadi penyebab masalah.

Dalam kebanyakan kasus, banyak manual, pekerjaan manusia yang terlibat, dan minyak siku dalam jumlah yang sehat diperlukan untuk mendeteksi dan memperbaiki masalah ini. Ini bisa diotomatisasi menggunakan pengujian end-to-end, tetapi kami tidak melihat ini banyak terjadi di WordPress.

Uji Ketersediaan untuk Plugin yang Dimanfaatkan

Untuk pengembang dan tim pengembangan: Terima kode hanya jika tes tersedia. Dengan cara ini, Anda memastikan bahwa pengujian manual lebih sedikit diperlukan, yang menghemat banyak waktu.

Pertanyakan strategi pengujiannya jika Anda ingin membeli plugin atau tema komersial. Dengan begitu, kami secara kolektif menciptakan kesadaran di antara pengembang/tim pengembangan di komunitas WordPress untuk mendapatkan pengujian yang lebih tinggi dalam agenda, dan kami semua mendapat manfaat.

Pengujian sering dipandang — secara tidak adil — sebagai biaya padahal, pada kenyataannya, menghemat uang. Investasi ekstra yang diperlukan untuk menulis tes terbayar dalam bentuk laporan bug yang jauh lebih sedikit dan lebih sedikit waktu yang dihabiskan untuk memperbaiki bug. Selain itu, dengan pengujian perangkat lunak otomatis, ekstensi dan modifikasi dapat dilakukan lebih cepat karena pengujian dapat dengan cepat mengonfirmasi bahwa fungsionalitas yang ada terus berfungsi.

''Berbaik hatilah pada diri Anda di masa depan, tolong ;-)'' - Juliette Reinders Folmer Klik untuk Tweet

Peran Host WordPress dan PHP 8.x

Untuk rata-rata pemilik situs, panduan dari host Anda sangat diinginkan. Pertimbangkan hal berikut:

• Dokumentasi dan pembaruan untuk pelanggan bahwa WordPress Core, plugin, dan/atau tema (dalam beberapa kasus) tidak kompatibel lintas versi PHP
• Opsi untuk pengujian (seperti bekerja dengan lingkungan pementasan)
• Metode untuk pelaporan kesalahan dan menghubungi dukungan

Ini juga menguntungkan host web, karena pemilik situs sering menghubungi host untuk meminta bantuan saat muncul masalah. Dalam kasus peralihan ke PHP 8.0 atau 8.1, pemilik situs bertanggung jawab atas potensi masalah, dan semakin banyak informasi yang harus disiapkan pemilik untuk peralihan tersebut, semakin baik.

Membuat PHP 8.0 atau 8.1 tersedia untuk pelanggan sebagai host web adalah satu hal, tetapi dalam melakukannya, mereka harus memastikan untuk menciptakan kesadaran di antara pelanggan sehingga mereka menyadari bahwa masalah mungkin muncul. Disarankan untuk menguji situs Anda dalam lingkungan pementasan dengan versi yang berbeda dari yang aktif. (Memilih versi PHP tersedia secara default di Kinsta.)

Versi PHP minimum untuk WordPress

Lebih dari 15% dari semua situs web saat ini menggunakan PHP versi 7.0 atau lebih rendah. Ini bisa dilihat di statistik WordPress resmi. Sekitar 83% dari semua situs WordPress saat ini menggunakan PHP versi 7.4 atau lebih rendah. Harap perhatikan bahwa versi yang lebih rendah atau sama dengan versi 7.4 saat ini tidak lagi didukung oleh PHP. Menggunakan versi PHP yang sudah habis masa pakainya dapat menimbulkan masalah karena pembaruan keamanan tidak lagi dirilis.

Untuk menghindari masalah, penting bagi pemilik situs WordPress untuk mengetahui dan mengetahui versi minimum PHP yang memungkinkan situs mereka berjalan dengan aman. Untuk bagian mereka, pemilik situs dapat memodifikasi sendiri versi PHP (mungkin di Kinsta untuk semua paket) atau meminta host mereka untuk memperbarui situs ke versi PHP yang lebih baru. Dalam kasus ekstrim, Anda dapat beralih ke host yang mendukung versi yang lebih baru ini.

Karena WordPress hanya membutuhkan versi minimal 7.4, tidak cukup motivasi bagi banyak host dan pemilik situs web untuk memperbarui situs mereka. Dan ini terlepas dari fakta bahwa PHP 7.4 mencapai akhir masa pakainya pada November 2022.

Jika WordPress pernah meningkatkan versi PHP minimum, ini mungkin berarti banyak situs tidak lagi kompatibel dengan pembaruan ke versi WordPress terbaru. Namun, pembaruan keamanan akan terus dirilis untuk versi lama tersebut selama beberapa waktu.

Ringkasan

Untuk beralih ke PHP 8.0 atau lebih tinggi untuk situs web Anda, ada beberapa langkah yang harus dilakukan oleh Anda atau pengembang Anda. Langkah-langkah penting meliputi:

• Analisis statis
• Pengujian unit
• Tes integrasi
• Pengujian manual

Saat beralih ke PHP 8.x, pastikan semuanya telah diuji dengan benar. Ini adalah satu-satunya cara untuk menjamin bahwa situs Anda akan berjalan dengan baik, cepat, dan aman pada versi PHP yang lebih baru.

Kami sangat berterima kasih kepada Juliette karena telah berpartisipasi dalam artikel ini dan untuk semua pekerjaannya pada alat yang disebutkan!

Foto Juliette, diambil oleh Jip Moors dan digunakan dengan izin.