تنبه نزاهة المنشئ مشكلات محرّك WordPress ومشغل الصفحات قبل أن تتحوّل إلى مشكلات في المحتوى.

ما الذي يكتشفه؟

عندما تتوقف حالة المحرّك والمحتوى المخزّن عن التوافق.

يمكن أن يتراكم في محتوى WordPress إشارات قديمة من المحرّك، وهيكل كتل مشوّه، أو حالة محرّك مختلطة، أو بيانات وصفية لم تعد تتطابق مع المحتوى المعروض. تفصل نزاهة المنشئ تلك الإشارات قبل أن تقرّر ما إذا كان ينبغي إصلاح أي شيء.

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

تقوم نزاهة المنشئ بفحص المحتوى المخزّن وإشارات المحرّك مباشرةً. تميّز بين الأدلة الإيجابية الخاصة بالمحرّك وبين العلامات التاريخية الأضعف، ثم تصنّف السجل بدلاً من افتراض أن قيمة واحدة من البيانات الوصفية تحدّد المحرّك الفعّال. هذا يجعل نتيجة التشخيص مفيدة قبل عمليات النقل، وتنظيف المحتوى، وسير عمل الترجمة مثل REEID Translate, تغييرات الثيم أو استكشاف أخطاء سلوك المحرّك غير المتوقع.

لماذا تتحقق من نزاهة المحرّك؟

حيث تساعد نزاهة المنشئ.

غالبًا ما تصبح حالات عدم التناسق في المحرّك واضحة فقط عندما يفتح شخص ما صفحة للتحرير، أو يغيّر المحرّكات، أو يجري عملية نقل، أو يترجم المحتوى، أو يحدّث إضافة. اكتشاف الحالة مبكرًا يوفّر لك نقطة انطلاق أوضح.

بالنسبة لمحتوى Gutenberg، تتحقّق نزاهة المنشئ من بنية التعليقات داخل الكتل بدلاً من الاعتماد فقط على قدرة WordPress على عرض الصفحة. يمكنها تحديد علامات الإغلاق اليتيمة، الفواصل غير المتطابقة، الكتل غير المغلقة، JSON سمات الكتل غير الصالحة، وتعليقات كتل WordPress المشوهة التي قد تبدو خلاف ذلك كHTML عادي.

للفحص اليدوي الأعمق لترميز Gutenberg المخزّن، راجع محرّك مصدر كتل Gutenberg.

بالنسبة لـ Elementor وSiteOrigin، تسجّل الإضافة الأدلة الخاصة بالمحرّك بشكل منفصل عن إشارات Gutenberg والمحتوى الكلاسيكي. وهذا مفيد عندما يكون السجل قد عُدّل بواسطة أكثر من نظام على مرّ الزمن، أو عندما تبقى بيانات وصفية قديمة للمحرّك بعد تغيير سير العمل.

الهدف هو التشخيص، وليس التنظيف الجذري. لا تُعامل الحالة المختلطة أو غير المعتادة تلقائيًا على أنها تستحق إعادة الكتابة. تبقى السجلات خارج نطاق قواعد الإصلاح الضيقة متاحة للمراجعة اليدوية بدلًا من أن تُغيّر تلقائيًا.

مدعوم في الإصدار 0.1.0

متحفظ بطبيعته.

يركز الإصدار الأول على الكشف والتشخيص. يتم intentionally تقييد الطفرات التلقائية. ولا يسعى Builder Integrity إلى إعادة بناء واسعة النطاق لـ Gutenberg أو نقل المنشئين.

• تشخيص محدود للموقع من خلال لوحة إدارة WordPress
• تشخيص لكل سجل على حدة
• مسح عبر WP-CLI
• كشف الأخطاء الهيكلية في Gutenberg
• كشف حالة Elementor وSiteOrigin
• كشف المحتوى الكلاسيكي/غير المُقسَّم
• اقتراح إصلاح تم مراجعته لحل مشكلة واحدة محددة لمكوّن مفقود في Gutenberg
• تحقق من مراجعة WordPress قبل إجراء الإصلاح المدعوم
• التحقق بعد الكتابة ومحاولة التراجع في حال الفشل

لا يرسل Builder Integrity محتوى الموقع إلى خدمات خارجية ولا يتضمن أي بيانات عن بعد.

ما لا يفعله الإصدار الأول

الإصدار 0.1.0 لا يسعى إلى إعادة بناء واسعة النطاق لـ Gutenberg، أو تحويل المنشئين تلقائيًا، أو إعادة كتابة المحتوى بشكل جماعي، أو تنظيف البيانات الوصفية المخفية. تبقى معظم التناقضات المكتشفة معلومات تشخيصية ما لم يتمكن المكوّن الإضافي من صياغة اقتراح إصلاح محدد وحاسم.

عند توفر إصلاح مدعوم، يتم مقارنة المحتوى الحالي مع المعاينة التي تمت مراجعتها، والتحقق من مراجعة مطابقة لـ WordPress أو إنشاؤها، ثم كتابة التغيير، وإعادة مسح النتيجة. وإذا فشل التحقق، يحاول Builder Integrity استعادة المحتوى الأصلي من تلك المراجعة.

لمن هو مخصص Builder Integrity؟

Builder Integrity مخصص لمسؤولي WordPress والمطورين والوكالات ومحافظي المواقع الذين يحتاجون إلى فهم كيفية تخزين المحتوى فعليًا قبل تحريره أو نقله أو إصلاحه. توفر تشخيصات المسؤول مسحًا محدودًا للموقع وفحصًا فرديًا لكل سجل، بينما يوفّر WP-CLI نفس سير العمل للتصنيف في عمليات التدقيق التقني والمواقع الكبيرة.