Upgrade WordPress atau PHP sering terasa seperti buka kotak misteri. Situs di staging terlihat aman, lalu satu callback hook meledak, satu nilai null masuk ke fungsi yang salah, dan QA harus mengejar bug yang seharusnya bisa ketahuan sebelum browser dibuka.

Di sinilah PHPStan WordPress dan Psalm masuk. Bukan sebagai pengganti testing manual, tetapi sebagai radar awal untuk type error, nullability, dead code, dan signature hook yang sering lolos saat review kode biasa.

Jawaban Singkat / Key Takeaways

PHPStan WordPress dan Psalm membantu dev plugin, theme, dan QA menemukan bug sebelum upgrade WordPress, PHP, atau WooCommerce. Mulai dari level rendah, pasang stub WordPress, lalu naikkan strictness bertahap agar tim nggak tenggelam dalam ratusan warning.

PHPStan dan Psalm untuk static analysis WordPress plugin dan theme
Static analysis memberi sinyal rusak sebelum upgrade benar-benar menyentuh produksi.

Kenapa Static Analysis Penting untuk WordPress?

WordPress fleksibel, tetapi fleksibilitas itu punya harga. Banyak plugin memakai hook dinamis, array bebas bentuk, global function, magic property, dan callback yang parameternya berubah mengikuti filter.

Akibatnya, bug sering baru muncul saat kombinasi ini terjadi:

  • PHP naik versi, misalnya 8.2, 8.3, atau 8.4.
  • WordPress core mengubah asumsi internal.
  • Plugin pihak ketiga mengirim tipe data berbeda.
  • QA hanya mengetes happy path.
  • Hook callback menerima jumlah argumen yang salah.

Dengan static analysis PHP, kamu bisa mendeteksi pola ini dari kode saja. Jadi, sebelum staging panik, CI sudah memberi tanda merah.

PHPStan vs Psalm, Pilih Mana?

Keduanya bagus. Namun, untuk proyek WordPress, PHPStan biasanya lebih cepat diadopsi karena ekosistem extension dan stub WordPress-nya matang. Sementara itu, Psalm kuat untuk analisis tipe yang detail, terutama bila codebase kamu mulai memakai class, interface, generic annotation, dan service container.

Pilihan praktisnya:

  • Plugin kecil sampai menengah: mulai dari PHPStan.
  • Produk SaaS berbasis WordPress: pakai PHPStan, lalu tambahkan Psalm untuk modul kritikal.
  • Team QA enterprise: jalankan keduanya di CI, tetapi pisahkan report agar triage tetap jelas.

Referensi resmi bisa kamu cek di PHPStan, Psalm, dan WordPress Coding Standards.

Bug yang Bisa Ketahuan Sebelum Upgrade

1. Type mismatch yang baru meledak di PHP baru

Contoh klasik: fungsi mengharapkan int, tetapi hasil dari get_option() bisa berupa false, string, atau array. Kode tetap jalan selama data “kebetulan benar”. Namun, saat konfigurasi berubah, fatal error muncul.

2. Nullability yang selama ini disamarkan

Banyak API WordPress mengembalikan false atau null. Karena itu, analisis tipe memaksa kamu menulis guard yang jelas sebelum memanggil method atau membaca property.

3. Dead code yang bikin refactor menipu

Dead code bukan cuma sampah. Dalam plugin lama, dead code sering menyimpan asumsi bisnis lama, hook usang, atau fallback PHP versi jadul yang sudah nggak relevan.

4. Hook signature yang salah

Ini masalah khas WordPress. Kamu menulis callback untuk add_filter(), tetapi jumlah argumen di parameter keempat salah. Akhirnya callback menerima data kurang, lalu bug baru terlihat di halaman tertentu.

Pipeline CI menjalankan PHPStan dan Psalm untuk plugin WordPress
Jalankan static analysis di CI, bukan hanya di laptop developer.

Framework Praktis: Baseline, Boundary, Budget

Banyak tim gagal memakai PHPStan atau Psalm karena langsung mengejar level tertinggi. Kedengarannya disiplin, tetapi hasilnya malah ratusan error, lalu tool dimatikan.

Pakai pendekatan Baseline, Boundary, Budget.

  • Baseline: rekam error lama sebagai utang teknis, jangan blokir semua sekaligus.
  • Boundary: wajibkan kode baru bebas error, terutama folder src/, endpoint AJAX, REST route, dan integrasi payment.
  • Budget: kurangi baseline tiap sprint, misalnya 20 error per minggu.

Ini lebih realistis. Selain itu, strategi ini membuat static analysis terasa seperti sistem peningkatan kualitas, bukan polisi yang menghukum tim.

Setup Minimal PHPStan untuk Plugin WordPress

Mulai dari Composer. Setelah itu, tambahkan extension WordPress agar fungsi core dikenali.

composer require --dev phpstan/phpstan szepeviktor/phpstan-wordpress
vendor/bin/phpstan analyse

Contoh phpstan.neon sederhana:

includes:
  - vendor/szepeviktor/phpstan-wordpress/extension.neon

parameters:
  level: 5
  paths:
    - src
    - includes
  bootstrapFiles:
    - vendor/szepeviktor/phpstan-wordpress/bootstrap.php

Naikkan level setelah error penting stabil. Jangan buru-buru level maksimal kalau team masih punya banyak legacy hook.

Setup Minimal Psalm untuk WordPress

composer require --dev vimeo/psalm
vendor/bin/psalm --init
vendor/bin/psalm

Psalm sangat berguna saat kamu mulai menulis annotation seperti:

/**
 * @return array{enabled: bool, limit: int}
 */
function my_plugin_get_settings(): array {
    return [
        'enabled' => (bool) get_option('my_enabled', false),
        'limit' => (int) get_option('my_limit', 10),
    ];
}

Dengan bentuk array yang eksplisit, QA dan dev sama-sama tahu kontrak data. Kemudian, bug akibat key hilang atau tipe berubah lebih cepat terlihat.

Dashboard laporan error PHPStan Psalm untuk QA WordPress
Report yang bersih membantu QA fokus pada risiko upgrade paling nyata.

Tips CI agar Nggak Mengganggu Rilis

  • Jalankan static analysis di pull request, bukan setelah merge.
  • Pisahkan job PHPStan, Psalm, PHPUnit, dan PHPCS agar error mudah dibaca.
  • Gunakan baseline untuk legacy code.
  • Blokir hanya error baru di area kritikal.
  • Simpan report sebagai artifact CI untuk audit QA.

Kalau kamu sedang menyiapkan upgrade PHP, baca juga panduan terkait di Warning PHP 8.4 Ini Bisa Meledak di Pluginmu dan Satu = null Bisa Bikin Plugin PHP-mu Kena Warning.

Checklist Cepat untuk Tim Plugin, Theme, dan QA

  • Pasang PHPStan WordPress di Composer.
  • Buat baseline untuk error lama.
  • Tambahkan Psalm untuk modul domain penting.
  • Audit semua callback add_action() dan add_filter().
  • Tambahkan tipe return pada fungsi internal.
  • Validasi hasil get_option(), get_post_meta(), dan REST input.
  • Jalankan di CI untuk setiap pull request.

FAQ

Apakah PHPStan WordPress bisa menggantikan PHPUnit?

Belum. PHPStan menemukan bug dari struktur kode, sedangkan PHPUnit membuktikan perilaku runtime. Gabungkan keduanya untuk hasil terbaik.

Level PHPStan berapa yang ideal untuk plugin lama?

Mulai dari level 3 sampai 5. Setelah baseline mengecil, naikkan level bertahap agar tim tetap produktif.

Apakah Psalm perlu kalau sudah pakai PHPStan?

Perlu bila codebase kamu kompleks, banyak array shape, DTO, service class, atau modul pembayaran. Untuk plugin sederhana, PHPStan saja biasanya cukup.

Penutup: Jadikan Upgrade Lebih Membosankan

Upgrade yang bagus seharusnya membosankan. Kalau setiap rilis terasa seperti investigasi kebakaran, kamu butuh sinyal lebih awal dari static analysis.

Mulai dari PHPStan WordPress, tambah Psalm saat perlu, lalu paksa kode baru melewati gerbang CI. Kalau kamu ingin update teknis WordPress, PHP, dan security yang langsung bisa dipakai tim dev, daftar newsletter Google kami di bawah.

PHP, Web Development, WordPress

Tagged in:

, , ,

About the Author

Dzul Qurnain

Suka nonton Anime, ngoding dan bagi-bagi tips kalau tahu.. Oh iya, suka baca ( tapi yang menarik menurutku aja)... Praktisi WordPress, web development, SEO, dan server administration yang membagikan tutorial teknis dan catatan implementasi nyata.

View All Articles