توقف عن إعادة بناء كل موقع WordPress

ملخص

تبني معظم الوكالات كل موقع WordPress من قالب فارغ، حتى عندما يمكن لأساس مشترك أن يوفر أسابيع من الجدول الزمني. تجادل هذه المقالة أن theme.json وأنماط الكتل والكتل الديناميكية تتيح لك توحيد الطبقة الهيكلية مع الحفاظ على التصميم المميز لكل عميل. وهي تعالج مباشرة الاعتراضات الخمسة التي تمنع الفرق من التغيير: ‘لدينا عملاء مختلفون’، ‘الكتل المخصصة مكلفة’، ‘المحرر مربك’، ‘سنفقد خطافاتنا وفلاترنا’، و‘محرر الموقع الكامل غير جاهز للإنتاج’. كل اعتراض يحصل على حجة مضادة عملية ونمط ملموس يمكنك اعتماده تدريجيًا. المكافأة هي عملية بناء قابلة للتكرار لا تزال تحترم العمل المصمم خصيصًا في مكانه. تحذير: لا يُعد بأزرار إعادة تعيين بنقرة واحدة.

كم عدد مواقع عملائك التي تشارك حتى سطرًا واحدًا من التعليمات البرمجية؟ ليس سطر حقوق النشر—بل التعليمات البرمجية الفعلية. إذا كانت الإجابة "بالكاد أي", فقد شعرت بالفعل بالألم: نفس قسم البطل أعيد بناؤه للمرة التاسعة، نفس ترميز شبكة الفريق منسوخ من مشروع إلى آخر، نفس تعديلات المعالجة المسبقة المشار إليها عبر نصف دزينة من القوالب. سمعت أيضًا الدفاع: "كل عميل لديه احتياجات مختلفة." صحيح. لكن الاستنتاج الذي يستخلصه الجميع—أن كل موقع يحتاج إلى أساس مصمم خصيصًا—خاطئ. الآن يمنحك نظام WordPress البيئي طريقة لتوحيد الأجزاء الهيكلية دون توحيد التصميم: theme.json لرموز التصميم، وأنماط الكتل للتخطيط المتكرر، والكتل الديناميكية للعدد القليل من الميزات التي تحتاج إلى منطق حقيقي من جانب الخادم. تدور هذه المقالة حول الاعتراضات التي تمنع الوكالات من اتخاذ تلك الخطوة، وما ينجح فعليًا عند الرد عليها.

اعتراض «لكن كل عميل مختلف»

المبدأ الأساسي: توحيد الأساس، ليس السطح. سبب إبقاء البنية في مكتبة مشتركة هو تحديدًا ترك الطبقة المرئية حرة. ملف theme.json ليس تصميمًا—إنه مجموعة من رموز التصميم. الألوان والتباعد والطباعة هي قيم، وليست ترميزًا. هذا هو التحول الحاسم: يمكنك مشاركة الترميز بينما يجعل theme.json الخاص بكل موقع الموقع يبدو مختلفًا تمامًا لعلامة تجارية مختلفة.

خذ عميلين: شركة محاماة ومتاجر للسلع الخارجية. لغات تصميمهما متباعدة أميالًا. لكن كلاهما يحتاج إلى قسم بطل وشبكة شهادات وشريط دعوة لاتخاذ إجراء. بدلاً من إعادة بناء الترميز لكل منهما، حافظ على ثلاثة أنماط كتل ودع theme.json لكل عميل يحدد الألوان والخطوط والتباعد. يظل الهيكل متطابقًا؛ رموز التصميم تحوله من علامة تجارية إلى أخرى. عندما يغير المتاجر لوحة الألوان في الربيع المقبل، يمكنك تعديل ملف واحد في موقعه—وليس الترميز في ستة قوالب.

عمليًا، هذا يعني أن فريقك ينشئ الأنماط ككود، ويسجلها في إضافة مشتركة، ويترك theme.json على كل موقع عميل يتعامل مع الطلاء. أسماء فئات النمط تصبح بنيتك المعمارية؛ القيم تصبح المتغيرات. يمكنك حتى الذهاب أبعد من ذلك وتوسيع theme.json لتضمين إعدادات مخصصة لأنواع المنشورات أو مخرجات الإضافات، على الرغم من أنك في مرحلة ما تبني واجهة تكوين بدلاً من موقع—وهو فخ تمت مناقشته في نظرتنا إلى توسيع theme.json. حافظ على الطبقة المشتركة بسيطة: يجب أن تحتوي فقط على ما يتكرر عبر العملاء. اللحظة التي تجد فيها نفسك تضيف إعدادًا "في حال أراده شخص ما يومًا ما," تكون قد أنشأت تجريدًا سيكلف صيانته أكثر مما يوفر.

عند إعداد عميل جديد، يجب أن تكون الدقائق الثلاثون الأولى: استنساخ إضافة الأنماط المشتركة، وإنشاء theme.json جديد مع لوحة ألوان العميل ومقياس الخطوط، وتسجيل شعارهم وتذييلهم. هذا ليس بناءً مخصصًا؛ إنها مهمة تكوين. العمل المتبقي الخاص بالعميل يذهب إلى المحتوى والبنية وأي ميزات مخصصة حقًا. هذا هو الفرق بين بناء كل منزل من الصفر والحصول على مجموعة من مخططات الطوابق الجاهزة التي يمكنك إعادة طلائها وإعادة ورق الجدران. القياس فضفاض، لكن المبدأ صحيح: كلما دفعت أكثر إلى قيم theme.json، قل ما عليك لمسه من الترميز.

من أبسط المكاسب هو النظر فعليًا إلى كيفية عمل أنماط الكتل. النمط هو مجرد مجموعة من الكتل بمحتوى وتنسيق محدد مسبقًا. يمكنك حفظ أي تكوين للكتل كنمط، ومن ثم يمكن للعميل إدراجه دون الحاجة إلى معرفة كيف تم بناؤه. هذا يعني أن النمط يصبح 'نقطة دخول' للمستخدمين غير التقنيين. عندما يحافظ فريقك على النمط الأساسي في الكود، يحصل العميل على مكتبة متسقة دون لمس وسوم PHP واحدة.

الآن، التحذير الذي أعود إليه دائمًا: لا تفرط في المركزية. theme.json مع إعداد لكل فارق دقيق يمكن تخيله هو مستنقع صيانة. يجب أن تكون الأنماط المشتركة ذات رأي، وليست كليّة القدرة. إذا احتاج عميل إلى تخطيط مختلف جذريًا—على سبيل المثال، صفحة رئيسية لمجلة مع شبكة مميزة كبيرة—قد لا تناسب مكتبة الأنماط القياسية لديك. هذا جيد. التوحيد يعني أنك تربح في 80% من المشاريع المتشابهة، وليس أن تجبر كل موقع على نفس القالب.

اعتراض «الكتل المخصصة تفجّر الميزانية»

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

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

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

عند إنشاء كتلة، block.json هو صديقك. إنه المصدر الوحيد للحقيقة للسمات والسيناريوهات والأنماط، مما يجعل الكتلة قابلة للنقل عبر المشاريع. كما يتيح لك إعلان التبعيات والترجمات بوضوح، وهو أمر ضروري عند توزيع مكتبة على العديد من مواقع العملاء. بالنسبة للمحتوى الذي يعتمد على بيانات مباشرة، تعرض الكتلة الديناميكية على الخادم، لذلك لا تحتاج إلى شحن حزمة JavaScript في كل عرض صفحة. وإذا تطورت كتلتها، يمكنك التعامل مع الإهمال (deprecation) بأناقة حتى لا ينكسر المحتوى الموجود—دليلنا إلى إهمال الكتل يشرح النمط الدقيق.

قبل إنشاء أي شيء، مرر القرار عبر هذا الجدول:

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

ستحتاج أيضًا إلى التفكير في تسمية الكتل من اليوم الأول. اسم الكتلة هو في الأساس عقد مع المحتوى الخاص بك. إذا أطلقت عليه wagent/team-grid وأعدت تسميته لاحقًا إلى wagent/team-carousel، فستكسر المحتوى الموجود ما لم توفر مسار إهمال. اختر أسماء عامة مبنية على الغرض لن تصبح إعلانًا كاذبًا مع تطور الكتلة. هذا نكهة من انضباط التسمية الذي تعلمناه جميعًا من بادئات الإضافات، وينطبق بنفس القدر على أسماء الكتل.

الرأي المخالف هنا هو أكثر شيء مفيد يمكنني قوله: الكتلة المخصصة التي تبنيها لأن عميلًا طلب "قطعة واحدة فقط" هي دائمًا تقريبًا خطأ. قل لا بأدب، وأطلق كتلة أساسية بفئة، ووفّر الساعات. ستحصل على احترام أكبر من العميل—وسطر أصغر في ميزانية الصيانة.

اعتراض «سيكسر العملاء المحرر»

هذا الاعتراض صحيح في منتصفه. محرر الكتل نفسه ليس المشكلة؛ المشكلة هي إعطاء العملاء حبلًا طويلًا جدًا. يمكن لـ theme.json تقييد ما يمكن تحريره: تعطيل محرر القوالب، وتقييد الكتل المسموح بها، وتعيين الأنماط الافتراضية بحيث يتسبب عمود في غير مكانه في ضرر أقل. سيظل بعض العملاء قادرين على كسر الأشياء، لكن يمكنك مسح صفحة إلى نمط محفوظ بنقرة واحدة—وهو شيء لم يستطع المحرر الكلاسيكي تقديمه.

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

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

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

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

اعتراض «لدينا بالفعل خطافات وفلاتر»

المبدأ هنا هو: أنت لا تتخلص من الخطافات؛ أنت تضيف طبقة فوقها. الكتل هي حدود العرض؛ الخطافات هي كيف تحقن المنطق. استدعاء العرض (render callback) لكتلة ديناميكية يعمل في PHP، مما يعني أنه يمكنك استدعاء نفس الدوال وتطبيق نفس الفلاتر التي تثق بها بالفعل.

تخيل إضافة تتيح لك إضافة حقل "منتج مميز" إلى أي منشور باستخدام فلتر. مع كتلة ديناميكية، يمكنك تضمين كتلة معروضة من الخادم تشغل هذا الفلتر وتطبع المخرجات داخل غلاف الكتلة. يقوم العميل بإدراج الكتلة؛ المنطق الحالي في PHP يقوم بالعمل الشاق. لا يتم التخلص من أي شيء. لمثال أكثر واقعية، فكر في كتلة مخصصة تعرض أحدث منشورات المشاريع. في استدعاء العرض الخاص بها، تستدعي get_posts()، ثم تكرر وتطبق the_title() و the_permalink()—وسوم القوالب نفسها التي استخدمتها لسنوات.

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

تفتح REST API أيضًا بابًا مختلفًا: يمكنك بناء كتل تسحب البيانات من مواقع WordPress أخرى أو خدمات طرف ثالث. يمكن لكتلة ديناميكية استدعاء wp_remote_get() لجلب JSON وعرضها في الواجهة الأمامية. هذا نمط قوي لبناء الوكالات حيث يريد العملاء عرض موجزات اجتماعية أو قوائم منتجات أو بيانات داخلية دون إدارة تكامل منفصل. المفاضلة هي التخزين المؤقت ومعالجة الأخطاء—إذا كانت واجهة برمجة التطبيقات البعيدة بطيئة، تكون صفحتك بطيئة. أبقِ الكتل القائمة على API خارج المحتوى الحرج في الجزء العلوي من الصفحة، أو استخدم العرض من جانب العميل مع حالة تحميل مناسبة.

لا تزال الإجراءات والفلاتر تعمل حول الحفظ والعرض؛ بنية الخطافات لا تختفي عندما تتبنى الكتل، إنها تنتقل فقط إلى سياق جديد. إذا كنت بحاجة إلى تحديث فهمك لمكان التقاء الإجراءات والفلاتر مع عالم الكتل الجديد، فإن غوصنا العميق في الخطافات هو تذكير مفيد.

اعتراض «محرر الموقع الكامل غير جاهز للإنتاج»

عادل بما يكفي، لكن اسأل ما الذي يعنيه "محفوف بالمخاطر" فعليًا. مر محرر الموقع الكامل بعدة إصدارات، واستقر theme.json في مخطط ثابت. الخطر ليس أن المحرر "ينكسر فجأة"—الخطر هو أن الكود المخصص لفريقك قد يعتمد على قوالب PHP القديمة التي تتعايش بشكل غير ملائم مع قوالب الكتل. أيضًا، لا تزال بعض إضافات الطرف الثالث تفترض المحرر الكلاسيكي أو المُخصِّص. هذا قرار توافق، وليس سببًا لرمي النموذج بأكمله.

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

قبل أن تقترح قالب كتل على عميل، راجع قائمة تحقق سريعة:

• هل لدى العميل قالب مخصص بشكل كبير يتطلب ترحيلًا؟
• هل تدعم الإضافات الأساسية محرر الموقع و REST API؟
• هل تسمح بيئة الاستضافة بوصول الملفات التي يتوقعها قالب الكتل؟
• هل خصصت وقتًا لتصميم الأنماط، وليس فقط تسجيل الكتل؟
• هل سيتحمل فريق العميل تغييرات المحرر، أم يحتاجون إلى قالب مقفل؟

إذا كانت أي إجابة لا، فعدل النطاق أو استخدم نهجًا هجينًا. هذا ليس تنازلاً؛ إنه حكم هندسي. وإذا كنت تبني هجينًا، فتذكر قصة الخطافات والفلاتر أعلاه—لا يزال بإمكانك لف المنطق القديم في كتل ديناميكية بينما يتعامل theme.json مع المظهر العام.

إصدار theme.json ليس مجرد اهتمام نظري. لقد رأيت مكتبة الكتل المخصصة لوكالة تتعطل عندما قام العميل بتحديث WordPress وتم تسجيل ملف style الخاص بالكتلة مع wp_register_style() تحت معرّف (handle) تم تغييره. كان الإصلاح سهلاً، لكن الذعر كان حقيقيًا. عملية اختبار بسيطة—قم بتشغيل التحديث على نسخة تجريبية من الموقع، وانقر عبر الصفحات الرئيسية، ثم أطلق—تحل معظم هذه المفاجآت.

الاعتراض الذي لم تثره لنفسك

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

إليك أول 30 يومًا تقريبًا:

1. راجع آخر خمسة مشاريع لعميل وقم بإدراج العشرة عناصر التخطيط الأكثر تكرارًا.
2. حوّل هذه العشرة عناصر إلى أنماط كتل، مع مجموعة صغيرة من فئات CSS.
3. أنشئ إضافة مشتركة (أو mu-plugin) تسجل تلك الأنماط. إذا لم تكن قد فكرت في تنظيم الإضافات لهذا الغرض، فتصفح هذا الدليل حول بناء إضافات قوية أولاً.
4. أنشئ theme.json واحدًا يطابق تصميمك الأساسي؛ أضف قيمًا خاصة بالعميل عند بدء مشاريع جديدة.
5. اختر مشروعًا داخليًا صغيرًا أو عميلًا ودودًا وقم بترحيله إلى الحزمة.
6. وثق قصة نجاح واحدة لعميل قام بتعديل صفحته الرئيسية دون الاتصال بك.

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

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

تأتي قابلية التكرار من الأجزاء المملة: مخطط theme.json متين، ومكتبة أنماط واضحة، والانضباط للحفاظ على الطبقة المشتركة بسيطة. هذا ليس النسخة اللامعة التي تسمعها في الندوات عبر الإنترنت. إنه الذي يهزم كآبة القالب الفارغ صباح الاثنين.