Mengatasi Error WordPress Paling Umum: White Screen, Error 500, dan Gagal Koneksi Database untuk Publisher

Situs WordPress yang tiba-tiba menampilkan layar putih kosong, pesan “There has been a critical error on this website”, error 500, atau “Error establishing a database connection” terasa menakutkan, apalagi kalau situs itu sumber penghasilan Anda sebagai publisher. Kabar baiknya, sebagian besar error WordPress yang paling umum punya penyebab yang bisa dilacak dengan urutan yang sistematis: periksa apa yang terakhir berubah, aktifkan pencatatan error dengan aman, isolasi plugin atau tema yang bermasalah, lalu perbaiki akar masalahnya, bukan sekadar gejalanya. Artikel ini membahas langkah demi langkah untuk tiga error paling sering ditemui publisher — white screen dan critical error, error 500, serta gagal koneksi database — ditambah error pendamping seperti 403, 404, 503, dan gagal unggah file, lengkap dengan tabel diagnosis cepat, daftar periksa perbaikan, dan cara mencegahnya terulang.

Poin Kunci

• Sebagian besar error WordPress berasal dari tiga area: plugin atau tema yang konflik, konfigurasi server dan file, atau koneksi database yang bermasalah. Menebak tanpa log hanya memperpanjang downtime.
• Langkah pertama yang benar hampir selalu sama: jangan panik, amankan backup, catat perubahan terakhir, lalu aktifkan pencatatan error (WP_DEBUG_LOG) tanpa menampilkannya ke pengunjung.
• White screen dan pesan critical error biasanya berarti ada PHP fatal error; sejak WordPress 5.2, mode pemulihan (recovery mode) membantu admin masuk dan menonaktifkan penyebabnya.
• Error 500 adalah pesan umum server, bukan diagnosis. Bedakan apakah halaman WordPress sempat tampil atau tidak — itu mempersempit penyebabnya menjadi plugin/tema atau konfigurasi server seperti file .htaccess.
• Pesan gagal koneksi database hampir selalu soal kredensial di wp-config.php, server database yang bermasalah, atau tabel yang rusak — bukan soal tema atau plugin.
• Setelah situs pulih, matikan kembali mode debug, perbarui semua komponen, dan jadwalkan backup otomatis agar error berikutnya tidak berubah menjadi kehilangan data.

Daftar Isi

1. Prinsip Diagnosis: Tenang, Backup, dan Catat Perubahan Terakhir
2. Alat Diagnosis yang Aman: WP_DEBUG, Log Error, dan Recovery Mode
3. White Screen dan “Critical Error”: Penyebab dan Cara Mengatasinya
4. Error 500 Internal Server Error: Cara Mempersempit Penyebabnya
5. Error Establishing a Database Connection: Periksa Kredensial dan Server Database
6. Error Pendamping: 403, 404, 503, Gagal Unggah, dan Mixed Content
7. Tabel Diagnosis Cepat: Gejala, Kemungkinan Penyebab, dan Langkah Pertama
8. Urutan Perbaikan Langkah demi Langkah untuk Publisher
9. Setelah Situs Pulih: Pencegahan agar Error Tidak Terulang
10. Kapan Harus Menghubungi Hosting atau Developer
11. FAQ
12. Kesimpulan
13. Sumber resmi yang dirujuk

Prinsip Diagnosis: Tenang, Backup, dan Catat Perubahan Terakhir

Sebelum menyentuh file apa pun, terapkan tiga kebiasaan yang membedakan perbaikan cepat dari kerusakan yang makin parah. Pertama, jangan melakukan banyak perubahan sekaligus. Kalau Anda menonaktifkan lima plugin, mengganti tema, dan mengedit wp-config.php dalam satu waktu, Anda tidak akan tahu perubahan mana yang benar-benar memperbaiki situs — dan Anda tidak bisa mengulanginya dengan aman di lain waktu. Ubah satu hal, uji, catat hasilnya, baru lanjut ke langkah berikutnya.

Kedua, amankan backup sebelum perbaikan. Dokumentasi resmi WordPress sendiri mengingatkan untuk memverifikasi bahwa Anda sudah memakai staging atau sudah mengambil backup yang sesuai sebelum memodifikasi situs. Kalau hosting Anda menyediakan backup otomatis, unduh salinan terbaru atau buat titik pemulihan baru sebelum mulai. Kalau tidak ada backup sama sekali, salin dulu folder situs dan ekspor database lewat panel hosting, sejauh akses masih memungkinkan. Backup yang diambil saat situs error memang belum tentu bersih, tetapi tetap jauh lebih baik daripada tidak punya titik kembali sama sekali.

Ketiga, catat perubahan terakhir. Dalam pengalaman banyak publisher, error jarang muncul tanpa pemicu. Tanyakan pada diri sendiri: apakah Anda baru memperbarui plugin, tema, atau versi WordPress? Apakah Anda baru memasang plugin baru, mengedit file lewat editor tema, mengubah pengaturan hosting, atau memindahkan situs ke server lain? Jawaban atas pertanyaan ini sering kali langsung menunjuk pelakunya. Kalau error muncul tepat setelah memperbarui satu plugin, plugin itu adalah tersangka pertama — bukan server, bukan database, bukan hal lain yang tidak berubah.

Satu prinsip lagi yang penting untuk publisher: bedakan antara situs yang benar-benar mati dan halaman tertentu yang error. Kalau hanya satu artikel yang menampilkan error sementara beranda dan halaman lain normal, penyebabnya kemungkinan ada di konten, shortcode, atau blok di halaman itu. Kalau seluruh situs mati termasuk wp-admin, penyebabnya lebih mungkin ada di level plugin, tema, konfigurasi, atau database. Catatan sederhana seperti ini menghemat banyak waktu diagnosis.

Jangan Menampilkan Error ke Pengunjung

Saat situs error, godaan terbesar adalah mengaktifkan tampilan error di layar agar cepat terlihat penyebabnya. Untuk situs yang masih bisa diakses pengunjung, itu praktik yang buruk: pesan error PHP dapat membocorkan jalur server, nama plugin, dan detail teknis lain yang tidak seharusnya dilihat publik. Cara yang benar adalah mencatat error ke file log privat, bukan menampilkannya. Bagian berikutnya menjelaskan caranya sesuai dokumentasi resmi WordPress.

Alat Diagnosis yang Aman: WP_DEBUG, Log Error, dan Recovery Mode

WordPress menyediakan sistem debugging bawaan yang dikendalikan lewat konstanta di file wp-config.php, yaitu file konfigurasi di folder root instalasi WordPress yang menyimpan kredensial database dan berbagai pengaturan. Dokumentasi resmi Debugging in WordPress menjelaskan tiga konstanta utama yang perlu Anda kenal.

Pertama, WP_DEBUG. Konstanta ini mengaktifkan mode debug di seluruh instalasi WordPress. Pada instalasi standar, nilainya false; untuk mengaktifkan debugging, ubah menjadi true. Kedua, WP_DEBUG_LOG. Konstanta pendamping ini membuat semua error juga disimpan ke file debug.log di dalam folder wp-content. Ketiga, WP_DEBUG_DISPLAY. Konstanta ini mengendalikan apakah pesan debug ikut ditampilkan di dalam HTML halaman situs. Untuk situs live, kombinasi yang aman menurut dokumentasi resmi adalah sebagai berikut, dan harus disisipkan sebelum baris “That’s all, stop editing! Happy blogging.” di wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Dengan kombinasi ini, error dicatat diam-diam ke wp-content/debug.log, sementara pengunjung tidak melihat apa pun yang aneh. Setelah itu, buka kembali halaman yang error, lalu unduh atau baca debug.log lewat file manager hosting atau SFTP. Baris terakhir di log biasanya menyebut file plugin atau tema yang memicu fatal error, lengkap dengan nomor barisnya. Itulah petunjuk paling berharga dalam seluruh proses ini. Setelah selesai, kembalikan WP_DEBUG ke false agar file log tidak terus membesar tanpa henti.

Recovery Mode Sejak WordPress 5.2

Sejak WordPress 5.2, WordPress memiliki penangan fatal error yang mencegah admin terkunci dari situsnya ketika tema atau plugin menyebabkan fatal error. Ketika fatal error terdeteksi, WordPress menampilkan pesan “There has been a critical error on this website” kepada pengunjung, dan mengirim email pemulihan ke alamat email admin. Email itu berisi tautan khusus ke recovery mode, sebuah mode aman yang memungkinkan Anda masuk ke dashboard dan menonaktifkan plugin atau tema yang bermasalah, meskipun situs bagian depan sedang error. Karena itu, langkah awal yang sering terlupakan adalah memeriksa kotak masuk email admin — termasuk folder spam — sebelum membongkar file lewat FTP. Kalau email pemulihan tidak datang, Anda masih bisa masuk lewat jalur file: ganti nama folder plugin yang dicurigai lewat file manager atau SFTP, dan WordPress akan menonaktifkannya secara otomatis.

Log Server Melengkapi Log WordPress

Perlu dipahami batasnya: debug.log WordPress hanya mencatat error PHP di dalam WordPress. Error yang terjadi sebelum PHP berjalan — misalnya kesalahan sintaks di file .htaccess, penolakan izin file, atau blok firewall — tidak akan muncul di sana. Untuk error seperti itu, Anda memerlukan log error server yang disediakan panel hosting Anda, misalnya menu Errors di cPanel atau file log di hPanel. Aturan praktisnya: kalau errornya berupa halaman WordPress yang bergaya (dengan pesan critical error), mulailah dari debug.log; kalau errornya berupa halaman server yang polos tanpa gaya WordPress, mulailah dari file .htaccess dan log server. Perbedaan tampilan ini saja sudah memotong daftar penyebab menjadi setengahnya.

White Screen dan “Critical Error”: Penyebab dan Cara Mengatasinya

White screen of death adalah halaman putih kosong tanpa pesan apa pun. Penyebabnya hampir selalu sama dengan pesan critical error: PHP mengalami fatal error tetapi tampilan error dimatikan, sehingga pengunjung hanya melihat kekosongan. Penyebab paling umum, berdasarkan pola yang berulang di panduan troubleshooting, adalah konflik plugin, konflik fungsi tema, kehabisan memori PHP, atau file wp-config.php yang rusak setelah diedit. Kabar baiknya, urutan perbaikannya juga relatif baku.

Langkah pertama, periksa email pemulihan dan coba recovery mode. Kalau berhasil masuk, nonaktifkan plugin yang terakhir diperbarui atau dipasang, lalu uji situs. Kalau tidak ada email, lakukan isolasi plugin lewat file. Caranya: lewat file manager hosting atau SFTP, masuk ke folder wp-content, lalu ganti nama folder plugins menjadi plugins-nonaktif. WordPress akan menonaktifkan semua plugin sekaligus. Kalau situs langsung pulih, penyebabnya ada di salah satu plugin. Kembalikan nama foldernya, lalu aktifkan plugin satu per satu dari dashboard sambil menguji situs setiap kali, sampai plugin pelakunya ketemu. Metode ini memang memakan waktu, tetapi jauh lebih akurat daripada menebak.

Kalau menonaktifkan semua plugin tidak membantu, ganti tema. Ganti nama folder tema aktif di wp-content/themes, dan WordPress akan jatuh kembali ke tema bawaan. Kalau situs pulih setelah itu, masalahnya ada di tema — biasanya fungsi di functions.php yang konflik atau kode yang tidak kompatibel dengan versi PHP atau WordPress terbaru. Hubungi pembuat tema atau kembalikan ke versi tema sebelumnya dari backup.

Kalau kedua langkah itu belum membantu, periksa memori. Kehabisan memori PHP adalah penyebab klasik white screen pada situs dengan banyak plugin. Sebagai patokan praktik (bukan aturan resmi WordPress), banyak panduan menyarankan menaikkan batas memori WordPress dengan menambahkan define(‘WP_MEMORY_LIMIT’, ‘256M’); ke wp-config.php. Perlu dicatat, batas ini tetap tunduk pada batas PHP di level server yang ditetapkan hosting Anda; kalau hosting membatasi lebih rendah, Anda perlu meminta penyesuaian ke dukungan hosting. Jangan menaikkan memori tanpa batas sebagai solusi permanen: memori yang terus membengkak justru bisa menandakan plugin yang boros atau query yang tidak efisien, dan itu perlu diperbaiki di sumbernya.

Terakhir, periksa apakah ada kesalahan sintaks akibat edit file yang baru dilakukan. Satu tanda kurung atau titik koma yang hilang di functions.php atau wp-config.php cukup untuk mematikan seluruh situs. Kalau Anda baru mengedit file, kembalikan salinan sebelum edit dari backup, lalu ulangi edit dengan hati-hati, idealnya di staging dulu. Setelah situs pulih, baca debug.log untuk memastikan tidak ada peringatan lain yang tertinggal, lalu matikan kembali mode debug.

Error 500 Internal Server Error: Cara Mempersempit Penyebabnya

Error 500 adalah pesan paling umum sekaligus paling tidak informatif: server hanya mengatakan ada sesuatu yang salah di sisi server, tanpa merinci apa. Karena itu, langkah pertama bukan menebak penyebab, melainkan mempersempit lokasi masalah dari tampilannya.

Ada tiga tampilan yang perlu dibedakan. Pertama, halaman bergaya WordPress dengan pesan “There has been a critical error on this website”. Ini berarti PHP sudah berjalan dan WordPress sudah sempat dimuat, lalu ada plugin atau tema yang mengalami fatal error. Penanganannya sama seperti white screen: periksa email pemulihan, baca debug.log, dan isolasi plugin atau tema. Kedua, halaman server yang polos, misalnya teks “Internal Server Error” dengan gaya standar browser atau halaman bermerek hosting. Ini berarti WordPress bahkan belum sempat berbicara: kegagalan terjadi di web server, di pengelola proses PHP, atau di file konfigurasi yang dibaca server sebelum menyerahkan permintaan ke PHP. Mulailah dari file .htaccess. Ketiga, halaman putih kosong total tanpa teks apa pun. Ini berada di antara keduanya: PHP mati dengan tampilan error yang dimatikan, dan penyebabnya bisa berupa fatal error di wp-config.php, di must-use plugin, atau file yang sudah kedaluwarsa di cache opcode. Untuk kasus ini, debug.log adalah penentu tercepat.

Memeriksa File .htaccess

File .htaccess adalah file konfigurasi server Apache (dan LiteSpeed yang kompatibel) yang mengatur permalink, pengalihan, dan aturan keamanan. File ini mudah rusak, misalnya karena plugin keamanan atau caching yang menulis aturan yang salah, atau karena proses migrasi yang tidak sempurna. Cara mengujinya aman: ganti nama file .htaccess menjadi .htaccess-lama, lalu coba buka situs. Kalau situs pulih, .htaccess adalah pelakunya. Setelah itu, masuk ke dashboard, buka Pengaturan lalu Permalink, dan klik Simpan tanpa mengubah apa pun — WordPress akan membuat file .htaccess baru yang bersih dengan aturan permalink standar. Aturan kustom lama yang masih Anda butuhkan bisa ditambahkan kembali satu per satu setelah itu, sambil menguji setiap penambahan. Jangan menghapus .htaccess secara permanen tanpa membuat yang baru, karena permalink Anda bisa ikut rusak.

Batas Memori dan Versi PHP

Dua penyebab 500 lain yang sering luput adalah batas memori PHP dan ketidakcocokan versi PHP. Plugin modern dan tema berat membutuhkan memori lebih besar daripada situs WordPress sederhana satu dekade lalu. Kalau debug.log menunjukkan pesan kehabisan memori, naikkan WP_MEMORY_LIMIT seperti dijelaskan sebelumnya, dan konfirmasikan batas PHP di hosting Anda. Sebaliknya, kalau error muncul setelah hosting menaikkan versi PHP atau setelah Anda memperbarui WordPress, bisa jadi ada plugin lama yang memakai fungsi PHP yang sudah tidak didukung. Dalam kasus ini, debug.log akan menyebut fungsi dan file yang bermasalah; perbarui plugin tersebut, atau ganti dengan alternatif yang masih dirawat, daripada memaksa menurunkan versi PHP sebagai solusi jangka panjang — menurunkan versi PHP hanya menunda masalah dan dapat membuka risiko keamanan.

Izin File dan Plugin yang Rusak

Penyebab 500 yang lebih jarang tetapi nyata adalah izin file yang salah setelah migrasi atau pemulihan backup, dan file plugin yang rusak karena proses unggah yang tidak sempurna. Sebagai patokan praktik umum, folder WordPress biasanya memakai izin 755 dan file memakai 644, tetapi angka pastinya bisa berbeda menurut konfigurasi hosting Anda, jadi konfirmasikan ke dokumentasi hosting sebelum mengubah izin secara massal. Kalau satu plugin dicurigai rusak, memasang ulang plugin itu dari direktori resmi WordPress sering kali menyelesaikan masalah tanpa mengubah pengaturannya, karena data pengaturan plugin biasanya tersimpan di database, bukan di file plugin itu sendiri.

Error Establishing a Database Connection: Periksa Kredensial dan Server Database

Pesan “Error establishing a database connection” berbeda dari error sebelumnya: pesan ini berarti WordPress tidak dapat berkomunikasi dengan database MySQL. Karena konten, pengaturan, pengguna, dan sebagian besar data situs tersimpan di database, situs tidak dapat menampilkan apa pun. Untungnya, penyebabnya juga lebih sempit dan lebih mudah dilacak.

Penyebab pertama dan paling umum adalah kredensial database yang salah di wp-config.php. File ini menyimpan empat nilai: DB_NAME (nama database), DB_USER (nama pengguna database), DB_PASSWORD (kata sandi), dan DB_HOST (host database). Kalau salah satu berubah — misalnya hosting mereset kata sandi database, atau Anda memindahkan situs dan lupa memperbarui wp-config.php — koneksi akan gagal. Bandingkan keempat nilai itu dengan data database yang ditampilkan panel hosting Anda, karakter demi karakter. Kesalahan umum termasuk spasi yang tidak sengaja, kata sandi yang disalin tidak lengkap, atau DB_HOST yang masih menunjuk ke host lama. Pada instalasi standar, DB_HOST biasanya localhost, tetapi beberapa hosting memakai host khusus, jadi jangan menebak: salin persis dari panel hosting.

Penyebab kedua adalah server database yang sedang bermasalah atau mati. Pada shared hosting, Anda tidak dapat me-restart MySQL sendiri; yang bisa Anda lakukan adalah memeriksa status layanan di panel hosting dan menghubungi dukungan hosting kalau memang server database sedang down. Tanda yang mengarah ke sini adalah ketika kredensial sudah benar tetapi error muncul di semua halaman, dan situs lain di server yang sama (kalau ada) ikut bermasalah. Jangan mengutak-atik wp-config.php berulang kali kalau kredensial sudah terverifikasi benar — itu hanya membuang waktu.

Penyebab ketiga adalah tabel database yang rusak. Ini bisa terjadi setelah server mati mendadak, proses impor yang gagal, atau disk yang penuh. WordPress menyediakan mode perbaikan bawaan yang dapat diaktifkan dengan menambahkan define(‘WP_ALLOW_REPAIR’, true); ke wp-config.php, lalu membuka alamat wp-admin/maint/repair.php. Halaman itu menawarkan tombol Repair Database dan Repair and Optimize Database. Setelah perbaikan selesai, hapus kembali baris WP_ALLOW_REPAIR dari wp-config.php, karena halaman perbaikan dapat diakses siapa pun selama konstanta itu aktif — membiarkannya aktif adalah risiko keamanan. Kalau perbaikan bawaan gagal, dukungan hosting biasanya dapat memperbaiki tabel dari phpMyAdmin atau dari sisi server.

Penyebab keempat, yang lebih jarang, adalah batas koneksi database yang terlampaui. Situs dengan traffic tinggi atau plugin yang membuka banyak koneksi dapat kehabisan slot koneksi MySQL. Gejalanya khas: error muncul sesekali, terutama pada jam sibuk, lalu hilang sendiri. Solusinya bukan di wp-config.php, melainkan di sisi server dan efisiensi plugin: kurangi plugin yang boros query, aktifkan caching yang benar, dan diskusikan batas koneksi dengan hosting Anda. Kalau situs Anda tumbuh, ini juga bisa menjadi tanda sudah waktunya naik ke paket hosting yang lebih memadai, seperti yang dibahas pada artikel memilih hosting di situs ini.

Urutan Periksa Database dalam Lima Menit

Untuk publisher yang sedang panik, urutan singkatnya adalah: pertama, verifikasi keempat kredensial di wp-config.php terhadap panel hosting. Kedua, periksa apakah server database sedang down lewat status hosting. Ketiga, coba akses phpMyAdmin: kalau phpMyAdmin juga tidak bisa dibuka, masalahnya hampir pasti di sisi server database, bukan di WordPress. Keempat, jalankan perbaikan tabel hanya kalau kredensial benar dan server database berjalan. Kelima, kalau semuanya gagal, hubungi hosting dengan menyertakan pesan error persis dan waktu kejadiannya — informasi itu mempercepat diagnosis mereka secara signifikan.

Error Pendamping: 403, 404, 503, Gagal Unggah, dan Mixed Content

Tidak semua error mematikan seluruh situs, tetapi error pendamping ini tetap merugikan publisher karena mengganggu pengunjung dan, dalam beberapa kasus, merusak SEO. Berikut cara membedakannya.

Error 403 Forbidden

Pesan 403 berarti server memahami permintaan Anda tetapi menolak mengizinkannya. Penyebab umum adalah aturan di .htaccess atau plugin keamanan yang terlalu agresif, izin file yang salah, atau pemblokiran IP oleh firewall hosting. Kalau 403 hanya muncul di satu halaman admin setelah Anda memasang plugin keamanan, nonaktifkan plugin itu lewat file dan uji lagi. Kalau 403 muncul di seluruh situs setelah migrasi, periksa izin file dan folder, lalu periksa aturan .htaccess yang baru ditulis. Jangan menonaktifkan plugin keamanan secara permanen sebagai solusi: cari aturan spesifik yang memblokir, lalu sesuaikan aturannya.

Error 404 dan Permalink yang Rusak

Error 404 setelah migrasi atau setelah mengubah pengaturan permalink hampir selalu soal permalink, bukan soal konten yang hilang. Solusi standarnya sama seperti pada .htaccess: buka Pengaturan lalu Permalink dan klik Simpan untuk membangun ulang aturan rewrite. Kalau hanya satu artikel yang 404 sementara yang lain normal, periksa slug artikel itu dan pastikan tidak ada konflik dengan slug halaman atau kategori lain. Untuk publisher, penting juga membedakan 404 yang sesungguhnya dari 404 yang disebabkan plugin cache yang menyajikan halaman lama: bersihkan cache plugin dan cache server setelah mengubah permalink.

Error 503 Service Unavailable

Pesan 503 berarti server untuk sementara tidak dapat menangani permintaan, sering kali karena perawatan, lonjakan traffic, atau sumber daya yang habis. Pada WordPress, ada satu penyebab 503 yang khas dan mudah dikenali: file .maintenance. Ketika WordPress memperbarui core, tema, atau plugin, ia membuat file .maintenance di folder root dan menampilkan pesan perawatan singkat. Normalnya file itu terhapus sendiri setelah pembaruan selesai. Kalau proses pembaruan gagal di tengah jalan, file .maintenance bisa tertinggal dan situs terus menampilkan pesan perawatan. Solusinya sederhana: hapus file .maintenance lewat file manager, lalu periksa dan selesaikan pembaruan yang tertunda. Kalau 503 muncul tanpa kaitan dengan pembaruan, penyebabnya kemungkinan ada di sisi server — periksa penggunaan CPU dan memori di panel hosting, dan hubungi hosting kalau situs Anda berulang kali kehabisan sumber daya pada jam sibuk.

Gagal Mengunggah dan “Failed to Write File to Disk”

Error unggah biasanya berbunyi “failed to write file to disk” atau unggahan berhenti di tengah jalan. Penyebab umum adalah folder wp-content/uploads yang tidak dapat ditulis oleh server, disk hosting yang penuh, atau batas ukuran unggahan PHP yang terlalu kecil. Periksa dulu sisa kuota disk di panel hosting — ini penyebab yang paling mudah dicek dan paling sering dilupakan. Setelah itu, periksa izin folder uploads dan pastikan pemilik folder sesuai dengan pengguna web server. Kalau file yang diunggah berukuran besar, misalnya video atau PDF berat, batas upload_max_filesize di PHP mungkin perlu disesuaikan lewat hosting. Untuk publisher, praktik yang lebih baik adalah mengompresi gambar sebelum mengunggah dan menghindari mengunggah video langsung ke WordPress; gunakan layanan video khusus dan sematkan saja, agar disk dan bandwidth tidak cepat habis.

Mixed Content: Situs HTTPS yang Memuat Elemen HTTP

Mixed content terjadi ketika halaman HTTPS memuat gambar, skrip, atau stylesheet lewat HTTP. Browser modern akan memblokir sebagian elemen itu dan menampilkan peringatan “Not Secure” sebagian, yang merusak kepercayaan pengunjung. Penyebab klasiknya adalah migrasi dari HTTP ke HTTPS yang tidak tuntas: alamat situs di Pengaturan Umum sudah HTTPS, tetapi konten lama masih menyimpan URL HTTP di database. Solusinya adalah memperbarui URL di database secara menyeluruh (lewat plugin pencarian dan penggantian yang tepercaya, atau lewat alat hosting), memastikan alamat WordPress dan alamat situs sama-sama HTTPS, dan memeriksa apakah ada tema atau plugin yang menulis URL HTTP secara hardcode. Setelah diperbaiki, uji dengan membuka halaman dan memeriksa ikon gembok browser, bukan sekadar melihat tampilannya.

Tabel Diagnosis Cepat: Gejala, Kemungkinan Penyebab, dan Langkah Pertama

Tabel ini adalah titik awal, bukan vonis akhir. Gejala yang sama bisa punya penyebab berbeda, dan hanya log yang bisa memastikan. Gunakan tabel untuk memilih langkah pertama yang paling mungkin, lalu biarkan log mengarahkan langkah berikutnya.

Urutan Perbaikan Langkah demi Langkah untuk Publisher

Berikut urutan yang dapat Anda ikuti dari awal sampai akhir ketika situs error, tanpa melompati langkah diagnosis yang penting.

1. Catat gejalanya persis: pesan error lengkap, halaman mana yang terdampak (semua halaman atau sebagian), dan kapan mulai terjadi.
2. Catat perubahan terakhir: pembaruan, plugin baru, edit file, perubahan hosting, atau migrasi.
3. Amankan backup: buat titik pemulihan baru atau unduh backup terbaru sebelum mengubah apa pun.
4. Periksa email admin untuk tautan recovery mode, termasuk folder spam.
5. Aktifkan WP_DEBUG_LOG dengan WP_DEBUG_DISPLAY false, lalu baca debug.log setelah memuat ulang halaman yang error.
6. Isolasi plugin: ganti nama folder plugins, uji situs, lalu aktifkan satu per satu sampai pelakunya ketemu.
7. Isolasi tema: ganti ke tema bawaan sementara untuk memastikan tema bukan penyebabnya.
8. Untuk error server polos, uji .htaccess dengan mengganti namanya dan membangun ulang permalink.
9. Untuk error database, verifikasi empat kredensial di wp-config.php, periksa status server database, lalu jalankan perbaikan tabel bila perlu.
10. Perbaiki akar masalahnya: perbarui, ganti, atau hapus plugin atau tema yang bermasalah; jangan hanya menonaktifkannya selamanya tanpa rencana pengganti.
11. Uji menyeluruh: beranda, satu artikel, satu halaman, formulir, dan dashboard wp-admin.
12. Bersihkan cache plugin dan cache server, lalu uji lagi sebagai pengunjung yang belum login.
13. Matikan kembali WP_DEBUG (kembalikan ke false) dan hapus konstanta perbaikan database bila sempat diaktifkan.
14. Catat apa yang terjadi dan apa yang diperbaiki, agar error yang sama di masa depan dapat ditangani lebih cepat.

Urutan ini sengaja menempatkan diagnosis sebelum perbaikan. Publisher yang langsung menghapus plugin atau menginstal ulang WordPress tanpa diagnosis sering kali kehilangan data pengaturan atau justru menambah masalah baru. Instalasi ulang core WordPress memang kadang diperlukan kalau file core rusak, tetapi itu langkah lanjutan, bukan langkah pertama, dan harus selalu didahului backup.

Kesalahan yang Sering Memperparah Keadaan

Ada beberapa kesalahan yang berulang kali membuat error kecil menjadi bencana. Pertama, mengedit file langsung di situs live tanpa backup dan tanpa staging. Kedua, membiarkan WP_DEBUG_DISPLAY tetap true sehingga error terpampang ke publik. Ketiga, membiarkan WP_ALLOW_REPAIR tetap aktif setelah perbaikan database selesai. Keempat, mengubah izin file secara massal tanpa memahami konfigurasi hosting, yang dapat mengunci situs sepenuhnya. Kelima, memasang banyak plugin “perbaikan” sekaligus saat situs error — plugin tambahan justru menambah variabel baru di tengah diagnosis. Dan keenam, mengabaikan pesan error yang sudah jelas di log karena lebih percaya pada tebakan. Hindari keenam hal ini, dan sebagian besar perbaikan akan berjalan jauh lebih tenang.

Setelah Situs Pulih: Pencegahan agar Error Tidak Terulang

Memperbaiki error hanyalah separuh pekerjaan; separuh lainnya adalah memastikan error yang sama tidak kembali minggu depan. Berikut kebiasaan pencegahan yang paling berdampak bagi publisher.

Pertama, jadwalkan pembaruan yang disiplin. Plugin dan tema yang tidak diperbarui adalah sumber konflik dan kerentanan yang paling umum. Perbarui secara berkala, tetapi jangan memperbarui semuanya sekaligus tanpa backup dan tanpa jeda pengujian. Praktik yang baik untuk publisher adalah memperbarui di jam sepi, satu kelompok dalam satu waktu, dan memeriksa situs setelah setiap kelompok. Kalau hosting Anda menyediakan staging, uji pembaruan besar di staging dulu sebelum diterapkan ke situs live.

Kedua, kurangi jumlah plugin. Setiap plugin adalah kode tambahan yang dapat konflik dengan plugin lain, membebani memori, dan membuka permukaan serangan. Audit plugin secara berkala: hapus plugin yang sudah tidak dipakai, ganti dua plugin yang fungsinya tumpang tindih dengan satu plugin yang terawat, dan periksa kapan terakhir kali setiap plugin diperbarui oleh pembuatnya. Plugin yang sudah bertahun-tahun tidak diperbarui adalah kandidat utama masalah berikutnya.

Ketiga, otomatiskan backup. Backup manual yang bergantung pada ingatan pasti akan gagal pada saat paling dibutuhkan. Atur backup otomatis harian — idealnya ke lokasi terpisah dari server situs — dan uji pemulihannya secara berkala. Backup yang belum pernah diuji pemulihannya belum bisa disebut backup yang dapat diandalkan. Untuk publisher yang menerbitkan setiap hari, kehilangan satu hari konten saja sudah mahal; backup harian adalah batas minimum yang masuk akal.

Keempat, pantau kesehatan situs. Periksa log error secara berkala, bukan hanya saat situs mati. Peringatan PHP yang berulang di debug.log sering kali merupakan tanda awal plugin yang akan gagal total pada pembaruan berikutnya. Alat pemantau uptime juga membantu Anda tahu situs down dalam hitungan menit, bukan setelah pembaca melapor berjam-jam kemudian. Semakin cepat Anda tahu, semakin kecil dampaknya pada traffic dan penghasilan iklan.

Kelima, jaga fondasi teknisnya: versi PHP yang didukung, tema yang terawat, dan hosting yang memadai. Situs yang tumbuh tetapi tetap memakai paket hosting paling kecil akan berulang kali menabrak batas memori dan koneksi database. Itu bukan error WordPress semata, melainkan tanda infrastruktur yang sudah tidak sebanding dengan beban situs. Menyesuaikan paket hosting pada waktunya sering kali lebih murah daripada downtime berulang.

Keenam, dokumentasikan konfigurasi Anda. Catat daftar plugin aktif, tema, versi PHP, dan penyesuaian penting di wp-config.php dan .htaccess. Dokumentasi sederhana ini sangat berharga ketika Anda harus meminta bantuan hosting atau developer: mereka tidak perlu menebak-nebak konfigurasi Anda dari nol, dan Anda sendiri tidak perlu mengingat semuanya di tengah kepanikan.

Kapan Harus Menghubungi Hosting atau Developer

Tidak semua error harus diselesaikan sendiri, dan memaksakan diri pada masalah di luar kendali Anda hanya membuang waktu. Hubungi dukungan hosting ketika: server database dikonfirmasi down, situs kehabisan sumber daya berulang kali, error berasal dari konfigurasi server yang tidak dapat Anda ubah di shared hosting, atau Anda mencurigai server terinfeksi malware. Saat menghubungi mereka, sertakan pesan error persis, waktu kejadian, langkah yang sudah Anda coba, dan isi debug.log yang relevan. Dukungan yang menerima laporan lengkap akan jauh lebih cepat membantu daripada dukungan yang harus menanyakan semuanya dari awal.

Hubungi developer ketika: penyebabnya ada di kode tema atau plugin kustom, error melibatkan integrasi khusus seperti sistem keanggotaan atau toko, atau perbaikan memerlukan perubahan kode yang Anda tidak pahami risikonya. Jangan meminta developer memperbaiki dengan akses admin penuh tanpa batas waktu dan tanpa backup terlebih dahulu; berikan akses yang diperlukan, minta penjelasan tentang apa yang diubah, dan cabut akses setelah pekerjaan selesai. Untuk publisher, hubungan yang sehat dengan developer cadangan — seseorang yang sudah mengenal situs Anda sebelum darurat terjadi — jauh lebih berharga daripada mencari bantuan dadakan saat situs sedang mati.

Satu hal terakhir yang perlu ditegaskan: kalau situs Anda menampilkan pesan error yang mengarah pada kemungkinan peretasan — misalnya file asing, pengguna admin yang tidak Anda kenal, atau pengalihan ke situs lain — jangan hanya memperbaiki gejalanya. Ikuti panduan keamanan WordPress secara menyeluruh: ganti semua kata sandi, periksa pengguna dan file yang mencurigakan, pindai malware, dan pulihkan dari backup bersih bila perlu. Artikel keamanan WordPress di situs ini membahas fondasi tersebut, termasuk login, plugin, backup, dan kewajiban perlindungan data pribadi.

FAQ

Apakah white screen selalu berarti situs saya diretas?

Tidak. White screen paling sering disebabkan konflik plugin atau tema, kehabisan memori, atau kesalahan edit file. Peretasan adalah kemungkinan, tetapi bukan penyebab pertama yang harus diasumsikan. Periksa debug.log dan perubahan terakhir dulu; kalau log menunjukkan file asing atau pengguna admin yang tidak dikenal, barulah jalankan pemeriksaan keamanan menyeluruh.

Apakah aman mengaktifkan WP_DEBUG di situs live?

Aman bila dilakukan dengan cara yang benar: aktifkan WP_DEBUG bersama WP_DEBUG_LOG true dan WP_DEBUG_DISPLAY false, sehingga error hanya tercatat di file debug.log privat dan tidak ditampilkan ke pengunjung. Yang tidak aman adalah mengaktifkan WP_DEBUG dengan tampilan error menyala di situs live, karena detail teknis dapat terlihat publik. Setelah selesai, kembalikan WP_DEBUG ke false.

Saya tidak bisa masuk wp-admin sama sekali. Apa yang harus dilakukan?

Gunakan jalur file: lewat file manager hosting atau SFTP, ganti nama folder plugin yang dicurigai atau seluruh folder plugins untuk menonaktifkan plugin, dan ganti nama folder tema aktif untuk kembali ke tema bawaan. Periksa juga email admin untuk tautan recovery mode dari WordPress 5.2 ke atas. Kalau wp-admin tetap tidak bisa dibuka setelah itu, kemungkinan penyebabnya ada di wp-config.php, .htaccess, atau server database — periksa ketiganya sesuai panduan di atas.

Berapa batas memori yang ideal untuk WordPress?

Tidak ada angka tunggal yang berlaku untuk semua situs, karena kebutuhan memori bergantung pada tema, jumlah plugin, dan traffic. Sebagai patokan praktik, banyak panduan memakai 256M sebagai titik awal untuk situs publisher aktif, tetapi batas sebenarnya tetap ditentukan konfigurasi PHP di hosting Anda. Kalau situs berulang kali kehabisan memori, menaikkan batas saja belum cukup: cari tahu plugin atau proses apa yang memakan memori, dan perbaiki di sumbernya.

Apakah menghapus dan memasang ulang WordPress akan menghilangkan konten saya?

Memasang ulang file core WordPress tidak menghapus konten, karena konten tersimpan di database dan file unggahan tersimpan di wp-content/uploads. Namun, memasang ulang tetap berisiko bila dilakukan tanpa backup, dan tidak boleh menjadi langkah pertama. Selalu amankan backup lengkap — file dan database — sebelum memasang ulang apa pun, dan jangan menghapus folder wp-content atau database.

Mengapa error database muncul hanya sesekali, lalu hilang sendiri?

Pola sesekali seperti itu biasanya mengarah pada batas koneksi database yang terlampaui pada jam sibuk, atau server database yang kelebihan beban sesaat. Periksa apakah error bertepatan dengan lonjakan traffic, kurangi plugin yang boros query, aktifkan caching, dan diskusikan batas koneksi dengan hosting Anda. Kalau pola ini makin sering, itu tanda paket hosting perlu ditingkatkan.

Kesimpulan

Error WordPress yang paling umum — white screen, critical error, error 500, dan gagal koneksi database — terlihat menakutkan, tetapi hampir semuanya dapat dilacak dengan urutan yang sama: catat gejala dan perubahan terakhir, amankan backup, aktifkan pencatatan error yang aman, baca lognya, isolasi plugin dan tema, lalu perbaiki akar masalahnya. Bedakan tampilan error untuk mempersempit penyebab: halaman WordPress yang bergaya mengarah ke plugin atau tema, halaman server yang polos mengarah ke .htaccess dan konfigurasi server, dan pesan database mengarah ke kredensial serta server database. Setelah situs pulih, matikan kembali mode debug, perbarui komponen yang tertinggal, kurangi plugin yang tidak perlu, dan pastikan backup otomatis berjalan dan teruji. Publisher yang merawat fondasi ini tidak hanya memulihkan situs lebih cepat saat error terjadi, tetapi juga membuat error berikutnya semakin jarang — dan itu berarti traffic, kepercayaan pembaca, dan penghasilan iklan yang lebih terjaga.

Sumber resmi yang dirujuk

• WordPress Developer Resources, Debugging in WordPress — panduan resmi konstanta WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, SCRIPT_DEBUG, dan SAVEQUERIES, serta anjuran backup atau staging sebelum modifikasi dan penempatan konstanta sebelum baris penanda akhir wp-config.php.
• WordPress Developer Resources, Debugging (Theme Handbook) — penjelasan mode debug, konstanta wp-config.php, dan penangan fatal error sejak WordPress 5.2.
• WordPress.org, dokumentasi wp-config.php dan file konfigurasi WordPress — peran wp-config.php sebagai file yang menyimpan kredensial database dan pengaturan instalasi.
• Panduan troubleshooting umum WordPress dari penyedia hosting dan dokumentasi komunitas — pola penyebab white screen, error 500, dan gagal koneksi database yang dirujuk sebagai patokan praktik, dibedakan dari aturan resmi WordPress di atas.