Cara Memperbaiki Website Error Setelah Update PHP: Penyebab dan Solusinya

Website error setelah update PHP sering muncul sebagai HTTP 500, halaman putih, pesan There has been a critical error on this website, atau gagal deploy lewat Composer. Versi PHP yang lebih baru belum tentu rusak: lebih sering kode lama, plugin, dependency, ekstensi yang hilang, atau pemetaan PHP-FPM di server yang tidak selaras dengan perubahan tadi. Langkah pertama yang paling aman adalah membaca log, memastikan runtime web dan CLI benar-benar memakai versi yang Anda kira, lalu memperbaiki satu penyebab per iterasi di staging bila memungkinkan.

Untuk memperbaiki website yang error setelah update PHP, cek log terlebih dahulu, pastikan PHP yang berjalan di web dan CLI sesuai, identifikasi sumber error (kode lama, dependency, ekstensi, atau konfigurasi PHP-FPM), perbaiki penyebabnya di staging, lalu uji ulang sebelum perubahan produksi. Jangan menjadikan downgrade ke PHP EOL sebagai solusi permanen.

Mengapa Website Bisa Error Setelah Update Versi PHP?

Upgrade PHP mengubah aturan bahasa: fungsi dihapus, tipe data lebih ketat, dan deprecation baru bisa memicu exception di framework yang menganggap warning sebagai fatal. Patch di cabang yang sama (8.3.35 ke 8.3.36) jarang merusak aplikasi sehat, tetapi upgrade antar cabang (7.4 ke 8.2, 8.2 ke 8.4) kerap mengekspos kode yang selama ini toleran di versi lama.

Perubahan juga datang dari luar kode: hosting mengganti handler default, migrasi server memindahkan php.ini, volume Docker menimpa folder ekstensi, atau domain masih mengarah ke pool PHP-FPM versi lama. Bedakan keempat skenario itu sebelum menyalahkan rilis PHP terbaru.

Pemeliharaan versi tetap penting untuk keamanan. Menurut jadwal dukungan resmi PHP, cabang 8.2 masih menerima perbaikan keamanan hingga 31 Desember 2026, sementara 8.1 sudah melewati akhir dukungan keamanan. End of life tidak otomatis berarti situs Anda diretas, tetapi patch upstream untuk cabang EOL tidak lagi dirilis kecuali vendor OS memberi backport terpisah.

Platform hosting WordPress seperti WP Cloud (pengumuman deprecasi PHP 8.1, KS-05, Confirmed vendor) mengikuti siklus EOL resmi: PHP 8.1 dihapus per 31 Desember 2025, default platform bergeser ke 8.3 lalu 8.4. Itu memaksa banyak situs naik versi tanpa audit plugin, sehingga error pasca-upgrade sering muncul saat cutover, bukan karena rilis PHP 8.4 sendiri rusak.

Sebelum naik versi di produksi, langkah persiapan yang terstruktur mengurangi risiko downtime. Panduan cara update PHP yang aman di aaPanel hosting membahas urutan backup, pemilihan versi, dan pengecekan situs setelah ganti handler, sehingga error pasca-upgrade lebih mudah dilacak ke perubahan spesifik tadi.

Periksa Ini Dulu Sebelum Memperbaiki Website

Gejala di browser saja jarang cukup untuk diagnosa. Gunakan urutan berikut supaya Anda tidak mengganti plugin, Composer, dan konfigurasi server sekaligus tanpa bukti.

1. Catat gejala. URL yang gagal, kode HTTP, waktu mulai error, versi PHP sebelum dan sesudah bila diketahui, serta perubahan di panel hosting atau deploy terakhir.
2. Amankan backup. File, database, snapshot VM bila ada, plus salinan konfigurasi virtual host dan pool PHP-FPM.
3. Konfirmasi runtime aktual. Versi yang tampil di panel, `php -v` lewat SSH, dan versi yang dipakai cron atau queue worker bisa berbeda (pola KS-16).
4. Buka log yang tepat. Error log web server, log pool PHP-FPM, log aplikasi, dan `debug.log` WordPress bila debugging sengaja diaktifkan di lingkungan terbatas.
5. Kategorikan error memakai tabel di bawah sebelum mengubah banyak variabel sekaligus.
6. Uji perbaikan di staging atau jendela maintenance. Catat setiap perubahan dan hasilnya.
7. Verifikasi fungsi bisnis: login, checkout, form, upload, email transaksional, cron, dan endpoint API.

Tabel ini menunjuk arah pemeriksaan, bukan diagnosa pasti. Dua situs dengan HTTP 500 bisa punya akar masalah berbeda meski sama-sama baru ganti PHP.

HTTP 500 atau Halaman Putih Setelah Update PHP

Pengunjung hanya melihat halaman kosong atau pesan server generik. Di log PHP biasanya ada fatal error yang tidak pernah sampai ke browser karena display_errors dimatikan, dan itu sudah benar untuk produksi.

Migrasi WordPress lama ke PHP 8.2 yang dilaporkan AtomixOne (21 April 2026, KS-01, status bukti Confirmed fixed) memperlihatkan HTTP 500 berlapis: gagal resolusi DB_HOST (infrastruktur, bukan inkompatibilitas PHP), Call to undefined function create_function() pada plugin lawas, Cannot redeclare get_options(), deprecation interpolasi ${var}, serta drop-in db.php dan object-cache.php era lama. Perbaikan: log debug, betulkan host database, rename folder plugin bermasalah, ganti drop-in. Laporan AtomixOne.

Panduan hosting cPanel (KS-06, Suggested but unverified, bukan satu insiden ber-ID) menyarankan urutan rollback sementara satu versi di panel untuk memulihkan akses, aktifkan WP_DEBUG_LOG tanpa menampilkan error ke publik, identifikasi plugin dari log, update atau ganti, lalu uji ulang di versi target. Rollback menunda risiko keamanan, bukan menggantikan perbaikan plugin. Pola serupa: Jolt.

Urutan aman: pastikan koneksi database jika log menyebut DB_HOST atau timeout MySQL, nonaktifkan drop-in cache sementara, lalu isolasi plugin dengan rename folder di wp-content/plugins satu per satu di staging. Jangan menghapus massal plugin produksi tanpa rencana rollback.

Konflik Cannot redeclare function berarti dua definisi fungsi dengan nama sama dimuat bersamaan. Itu bukti bentrok kode atau autoload, bukan fitur baru PHP 8 yang melarang deklarasi ganda tanpa konteks file.

Setelah perbaikan, muat ulang homepage dan wp-admin, cek error log kosong dari entri fatal baru, lalu jalankan smoke test form dan upload.

WordPress Menampilkan “There Has Been a Critical Error on This Website”

Pesan ini muncul ketika WordPress menangkap fatal error di core, theme, atau plugin. Core WordPress yang mendukung cabang PHP target tidak menjamin seluruh ekosistem plugin ikut kompatibel.

Make WordPress Core (KS-04, Maintainer-confirmed) menghapus label dukungan PHP 8.x “beta” secara retrospektif. WordPress 6.9/7.0 terdokumentasi mendukung PHP 8.5 penuh, 6.8+ untuk 8.4, 6.4+ untuk 8.3. Minimum supported sejak WP 7.0 adalah PHP 7.4, minimum recommended PHP 8.3. Klarifikasi Mei 2026, handbook kompatibilitas PHP.

Aktifkan debugging hanya dengan kontrol ketat: WP_DEBUG true, WP_DEBUG_LOG true, WP_DEBUG_DISPLAY false, dan pastikan display_errors off di publik. Panduan resmi ada di Debugging in WordPress. Alur ini selaras KS-06 dan KS-01: log dulu, plugin/theme dari stack trace, bukan tebakan dari layar critical error.

Identifikasi path plugin atau theme dari log, update ke rilis yang mendeklarasikan dukungan PHP Anda, atau ganti plugin yang sudah abandoned. Setelah update PHP, error izin kadang muncul terpisah dari fatal PHP, seperti pesan akses wp-admin pasca migrasi yang dibahas di artikel cara atasi error not allowed to access this page di WordPress.

Fatal Error: Call to Undefined Function Setelah Upgrade PHP

Pesan Call to undefined function punya dua keluarga berbeda. Pertama, fungsi yang dihapus dari PHP, seperti create_function() dan each(), yang tidak ada lagi sejak PHP 8.0 (KS-01, KS-17). Kedua, fungsi ekstensi (PDO, MySQLi, imagick) yang belum terpasang pada runtime web meskipun ada di CLI.

Untuk fungsi yang dihapus, perbarui plugin atau ganti dengan closure dan foreach pada kode yang Anda kuasai. Jangan menempel patch permanen di folder vendor/.

PHPUnit lama yang masih memanggil each() memicu fatal di PHP 8.0+ (KS-17, panduan teknis, Suggested but unverified). Solusi standar: upgrade PHPUnit ke versi yang mendukung PHP target, ganti each() dengan foreach pada kode custom. Panduan CodeGenes. Dokumentasi resmi PHP 8.0 tetap sumber utama untuk daftar fungsi yang dihapus.

Untuk fungsi ekstensi, bandingkan output modul PHP antara CLI dan SAPI FPM. Instal ekstensi yang hilang lewat panel, package manager distro, atau image Docker yang benar, lalu restart pool FPM.

PHP Deprecated, Dynamic Properties, dan Implicit Nullable Parameter

Deprecation tidak selalu mematikan situs seketika, tetapi handler error custom atau framework bisa mengubahnya menjadi exception. Menyembunyikan deprecation di error_reporting bukan perbaikan akar masalah.

Creation of Dynamic Property … is Deprecated (PHP 8.2+)

PHP 8.2 memperingatkan penambahan properti objek tanpa deklarasi di class. Fork pocketarc CodeIgniter 3 (KS-11, Maintainer-confirmed pada fork) melaporkan notice pada Model/Controller dan internal CI (CI_URI::$config) saat PHP 8.4 + CI 3.3.x. Deprecation ini dirancang menjadi fatal di PHP 9 bila properti tidak dideklarasikan. Solusi: deklarasikan properti, CI 3.3.x, atribut #[\AllowDynamicProperties] sebagai jembatan terbatas, rencana migrasi CI4. pocketarc#25.

Implicitly Marking Parameter as Nullable is Deprecated (PHP 8.4+)

Signature seperti function foo(string $s = null) harus memakai tipe nullable eksplisit (?string $s = null) setelah Anda memastikan perilaku method dan override child class tetap valid. AgiCAD (KS-02, 20 Oktober 2026, Confirmed fixed) mengekspos deprecation dari framework CodeIgniter lama saat audit dengan error_reporting=E_ALL, bukan hanya kode aplikasi. Laporan AgiCAD. Ringkasan migrasi korporat Deel (KS-03, Suggested but unverified) mendokumentasikan inventaris implicit nullable 8.3→8.4, tetapi hasil akhir per fase belum dipublikasikan lengkap. Gist Deel.

Upstream CodeIgniter 3 (KS-12, Unresolved) masih memancarkan implicit nullable pada test suite PHP 8.4 lewat issue bcit-ci#6302. Symfony 7.x (KS-13, Suggested but unverified) dan modul Magento MageWorx (KS-14, Suggested but unverified, Maret 2026) menunjukkan pola yang sama di ekosistem berbeda. Diskusi Symfony: #61042. Pola perbaikan modul: TescaDev.

strlen(), trim(), dan htmlspecialchars() Menerima null

PHP 8.1 meng-deprecate passing null ke beberapa fungsi string internal. Di strict context bisa muncul TypeError. KS-02 melaporkan input UTF-8 invalid pada htmlspecialchars() tanpa flag yang tepat dapat menghilangkan data secara senyap, sehingga perbaikan validasi boundary dan flag seperti ENT_QUOTES | ENT_SUBSTITUTE relevan bila domain data membutuhkannya.

Deprecated Bukan Selalu Fatal

Log penuh deprecation memang berisik, tetapi situs masih bisa dilayani. Prioritaskan fatal error dan error yang memblokir checkout atau login. Rencanakan refactor library sebelum deprecation menjadi error di rilis major PHP mendatang, tanpa membuat klaim pasti tentang kebijakan PHP 9 yang belum final.

Composer Error Setelah Update PHP: Dependency Tidak Kompatibel

Pesan Composer detected issues in your platform atau Your Composer dependencies require a PHP version berarti composer.lock dan batas require.php tidak cocok dengan binary PHP yang menjalankan Composer, atau platform config sengaja dikunci ke versi lama.

Periksa berurutan: versi php -v saat menjalankan Composer, versi PHP-FPM yang dilayani ke nginx atau Apache, isi composer.json, lalu jalankan composer check-platform-reqs di root proyek yang benar. Dokumentasi perintah ada di Composer check-platform-reqs.

Laravel 13.3+ (KS-07, April 2026, Suggested but unverified) gagal composer install karena Symfony 8 transitif mensyaratkan PHP 8.4 meski framework mengiklankan minimal 8.3. Issue GitHub ditutup, detail fix final belum diverifikasi. laravel/framework#59564. Paket spatie/laravel-data (KS-10, Maintainer-confirmed, Closed via upstream) mengalami jeda kompatibilitas serupa karena phpdocumentor/reflection. #1172.

Lock file yang digenerate di PHP berbeda dari produksi, config.platform salah, atau CLI ≠ FPM (KS-16, pola lintas panduan, Confirmed sebagai solusi standar) adalah sumber deploy gagal yang berulang. Regenerate lock di versi target dan selaraskan platform. Panduan Sentry.

Naikkan dependency ke rilis yang mendukung cabang PHP Anda, regenerate lock di environment staging, jalankan test suite, baru deploy. Flag --ignore-platform-reqs hanya untuk eksperimen lokal, bukan produksi. Status issue Closed di GitHub tidak otomatis berarti fix final sudah terbit di versi yang Anda pakai, cek tag rilis sebelum klaim ke tim.

Database Error: could not find driver / pdo_mysql Hilang

could not find driver hampir selalu menandakan ekstensi PDO belum termuat, bukan password database salah. Credential salah biasanya menghasilkan pesan koneksi atau access denied, bukan driver missing. KS-01 juga menampilkan kegagalan DB_HOST yang terpisah dari driver PDO.

Chris Shennan (KS-15, 1 Februari 2026, Confirmed fixed) mendiagnosis pdo_mysql yang kadang hilang dari php -m setelah ganti image PHP-FPM Docker karena volume mount menimpa conf.d. Perbaikan: pasang ekstensi di Dockerfile dan perbaiki mount agar tidak menimpa konfigurasi image. Artikel diagnosis Docker.

Alur instal ekstensi di server bare metal bisa berbeda. Ringkasan tooling modern dijelaskan pada artikel PIE 1.5 memasang ekstensi PHP, berguna ketika panel hosting tidak menyediakan toggle ekstensi yang Anda butuhkan.

Website 502/503 Setelah Update PHP-FPM atau Ganti Versi di Hosting

502 Bad Gateway sering berarti web server tidak bisa berbicara ke PHP-FPM: service mati, nama unit service salah setelah ganti versi, path listen FastCGI tidak cocok, atau permission file soket Unix.

cPanel ELS-PHP (KS-18, Suggested but unverified) mendokumentasikan service FPM alt-PHP yang gagal start setelah domain berganti versi. Gejala vendor jelas, remediasi spesifik harus mengikuti KB resmi. cPanel KB. Studi kasus CodeRivers (KS-19, September 2026, Suggested but unverified) menambah pola Unit php-fpm.service not found, 502 karena unit systemd versi-spesifik (contoh php8.3-fpm.service), path FastCGI salah, atau php_value di .htaccess invalid di PHP-FPM sehingga situs HTTP 500. CodeRivers, SkyServer.

Apache dengan .htaccess dan Nginx dengan blok fastcgi_pass memakai mekanisme berbeda. Direktif php_value di .htaccess tidak otomatis berlaku di PHP-FPM. aaPanel, cPanel, dan Plesk punya nama service dan tombol restart sendiri, jadi jangan copy perintah systemctl dari tutorial distro lain tanpa cek panel Anda.

Untuk WordPress di VPS aaPanel yang lambat atau timeout setelah perubahan PHP, urutan diagnosis server dan plugin pada tutorial WordPress di VPS aaPanel terasa lambat: diagnosis dulu membantu memisahkan masalah FPM dari masalah query atau cache.

Aplikasi PHP dengan ionCube Loader Tidak Berjalan

Vendor ionCube (KS-20, Juni 2026, Maintainer-confirmed) menegaskan aplikasi ter-encode gagal setelah upgrade PHP bila Loader untuk cabang target belum tersedia (The file ... cannot be decoded). Upgrade PHP harus selaras jadwal rilis Loader dan paket dari vendor aplikasi, bukan sekadar tombol panel hosting.

IonCube menerbitkan panduan menjalankan file encoded di versi PHP mendatang (ionCube blog). Upaya membypass enkoding ilegal tidak masuk scope troubleshooting ini.

Kesalahan yang Tidak Langsung Terlihat: Website Terbuka, tetapi Fungsi Tertentu Rusak

Homepage bisa normal sementara upload gagal karena upload_max_filesize berbeda di pool FPM baru, cron gagal karena CLI masih PHP 7.4, atau login aneh karena path session berubah. PHP 8 mengubah perbandingan longgar seperti 0 == "foo" menjadi false (KS-02, KS-09), yang bisa memengaruhi auth guard atau lookup legacy tanpa fatal error di homepage.

Point release PHP 8.4.21 mengubah perilaku tempnam() sehingga operasi file Laravel 13.9 memicu ErrorException (KS-09, Maintainer-confirmed, issue Closed, detail patch tidak dijanjikan). laravel/framework#60141. Di jalur berbeda, Laravel 12 pada PHP 8.4.4 melaporkan exit code 139 (segfault) saat test HTTP gagal koneksi Guzzle (KS-08, issue Closed, patch spesifik tidak diverifikasi). laravel/framework#54875.

Uji manual tiap fungsi kritikal setelah upgrade, jangan hanya membuka halaman depan. Bandingkan perilaku di staging dengan produksi lama bila masih ada snapshot.

Cara Memperbaiki Website Setelah Upgrade PHP Secara Aman (Checklist Berurutan)

1. Konfirmasi apa yang berubah: cabang PHP, handler, image Docker, atau deploy Composer.
2. Kumpulkan bukti HTTP, log, dan versi CLI versus web.
3. Pastikan backup dan rencana rollback teruji.
4. Pilih satu kategori error dari tabel diagnostik.
5. Reproduksi di staging yang mirroring produksi.
6. Terapkan perbaikan spesifik kategori: kode, plugin, Composer, ekstensi, DB, FPM, loader.
7. Jalankan test otomatis dan manual pada alur bisnis.
8. Deploy bertahap bila infrastruktur mendukung, dokumentasikan setiap commit config.
9. Verifikasi log bersih, monitor error rate, dan konfirmasi dengan pemilik produk.
10. Jadwalkan upgrade berikutnya sebelum cabang PHP Anda mendekati EOL.

Bagaimana Jika Website Tidak Kompatibel dengan PHP Versi Baru?

Theme atau plugin abandoned: ganti komponen atau refactor bagian custom. Framework legacy CodeIgniter 3 ke 4 membutuhkan proyek migrasi (KS-11, KS-12 unresolved upstream), bukan hanya bump versi di Composer. Aplikasi encoded tanpa source (KS-20): negosiasi dengan vendor atau rencana rebuild. Runtime sementara di versi lama hanya isolasi darurat dengan tenggat migrasi tertulis, bukan strategi keamanan jangka panjang.

Apakah PHP Lama Lebih Aman daripada Website yang Error Setelah Update?

Tidak otomatis. Situs yang tampil normal di PHP EOL masih bisa rentan celah yang sudah ditambal di cabang aktif. Situs error setelah update justru menandakan incompatibility yang perlu diperbaiki, bukan alasan menetap di runtime lama selamanya.

Rilis keamanan 21 Oktober 2026 (KS-21, Confirmed fixed pada cabang didukung, Unresolved untuk EOL tanpa backport vendor) menutup CVE-2026-109618 dan CVE-2026-109619 pada PHP 8.2.35, 8.3.36, 8.4.27, dan 8.5.12. Cabang EOL tidak menerima patch upstream, sehingga upgrade ke cabang terpatch atau backport distro (Ubuntu Pro, RHEL) menjadi jalur aman. PHP archive, berita patch RCE, PHP Foundation.

FAQ: Pertanyaan Umum Setelah Update PHP

Kenapa website menjadi blank atau HTTP 500 setelah update PHP?

Karena fatal error di PHP, plugin, theme, atau konfigurasi server yang baru aktif. Baca log PHP dan web server untuk baris spesifik, jangan menebak dari gejala browser saja (lihat KS-01, KS-06).

Apakah WordPress otomatis kompatibel jika PHP diperbarui?

Core WordPress modern mendukung cabang PHP baru (KS-04), tetapi plugin dan theme pihak ketiga bisa gagal. Uji staging wajib untuk toko online dan membership.

Bagaimana membaca pesan critical error on this website?

Aktifkan log debug tanpa menampilkan error ke publik, buka debug.log, identifikasi path plugin atau theme pada stack trace, lalu update atau nonaktifkan komponen tersebut di staging.

Apakah pesan Deprecated berarti website sudah rusak?

Belum tentu. Banyak situs masih online dengan deprecation, tetapi log akan penuh dan beberapa stack mengubahnya jadi exception. Rencanakan perbaikan library sebelum menjadi fatal.

Kenapa PHP CLI dan PHP website bisa berbeda versi?

Cron, deploy script, dan worker queue sering memakai binary berbeda dari pool FPM yang dilayani ke pengunjung. Selaraskan keduanya sebelum menjalankan Composer atau artisan di produksi (KS-16).

Apakah boleh downgrade PHP agar website segera normal?

Boleh sementara untuk pemulihan darurat jika backup dan isolasi jelas, tetapi cabang lama tidak menerima patch keamanan upstream. Tetapkan tenggat migrasi ke versi didukung (pola KS-06).

Apakah upgrade PHP otomatis meningkatkan keamanan jika plugin masih usang?

PHP patch menutup celah di interpreter (KS-21), tetapi plugin rentan tetap rentan. Keduanya harus dikelola bersamaan.

Apa yang harus dilakukan jika aplikasi PHP custom tidak kompatibel?

Audit dependency, buat matriks incompatibility dari log, refactor atau isolasi modul, dan rencanakan upgrade framework dengan test otomatis. Bila tim internal kehabisan waktu, audit kompatibilitas oleh pihak ketiga bisa mempercepat prioritas perbaikan.

Verifikasi Perbaikan dan Rencana Upgrade PHP Berikutnya

Website error setelah update PHP paling cepat reda bila Anda memperlakukan log sebagai sumber kebenaran, mengubah satu variabel per percobaan, dan memverifikasi fungsi bisnis setelah setiap perbaikan. Patch PHP dan kompatibilitas aplikasi adalah dua jalur yang harus jalan bersama, terutama saat cabang runtime Anda mendekati akhir dukungan keamanan.

Jika website tetap error setelah update PHP dan masalahnya melibatkan plugin lama, dependency Composer, atau konfigurasi server, CodeF dapat membantu audit kompatibilitas dan merencanakan perbaikan berdasarkan kondisi website Anda.