Warning PHP 8.4 Ini Bisa Meledak di Pluginmu

Plugin WordPress kamu bisa terlihat aman hari ini, lalu mendadak rusak saat hosting pindah ke PHP 9. Penyebabnya sering bukan bug besar, melainkan deprecation warning kecil yang selama ini tertutup log, dimatikan di produksi, atau dianggap “nanti saja”.

Kenapa PHP 8.4 Jadi Alarm Dini untuk Developer WordPress?

PHP 8.4 bukan cuma “versi baru yang perlu dites”. Buat plugin dev, theme dev, dan agency maintainer, versi ini adalah simulasi awal untuk melihat kode mana yang akan patah saat PHP 9 datang.

Masalahnya, WordPress punya ekosistem yang luas. Pluginmu mungkin aman, tetapi dependency Composer, polyfill, snippet lama, atau integrasi hook pihak ketiga bisa memicu warning.

Karena itu, checklist ini fokus pada satu tujuan: temukan warning sebelum warning itu berubah jadi fatal.

Checklist PHP 8.4 Deprecation untuk Plugin WordPress

1. Aktifkan Error Reporting Secara Agresif di Environment Test

Kalau warning nggak kelihatan, timmu akan merasa kode baik-baik saja. Jadi, mulai dari konfigurasi test yang sengaja cerewet.

error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('log_errors', '1');

Di WordPress, aktifkan juga:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Dengan begitu, kamu bisa menangkap noise dari plugin, theme, mu-plugin, dan dependency. Setelah itu, pisahkan warning milikmu dari warning milik pihak ketiga.

2. Cari Dynamic Properties yang Masih Nyelinap

Dynamic properties sudah jadi sumber deprecation sejak PHP 8.2, tetapi masih sering muncul di plugin WordPress lama. Biasanya bentuknya seperti ini:

$this->settings_cache = $data;

Kalau properti itu nggak dideklarasikan di class, kamu punya utang kompatibilitas. Perbaiki dengan deklarasi eksplisit.

class My_Plugin_Service {
    private array $settings_cache = [];
}

Untuk object yang memang perlu fleksibel, pertimbangkan stdClass, array terstruktur, atau DTO kecil. Jangan langsung menempelkan #[AllowDynamicProperties] ke semua class, karena itu cuma menunda masalah.

3. Audit Nullable Parameter Implisit

PHP makin ketat soal tipe. Pola lama seperti ini sering tampak normal, tetapi berisiko:

function sync_user($user_id = null) {}

Kalau kamu memang menerima null, tulis secara eksplisit:

function sync_user(?int $user_id = null): void {}

Ini bukan sekadar kosmetik. Tipe yang jelas membuat static analysis lebih akurat, CI lebih berguna, dan bug integrasi lebih cepat ketahuan.

4. Cocokkan Signature Method dengan Parent, Interface, dan Hook Callback

Banyak plugin WordPress memakai inheritance untuk service, REST controller, custom table, atau gateway pembayaran. Saat signature method melenceng dari parent atau interface, PHP bisa memberi warning lebih keras dari sebelumnya.

Periksa area ini:

• Class yang extend WP_REST_Controller
• Implementasi interface internal plugin
• Adapter payment, shipping, membership, dan CRM
• Callback filter/action yang menerima jumlah argumen berbeda

Selain itu, cek catatan rilis PHP 8.4 dan panduan kompatibilitas PHP WordPress sebagai baseline resmi.

Framework 3 Lapisan: Jangan Cuma “Fix Warning”

Kesalahan umum tim agency adalah memperlakukan deprecation sebagai daftar error yang harus dihapus. Padahal, warning PHP adalah sinyal desain.

Pakai 3 lapisan ini:

• Lapisan runtime: warning muncul saat plugin dipakai user.
• Lapisan kontrak: tipe, signature, return value, dan interface nggak konsisten.
• Lapisan supply chain: dependency lama membawa warning ke kode yang kamu ship.

Dengan pendekatan ini, kamu nggak cuma membersihkan log. Kamu mengurangi risiko rilis, support ticket, dan panic patch saat hosting menaikkan versi PHP.

CI Matrix: Tempat Warning Harus Mati

Local test bagus, tetapi CI matrix jauh lebih jujur. Jalankan test pluginmu minimal di PHP 8.1, 8.2, 8.3, dan 8.4. Kalau target user masih luas, sesuaikan dengan minimum versi yang kamu dukung.

strategy:
  matrix:
    php: ['8.1', '8.2', '8.3', '8.4']

Tambahkan Composer audit, PHPUnit, PHPStan atau Psalm, lalu PHPCompatibility untuk WordPress Coding Standards. Referensi teknisnya bisa kamu cek di PHPCompatibility.

Kalau kamu juga mengelola dependensi plugin, baca juga panduan internal ini: Plugin WordPress Kamu Punya Bom Dependensi Tersembunyi.

Area WordPress yang Paling Sering Memicu Warning

• REST API callback: argumen request nggak ditipekan jelas.
• Shortcode lama: parameter default bercampur string, array, dan null.
• WooCommerce extension: class extend object besar dengan signature berubah.
• Admin screen: dynamic property untuk menyimpan state sementara.
• Cron job: callback menerima data yang formatnya berubah antar versi.
• Vendor lama: library belum siap PHP 8.4.

Selain itu, pastikan dependency install di CI nggak membuka risiko lain. Kamu bisa lanjut membaca Lockfile Kamu Bohong Kalau CI Masih Pakai Install Biasa.

Prioritas Fix yang Paling Masuk Akal

Jangan mulai dari file yang paling mudah. Mulai dari file yang paling sering dieksekusi user.

1. Bootstrap plugin, loader, service container.
2. Public hooks, shortcode, REST route, AJAX handler.
3. Admin flow, settings page, import/export.
4. Integrasi eksternal, API client, webhook, payment.
5. Dependency vendor, terutama yang tidak aktif dirawat.

Urutan ini terasa kurang intuitif, tetapi efektif. Satu warning di bootstrap bisa menyentuh semua user, sementara warning di fitur jarang pakai mungkin bisa masuk sprint berikutnya.

FAQ

Apa itu PHP 8.4 deprecation checklist?

PHP 8.4 deprecation checklist adalah daftar pemeriksaan untuk menemukan pola kode yang masih jalan sekarang, tetapi berpotensi rusak di PHP 9. Untuk WordPress, checklist ini mencakup plugin, theme, hook, dependency, dan test matrix.

Apakah plugin WordPress wajib support PHP 8.4 sekarang?

Belum selalu wajib, tergantung target user. Namun, kamu sebaiknya mulai test sejak sekarang karena hosting biasanya bergerak cepat setelah versi PHP stabil tersedia.

Tool apa yang cocok untuk cek kompatibilitas PHP 8.4?

Gunakan PHPUnit, PHPStan atau Psalm, Composer audit, dan PHPCompatibility. Gabungkan semuanya di CI agar warning tidak hanya ditemukan di laptop developer.

Apakah deprecation warning berbahaya di produksi?

Warning biasanya belum mematikan aplikasi. Namun, kalau dibiarkan, warning yang sama bisa berubah menjadi fatal error di versi PHP berikutnya.

Kesimpulan: Jangan Tunggu PHP 9 Baru Panik

PHP 8.4 deprecation checklist memberi kamu kesempatan untuk memperbaiki plugin sebelum user yang menemukan masalahnya. Mulai dari error reporting, dynamic properties, nullable type, signature method, dependency, lalu kunci semuanya di CI matrix.

Kalau kamu mengelola banyak plugin atau theme klien, jadikan checklist ini bagian dari release gate. Lebih murah memperbaiki warning minggu ini daripada menjawab tiket massal saat hosting menaikkan PHP nanti.