Mengira DISABLE_WP_CRON Cukup, Padahal Jadwal WordPress Jadi Tidak Jalan Sama Sekali

Saran untuk mematikan WP-Cron supaya server lebih ringan sering muncul di artikel optimasi dan forum WordPress. Banyak orang lalu menambahkan satu baris DISABLE_WP_CRON ke wp-config.php, melihat situs terasa sedikit lebih enteng, dan melupakannya. Beberapa hari kemudian post terjadwal muncul dengan label Missed schedule, email dari plugin form tidak terkirim, dan backup otomatis terakhir ternyata sudah lama sekali. Tidak ada error di mana pun, karena memang tidak ada yang gagal. Tugas-tugas itu hanya tidak pernah dipanggil. Konstanta itu sendiri tidak salah. Yang keliru adalah anggapan bahwa menambahkannya sudah cukup.

Apa yang sebenarnya dimatikan oleh DISABLE_WP_CRON

WP-Cron bukan cron dalam arti sistem operasi. Ia adalah penjadwal internal WordPress. Daftar tugasnya disimpan di database, tepatnya di option cron pada tabel wp_options. Isinya hal-hal seperti publikasi post terjadwal, pengecekan update, pembersihan transient, pengiriman email antrean, sampai tugas backup yang didaftarkan plugin. Masalahnya, WordPress tidak punya proses yang terus berjalan di latar belakang. Jadi ia butuh sesuatu yang membangunkannya. Caranya begini: setiap kali ada request yang memuat WordPress, misalnya pengunjung membuka halaman, WordPress mengecek apakah ada tugas yang sudah jatuh tempo. Kalau ada, WordPress mengirim request HTTP ke wp-cron.php miliknya sendiri. Request ini disebut loopback request. Ia dikirim tanpa menunggu jawaban, supaya pengunjung tidak ikut menunggu. Di request terpisah itulah tugas-tugasnya dijalankan. Konstanta ini hanya mematikan langkah pemicu tersebut. Isinya kira-kira seperti ini:

PHP

// wp-config.php
// Mematikan pemicu WP-Cron dari setiap page load.
// Tidak menjalankan apa pun sebagai gantinya.
define( 'DISABLE_WP_CRON', true );

Setelah baris itu aktif, wp-cron.php masih ada dan masih bekerja normal kalau dipanggil. Daftar tugas di database juga tetap terisi dan terus bertambah. Bedanya, sekarang tidak ada lagi yang memanggil wp-cron.php. Kalau tidak ada pengganti, jadwal akan diam selamanya. Tidak ada log error karena dari sudut pandang WordPress semuanya wajar, hanya belum waktunya dijalankan.

Kenapa sarannya masuk akal, tapi sering dipahami setengah

Alasan mematikan pemicu bawaan ini sebenarnya valid. Di situs yang ramai, pengecekan jadwal terjadi di banyak sekali request. Kalau ada tugas berat yang jatuh tempo, loopback request bisa ikut memakan worker PHP di saat traffic sedang tinggi. Di situs yang sepi, masalahnya justru kebalikannya: tidak ada kunjungan berarti tidak ada pemicu, jadi post yang dijadwalkan jam 8 pagi baru terbit saat ada orang pertama yang mampir. Ada juga kasus yang sering terlewat, yaitu full-page cache. Kalau halaman dilayani dari cache oleh web server atau CDN tanpa memuat PHP sama sekali, kunjungan itu tidak memicu WP-Cron. Situsnya terlihat ramai, tapi dari sisi WordPress hampir tidak ada request yang benar-benar masuk. Apakah ini terjadi di servermu tergantung cara cache-nya dipasang. Karena itu, saran yang benar selalu datang sepaket: matikan pemicu dari kunjungan, lalu pasang cron job di level server yang memanggil WP-Cron secara rutin. Bagian kedua ini yang sering hilang saat saran tersebut disalin dari satu artikel ke artikel lain. Di meja support, pertanyaan seperti kenapa post saya tidak terbit atau kenapa email WooCommerce berhenti cukup sering berujung pada baris ini. Kadang baris itu ditambahkan oleh plugin optimasi atau developer sebelumnya, dan pemilik situs tidak tahu baris itu ada.

Cara memastikan jadwalnya memang macet

Sebelum mengubah apa pun, pastikan dulu masalahnya memang di sini. Cara paling cepat adalah lewat WP-CLI, alat baris perintah resmi untuk WordPress. Jalankan perintahnya dari folder instalasi WordPress, sebagai user pemilik situs dan bukan root. WP-CLI sendiri menolak berjalan sebagai root kecuali dipaksa, dan file yang dibuat sebagai root bisa menimbulkan masalah permission di kemudian hari.

BASH

# Cek apakah konstanta aktif di wp-config.php
wp config get DISABLE_WP_CRON

# Lihat daftar event beserta jadwal berikutnya
wp cron event list --fields=hook,next_run_gmt,recurrence

# Uji apakah WP-Cron bisa dipicu lewat loopback
wp cron test

Semua perintah di atas hanya membaca, jadi aman dijalankan. Yang perlu diperhatikan ada di output wp cron event list. Kalau banyak event yang next_run_gmt-nya sudah lewat jauh, jam atau hari sebelum sekarang, artinya tidak ada yang menjalankannya. Perintah wp cron test biasanya juga akan memberi tahu kalau pemicu WP-Cron dimatikan oleh konstanta ini, walaupun bunyi pesannya bisa berbeda antar versi. Kalau tidak punya akses SSH, halaman Tools > Site Health di dashboard WordPress umumnya menampilkan peringatan saat ada scheduled event yang terlambat. Plugin seperti WP Crontrol juga bisa menampilkan daftar event dari dashboard.

Mengganti pemicu dengan cron job server

Ada dua cara umum untuk memanggil WP-Cron dari luar. Cara pertama memanggil wp-cron.php lewat HTTP dengan curl. Cara kedua menjalankan event langsung lewat WP-CLI. Aku cenderung memilih WP-CLI kalau tersedia, karena request-nya tidak lewat web server sama sekali. Jadi ia tidak terhalang WAF, rate limit, HTTP auth, aturan Cloudflare, atau timeout web server. Trade-off-nya, WP-CLI butuh akses shell, dan PHP yang dipakai di CLI belum tentu sama dengan PHP yang dipakai situs lewat web. Contoh entri crontab, yang bisa ditambahkan lewat crontab -e sebagai user pemilik situs atau lewat menu Cron Jobs di control panel:

BASH

# Opsi A: WP-CLI, setiap 5 menit. Ganti path sesuai server (cek dengan: which wp)
*/5 * * * * cd /home/USER/public_html && /usr/local/bin/wp cron event run --due-now >> /home/USER/wp-cron.log 2>&1

# Opsi B: lewat HTTP kalau WP-CLI tidak tersedia
*/5 * * * * curl -fsS -o /dev/null 'https://example.com/wp-cron.php?doing_wp_cron' >> /home/USER/wp-cron.log 2>&1

# Multisite: --due-now hanya berlaku untuk satu site, jadi ulangi per site
*/5 * * * * cd /home/USER/public_html && /usr/local/bin/wp site list --field=url | xargs -I {} /usr/local/bin/wp cron event run --due-now --url={} >> /home/USER/wp-cron.log 2>&1

Beberapa hal yang sering bikin cron job ini diam-diam tidak jalan:

Lingkungan cron punya PATH yang sangat minimal. Perintah wp atau php yang jalan normal di terminal bisa tidak ditemukan oleh cron. Pakai path lengkap. Path di contoh atas hanya ilustrasi, jadi cek dulu di servermu dengan which wp.
Di server dengan banyak versi PHP, termasuk banyak instalasi cPanel, perintah php di CLI bisa menunjuk ke versi yang berbeda dari versi yang dipakai situs. Kalau plugin butuh PHP baru tapi CLI masih versi lama, event bisa gagal dengan fatal error yang hanya terlihat di log cron.
Banyak contoh di internet mengarahkan output ke /dev/null. Itu membuat error ikut tidak terlihat. Untuk awal, simpan output ke file log seperti contoh di atas. Kalau sudah yakin semuanya stabil, baru pertimbangkan untuk dibuang atau dirotasi.
Opsi B tetap melewati jalur HTTP. Kalau situs berada di balik proteksi bot, maintenance mode, atau password direktori, request dari server sendiri bisa ikut terblokir.

Soal interval, 5 menit adalah aturan praktis yang cukup untuk kebanyakan situs. Situs dengan antrean berat, seperti toko online yang mengirim banyak email transaksi, mungkin butuh interval lebih rapat. Situs profil perusahaan yang jarang di-update bisa lebih longgar. Sebagian shared hosting membatasi interval minimum cron job, jadi cek aturan di tempat kamu. Kalau ada tugas yang bisa berjalan lebih lama dari interval cron, pertimbangkan membungkus perintahnya dengan flock -n agar dua proses tidak berjalan bersamaan.

Setelah dipasang, pastikan benar-benar jalan

Cron job yang sudah ditulis belum tentu sudah berjalan. Cara paling sederhana untuk memastikannya adalah menjadwalkan post percobaan beberapa menit ke depan, lalu lihat apakah post itu terbit tepat waktu. Setelah itu jalankan lagi wp cron event list. Event yang tadinya tertinggal seharusnya sudah punya jadwal berikutnya di masa depan. File log cron juga perlu dilihat di hari-hari pertama, karena di sanalah error PHP CLI, path yang salah, atau masalah permission akan muncul. Kalau jadwal masih molor walaupun cron job terlihat terpasang, penyebabnya biasanya ada di eksekusi: timeout, user yang salah, atau perintah yang tidak ditemukan. Cara menelusurinya lebih detail dibahas di How to Verify Your WordPress System Cron Job Is Actually Running. Satu hal lagi: jangan lupa menulis catatan. Siapa pun yang nanti memindahkan situs ke server lain akan membawa wp-config.php beserta konstanta ini, tapi crontab tidak ikut terbawa. Migrasi adalah momen paling umum jadwal WordPress berhenti lagi tanpa ada yang sadar. Jadi, anggap DISABLE_WP_CRON sebagai setengah dari satu perubahan, bukan perubahan yang berdiri sendiri. Begitu baris itu masuk ke wp-config.php, langsung pasang cron job penggantinya, simpan output-nya ke log, dan uji dengan post terjadwal. Kalau menemukan situs yang jadwalnya macet tanpa error, cek konstanta ini lebih dulu. Satu perintah wp config get sering sudah cukup untuk menjawabnya.