Satu `= null` Bisa Bikin Plugin PHP-mu Kena Warning

Plugin WordPress kamu bisa jalan mulus hari ini, lalu mulai membanjiri log begitu server naik ke PHP 8.4. Penyebabnya sering terlihat sepele: parameter bertipe class, array, atau interface yang diberi default null, tetapi belum ditulis sebagai nullable type.

Kalau kamu melihat pola Type $x = null, saatnya rapikan menjadi ?Type $x = null. Perbaikan kecil ini bikin kode lebih eksplisit, lebih siap untuk PHP baru, dan lebih aman untuk ekosistem plugin WordPress yang sering hidup bertahun-tahun.

Masalahnya Bukan Null, Masalahnya Kontrak yang Samar

Di PHP lama, kode seperti ini terasa normal:

function register_service(Logger $logger = null) {
    // ...
}

Namun, secara desain, tipe Logger berarti parameter harus berisi objek Logger. Sementara itu, default null diam-diam bilang, “boleh kosong juga.”

PHP modern mendorong kamu menulis niat itu secara jelas:

function register_service(?Logger $logger = null) {
    // ...
}

Hasilnya sederhana: engine, static analyzer, IDE, dan developer lain membaca kontrak yang sama.

Kenapa WordPress Plugin Authors Harus Peduli Sekarang

Plugin WordPress punya tantangan unik. Kode bisa dipasang di ribuan hosting dengan versi PHP berbeda, konfigurasi error reporting berbeda, dan plugin lain yang memanggil hook milikmu dengan cara yang kadang kreatif.

Karena itu, warning kecil bisa berubah jadi masalah operasional:

• Log membengkak, terutama di hosting dengan debug aktif.
• CI gagal, bila deprecation diperlakukan sebagai error.
• Support ticket naik, karena user melihat warning di admin.
• Kompatibilitas PHP 9 makin berisiko kalau warning diabaikan.

Untuk konteks lebih luas, kamu juga bisa baca artikel internal tentang warning PHP 8.4 yang bisa meledak di plugin WordPress. Topiknya nyambung langsung dengan audit ini.

Aturan Cepat: Ubah Saat Null Memang Valid

Jangan asal ganti semua parameter. Pertama, tanya satu hal: apakah null benar-benar nilai yang valid dalam logika fungsi?

Kalau Null Valid, Pakai Nullable Type

// Sebelum
function boot(Container $container = null) {}

// Sesudah
function boot(?Container $container = null) {}

Ini fix utama untuk implicit nullable parameter PHP. Kamu mempertahankan perilaku lama, tetapi kontraknya jadi eksplisit.

Kalau Null Cuma Warisan Lama, Pecah Kontraknya

Kadang null cuma bekas “jalan pintas” dari masa lalu. Dalam kasus itu, nullable type bukan solusi terbaik.

// Kurang tegas
function send(Mailer $mailer = null) {
    $mailer = $mailer ?: new Mailer();
}

// Lebih jelas
function send(Mailer $mailer) {
    // dependency wajib dikirim
}

Namun, hati-hati. Kalau fungsi itu public API, hook callback, atau method yang dipakai plugin lain, perubahan seperti ini bisa breaking change.

Framework Audit 3 Lapisan untuk Plugin WordPress

Perbaikan terbaik bukan sekadar search and replace. Pakai audit 3 lapisan supaya kamu nggak merusak API plugin sendiri.

1. Lapisan Private: Aman untuk Dirapikan Cepat

Mulai dari method private, protected internal, helper function, dan class yang nggak diekspos ke hook publik. Biasanya ini paling aman.

• private function build(Foo $foo = null)
• protected function resolve(Bar $bar = null)
• helper dalam namespace internal

Di sini, ubah ke ?Foo atau refactor null handling sesuai kebutuhan.

2. Lapisan Hook: Jangan Rusak Signature Sembarangan

WordPress sangat bergantung pada hook. Jadi, cek fungsi yang terhubung ke add_action(), add_filter(), shortcode, REST callback, AJAX handler, dan WP-CLI command.

Kalau callback menerima object nullable karena alur WordPress memang bisa mengirim kosong, tulis nullable eksplisit. Selain itu, pastikan jumlah argumen pada add_action() atau add_filter() tetap cocok.

3. Lapisan Public API: Versi Minor, Changelog Jelas

Untuk class yang dipakai developer lain, jangan cuma memperbaiki diam-diam. Catat di changelog, tambah test, lalu rilis sebagai compatibility update.

Kalau kamu mengelola dependency Composer dalam plugin, artikel lockfile integrity npm Composer juga relevan, karena audit runtime sering ketemu bareng audit dependency.

Cara Menemukan Implicit Nullable Parameter PHP

Cara paling cepat adalah grep. Ini cukup untuk scan awal:

grep -RInP 'function\s+\w+\s*\([^)]*\\?[A-Za-z_\\\\][A-Za-z0-9_\\\\]*\s+\$\w+\s*=\s*null' .

Namun, regex bisa meleset. Karena itu, kombinasikan dengan static analysis.

• PHPStan, bagus untuk audit tipe dan kontrak.
• Psalm, kuat untuk library dan API yang kompleks.
• Rector, praktis untuk refactor massal.
• CI matrix, jalankan test di beberapa versi PHP.

Lihat juga dokumentasi resmi PHP type declarations dan catatan PHP 8.4 tentang implicit nullable deprecation untuk detail teknis.

Advanced Tip: Jangan Biarkan `?Type` Menjadi Alibi Desain Buruk

Ini bagian yang sering dilewatkan. Nullable type memang menghapus warning, tetapi bisa menyembunyikan desain dependency yang lemah.

Kalau sebuah service selalu butuh logger, cache, atau container, jangan biasakan ?Logger hanya karena dulu default-nya null. Lebih baik jadikan dependency wajib, lalu buat factory atau bootstrapper yang mengurus fallback.

// Fix kompatibilitas
function import(?LoggerInterface $logger = null) {
    $logger ??= new NullLogger();
}

// Desain lebih bersih untuk kode baru
function import(LoggerInterface $logger) {
    // caller wajib menentukan logger
}

Prinsipnya: nullable untuk nilai opsional, bukan untuk dependency yang malas dipasang.

Checklist Fix Sebelum Rilis Plugin

• Scan semua Type $x = null.
• Pastikan null memang bagian dari kontrak.
• Ubah ke ?Type $x = null bila perilaku lama harus dipertahankan.
• Jangan ubah public API tanpa test kompatibilitas.
• Jalankan unit test di PHP versi minimum plugin dan PHP terbaru.
• Aktifkan deprecation sebagai failure di CI, minimal untuk branch utama.
• Catat perubahan di changelog agar developer lain paham.

Kalau pluginmu juga punya banyak library pihak ketiga, baca artikel internal tentang SBOM WordPress dan bom dependensi tersembunyi. Banyak warning runtime muncul dari vendor code yang jarang disentuh.

FAQ

Apa itu implicit nullable parameter PHP?

Implicit nullable parameter PHP adalah parameter bertipe non-nullable yang diberi default null, misalnya Foo $foo = null. Bentuk modernnya adalah ?Foo $foo = null.

Apakah fix ini breaking change?

Biasanya tidak, kalau kamu hanya mengubah Foo $foo = null menjadi ?Foo $foo = null. Perilaku runtime tetap sama, tetapi kontrak tipenya lebih eksplisit.

Apakah semua parameter default null harus nullable?

Kalau parameter punya type declaration dan default-nya null, ya, sebaiknya nullable ditulis eksplisit. Namun, kalau null sebenarnya tidak valid, pertimbangkan refactor desain.

Apakah plugin WordPress lama wajib diperbaiki?

Sangat disarankan. Fix ini kecil, tetapi membantu mengurangi deprecation warning dan mempersiapkan plugin untuk PHP versi berikutnya.

Rapikan Sekarang, Sebelum Warning Jadi Tiket Support

Implicit nullable parameter PHP terlihat seperti detail sintaks. Namun, untuk plugin WordPress yang dipakai banyak situs, detail kecil ini bisa menentukan apakah upgrade PHP terasa mulus atau penuh warning.

Mulai dari audit private method, lanjut ke hook callback, lalu tutup dengan public API. Dengan begitu, kamu memperbaiki kompatibilitas tanpa mengorbankan stabilitas.