DISABLE_WP_CRON = true tidak menutup endpoint wp-cron.php; ini hanya menghentikan WordPress dari menjalankan request loopback-nya sendiri. File tersebut tetap dapat diakses dari web, sehingga siapa pun masih bisa mengaksesnya dan memaksa proses bootstrap WordPress secara penuh.

Titik masuk tersembunyi tersebut dapat membuang-buang CPU, memori, dan PHP workers, terutama pada situs yang sibuk. Jika Anda mengira telah menutup pintunya, Anda belum melakukannya—setidaknya belum sepenuhnya.

Mengapa pengaturan ini sering disalahpahami

Saat WordPress menjalankan tugas terjadwal, ia pertama-tama mencoba melakukan request HTTP cepat ke file wp-cron.php miliknya sendiri. Mengatur DISABLE_WP_CRON ke true memberi tahu core untuk melewati request internal tersebut. Core tidak mengubah konfigurasi web-server, juga tidak menambahkan lapisan autentikasi apa pun ke wp-cron.php. Skrip tersebut tetap menjadi URL publik yang mengembalikan status 200 bahkan jika proses PHP berhenti lebih awal.

Penyerang yang menemukan URL tersebut dapat melakukan ping berulang kali, yang menyebabkan WordPress memuat semua plugin, tema, dan database setiap saat. Pada shared host atau situs dengan PHP workers yang terbatas, satu endpoint tersebut dapat menjadi vektor denial-of-service.

Apa yang sebenarnya perlu dilakukan

Untuk memindahkan pekerjaan terjadwal ke scheduler tingkat sistem (cron, systemd-timer, dll.) dan menutup pintu publik, ikuti lima langkah berikut.

1. Nonaktifkan loopback internal

Tambahkan baris 

define( 'DISABLE_WP_CRON', true );

ke wp-config.php. Ini menghentikan WordPress dari mencoba request HTTP-nya sendiri, tetapi tidak menghentikan panggilan eksternal.

2. Blokir wp-cron.php di web-server

Dengan Nginx, misalnya, masukkan blok location yang mengembalikan 403 Forbidden:

location = /wp-cron.php {
    return 403;
}

Server sekarang menolak request sebelum PHP dimulai, sehingga menghilangkan biaya bootstrap.

3. Tambahkan mu-plugin sebagai jaring pengaman

Buat must-use plugin (diletakkan di wp-content/mu-plugins) yang mencatat setiap request yang mencapai wp-cron.php dan keluar dengan status 403. Ini menangkap request yang entah bagaimana melewati aturan server—mungkin melalui hostname yang berbeda atau aturan edge CDN.

4. Redam panggilan async Action Scheduler

Banyak plugin menggunakan library Action Scheduler, yang dapat memicu request loopback-nya sendiri. Gunakan hook pada action_scheduler_queue_runner dan lakukan return lebih awal untuk request non-CLI, guna mencegah library tersebut mencoba membuka pintunya sendiri.

5. Lepaskan queue runner dari hook WP-Cron

Hapus queue runner default Action Scheduler yang terpasang pada hook cron wp. Ini memastikan antrean hanya berjalan saat Anda memicunya secara eksplisit dari command line.

Menjalankan pekerjaan dengan cara yang benar

Dengan endpoint publik yang telah ditutup, gunakan scheduler sistem untuk memanggil WordPress sekali per menit (atau ritme apa pun yang Anda butuhkan) melalui WP-CLI:

wp cron event run --due-now

Perintah tunggal tersebut memproses event cron core dan antrean Action Scheduler dalam lingkungan yang terkendali, menggunakan proses PHP yang sama dengan yang Anda gunakan untuk tugas CLI lainnya.

Manfaat yang dapat Anda ukur

  • Keamanan – Tidak ada pengguna tanpa autentikasi yang dapat memulai pekerjaan latar belakang yang berat.
  • Performa – PHP workers tetap tersedia untuk pengunjung asli; lonjakan memori akibat hit cron yang nyasar akan hilang.
  • Keandalan – Penjadwalan menjadi proaktif; Anda tahu persis kapan sebuah pekerjaan berjalan karena dijalankan oleh cron sistem, bukan oleh pemuatan halaman pengunjung.

Apa yang perlu diperhatikan setelah perubahan

Jangan mengandalkan kode status HTTP dari wp-cron.php; ia mungkin tetap mengembalikan 200 bahkan saat diblokir oleh PHP. Sebaliknya:

  • Pantau ukuran antrean Action Scheduler. Antrean yang terus bertambah sering kali menandakan adanya jadwal yang terlewat.
  • Periksa log server untuk entri “403” dari blok location wp-cron.php.
  • Amati jumlah proses PHP-FPM atau FastCGI selama trafik puncak untuk memastikan beban kerja telah menurun.

Catatan peringatan

Beberapa administrator membiarkan DISABLE_WP_CRON bernilai false karena mereka mengandalkan situs dengan trafik rendah untuk memicu cron secara alami. Pendekatan di atas menghapus ketergantungan tersebut sepenuhnya, tetapi menambahkan langkah pemeliharaan: Anda harus memastikan scheduler sistem berjalan dengan andal. Jika cron daemon server gagal, pekerjaan terjadwal akan berhenti. Pasangkan pengaturan ini dengan pemantauan layanan cron sistem untuk menghindari kendala tersebut.

Intinya: mengatur DISABLE_WP_CRON ke true hanya menghentikan WordPress dari melakukan ping ke dirinya sendiri; ini tidak menutup endpoint publik wp-cron.php. Blokir file tersebut di web-server, tambahkan fallback mu-plugin, dan arahkan semua pekerjaan terjadwal melalui scheduler sistem via WP-CLI. Melakukan hal ini akan mengamankan situs, mengurangi pekerjaan PHP yang tidak perlu, dan memberi Anda kontrol presisi atas kapan tugas latar belakang dieksekusi.