الاستخدام المستقل

حُزمت Queuety كإضافة WordPress، لكن معظم بيئة التشغيل لا تحتاج فعليًا إلى طلب WordPress نشط.

تعمل قائمة الانتظار ومحرك سير العمل وآلات الحالات والإشارات والآثار والتجميع والجدولة والتسجيل والمقاييس وإدارة الموارد جميعها على جداول MySQL نفسها. إذا تمكنت عملية أخرى من PHP من فتح قاعدة البيانات نفسها، فيمكنها استخدام تلك النواة مباشرة.

هذا هو حد الاستخدام المستقل في Queuety. يمكن استخدام محرك التنسيق المدعوم بقاعدة البيانات خارج WordPress. أما جسور WordPress فتبقى ضمن WordPress.

ما يعمل خارج WordPress

باستخدام Connection مباشر، يمكن لعملية مستقلة تهيئة Queuety واستخدام أساليب الواجهة نفسها التي تستخدمها الإضافة لبيئة التشغيل الأساسية:

• إرسال الوظائف
• تشغيل العمال ومجموعات العمال
• إنشاء تدفقات العمل وإرسالها
• إرسال الإشارات وطلبات الموافقة ومدخلات سير العمل
• إنشاء آلات الحالات وإرسالها
• فحص حالة سير العمل والآلة
• تخزين الآثار وقراءتها
• تشغيل التجميع والتسلسل والجداول المتكررة
• الاستعلام عن السجلات والمقاييس وقوائم الانتظار وحالة بيئة التشغيل

وهذا يعني أن بإمكان منتج خارجي التعامل مع حالة التنسيق نفسها دون تشغيل WordPress أولًا، ما دام يستخدم قاعدة البيانات وأسماء الجداول نفسها.

تُعد مجموعات العمال الاستثناء الوحيد حاليًا: إذ يقرأ Queuety::run_worker_pool() وQueuety::run_auto_scaling_worker_pool() ثوابت WordPress وDB_HOST وDB_NAME وDB_USER وDB_PASSWORD بدلًا من الاتصال المُهيأ، لذا يجب أن تعرّف العملية المستقلة تلك الثوابت قبل بدء المجموعة (#5).

ما يظل داخل WordPress

لا تزال طبقة الجسور الخاصة بـWordPress تعتمد على تحميل WordPress.

ويشمل ذلك:

• تهيئة الإضافة وسلوك تنشيطها في queuety.php
• Queuety::on_action()، الذي يتطلب add_action()
• Queuety::replace_wp_cron() وQueuety::restore_wp_cron()، اللذين يعتمدان على عوامل التصفية وdo_action() الخاصة بـWordPress cron
• مسار تسجيل الأوامر الفعلي لـwp queuety ...، الذي يعتمد على تحميل WP-CLI لـWordPress

تلك المكونات محولات حول بيئة التشغيل الأساسية، وليست بيئة التشغيل نفسها.

التهيئة

المسار المستقل بسيط عمدًا. افتح Connection مدعومًا بقاعدة بيانات، وهيّئ الواجهة، وتأكد من وجود المخطط.

use Queuety\Connection;
use Queuety\Queuety;

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
);

Queuety::init( $conn );
Queuety::ensure_schema();

بعد ذلك، تصبح واجهة بيئة التشغيل العادية API متاحة:

Queuety::dispatch( 'send_email', [ 'to' => 'user@example.com' ] );

$workflow_id = Queuety::workflow( 'report' )
    ->then( FetchReportData::class )
    ->then( RenderReport::class )
    ->dispatch( [ 'report_id' => 42 ] );

$machine_id = Queuety::machine( 'agent_session' )
    ->state( 'awaiting_input' )
    ->on( 'message', 'planning' )
    ->state( 'planning' )
    ->action( PlanSessionAction::class )
    ->dispatch();

تسمية الجداول

لا يتطلب الاستخدام المستقل أسماء جداول WordPress تحديدًا؛ بل يحتاج فقط إلى استراتيجية ثابتة للبادئات.

إذا وجّهت Queuety إلى قاعدة بيانات WordPress، فاستخدم البادئة نفسها التي تستخدمها الإضافة هناك. وإذا استخدمت Queuety في قاعدة بيانات منفصلة، فيمكن أن تكون بادئة الاتصال كما يتوقع التطبيق المضيف. ويظل الجزء الخاص بـQueuety من اسم الجدول خاضعًا للتحكم عبر QUEUETY_TABLE_PREFIX والتجاوزات لكل جدول.

يمكن لبيئات التشغيل المضمنة التي تشترك في قاعدة بيانات واحدة تعيين هذا الجزء الخاص بـQueuety لكل اتصال:

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
    table_prefix: 'themequeue_',
);

وهذا يُبقي بادئة قاعدة بيانات WordPress كما هي، ويحل أسماء الجداول مثل queuety_jobs إلى wp_themequeue_jobs.

التصور الذهني

يمكن فهم هذا الفصل ببساطة على النحو التالي:

• نواة Queuety = قائمة الانتظار والعمال وتدفقات العمل وآلات الحالات والإشارات والآثار وبيانات بيئة التشغيل الوصفية
• محول WordPress = تهيئة الإضافة وجسور الخطافات واستبدال WP-Cron وتسجيل WP-CLI

وهذا يُبقي محرك تنسيق واحدًا، مع ترك تكامل الأحداث والطلبات الخاص بـWordPress في موضعه المناسب.