حدّث WordPress متطلبات بيئة التطوير الرسمية إلى Node.js 24 وnpm 11 للمساهمين في Core وGutenberg. التغيير لا يرفع متطلبات PHP أو Node.js لتشغيل موقع WordPress على الخادم؛ هو تغيير في Build Tooling وLocal Development وCI. إذا كنت تعمل على wordpress-develop أو Gutenberg trunk أو فرع 7.1، فالمطلوب الآن Node.js 24.18.0+ وnpm 11.16.0+.
أعلن فريق WordPress Core التغيير رسميًا في 9 سبتمبر 2026، موضحًا أن المتطلبات الجديدة أصبحت مطبقة منذ 8 سبتمبر على trunk في المستودعين، وعلى wp/7.1 في Gutenberg و7.1 في wordpress-develop. المصدر الأساسي: Make WordPress Core — Updating WordPress to use Node.js 24 and npm 11.
ما الذي تغير بالضبط؟
أصبحت بيئة التطوير الحديثة لـWordPress تتطلب Node.js 24.x بحد أدنى 24.18.0 وnpm 11.x بحد أدنى 11.16.0. هذا ينطبق على مساهمات Core وGutenberg الحديثة، بينما تبقى الفروع الأقدم حاليًا على متطلبات Node.js وnpm السابقة.
المغزى العملي: إذا كان لديك Checkout محلي قديم، أو Pull Request مفتوح، أو CI workflow مثبت على Node.js 20، فقد تفشل الاختبارات أو تُحجب عملية الدمج حتى تحديث الفرع وبيئة البناء.
من المتأثر؟
مطورو WordPress Core وGutenberg
هذه هي الفئة المتأثرة مباشرة. إذا كنت تعمل على trunk أو الفروع المحددة في الإعلان الرسمي، يجب تحديث Node.js وnpm قبل تثبيت الحزم وتشغيل الاختبارات.
مطورو القوالب والإضافات
لن يتعطل Plugin أو Theme منشور لمجرد هذا التغيير. لكن إذا كانت سلسلة البناء لديك تعتمد على حزم @wordpress/* أو اختبارات مرتبطة مباشرة بـGutenberg/wordpress-develop، فمن المنطقي اختبار مشروعك على Node.js 24 وعدم إبقاء CI على نسخة انتهى دعمها.
أصحاب المواقع والمتاجر
لا يوجد إجراء مطلوب لموقع Production فقط بسبب هذا الخبر. لا تغيّر PHP أو إعدادات الاستضافة أو WooCommerce لمجرد أن WordPress حدّث Node.js في بيئة التطوير. هذا فرق مهم بين runtime requirements وdevelopment tooling requirements.
لماذا انتقل WordPress إلى Node.js 24؟
بحسب فريق Core، Node.js 20 وصل إلى نهاية عمره في أبريل 2026، وبدأت منظومة الأدوات والخدمات الخارجية تتوقف عن دعمه. الانتقال إلى Node.js 24 يفتح أيضًا تحديثات كانت معلقة بسبب قيود الإصدارات القديمة.
من أبرز النتائج التي ذكرها WordPress: دعم استراتيجية npm linked لعزل الاعتماديات، تمكين OIDC Trusted Publishing لحزم @wordpress/* دون الاعتماد على npm token طويل العمر، تفعيل حماية minimumReleaseAge محليًا، والاستفادة من تشغيل TypeScript مباشرة عبر Type Stripping في Node.js 24.
كما يتيح التغيير ترقية أدوات مثل Lerna وLighthouse وwebpack-dev-server وحزم أخرى تتطلب Node.js 22 أو أحدث، وتقليل بعض الاعتماديات بفضل APIs أصلية مثل fetch وglob وواجهات crypto الحديثة.
طريقة ترقية بيئة WordPress Development بأمان
1. افحص نسخ Node.js وnpm الحالية
node --version
npm --versionإذا كنت أقل من Node.js 24.18.0 أو npm 11.16.0 في Checkout حديث لـCore/Gutenberg، حدّث البيئة قبل المتابعة.
2. استخدم nvm أو fnm بدل تثبيت نسخة عشوائية
التوصية الرسمية لمستخدمي nvm هي تشغيل:
nvm install
nvm use
npm ciداخل Checkout الخاص بـwordpress-develop أو Gutenberg. ملف .nvmrc يحدد النسخة المطلوبة في المشروع.
3. حدّث Pull Request أو الفرع المحلي
إذا كان لديك PR مفتوح، ادمج أو أعد Base على أحدث trunk. WordPress يوضح أن اختبارات CI المطلوبة أصبحت تعمل على Node.js 24، وقد لا تظهر Checks المطلوبة في فروع مبنية على trunk قديم حتى يتم تحديثها.
4. أعد تشغيل الاختبارات والبناء
لا تعتمد على أن npm ci انتهى بنجاح فقط. شغّل Test/Lint/Build commands الخاصة بالمشروع وراجع أي تغيير في lockfile أو peer dependencies أو scripts تعتمد على Node APIs قديمة.
هل يؤثر التغيير على Backward Compatibility؟
على مستوى الموقع النهائي، لا يعد هذا تغييرًا في WordPress runtime ولا يفرض Node.js 24 على المستخدم النهائي. لكن في بيئة التطوير قد تظهر incompatibilities في scripts أو tools قديمة لم تُختبر مع Node.js 24/npm 11.
لهذا السبب، في المشاريع التي تملك pipeline مخصصًا، اختبر:
- CI images وGitHub Actions أو أي runners داخلية.
- Node-based build scripts للقوالب والإضافات.
- ESLint وStylelint وwebpack/Vite وبقية أدوات bundling.
- أي package pinning أو engines constraints داخل
package.json. - تثبيت dependencies من lockfile نظيف باستخدام
npm ci.
ماذا عن الفروع القديمة؟
بحسب الإعلان الرسمي، الفروع الأقدم بقيت دون تغيير وقت الإعلان، وتستخدم متطلبات Node/npm السابقة. لكن فريق WordPress يدرس تحديث فروع 6.4 حتى 7.0 لاحقًا، مع توجه مستقبلي للانتقال إلى Node.js 26 عندما يصبح Active LTS في أكتوبر 2026. لذلك لا تفترض أن الإعداد الحالي سيظل ثابتًا طويلًا في بيئات التطوير التاريخية.
هل يجب أن أغيّر Node.js في استضافة WordPress؟
لا. إذا كنت تدير موقع WordPress أو متجر WooCommerce عاديًا، فلا تغيّر إعدادات الخادم بسبب هذا الإعلان. PHP وMySQL/MariaDB هما جزء من متطلبات تشغيل WordPress؛ أما Node.js هنا فهو أداة ضمن بيئة بناء وتطوير Core/Gutenberg.
إذا كنت تستخدم SSR أو build process منفصلًا أو Headless frontend مبنيًا على Node.js فهذه بنية مشروع خاصة بك، وليست نتيجة مباشرة لهذا التغيير في WordPress Core.
ما علاقة هذا بـWordPress 7.1 و7.2؟
التغيير طُبق على فرع 7.1 في بيئة التطوير وعلى trunk الذي يتجه إلى 7.2. إذا كنت تراجع تغييرات WordPress 7.1 نفسها، راجع أيضًا تحليل WordPress 7.1 للمطورين والتحديث الآمن. أما هذا المقال فنيته مختلفة: هو مخصص فقط لمتطلبات Node.js/npm الخاصة ببيئة التطوير والـCI.
للمطورين الذين يريدون فهم أساس JavaScript داخل مشاريع WordPress، راجع أيضًا دليل JavaScript للمطورين.
الخلاصة العملية
إذا كنت مساهمًا في WordPress Core أو Gutenberg، حدّث بيئتك الآن إلى Node.js 24.18.0+ وnpm 11.16.0+، أعد تثبيت dependencies بـnpm ci، وحدّث الفرع ثم تحقق من CI. أما إذا كنت صاحب موقع إنتاجي فقط، فلا يوجد تغيير مطلوب في الاستضافة بسبب هذا الخبر.
أسئلة شائعة
هل WordPress أصبح يحتاج Node.js 24 على السيرفر؟
لا. التغيير يخص بيئة التطوير الرسمية لـCore وGutenberg وليس متطلبات تشغيل موقع WordPress الإنتاجي.
ما الحد الأدنى الجديد لـNode.js؟
Node.js 24.18.0 على الفروع الحديثة المحددة في إعلان WordPress الرسمي.
ما الحد الأدنى الجديد لـnpm؟
npm 11.16.0 وفق الإعلان الرسمي.
هل أحتاج تحديث مشاريع القوالب والإضافات؟
ليس بالضرورة. لكن إذا كانت بيئة Build أو CI لديك تعتمد على WordPress trunk أو Gutenberg الحديث أو حزم وأدوات تتأثر بإصدار Node.js، اختبرها على Node.js 24 قبل اعتمادها.
