# Pengganti WP-Cron

Queuety dapat menggantikan sistem WordPress cron bawaan. Saat diaktifkan, pemanggilan `wp_schedule_event()` akan dicegat dan diarahkan melalui penjadwal Queuety alih-alih mekanisme WP-Cron default. Event dirancang untuk diproses oleh worker Queuety, yang menjalankan tugas terlepas dari lalu lintas situs.

> **Batasan saat ini:** bridge membuat jadwal Queuety, tetapi worker tidak memiliki handler untuk job `__queuety_cron_{hook}` yang dihasilkannya, sehingga callback WordPress asli tidak pernah dijalankan. Setiap job gagal, dicoba ulang dengan jeda bertahap, lalu akhirnya dikubur ([#9](https://github.com/inline0/queuety/issues/9)). Jangan aktifkan bridge di situs yang event cron-nya harus berjalan sampai masalah ini diperbaiki.

## Mengaktifkan pengganti

Panggil `Queuety::replace_wp_cron()` lebih awal saat inisialisasi plugin atau tema Anda:

```php
use Queuety\Queuety;

Queuety::replace_wp_cron();
```

Biasanya ini dipanggil di file utama plugin atau pada hook `plugins_loaded`. Ini harus dipanggil saat WordPress dimuat (plugin harus aktif).

## Yang diintersepsi

Bridge cron terhubung ke tiga filter WordPress:

| Fungsi WordPress | Filter yang dipasang hook | Perilaku |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Membuat jadwal Queuety dengan interval yang sama |
| `wp_unschedule_event()` | `pre_unschedule_event` | Menghapus jadwal Queuety yang sesuai |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Mengembalikan data jadwal dari Queuety |

Hanya event **berulang** (yang memiliki properti `schedule` seperti `hourly`, `twicedaily`, `daily`) yang diintersepsi. Event sekali jalan yang dijadwalkan dengan `wp_schedule_single_event()` tidak diintersepsi.

## Cara pemetaan event

Saat plugin memanggil `wp_schedule_event()`, Queuety mencari nama jadwal melalui `wp_get_schedules()`, membuat jadwal Queuety dengan nama handler `__queuety_cron_{hook}`, lalu menyimpan nama hook WordPress asli dan argumennya dalam payload jadwal.

Perilaku yang diharapkan adalah worker Queuety yang memproses job terjadwal memanggil `do_action()` dengan nama hook dan argumen asli, sehingga callback WordPress yang ada berjalan dengan Queuety mengatur waktunya. `CronBridge::process_cron_event()` menerapkan pemanggilan tersebut, tetapi belum ada yang memanggilnya (lihat batasan di atas). Jadwal juga hanya dievaluasi oleh proses `wp queuety work` yang berjalan lama, kira-kira sekali per menit (lihat [Penjadwalan](https://queuety.inline0.dev/id/docs/features/scheduling)).

### Resolusi interval

Bridge mencari nama jadwal melalui `wp_get_schedules()` terlebih dahulu, lalu menggunakan nilai bawaan:

| Nama jadwal | Interval |
|---|---|
| `hourly` | 3,600 detik |
| `twicedaily` | 43,200 detik |
| `daily` | 86,400 detik |
| `weekly` | 604,800 detik |

Interval jadwal khusus yang didaftarkan melalui filter `cron_schedules` didukung selama `wp_get_schedules()` mengembalikannya.

## Memulihkan WP-Cron

Untuk kembali ke sistem WordPress cron bawaan:

```php
Queuety::restore_wp_cron();
```

Ini menghapus hook filter dan memungkinkan WordPress menangani event cron lagi melalui mekanisme bawaannya. Perhatikan bahwa `DISABLE_WP_CRON` ditetapkan sebagai `true` saat bridge dipasang dan tidak dapat dibatalkan saat runtime, jadi Anda mungkin perlu menghapus konstanta tersebut dari `wp-config.php` atau memulai ulang proses.

## Kapan menggunakannya

Pengganti ini paling berguna ketika situs Anda memiliki lalu lintas rendah, ketika Anda membutuhkan waktu yang lebih andal daripada yang dapat diberikan WP-Cron, atau ketika Anda sudah menjalankan worker Queuety dan ingin eksekusi cron berada dalam sistem operasional yang sama. Ini juga membantu ketika observabilitas terpusat penting, karena event cron akan muncul di log dan metrik yang sama dengan pekerjaan antrean lainnya.

## Batasan

Ada beberapa batasan penting. Worker Queuety yang aktif diperlukan; jika tidak, event terjadwal tidak akan pernah berjalan. Hanya jadwal berulang yang diintersepsi; event sekali jalan yang dibuat dengan `wp_schedule_single_event()` tetap berada di luar bridge. `replace_wp_cron()` juga menetapkan `DISABLE_WP_CRON` untuk sisa proses PHP saat ini, sehingga `restore_wp_cron()` menghapus hook tetapi tidak dapat membatalkan konstanta tersebut. Terakhir, bridge hanya berfungsi saat WordPress dimuat, karena bergantung pada filter WordPress dan `do_action()`.

## Contoh: penyiapan lengkap

```php
use Queuety\Queuety;

// In your plugin's main file.
add_action( 'plugins_loaded', function () {
    Queuety::replace_wp_cron();
} );
```

Anda tidak perlu memanggil `Queuety::init()` di sini: plugin Queuety yang aktif membuat koneksinya dari kredensial database WordPress dan menginisialisasi dirinya pada `plugins_loaded`. `replace_wp_cron()` hanya memasang filter, jadi tidak bergantung pada proses tersebut yang sudah berjalan lebih dahulu.

Setelah ini, event berulang yang didaftarkan plugin dengan `wp_schedule_event()` disimpan sebagai jadwal Queuety. Sampai [#9](https://github.com/inline0/queuety/issues/9) diperbaiki, callback-nya tidak berjalan.