PHP 8.6.0 RC4 Rilis 21 Oktober 2026: 50 Perbaikan Sejak RC3 & Checklist Uji Source Code Sebelum 19 November

PHP 8.6.0 RC4 tersedia untuk pengujian sejak 21 Oktober 2026, membawa sekitar 50 perbaikan sejak RC3 dan menjadi kandidat rilis terakhir sebelum RC5. Bagi pembeli dan penjual source code, ini adalah jendela uji paling realistis sebelum versi final meluncur 19 November 2026 — asalkan pengujian dilakukan di staging, bukan di server produksi.

Apa itu PHP 8.6.0 RC4?

PHP 8.6.0 RC4 adalah release candidate keempat PHP 8.6, diumumkan release manager Matteo Beccati pada 21 Oktober 2026 melalui milis resmi PHP. RC adalah singkatan dari release candidate: build yang sudah mendekati final, tetapi masih berstatus versi uji. Tim PHP secara eksplisit meminta pengembang menguji versi ini dan melaporkan bug yang ditemukan, dan secara eksplisit pula melarang pemakaiannya di produksi.

RC4 penting karena satu alasan sederhana: daftar fiturnya sudah beku sejak hard feature freeze 22 September 2026. Artinya, yang berubah dari RC4 ke versi final nanti hanyalah perbaikan bug, bukan penambahan fitur. Apa yang Anda uji di RC4, kurang-lebih, adalah apa yang akan Anda dapatkan di versi final.

Apa yang baru di PHP 8.6.0 RC4?

RC4 sendiri bukan rilis fitur baru — ia adalah paket perbaikan atas RC3. Namun karena banyak pembaca yang baru mengikuti dari sini, berikut ringkasan fitur PHP 8.6 yang sudah terkunci dan ikut teruji di RC4:

1. Fungsi clamp() baru — membatasi nilai ke rentang tertentu tanpa min(max(...)) bersarang.
2. Partial function application — cara baru membuat fungsi turunan dengan sebagian argumen sudah terisi.
3. Kelas Time\Duration — representasi durasi waktu yang lebih eksplisit dibanding integer detik mentah.
4. Enum SortDirection — arah pengurutan yang type-safe untuk API dan query builder.
5. Pesan error json_decode() yang menunjukkan posisi kesalahan — debugging JSON jauh lebih cepat.
6. Default sesi yang lebih ketat — mode ketat aktif, cookie sesi HttpOnly, dan SameSite default Lax. Ini yang paling berpotensi "merusak" aplikasi lama secara diam-diam, terutama alur login dan callback pembayaran.

Satu catatan penting yang sering disalahpahami: RC4 dirilis di hari yang sama dengan patch keamanan darurat PHP untuk dua celah remote code execution (RCE) yang dijuluki PHP2Shell. Build RC4 memang memuat perbaikan tersebut, tetapi itu bukan alasan memakai RC di produksi. Perbaikan produksi yang benar adalah pindah ke cabang stabil — PHP 8.5.12, 8.4.27, 8.3.36, atau 8.2.35 — seperti yang sudah kami bahas tuntas di artikel PHP2Shell: Celah Keamanan PHP CVSS 9.2. Jangan tertukar: RC4 untuk menguji masa depan, patch stabil untuk mengamankan hari ini.

Mengapa RC4 penting untuk pembeli dan penjual source code?

Kebanyakan liputan RC4 berhenti di daftar fitur. Padahal, bagi ekosistem jual-beli source code, ada tiga hal yang jauh lebih praktis:

1. Source code yang Anda beli hari ini akan hidup di PHP 8.6 besok. Toko online, aplikasi kasir, atau sistem informasi yang dibeli sekarang kemungkinan masih dipakai saat hosting mulai menawarkan PHP 8.6. Mengetahui sejak dini apakah source code itu bermasalah di 8.6 jauh lebih murah daripada mengetahuinya setelah pelanggan komplain.

2. Penjual yang menguji lebih dulu punya keunggulan nyata. Penjual source code yang bisa menulis di deskripsi produknya "sudah diuji pada PHP 8.6 RC4" memberi sinyal kualitas yang tidak dimiliki kompetitor yang hanya mengklaim "support PHP terbaru" tanpa bukti. Lihat panduan kami tentang cara menulis deskripsi produk source code yang menjual — klaim yang bisa diverifikasi selalu mengalahkan klaim kosong.

3. Hosting tidak akan menyediakan PHP 8.6 tepat pada 19 November. Penyedia hosting menambahkan versi PHP baru ke panel mereka sesuai jadwal masing-masing. Pekerjaan kompatibilitas yang Anda lakukan sekarang di staging membuat perpindahan nanti tinggal ganti versi di panel — bukan proyek migrasi dadakan.

Bagaimana cara menguji source code di PHP 8.6.0 RC4?

Ikuti checklist ini secara berurutan. Total waktu untuk satu proyek Laravel atau WordPress umumnya 1–3 jam, jauh lebih singkat daripada memperbaiki produksi yang rusak.

1. Siapkan lingkungan terisolasi

Jangan pernah menguji RC di server yang sama dengan produksi. Pakai Docker atau mesin staging terpisah, dan unduh build RC4 dari halaman pre-release resmi php.net. Verifikasi versi yang benar-benar berjalan, jangan percaya label image begitu saja:

Perintah pertama harus menunjukkan 8.6.0RC4. Perintah kedua memastikan ekstensi yang dibutuhkan aplikasi Anda — seperti intl, gd, zip, atau redis — memang tersedia di build tersebut.

2. Periksa dependensi Composer

Di dalam salinan proyek (bukan repositori utama), jalankan:

check-platform-reqs adalah langkah yang paling sering dilewati, padahal di sinilah konflik versi PHP dan ekstensi biasanya ketahuan duluan. Jika ada paket yang menolak PHP 8.6, catat — itu sinyal untuk menunggu update paket tersebut, bukan memaksa instalasi.

3. Jalankan seluruh test suite

Untuk proyek WordPress atau PHP murni, jalankan PHPUnit atau Pest yang setara. Bandingkan hasilnya dengan baseline di PHP versi produksi Anda saat ini. Satu test yang gagal di RC4 dan lolos di versi stabil adalah laporan bug yang berharga — untuk tim PHP, maupun untuk Anda sendiri.

4. Uji tiga alur yang paling rawan

Default sesi baru PHP 8.6 membuat tiga alur ini wajib diuji manual, bukan hanya lewat test otomatis:

1. Login dan logout — termasuk "ingat saya" dan sesi yang dibuka di dua perangkat.
2. Keranjang dan checkout — terutama callback dari payment gateway yang datang lewat POST lintas situs (di sinilah SameSite=Lax paling terasa).
3. Queue dan cron — job yang berjalan di latar belakang sering memakai handler sesi atau serialisasi yang berbeda dari request web biasa.

5. Uji dengan data yang realistis

Test dengan database kosong memberi rasa aman yang palsu. Salin data staging yang menyerupai produksi — jumlah produk, variasi karakter (termasuk emoji dan karakter khusus), dan riwayat transaksi — lalu ulangi langkah 3 dan 4. Perilaku trim() yang kini juga memangkas form-feed, misalnya, hanya ketahuan kalau data Anda memang mengandung karakter semacam itu.

6. Laporkan temuan, jangan diam

Jika menemukan perilaku yang berubah tanpa penjelasan di dokumen UPGRADING PHP 8.6, laporkan ke GitHub php/php-src. Inilah gunanya masa RC: laporan Anda masih bisa mengubah versi final. Setelah 19 November, yang tersisa hanyalah menunggu patch.

Apa yang belum bisa dijanjikan RC4?

Kejujuran adalah bagian dari standar artikel ini, jadi ini batasannya:

1. RC4 bukan jaminan kompatibilitas. Lolos uji di RC4 tidak berarti aplikasi Anda otomatis lolos di versi final, karena masih ada RC5 dan perbaikan lanjutan.
2. Dukungan framework belum resmi. Sampai 26 Oktober 2026, Laravel belum mengumumkan dukungan resmi PHP 8.6 — Laravel 13 saat ini menargetkan PHP 8.3 sampai 8.5. Framework bisa boot di RC4, tetapi "bisa jalan" dan "didukung resmi" adalah dua hal berbeda.
3. Hosting bersama kemungkinan belum menyediakan RC. Jangan berharap menemukan PHP 8.6 di cPanel shared hosting dalam waktu dekat; pengujian RC praktis hanya bisa dilakukan lewat Docker, VPS, atau mesin lokal.
4. Jangan jadikan RC sebagai alasan menunda patch keamanan. Jika server produksi Anda masih di PHP 8.5.11 ke bawah, urusan mendesak Anda adalah patch stabil 8.5.12 — bukan RC4. Prioritasnya sudah kami urutkan di artikel PHP 8.2 End of Life 31 Desember 2026 dan artikel PHP2Shell di atas.

Kapan harus pindah ke PHP 8.6?

Aturan praktisnya sederhana:

Untuk konteks perjalanan PHP 8.6 dari awal, Anda bisa membaca artikel kami sebelumnya: PHP 8.6.0 RC3 Rilis 8 Oktober 2026 dan PHP 8.6 Rilis 19 November 2026. Dan jika Anda baru membeli source code dan ingin mengamankannya sebelum dipakai, mulai dari 9 Langkah Mengamankan Website Setelah Beli Source Code.

Kesimpulan

PHP 8.6.0 RC4 adalah sinyal "hampir sampai" yang paling konkret sejauh ini: fitur beku, sekitar 50 bug dari RC3 sudah diperbaiki, dan hanya RC5 yang memisahkan kita dari versi final 19 November 2026. Manfaatkan tiga minggu ke depan untuk menguji source code Anda di staging — login, checkout, queue, dan dependensi Composer — dan laporkan apa pun yang janggal. Pekerjaan satu sore di staging hari ini adalah cara termurah untuk memastikan source code Anda tetap laku dan tetap jalan saat PHP 8.6 menjadi standar baru.

FAQ

Apakah PHP 8.6.0 RC4 aman dipakai di website produksi?

Tidak. Tim PHP menyatakan RC adalah versi uji awal dan melarang pemakaian produksi. Untuk produksi, pakai cabang stabil seperti PHP 8.5.12, 8.4.27, 8.3.36, atau 8.2.35.

Kapan PHP 8.6 versi final dirilis?

Menurut jadwal resmi, versi final (GA) direncanakan 19 November 2026, didahului RC5 pada 5 November 2026. Jadwal ini masih bisa berubah.

Apa bedanya RC4 dengan RC3?

RC4 adalah kandidat yang lebih baru dengan sekitar 50 perbaikan bug sejak RC3 dan daftar fitur yang sama (sudah beku sejak 22 September 2026). Jika Anda sudah menguji RC3, ulangi pengujian di RC4 karena perbaikan tersebut bisa mengubah perilaku yang sempat Anda anggap bug.

Apakah Laravel sudah mendukung PHP 8.6?

Belum secara resmi per 26 Oktober 2026. Laravel 13 menargetkan PHP 8.3–8.5. Aplikasi Laravel bisa diuji di RC4, tetapi dukungan resmi diperkirakan menyusul setelah versi final PHP 8.6.

Apakah RC4 memperbaiki celah PHP2Shell?

Build RC4 memuat perbaikan dua celah RCE tersebut, tetapi perbaikan itu bukan alasan memakai RC di produksi. Untuk produksi, update ke rilis stabil yang menambal celah itu (8.5.12, 8.4.27, 8.3.36, atau 8.2.35).

Bagaimana cara menguji RC4 tanpa merusak website yang sedang jalan?

Pakai lingkungan terisolasi: Docker, VPS staging, atau mesin lokal — jangan pernah di server produksi. Verifikasi dengan php -v, lalu jalankan composer check-platform-reqs dan test suite sebelum menguji login, checkout, dan queue secara manual.

Apakah saya harus langsung upgrade ke PHP 8.6 begitu rilis final?

Tidak harus pada hari pertama. Praktik yang aman: tunggu versi final plus patch pertamanya, pastikan framework dan paket Anda menyatakan dukungan resmi, dan lakukan perpindahan setelah test suite hijau di staging.