Log error yang penuh warning kecil sering terlihat sepele. Namun, saat PHP 8.2+ mulai menandai dynamic property sebagai deprecated, theme atau plugin legacy kamu bisa bikin admin melambat, file log membengkak, dan proses debugging jadi kabur.
Masalahnya jarang langsung membuat situs mati. Justru karena itu, banyak tim maintenance menundanya sampai hosting menaikkan versi PHP, lalu warning muncul di mana-mana.
Jawaban Singkat / Key Takeaways
Dynamic property cleanup adalah proses mengganti properti PHP yang dibuat mendadak menjadi properti eksplisit, struktur data, atau atribut kompatibilitas. Dengan begitu, theme dan plugin legacy WordPress tetap bersih di PHP 8.2+, log lebih mudah dibaca, dan risiko upgrade PHP turun drastis.

Kenapa PHP 8.2 Membuat Dynamic Property Jadi Masalah?
Sebelum PHP 8.2, kode seperti ini sering lolos tanpa drama:
class Legacy_Widget {}
$widget = new Legacy_Widget();
$widget->title = 'Promo';
Di PHP 8.2, assignment seperti itu memicu deprecation warning karena properti $title belum dideklarasikan. Menurut dokumentasi resmi PHP, dynamic properties sudah deprecated dan akan makin berisiko pada versi PHP berikutnya: PHP 8.2 deprecated features.
Di WordPress, pola ini sering muncul pada:
- class widget lama, shortcode handler, atau page builder addon,
- object hasil parsing API yang diperlakukan seperti DTO bebas,
- plugin settings yang disisipkan langsung ke object,
- theme framework lawas yang memakai magic object.
Dampaknya Bukan Cuma “Warning Doang”
Kalau kamu mengelola banyak situs klien, dynamic property cleanup bukan kosmetik. Ini bagian dari kesiapan upgrade PHP.
Warning yang berulang bisa menyebabkan:
- log membengkak, terutama di traffic tinggi,
- admin terasa berat karena logging aktif,
- error penting tenggelam di antara ribuan notice,
- CI/CD gagal jika deprecation diperlakukan sebagai error,
- biaya maintenance naik karena sumber masalah sulit dipilah.
Selain itu, WordPress sendiri terus mendorong kompatibilitas PHP modern. Kamu bisa cek rekomendasi teknisnya di PHP compatibility and WordPress versions.
Cara Audit Dynamic Property di Theme dan Plugin Legacy
1. Mulai dari Log, Bukan dari Grep Buta
Grep tetap berguna. Namun, log produksi atau staging biasanya memberi prioritas terbaik karena menunjukkan jalur kode yang benar-benar dieksekusi.
Deprecated: Creation of dynamic property My_Plugin::$settings is deprecated
Catat class, property, file, dan action hook yang memicunya. Setelah itu, kelompokkan per modul supaya cleanup nggak melebar tanpa arah.
2. Jalankan Static Analysis Ringan
Untuk proyek kecil, pencarian manual cukup. Namun, untuk agency yang memegang banyak codebase, gunakan PHPStan atau Psalm agar pola berulang cepat muncul.
vendor/bin/phpstan analyse wp-content/plugins/my-plugin --level=5
Kalau plugin belum siap dianalisis penuh, mulai dari level rendah. Kemudian, naikkan level setelah dynamic property paling berisik selesai.
Framework 4D untuk Membersihkan Dynamic Property
Pakai kerangka Detect, Decide, Declare, Defend. Framework ini menjaga cleanup tetap cepat, aman, dan mudah direview.
Detect: Temukan Jalur yang Aktif
Prioritaskan warning yang muncul di admin, checkout, login, cron, atau REST API. Dengan begitu, kamu menyelesaikan area yang paling terasa oleh pengguna dan klien.
Decide: Pilih Bentuk Data yang Benar
Jangan otomatis menambahkan property ke class. Kadang properti itu sebenarnya lebih cocok menjadi array konfigurasi, value object, atau transient.
Inilah bagian yang sering dilewatkan. Cleanup terbaik bukan cuma membungkam warning, tetapi juga memperjelas model data.
Declare: Tambahkan Properti Eksplisit
Jika property memang bagian dari state class, deklarasikan langsung.
class My_Plugin {
public array $settings = [];
public string $version = '1.0.0';
}
Kalau kamu masih mendukung PHP lama, hindari typed property yang belum kompatibel. Sebagai gantinya, gunakan docblock.
class My_Plugin {
/** @var array */
public $settings = [];
}
Defend: Tambahkan Guard agar Warning Tidak Balik
Tambahkan test sederhana, static analysis, atau minimal checklist PR. Dengan demikian, property liar baru nggak masuk lagi saat tim menambah fitur.
Kapan Boleh Pakai #[AllowDynamicProperties]?
Atribut #[AllowDynamicProperties] bisa menahan warning. Namun, anggap ini sebagai penyangga sementara, bukan solusi utama.
Pakai hanya jika:
- class memang berfungsi sebagai container bebas,
- kamu sedang melakukan migrasi bertahap,
- risiko refactor lebih besar daripada warning saat ini,
- kode berasal dari vendor lama yang belum bisa disentuh.
Untuk class bisnis inti, lebih baik deklarasikan property. Kalau semua class diberi atribut ini, kamu cuma memindahkan utang teknis ke masa depan.
Checklist Cleanup untuk Agency Maintenance
- Buat staging dengan PHP 8.2 atau lebih baru.
- Aktifkan logging, tetapi jangan tampilkan error ke publik.
- Reproduksi flow admin, checkout, form, cron, dan REST endpoint.
- Kelompokkan warning berdasarkan plugin, theme, dan class.
- Perbaiki property yang muncul paling sering dulu.
- Deploy kecil, lalu pantau log 24 sampai 72 jam.
- Dokumentasikan class yang sengaja memakai
#[AllowDynamicProperties].
Kalau kamu juga sedang menyiapkan upgrade PHP lebih jauh, baca panduan terkait ini: Warning PHP 8.4 Ini Bisa Meledak di Pluginmu.
Contoh Refactor Nyata di Plugin WordPress
Sebelum cleanup:
class Promo_Box {
public function boot() {
$this->options = get_option('promo_box_options', []);
}
}
Sesudah cleanup:
class Promo_Box {
/** @var array */
public $options = [];
public function boot() {
$this->options = get_option('promo_box_options', []);
}
}
Perubahannya kecil. Namun, hasilnya besar karena log bersih, intent class jelas, dan kompatibilitas PHP naik.
Kesalahan yang Sering Bikin Cleanup Gagal
- Hanya menutup warning tanpa memahami alur data.
- Mengubah visibility sembarangan lalu merusak integrasi lama.
- Memakai typed property padahal minimum PHP plugin masih rendah.
- Lupa test hook WordPress seperti
init,admin_init, danwp_ajax_*. - Membersihkan semua sekaligus sehingga review jadi sulit.
FAQ
Apa itu dynamic property di PHP?
Dynamic property adalah properti object yang dibuat tanpa deklarasi di class. Di PHP 8.2, pola ini memicu deprecation warning kecuali class memakai mekanisme tertentu seperti __get, __set, atau #[AllowDynamicProperties].
Apakah warning dynamic property merusak WordPress?
Biasanya belum langsung merusak situs. Namun, warning bisa memenuhi log, mengganggu admin, dan menjadi risiko besar saat upgrade PHP berikutnya.
Solusi tercepat untuk theme legacy apa?
Solusi tercepat adalah mendeklarasikan property yang memang dipakai sebagai state class. Jika class hanya container sementara, gunakan array atau atribut #[AllowDynamicProperties] sebagai langkah transisi.
Rapikan Sekarang, Upgrade Nanti Jadi Ringan
Dynamic property cleanup terasa kecil, tetapi dampaknya besar untuk theme dev dan agency maintenance. Kamu mendapatkan log yang lebih bersih, debugging yang lebih cepat, dan jalur upgrade PHP yang jauh lebih aman.
Kalau kamu ingin checklist teknis WordPress, PHP, dan security yang praktis, langganan newsletter Google kami lewat blok di bawah ini.



