ميزات جديدة في ووردبريس وتأثيرات ملموسة للمطورين

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

يواصل WordPress 6.9.x (وبشكل أكثر تحديدًا 6.9.4، المستقر في أبريل 2026) اتجاهًا واضحًا على الجانب الأساسي: المزيد من اتساق واجهة برمجة التطبيقات، والمزيد من تعزيز الأمان، والتطورات في محرر الكتل (Gutenberg) التي تؤثر في النهاية على قوالبك، ورموزك المختصرة التاريخية، وعمليات تكامل منشئ الصفحات.

ما التغييرات

التغيير "المهم" بالنسبة لـ المطورين لا يمثل الإصدار 6.9.x واجهة برمجة تطبيقات سحرية واحدة. بل هو مجموعة من النقاط التي، مجتمعة، تغير طريقة تقديم الميزات: تحسين توحيد الأصول (البرامج النصية/الأنماط)، وتعزيز أمان المدخلات/المخرجات (التنظيف/الهروب)، والمواءمة التدريجية للسمات الكلاسيكية مع قيود تحرير الموقع (FSE).

على وجه التحديد، لقد رأيت ثلاثة مجالات تتعطل في الإنتاج على مواقع 6.9.x: البرامج النصية سيئة التعريف (تحميل سيئ، تبعيات مفقودة)، نقاط نهاية REST المتساهلة للغاية (القدرات/nonce)، و"المقتطفات" الموروثة من البرامج التعليمية القديمة التي تستخدم الخطافات في الوقت الخطأ.

الأصول (JS/CSS): أصبحت التوقعات المتعلقة بقائمة الانتظار (التبعيات، استراتيجية التحميل، الإصدارات) أكثر صرامة. وتتحول مشكلات "يعمل بدون تبعيات" إلى أخطاء متقطعة، خاصةً مع التخزين المؤقت/الدمج/التصغير.
واجهة برمجة تطبيقات REST / الأمان: مزيد من الاهتمام رد الاتصال الخاص بالصلاحيات، والأرقام العشوائية، وفحوصات السعة. المواقع التي تضم محررين متعددين (مؤلفين، ومساهمين) هي أول من يُفاجأ.
القوالب والوحدات: يتجه النظام البيئي بشكل متزايد نحو أنماط متوافقة مع FSE. لا تزال السمات الكلاسيكية مدعومة، لكن عمليات التكامل "القديمة" (خيارات السمات، رموز التخطيط المختصرة) تتطلب خطة.

لتتبع التغييرات في السلوك، فإن أفضل مصادرك هي ملاحظات المطورين الأساسية وتذاكر الدعم:

ملاحظة منهجية: لن أدّعي أن الإصدار الفرعي ".4" يُحدث تغييرًا جذريًا. عمليًا، تنشأ المشاكل غالبًا من تراكم التغييرات (6.7 ← 6.8 ← 6.9)، ومن استخدام إضافة/قالب يعتمد على افتراضات قديمة. يهدف تحليل الإصدار "6.9.4" إلى تزويدكم بنظرة عامة شاملة وقابلة للاستخدام. maintenant، مع PHP 8.1+.

ملخص سريع

يجب أن يكون الكود الخاص بك "صارمًا" عند إضافة العنصر إلى قائمة الانتظار. : الاعتمادات الصريحة، والتحميل المشروط، وعدم وجود نصوص برمجية مُضمنة بشكل مباشر في التذييل.
REST: permission_callback + nonces لم تعد "اختيارية" إذا قمت بعرض الإجراءات (حتى الداخلية منها).
خطافات ذات توقيت سيئ (init vs wp_loaded vs enqueue) تصبح أخطاء مرئية مع ذاكرة التخزين المؤقت ومحرر الكتل وبعض أدوات البناء.
مواضيع كلاسيكية: لا تزال هذه الأساليب قابلة للتطبيق، ولكنك تستفيد من اعتماد أنماط متوافقة مع الكتل (القوالب، والأنماط، والاختلافات).
Divi 5 / Elementor / Avada: معظم المشاكل تأتي من الأصول والشروط (لا يتم تحميلها في كل مكان)، أكثر من كونها ناتجة عن لغة HTML.
يلزم اتخاذ إجراء فوري : تدقيق سريع لأصولك + نقاط نهاية REST + مقتطفات من "الدروس القديمة".

قبل/بعد في الكود

سأتناول حالة حقيقية أقوم باستكشاف أخطائها وإصلاحها في كثير من الأحيان: إضافة (أو ملف functions.php) تقوم بحقن JS/CSS "كما كان من قبل"، ثم ينتهي الأمر بتعارضات (jQuery غير محمل في الوقت المناسب، وتحميل نصوص البناء بعد ذلك، والتصغير الذي يعيد ترتيب كل شيء).

الحالة رقم 1: عملية إضافة الأصول "فضفاضة" للغاية (مشاكل في ذاكرة التخزين المؤقت والمنشئين)

قبل (نمط معاكس متكرر)

<?php
// Mauvais exemple : injection directe, pas de dépendances, pas de version, pas de condition.
add_action('wp_footer', function () {
    ?>
    <script>
    // Code inline difficile à déboguer, souvent cassé par la minification
    jQuery(function($){
        $('.cta').on('click', function(){ alert('ok'); });
    });
    </script>
    <?php
});

// Mauvais exemple : style chargé partout, même dans l'admin et le builder
add_action('wp_enqueue_scripts', function () {
    wp_enqueue_style('mon-style', get_stylesheet_directory_uri() . '/assets/style.css');
});

ما يحدث في الخلفية: يفترض برنامجك النصي وجود مكتبة jQuery، لكنك لم تُحدد تبعيتها. مع بعض أنواع التخزين المؤقت، يتغير الترتيب. في Divi/Elementor، يقوم المحرر بتحميل حزمه الخاصة، مما قد يؤخر تنفيذ بعض البرامج النصية. والنتيجة: خلل متقطع، يستحيل إعادة إنتاجه عند الطلب.

بعد (نهج قوي لـ WordPress 6.9.4+)

<?php
/**
 * Enqueue propre : dépendances, versioning, conditionnel, et inline script attaché au handle.
 * Compatible WordPress 6.9.4+ / PHP 8.1+.
 */
add_action('wp_enqueue_scripts', function () {

    // Exemple de condition : ne chargez pas sur tout le site si ce n'est utile que sur une page.
    if ( ! is_page('contact') ) {
        return;
    }

    $theme_version = wp_get_theme()->get('Version');

    // CSS versionné
    wp_enqueue_style(
        'mon-style',
        get_stylesheet_directory_uri() . '/assets/style.css',
        array(),
        $theme_version
    );

    // JS externe versionné + dépendances explicites
    wp_enqueue_script(
        'mon-cta',
        get_stylesheet_directory_uri() . '/assets/cta.js',
        array('jquery'),
        $theme_version,
        array(
            'in_footer' => true,
        )
    );

    // Inline script attaché au bon handle (évite l'injection "au hasard" dans le footer)
    $inline = <<<JS
jQuery(function($){
    $('.cta').on('click', function(){
        alert('ok');
    });
});
JS;

    wp_add_inline_script('mon-cta', $inline, 'after');
}, 20);

الاختلافات الرئيسية:

التبعيات الصريحة لا مزيد من عبارة "إنها تعمل طالما أن...".
الإصدارات تم إبطال ذاكرة التخزين المؤقت بشكل صحيح بعد التثبيت القالب/الإضافة محدّث.
الشرط : الأداء + تقليل التعارضات مع حزم البناء.
خط متصل بمقبض : ترتيب مضمون وسهولة في تصحيح الأخطاء.

الحالة رقم 2: نقطة نهاية REST متساهلة للغاية (مما يشكل في النهاية خطراً حقيقياً)

خطأ شائع آخر: استخدام نقطة نهاية REST "داخلية" لتنفيذ إجراء ما (مثل مسح ذاكرة التخزين المؤقت، أو إعادة المزامنة، أو الاستيراد). تفتقر العديد من الأجزاء البرمجية المهملة إلى دالة رد نداء قوية للأذونات. هذا ليس مجرد "ممارسة جيدة"، بل هو ثغرة أمنية.

قبل (خطير)

<?php
add_action('rest_api_init', function () {
    register_rest_route('monplugin/v1', '/purge', array(
        'methods'  => 'POST',
        'callback' => function () {
            // Dangereux : aucune permission, aucune vérification
            do_action('monplugin_purge_cache');
            return array('ok' => true);
        },
    ));
});

بعد (الأذونات + رقم عشوائي + استجابة موحدة)

<?php
add_action('rest_api_init', function () {

    register_rest_route('monplugin/v1', '/purge', array(
        'methods'             => 'POST',
        'callback'            => 'monplugin_rest_purge_cache',
        'permission_callback' => function (WP_REST_Request $request) {

            // 1) Capacité : adaptez selon votre besoin (manage_options est volontairement strict).
            if ( ! current_user_can('manage_options') ) {
                return false;
            }

            // 2) Nonce REST : attendu via header X-WP-Nonce côté JS.
            $nonce = $request->get_header('X-WP-Nonce');
            if ( ! $nonce || ! wp_verify_nonce($nonce, 'wp_rest') ) {
                return false;
            }

            return true;
        },
    ));
});

/**
 * Callback REST.
 */
function monplugin_rest_purge_cache(WP_REST_Request $request): WP_REST_Response {
    do_action('monplugin_purge_cache');

    return new WP_REST_Response(
        array(
            'ok'      => true,
            'message' => 'Cache purgé.',
        ),
        200
    );
}

الاختلافات الرئيسية:

رد الاتصال الخاص بالصلاحيات إنها ليست للزينة: إنها وسيلة حمايتك.
Nonce wp_rest : ضروري إذا كنت تقوم باستدعاء نقطة النهاية من المسؤول (أو شاشة محمية).
WP_REST_Response أكثر استقرارًا لعملاء جافا سكريبت (رمز الحالة، البنية).

تأثير ملموس

للمدونين (المتوسطين)

ستشعر بذلك بشكل خاص من خلال إضافاتك: تحديث WordPress 6.9.x + إضافة تقوم بتحميل البرامج النصية في كل مكان يمكن أن يبطئ المحرر، أو يعطل زرًا، أو يتسبب في ظهور أخطاء في وحدة التحكم فقط في صفحات معينة.

الأعراض النموذجية "يعمل على الصفحة أ، وليس على الصفحة ب". السبب الشائع: غياب الشروط، وعدم تعريف التبعيات، والتخزين المؤقت المفرط.
عرض آخر يتم تحميل أداة البناء، لكن بعض الوحدات النمطية فارغة. غالباً ما يكون هذا تعارضاً في جافا سكريبت (ترتيب التحميل، أو وجود نسخة مكررة من مكتبة).

للمطورين

يتجه عملك نحو الموثوقية: حدد، اعزل، اختبر. لا يزال بإمكانك استخدام مقتطفات "سريعة"، ولكن يجب وضعها في المكان الصحيح وربطها بالخطاف المناسب، مع وجود تبعيات نظيفة. كثيراً ما رأيت أخطاءً ناتجة عن نسخ الكود إلى الملف الخاطئ (ملف functions.php الخاص بالقالب الرئيسي بدلاً من ملف functions.php الخاص بالقالب الفرعي، أو إلى إضافة مقتطفات بدون نظام تحكم في الإصدار).

الإضافات الموجودة : أولئك الذين يقومون بحقن جافا سكريبت بشكل مضمن، أو الذين يكشفون نقاط نهاية REST بدون إذن، معرضون للخطر (الأخطاء + الأمن).
المواضيع الكلاسيكية إذا قمت بمزج أكواد التخطيط المختصرة + أداة البناء + جافا سكريبت المخصصة، يصبح ترتيب التحميل أمراً بالغ الأهمية.
سمات FSE (سمات الكتل) : ستحصل على الاتساق إذا قمت بنقل جزء من التصميم إلى أنماط/كتل، ولكن يجب أن تتعلم "التفكير في القوالب" بدلاً من "الخيارات".

تأثير محدد على Divi 5 و Elementor و Avada

تشترك الثلاثة في شيء واحد: فهي تقوم بتحميل الكثير من الأصول، وأحيانًا بشكل مشروط، ولديها أوضاع تحرير/معاينة لا تتصرف مثل الواجهة الأمامية.

ديفي 5 احذر من البرامج النصية التي يتم تحميلها فقط على is_admin() (اختبار غير مناسب)، لأن Divi يحتوي على شاشات هجينة. من الأفضل اختبار إجراءات محددة (مثل إضافة عنصر إلى قائمة الانتظار). wp_enqueue_scripts (بالإضافة إلى الكشف عن السياق إذا لزم الأمر) وتجنب حقن جافا سكريبت عبر wp_footer بدون مقبض.
Elementor إذا كنت تقوم بتطوير أداة مخصصة، فقم بتحميل مواردك فقط عند وجود الأداة (أو على الأقل في صفحات Elementor). غالبًا ما تنشأ حالات التعارض من نص برمجي عام يتم تحميله عبر الموقع بأكمله.
فتح يحتوي برنامج Fusion Builder على نظامه الخاص من البرامج النصية. وينطبق عليه نفس المبدأ: تحديد التبعيات بشكل صريح، والتحكم في الإصدارات، وتجنب تحميل المكتبات مرتين.

مخطط تشخيصي (عندما "يعمل ثم يتعطل")

عرض	السبب المحتمل	التحقق	الحلول
زر جافا سكريبت غير نشط في بعض الصفحات	تم تحميل البرنامج النصي قبل التبعية (jQuery/Bundle) أو لم يتم تحميله على الإطلاق	افتح وحدة تحكم المتصفح + علامة تبويب الشبكة، وتحقق من ترتيب الملفات ووجودها.	wp_enqueue_script مع التبعيات + الشرط + wp_add_inline_script
وظيفة REST "ممنوعة" بعد التحديث	إذن_الاستدعاء_صارم_جدا أو قيمة_الرقم_التسلسلي_مفقودة	افحص الطلب (الرأس X-WP-Nonce)، وتحقق من current_user_can	أضف قيمة عشوائية wp_rest + السعة المناسبة + الرسائلخطأ
محرر Elementor/Divi بطيء	الأصول العالمية ضخمة للغاية وموزعة في كل مكان.	في أداة تحليل الأداء (علامة تبويب الأداء)، قم بتعطيل المكون الإضافي المعني مؤقتًا.	التحميل فقط على الصفحات/السياقات الضرورية
مقطع "عشوائي" يتعطل بعد التحديث	خطاف غير مناسب (init مقابل wp_loaded)، تم استدعاء الدالة مبكرًا جدًا	سجل تصحيح الأخطاء WP_DEBUG_LOG + تتبع المكدس، تحقق من ترتيب التنفيذ	حرك الخطاف، واضبط الأولوية، وتحقق من وجود الوظيفة.
تغييرات غير مرئية رغم النشر	ذاكرة التخزين المؤقت (الملحق/شبكة توصيل المحتوى/المتصفح) + إصدار الأصول الثابتة	مسح ذاكرة التخزين المؤقت + التحقق من إصدار سلسلة الاستعلام	الإصدار عبر wp_get_theme()->get('Version') أو وقت التحديث

المخاطر، والتوافقات، ونقاط اليقظة

ما الجديد (الاتجاه 6.7 → 6.9.4)

متطلبات النظافة فيما يتعلق بالأصول: فإن WordPress والنظام البيئي (المنشئون، وذاكرة التخزين المؤقت، والتحسين) أقل تسامحًا مع البرامج النصية "المُدخلة" خارج خط الأنابيب.
التصلب الضمني ما كان يحدث "بالصدفة" أصبح يحدث بشكل أقل تكراراً.
مناطق استراحة إضافية (المكونات الإضافية، الكتل، واجهة المستخدم): لذلك هناك خطر أكبر إذا كانت أذوناتك غير واضحة.

ما الذي يتغير (دون الإعلان عنه على أنه "تغيير جذري")

أمر التنفيذ قد تتحول الخطافات المختارة بشكل سيئ إلى أخطاء برمجية. ومن الأمثلة الكلاسيكية على ذلك تسجيل البرامج النصية مبكراً جداً (التهيئة) وإضافتها إلى قائمة الانتظار متأخراً جداً، أو العكس.
التخزين المؤقت والتصغير : مع HTTP/2/3 + المكونات الإضافية للتجميع، فإن الافتراضات المتعلقة بترتيب البرامج النصية تكون هشة.
المحررين لم يعد المكتب الخلفي "مكانًا منفصلاً". أصبح محرر الموقع وأدوات الإنشاء تشبه التطبيقات، لذا ستتفاعل البرامج النصية العامة الخاصة بك معها.

ما الذي قد يتعطل؟

الكود من درس تعليمي قديم : مقتطفات 2017-2021 التي تقوم بحقن جافا سكريبت مضمنة، أو تستخدم خطافات تقريبية، أو تقوم بـ REST بدون إذن.
لغة PHP قديمة جدًا إذا كان مزود خدمة الاستضافة لديك بطيئًا، فستواجه أخطاءً جسيمة (مثل أخطاء في كتابة الخصائص، والمطابقة، وما إلى ذلك). يُنصح بتشغيل ووردبريس 6.9.4 مع PHP 8.1 أو أحدث. تحقق من بيئة الإنتاج لديك.
مقتطفات في القالب الرئيسي تحديث القالب = فقدان الكود = "لقد اختفى". هذه "حادثة" شائعة جدًا.

الجدول الزمني للاستهلاك (عملي)

نادراً ما يتم إيقاف دعم الكود الأساسي فجأةً دون فترة سماح. يكمن الخطر الحقيقي في اعتماد الكود على سلوك غير مضمون (الترتيب، التبعيات الضمنية) مما قد يؤدي إلى تعطله في النهاية. لذا، تعامل مع هذا الأمر على أنه إيقاف دعم افتراضي.

توصيتي لعام 2026: ضع في اعتبارك أي كود يتضمن أصولًا ثابتة (مثل صدى الصوت). ) comme “à migrer”, même s’il n’y a pas de notice officielle.

كيفية الترحيل

الخطوة 1: تدقيق سريع (30 دقيقة، فعال من حيث التكلفة للغاية)

ابحث في الإضافات/القوالب الخاصة بك: wp_footer + <script>, echo '<script', admin-ajax.php, register_rest_route بدون رد اتصال خاص بالإذن.
قم بإدراج الصفحات التي تحتاج فيها أصولك فعليًا (غالبًا ما تشكل 10-20% من الموقع).
تفعيل تسجيل الأحداث في بيئة تجريبية: WP_DEBUG, WP_DEBUG_LOGتجنب القيام بذلك في بيئة الإنتاج دون إشراف (خطر تسريب المعلومات).

<?php
// wp-config.php (staging uniquement)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false); // Évite d'afficher les erreurs aux visiteurs

الخطوة الثانية: نقل الأصول إلى المقابض (وإيقاف الحقن العشوائي)

استراتيجيتان موثوقتان للتحكم في الإصدارات: التحكم في إصدارات القوالب/الإضافات (بسيط) أو filemtime() (صحيح، ولكن احذر من أنظمة الملفات الموزعة).

<?php
add_action('wp_enqueue_scripts', function () {

    $file = get_stylesheet_directory() . '/assets/cta.js';
    $url  = get_stylesheet_directory_uri() . '/assets/cta.js';

    // Attention : filemtime() peut être coûteux sur certains hébergements réseau.
    $ver = file_exists($file) ? (string) filemtime($file) : wp_get_theme()->get('Version');

    wp_enqueue_script(
        'mon-cta',
        $url,
        array('jquery'),
        $ver,
        array('in_footer' => true)
    );
});

الخطوة 3: تأمين REST (الصلاحيات + nonce) وتوثيقه

إذا تم استدعاء نقطة النهاية الخاصة بك من واجهة المستخدم (من قِبل الزوار)، فإن قيمة "wp_rest" العشوائية ليست كافية دائمًا (وهي ليست آلية مصادقة عامة). في هذه الحالة، استخدم رموز التطبيق أو التوقيعات، أو قيّد الإجراءات بشكل صارم. لا تسمح بالوصول المجهول إلى نقطة نهاية "الحذف/الاستيراد".

الخطوة الرابعة: التحقق من الخطافات والأولويات (مصدر الأخطاء "الوهمية")

أخطاء واقعية أراها:

استخدم الخطاف الخاطئ : الوقوف في طابور init بدلا من wp_enqueue_scripts.
تضارب الأولويات : يتم تشغيل الكود الخاص بك قبل المُنشئ/ذاكرة التخزين المؤقت، ثم يتم استبداله.
يتم استدعاء الدالة قبل التحميل أنت تستخدم وظيفة من وظائف الملحق بينما لم يقم الملحق بعد بتهيئة فئاته.

<?php
// Exemple : si vous dépendez d'un plugin, évitez d'appeler ses classes trop tôt.
add_action('plugins_loaded', function () {

    if ( ! class_exists('MaLib\Client') ) {
        // Le plugin dépendant n'est pas chargé ou pas actif
        return;
    }

    // Initialisation sûre ici
}, 20);

الخطوة 5: قائمة التحقق من التوافق (مرحلة الإعداد)

قم بتحديث ووردبريس إلى الإصدار 6.9.4 على بيئة الاختبار.
تحديث Divi 5 / Elementor / Avada + الإضافات.
مسح ذاكرة التخزين المؤقت (ذاكرة التخزين المؤقت للملحقات، والخادم، وشبكة توصيل المحتوى) و ذاكرة التخزين المؤقت للمتصفح (غالباً ما يتم نسيانها).
اختبار: منشئ الصفحات في وضع التحرير، الواجهة الأمامية، الهاتف المحمول، مستخدم غير إداري.
تحقق من الروابط الدائمة (أعد الحفظ) إذا قمت بتعديل المسارات/إعادة الكتابة.

هل نتصرف الآن أم ننتظر؟

تحرك الآن إذا قمت بتحديد مربع واحد على الأقل:

لديك مقتطفات "تاريخية" (functions.php، إضافة المقتطفات) لم يتم اختبارها لفترة طويلة.
تقوم بعرض نقاط نهاية REST أو إجراءات AJAX "admin-ajax" للمهام الحساسة.
أنت تستخدم أداة إنشاء (Divi 5/Elementor/Avada) ولديك نصوص برمجية مخصصة عامة.
لديك موقع به أدوار متعددة (مؤلفون، مساهمون): تصبح إمكانيات/أمان REST غير قابلة للتفاوض.

يمكنك الانتظار (بضعة أسابيع) إذا:

موقعك لا يحتوي على أي كود مخصص (أو يحتوي فقط على أكواد برمجية موثوقة)،
لديك عملية تجهيز وتحديث شهري،
أنت لا تعرض أي واجهات REST/AJAX مخصصة.

بحسب خبرتي، فإن "الانتظار" دون تجهيز بيئة تجريبية ينتهي بتكلفة أكبر. الحل الأمثل هو: تحديثات منتظمة للنظام الأساسي، مع إجراء عمليات تدقيق مُستهدفة لمناطق المخاطر (الأصول + REST + الخطافات).

نصائح الصيانة

1) قم بتوحيد طريقة إضافة التعليمات البرمجية

تجنب لصق مقتطفات من التعليمات البرمجية في القالب الرئيسي.
يفضل استخدام إضافة "موقع" مصغرة (إضافة mu إذا كانت مناسبة) لمنطق العمل.
إذا كنت تستخدم إضافة مقتطفات، فقم بإصدار مقتطفاتك (نسخة Git): لقد رأيت مقتطفات يتم تعطيلها بعد خطأ PHP، ولم يكن أحد يعرف "ما الذي تغير".

2) الحد الأدنى من الاختبارات التي يجب التخطيط لها لكل تحديث من تحديثات ووردبريس

الواجهة الأمامية: الصفحات الرئيسية، النماذج، التتبع.
المسؤول: محرر الكتل، شاشة البناء، الوسائط.
الأدوار: الاختبار باستخدام حساب مؤلف (وليس حساب مسؤول) لتحديد أخطاء الإمكانيات.
جافا سكريبت في وحدة التحكم: مراجعة سريعة واحدة على الأقل (الأخطاء/التحذيرات).

3) الأداء: حمل أقل، ولكن بشكل أفضل

قم بضبط خصائص أصولك (الصفحة، نوع المحتوى، وجود رمز مختصر/كتلة).
قم بإزالة المكتبات التي يتم تحميلها مرتين (غالباً مع أدوات البناء + المكون الإضافي للتسويق).
قم بتثبيت الإصدار الصحيح لتجنب "المشاكل العالقة".

4) الأمان: REST/AJAX و nonce

يجب على كل إجراء يُغير شيئًا ما أن يتحقق قدرات + السفير البابوي.
لا تثق في معلمات جانب العميل. قم بتنظيفها/التحقق من صحتها بشكل منهجي.

مرجع مفيد للغة PHP: تشفير كلمات المرور باستخدام PHP (إذا كنت تتعامل مع الرموز المميزة) أما من جانب ووردبريس، فتشمل ميزات الأمان المذكورة في الدليل.

الموارد

الأسئلة الشائعة

1) لقد نسخت جزءًا من الكود، لكنني أتلقى خطأ 500. ما الذي يجب عليّ فعله أولاً؟

قم بتعطيل المقتطف (أو أعد تسمية الملف إذا وضعته في إضافة)، ثم انظر wp-content/debug.log فيما يتعلق بالتحضير، يبقى الخطأ الأكثر شيوعًا هو غياب الفاصلة المنقوطة أو عدم إغلاق القوس المعقوف بشكل صحيح.

2) أين يتم وضع الكود المخصص في الإصدار 2026: functions.php، plugin، mu-plugin؟

بالنسبة لرمز "الأعمال" (CTA، REST، التتبع الداخلي)، أوصي باستخدام إضافة صغيرة مخصصة. functions.php يُعد هذا مقبولاً لأغراض تجميلية، ولكنك تخاطر بفقدان الكود عند تغيير السمات.

3) يعمل كود جافا سكريبت الخاص بي في واجهة المستخدم، لكنه لا يعمل في Elementor/Divi. لماذا؟

لأن المحرر ليس واجهة المستخدم. تقوم أدوات البناء بتحميل حزم مختلفة، أحيانًا داخل إطار iframe. قم بتحميل البرامج النصية الخاصة بك عبر wp_enqueue_scriptقم بتعريف التبعيات، وتجنب استخدام المحددات العامة بشكل مفرط.

4) هل ما زلت بحاجة إلى استخدام jQuery؟

إذا كان موقعك (أو أداة الإنشاء) يعتمد عليه بالفعل، نعم، ولكن حدد التبعية. أما إذا كنت تبدأ وحدة جديدة، فاستخدم جافا سكريبت الحديثة بدون تبعيات، وقم بتحميلها بشكل مشروط.

5) لماذا تُرجع نقطة نهاية REST الخاصة بي رمز الخطأ 403 على الرغم من أنني مسؤول النظام؟

غالباً بسبب المبعوث البابوي wp_rest لم يتم إرسالها (الرأس) X-WP-Nonceأو لأنك تختبر من سياق غير مصادق عليه (علامة تبويب خاصة، نطاق مختلف، ذاكرة تخزين مؤقتة). تحقق من الطلب في علامة تبويب الشبكة.

6) ما هي ذاكرة التخزين المؤقت التي أحتاج إلى مسحها بعد تعديل البرنامج النصي؟

كحد أدنى: ذاكرة التخزين المؤقت للملحقات (إن وجدت) + ذاكرة التخزين المؤقت للخادم/شبكة توصيل المحتوى + ذاكرة التخزين المؤقت للمتصفح. إذا لم يتغير إصدار ملفك، سيحتفظ المتصفح بالنسخة القديمة حتى لو قمتَ بمسح ذاكرة التخزين المؤقت لـ WordPress.

7) لا يعمل الكود الخاص بي، لكنني لا أرى أي أخطاء.

ربما تكون على الخطاف الخطأ، أو أن حالتك الصحية غير مناسبة. is_page() / is_admin() هذا لا يتوافق مع السياق. أضف سجلًا مؤقتًا (في بيئة الاختبار) وتحقق من أولوية الخطاف.

8) الإجراءات مقابل الفلاتر: هل يمكنها حقاً أن تُعطل موقع الويب؟

نعم. لقد رأيت مطورين يستخدمونه من قبل. add_filter في حالة استخدام دالة لا تُسند قيمة، وتنتظر قيمة مُعادة، فلن يحدث شيء. وعلى العكس، فإن إعادة قيمة في إجراء ما أمرٌ غير مُجدٍ. راجع توثيق الدالة ذات الصلة.

9) هل يتطلب WordPress 6.9.4 الإصدار PHP 8.1؟

لا تزال ووردبريس تتسم بالواقعية فيما يتعلق بالتوافق، ولكن في عام 2026، يُوصى باستخدام PHP 8.1 أو أحدث كحد أدنى لضمان الاستقرار والأمان. العديد من الإضافات الحديثة تفترض بالفعل الإصدار 8.1.

10) قمت بتعديل بعض المسارات/الروابط الدائمة وأتلقى أخطاء 404.

أعد حفظ روابطك الدائمة (الإعدادات ← الروابط الدائمة ← حفظ) وتحقق من قواعد إعادة الكتابة. هذا خطأ شائع للغاية بعد عملية نقل البيانات أو إضافة أنواع المنشورات المخصصة.