Eylem Tetikleyicileri

Queuety::on_action(), normal bir WordPress eylemini kalıcı bir iş akışı başlatma işlemine dönüştürmenizi sağlar.

Böylece arada temiz bir köprü kurulur:

WordPress action -> mapped payload -> durable workflow

İlginç olay zaten WordPress içinde mevcutsa ve maliyetli ya da uzun süren yanıtın eşzamansız gerçekleşmesi gerekiyorsa bu kullanışlıdır.

Örnek: bir gönderi kaydedildiğinde içeriği inceleme

use Queuety\Queuety;

Queuety::on_action(
    'save_post',
    workflow: 'content_review',
    map: static fn ( int $post_id, object $post, bool $update ): array => [
        'post_id' => $post_id,
        'post_type' => $post->post_type,
        'update' => $update,
    ],
    when: static fn ( int $post_id, object $post ): bool => 'post' === $post->post_type,
    idempotency_key: static fn ( int $post_id ): string => "save_post:{$post_id}",
);

Bu örnekte:

• save_post hâlâ orijinal WordPress olayıdır
• map ham kanca bağımsız değişkenlerini düz iş akışı durumuna dönüştürür
• when sıraya alınmadan önce istenmeyen olayları atlar
• idempotency_key yinelenen kanca tetiklemelerinin yinelenen çalıştırmalar başlatmasını önler

Eşzamanlı olarak neler çalışır

Eylem geri çağırma işlevinin kendisi hâlâ geçerli WordPress isteği içinde çalışır.

Bu, şu bölümlerin eşzamanlı olduğu anlamına gelir:

• when
• map
• idempotency_key

Yalnızca dağıtımdan sonra iş akışı adımları eşzamansız çalışır.

Yük kuralları

Eşlenen yükler düz diziler, skalerler ve null içermelidir.

WP_Post gibi ham WordPress nesnelerini doğrudan iş akışı durumuna aktarmayın. Önce bunları map() içinde normalize edin:

Queuety::on_action(
    'save_post',
    workflow: 'content_review',
    map: static fn ( int $post_id, object $post, bool $update ): array => [
        'post_id' => $post_id,
        'post_type' => $post->post_type,
        'post_status' => $post->post_status,
        'update' => $update,
    ],
);

_ ile başlayan anahtarlar reddedilir; çünkü bu adlar dahili iş akışı durumu için ayrılmıştır.

Kabul edilen bağımsız değişkenler

WordPress, bir eylem geri çağırma işlevi kaydedilirken accepted_args sayısı gerektirir.

Queuety varsayılan olarak bunu map, when ve idempotency_key geri çağırma işlevlerinizden çıkarır; bu nedenle yaygın kullanım için ek yapılandırma gerekmez:

Queuety::on_action(
    'save_post',
    workflow: 'content_review',
    map: static fn ( int $post_id, object $post, bool $update ): array => [
        'post_id' => $post_id,
        'update' => $update,
    ],
);

Elle geçersiz kılmanız gerekiyorsa accepted_args değerini açıkça iletin:

Queuety::on_action(
    'comment_post',
    workflow: 'comment_review',
    accepted_args: 2,
);

Satır içi iş akışı oluşturucuları

Kayıtlı bir iş akışı adını veya satır içi bir WorkflowBuilder dağıtabilirsiniz.

Kancaya özgü iş akışı aynı önyükleme dosyasında tanımlandığında satır içi oluşturucular kullanışlıdır:

$review = Queuety::workflow( 'comment_review' )
    ->then( ModerateCommentStep::class )
    ->then( NotifyModeratorStep::class );

Queuety::on_action(
    'comment_post',
    workflow: $review,
    map: static fn ( int $comment_id ): array => [
        'comment_id' => $comment_id,
    ],
    idempotency_key: static fn ( int $comment_id ): string => "comment:{$comment_id}",
);

Ne zaman uygundur

Şu durumlarda eylem tetikleyicilerini kullanın:

• WordPress ilgilendiğiniz olayı zaten yayıyorsa
• yanıtın istek zaman aşımından veya çalışan yeniden başlatmalarından etkilenmemesi gerekiyorsa
• sonraki iş dallanabilir, bekleyebilir veya onay gerektirebilirse
• yinelenen kanca tetiklemeleri için kalıcı idempotensi gerekiyorsa

İş bir WordPress olay sınırına bağlı değilse bunun yerine doğrudan Queuety::dispatch() veya Queuety::workflow() çağrısı kullanın.

Filtreler için değil

Queuety::on_action() bilinçli olarak yalnızca eylemler için tasarlanmıştır.

Filtreler, istek sırasında eşzamanlı çalışan dönüşümlerdir. Genellikle eşzamanlı kalmalıdırlar; çünkü WordPress filtrelenmiş bir değerin hemen döndürülmesini bekler.