Pluginmu Lulus di Laptop, Tapi Tumbang di PHP 8.4?

Build hijau di laptop sering menipu. Plugin WordPress-mu bisa aman di PHP 8.1, lalu meledak di PHP 8.4 karena satu deprecated dynamic property, signature mismatch, atau perubahan kecil di WordPress core.

Kalau kamu vendor plugin atau penjaga CI, masalahnya bukan “punya test atau belum”. Masalahnya, test-mu jalan di kombinasi yang benar atau cuma di satu dunia nyaman?

Kenapa Test Biasa Nggak Cukup untuk Plugin WordPress

Plugin WordPress hidup di ekosistem yang bergerak dari banyak arah. PHP naik versi, WordPress core berubah, dependency ikut bergeser, sementara hosting user sering telat atau terlalu cepat upgrade.

Akibatnya, satu test suite yang cuma jalan di versi PHP default CI tidak memberi gambaran nyata. Bahkan, test yang lulus 100% bisa tetap gagal saat user pakai kombinasi WordPress lama plus PHP baru.

PHPUnit WP test matrix menyelesaikan celah itu dengan menjalankan test yang sama di beberapa kombinasi:

• PHP 8.1, 8.2, 8.3, 8.4
• WordPress latest stable
• WordPress minimum supported version
• Dependency lowest dan highest jika pluginmu pakai Composer

Matrix yang Kecil Biasanya Lebih Kuat

Banyak tim langsung membuat 20 sampai 40 job CI. Kelihatannya serius, tetapi sering lambat, mahal, dan akhirnya diabaikan saat deadline menekan.

Mulailah dari matrix minimal yang menangkap risiko terbesar. Setelah itu, baru perluas saat ada alasan teknis.

Matrix Awal yang Saya Rekomendasikan

strategy:
  fail-fast: false
  matrix:
    php: ['8.1', '8.2', '8.3', '8.4']
    wordpress: ['latest']
    include:
      - php: '8.1'
        wordpress: '6.3'
      - php: '8.4'
        wordpress: 'latest'

Kenapa begini? Karena kamu ingin dua sinyal utama: batas bawah support dan masa depan. PHP 8.1 menjaga janji kompatibilitas, sedangkan PHP 8.4 menangkap warning lebih awal.

Gunakan PHP 8.4 sebagai Alarm, Bukan Polisi

Ini bagian yang sering salah. Banyak vendor langsung menjadikan PHP 8.4 job sebagai blocker, lalu frustrasi karena ekosistem dependency belum semuanya siap.

Lebih aman, jadikan PHP 8.4 sebagai allowed failure sementara, tetapi tetap tampilkan hasilnya di PR. Dengan begitu, tim melihat kerusakan sejak dini tanpa menghentikan semua rilis penting.

Namun, begitu dependency utama sudah kompatibel, ubah PHP 8.4 menjadi required check. Transisinya bertahap, bukan mendadak.

Contoh GitHub Actions untuk PHPUnit + WordPress

Berikut pola sederhana yang bisa kamu adaptasi. Pastikan versi PHPUnit sesuai constraint WordPress dan pluginmu.

name: PHPUnit WordPress Matrix

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        php: ['8.1', '8.2', '8.3', '8.4']
        wordpress: ['latest']

    steps:
      - uses: actions/checkout@v4

      - uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}
          coverage: none
          tools: composer

      - name: Install dependencies
        run: composer install --prefer-dist --no-progress

      - name: Install WP test suite
        run: bash bin/install-wp-tests.sh wordpress_test root root 127.0.0.1 ${{ matrix.wordpress }}

      - name: Run PHPUnit
        run: vendor/bin/phpunit

Rujukan teknis yang layak kamu bookmark: WordPress PHPUnit handbook, PHP 8.4 release notes, dan GitHub Actions matrix docs.

Bug Kompatibilitas yang Paling Sering Ketangkap

Matrix lintas PHP dan WordPress biasanya cepat membongkar bug kecil yang jarang terlihat di review kode.

• Dynamic properties, terutama di class lama yang belum punya deklarasi properti.
• Return type mismatch, terutama saat extend class bawaan atau interface dependency.
• Deprecated function yang masih jalan di PHP lama, tetapi mulai berisik di PHP baru.
• Test bootstrap rapuh, biasanya karena hardcode path WordPress.
• Perbedaan behavior core antara minimum supported WP dan latest.

Kalau pluginmu juga punya risiko security, sambungkan matrix ini dengan audit pola insecure. Kamu bisa baca pembahasan terkait di pola insecure code yang bikin plugin WordPress dibobol.

Framework 3 Lapis: Smoke, Compatibility, Release Gate

Jangan perlakukan semua test sama beratnya. CI yang baik punya lapisan, sehingga cepat saat PR kecil, tetapi tetap ketat saat rilis.

1. Smoke Test

Jalankan di setiap PR. Fokusnya cepat: lint, install dependency, bootstrap WordPress, test unit penting.

2. Compatibility Matrix

Jalankan di PR utama dan nightly. Di sinilah PHP 8.1 sampai 8.4 serta WordPress minimum sampai latest diuji.

3. Release Gate

Jalankan sebelum tag rilis. Tambahkan coverage dependency lowest, multisite jika relevan, dan test integrasi yang lebih berat.

Dengan pola ini, CI tetap manusiawi. Selain itu, timmu tidak tergoda mematikan test karena terlalu lambat.

Checklist Cepat untuk Vendor Plugin

• Tentukan minimum PHP dan minimum WordPress secara eksplisit.
• Test PHP 8.1 sampai 8.4, minimal terhadap WordPress latest.
• Tambahkan satu job untuk WordPress minimum supported.
• Jangan sembunyikan deprecation warning di log.
• Gunakan nightly schedule agar bug muncul sebelum release window.
• Hubungkan hasil CI dengan aturan merge.

Kalau kamu sedang mengejar kesiapan PHP terbaru, lanjutkan juga ke artikel warning PHP 8.4 yang bisa meledak di pluginmu.

FAQ

Apakah semua plugin wajib test PHP 8.1 sampai 8.4?

Kalau pluginmu dipakai publik, iya, sangat disarankan. Kamu tidak harus menjadikan semua job sebagai blocker sejak hari pertama, tetapi hasilnya perlu terlihat.

WordPress versi mana yang harus masuk matrix?

Pakai WordPress latest dan minimum supported version pluginmu. Jika kamu mendukung banyak versi lama, pilih versi batas bawah yang benar-benar masih kamu janjikan.

Apakah PHPUnit WP test matrix bikin CI lambat?

Bisa, kalau semua job dijalankan setiap waktu. Solusinya, pisahkan smoke test untuk PR cepat, compatibility matrix untuk PR penting atau nightly, lalu release gate sebelum tag rilis.

Penutup: Bug Kompatibilitas Itu Murah Kalau Ketangkap di CI

Bug lintas versi hampir selalu mahal saat sudah sampai user. Namun, bug yang sama jadi murah ketika muncul sebagai satu job merah di CI.

Bangun PHPUnit WP test matrix kecil dulu, lalu perkuat pelan-pelan. Kamu akan rilis lebih percaya diri, menjaga reputasi plugin, dan mengurangi tiket support yang sebenarnya bisa dicegah.

Mau checklist CI WordPress dan Google update yang lebih praktis? Langganan newsletter di bawah ini.