# WP-Cron Değişimi

Queuety, yerleşik WordPress cron sisteminin yerini alabilir. Etkinleştirildiğinde `wp_schedule_event()` çağrıları yakalanır ve varsayılan WP-Cron mekanizması yerine Queuety zamanlayıcısına yönlendirilir. Olaylar, site trafiğinden bağımsız yürütme sağlayan Queuety çalışanı tarafından işlenmek üzere tasarlanmıştır.

> **Mevcut sınırlama:** köprü Queuety zamanlamalarını oluşturuyor, ancak çalışan bu zamanlamaların oluşturduğu `__queuety_cron_{hook}` işleri için bir işleyiciye sahip olmadığından özgün WordPress geri çağrıları hiçbir zaman çalışmıyor. Her iş başarısız oluyor, yeniden deneme gecikmesiyle tekrar deneniyor ve sonunda kuyruğun en arkasına atılıyor ([#9](https://github.com/inline0/queuety/issues/9)). Bu sorun giderilene kadar cron olaylarının çalışması gereken sitelerde köprüyü etkinleştirmeyin.

## Değişimi etkinleştirme

Eklentinizi veya temanızı başlatırken `Queuety::replace_wp_cron()` çağrısını erken yapın:

```php
use Queuety\Queuety;

Queuety::replace_wp_cron();
```

Bu genellikle eklentinizin ana dosyasında veya bir `plugins_loaded` kancasında çağrılır. WordPress yüklenmişken çağrılmalıdır (eklenti etkin olmalıdır).

## Neleri yakalar

cron köprüsü, üç WordPress filtresine bağlanır:

| WordPress işlevi | Bağlanan filtre | Davranış |
|---|---|---|
| `wp_schedule_event()` | `pre_schedule_event` | Aynı aralıkla bir Queuety zamanlaması oluşturur |
| `wp_unschedule_event()` | `pre_unschedule_event` | İlgili Queuety zamanlamasını kaldırır |
| `wp_get_scheduled_event()` | `pre_get_scheduled_event` | Zamanlama verilerini Queuety kaynağından döndürür |

Yalnızca `hourly`, `twicedaily`, `daily` gibi bir `schedule` özelliği olan **yinelenen** olaylar yakalanır. `wp_schedule_single_event()` ile zamanlanan tek seferlik olaylar yakalanmaz.

## Olaylar nasıl eşlenir

Bir eklenti `wp_schedule_event()` çağırdığında Queuety, zamanlama adını `wp_get_schedules()` üzerinden çözümler, işleyici adı `__queuety_cron_{hook}` olan bir Queuety zamanlaması oluşturur ve özgün WordPress kanca adını ve bağımsız değişkenlerini zamanlama yükünde saklar.

Amaçlanan davranış, bu zamanlanmış işi işleyen Queuety çalışanının özgün kanca adı ve bağımsız değişkenleriyle `do_action()` çağırması ve mevcut WordPress geri çağrılarının zamanlamayı Queuety belirlerken çalışmasıdır. `CronBridge::process_cron_event()` bu çağrıyı uygular, ancak henüz hiçbir şey onu çağırmıyor (yukarıdaki sınırlamaya bakın). Zamanlamalar yalnızca uzun süre çalışan `wp queuety work` süreci tarafından yaklaşık dakikada bir değerlendirilir (bkz. [Zamanlama](https://queuety.inline0.dev/tr/docs/features/scheduling)).

### Aralık çözümleme

Köprü, önce `wp_get_schedules()` üzerinden zamanlama adlarını çözümler, ardından yerleşik varsayılanlara başvurur:

| Zamanlama adı | Aralık |
|---|---|
| `hourly` | 3,600 saniye |
| `twicedaily` | 43,200 saniye |
| `daily` | 86,400 saniye |
| `weekly` | 604,800 saniye |

`cron_schedules` filtresiyle kaydedilen özel zamanlama aralıkları, `wp_get_schedules()` bunları döndürdüğü sürece desteklenir.

## WP-Cron'yi geri yükleme

Varsayılan WordPress cron sistemine dönmek için:

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

Bu işlem filtre kancalarını kaldırır ve WordPress'ın cron olaylarını yeniden yerleşik mekanizmasıyla işlemesini sağlar. Köprü kurulduğunda `DISABLE_WP_CRON`, `true` olarak tanımlanır ve çalışma zamanında tanımı kaldırılamaz. Bu nedenle bu sabiti `wp-config.php` dosyasından kaldırmanız veya süreci yeniden başlatmanız gerekebilir.

## Ne zaman kullanılır?

Değişim, en çok sitenizin trafiği düşük olduğunda, WP-Cron'ın sağlayabileceğinden daha güvenilir bir zamanlama gerektiğinde veya zaten Queuety çalışanları çalıştırıp cron yürütmesinin aynı operasyonel sistemde olmasını istediğinizde yararlıdır. Merkezi gözlemlenebilirlik gerektiğinde de yardımcı olur; böylece cron olayları diğer kuyruk işlerinizle aynı günlüklerde ve metriklerde görünür.

## Sınırlamalar

Birkaç önemli kısıtlama vardır. Zamanlanmış olayların çalışması için etkin bir Queuety çalışanı gerekir; aksi halde bu olaylar hiç çalışmaz. Yalnızca yinelenen zamanlamalar yakalanır; `wp_schedule_single_event()` ile oluşturulan tek seferlik olaylar köprünün dışında kalır. `replace_wp_cron()` ayrıca mevcut PHP sürecinin geri kalanı için `DISABLE_WP_CRON` tanımlar. Bu nedenle `restore_wp_cron()` kancaları kaldırsa da sabitin tanımını kaldıramaz. Son olarak köprü yalnızca WordPress yüklüyken çalışır; çünkü WordPress filtrelerine ve `do_action()` öğesine bağlıdır.

## Örnek: tam kurulum

```php
use Queuety\Queuety;

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

Burada `Queuety::init()` çağrısı yapmanız gerekmez: etkin Queuety eklentisi bağlantısını WordPress veritabanı kimlik bilgilerinden oluşturur ve `plugins_loaded` üzerinde kendini başlatır. `replace_wp_cron()` yalnızca filtreleri kurduğundan bu işlemin önce yapılmasına bağlı değildir.

Bundan sonra eklentilerin `wp_schedule_event()` ile kaydettiği yinelenen olaylar Queuety zamanlamaları olarak saklanır. [#9](https://github.com/inline0/queuety/issues/9) düzeltilene kadar geri çağrıları çalışmaz.