المحرر داخل iframe ليس تفصيل واجهة؛ قد يكشف إضافات تعتمد على window أو document بطريقة خاطئة.

نُشر في 6 أغسطس 2026 · WordPress 7.1 / Iframed Editor / Plugin Compatibility

نشر فريق WordPress Field Guide لإصدار 7.1، ومن أبرز Dev Notes أن post editor أصبح دائمًا داخل iframe. عمليًا، أي إضافة أو كود مخصص يتعامل مع المحرر عبر global document أو window قد يحتاج تعديلًا أو اختبارًا قبل تحديث موقع حي.

أين يظهر التعارض؟

الإضافات التي تضيف controls داخل المحرر أو تعتمد على DOM مباشر قد تفشل إذا افترضت أن canvas موجود داخل نفس document الرئيسي. Dev Note ينبه المطورين لاستخدام ownerDocument وdefaultView من العنصر داخل iframe بدل global document/window عند الحاجة.

من زاوية الاستضافة، التعارض قد لا يظهر للزائر، لكنه يعطل فريق المحتوى: بلوك لا يحفظ، زر لا يعمل، CSS لا يظهر داخل المحرر، أو script يسبب أخطاء في console.

خطة اختبار قصيرة

ابدأ بأكثر إضافات المحرر حساسية: page builder، blocks، SEO fields، forms، custom fields، وإضافات الترجمة. افتح صفحات موجودة وصفحات جديدة على staging، ثم اختبر إدراج بلوك، حفظ، preview، وإعادة فتح الصفحة.

سجل أخطاء console وPHP logs بعد كل سيناريو. إذا ظهر تعارض، لا تحدث الإنتاج حتى تعرف هل يوجد تحديث للإضافة أو workaround محدود.

Checklist قبل update

• راجع Field Guide وDev Notes المرتبطة بالمحرر.
• اختبر page builders والبلوكات المخصصة على staging.
• افحص console errors أثناء edit وsave وpreview.
• راجع CSS داخل المحرر وليس الواجهة فقط.
• اختبر SEO/meta/custom fields التي تظهر داخل edit screen.
• اكتب قرار go/no-go لكل موقع مهم.

أين تدخل ok4host؟

ok4host يتعامل مع تحديثات WordPress كعملية QA: staging، قائمة إضافات حساسة، سجلات أخطاء، وخطة تحديث تدريجية بدل الضغط على تحديث جماعي.

أسئلة شائعة

هل المشكلة أمنية مباشرة؟ ليست بالضرورة، لكنها قد تعطل التحرير والتشغيل اليومي.

هل كل الإضافات ستفشل؟ لا، لكن الإضافات التي تتعامل مع محرر البلوكات تحتاج اختبارًا واضحًا.

ما أول سيناريو؟ تعديل صفحة مهمة وحفظها ثم معاينة النتيجة.

المصادر

• Make WordPress Core: WordPress 7.1 Field Guide and dev notes.
• Make WordPress Core: WordPress 7.1 schedule.
• WordPress.org Releases.