معظم مشاريع تطوير إضافات ووردبريس تتبع المسار نفسه. أحدهم يحتاج نموذج حجز أو مستورد تغذية أو حقلاً إضافياً عند إتمام الطلب، فيكتبه مطوّر، ويعمل، وينصرف الجميع إلى غيره. وبعد عامين يبقى الموقع عالقاً على إصدار قديم من ووردبريس لأن لا أحد واثق من أن تلك الإضافة ستنجو من التحديث، ومن كتبها قد رحل.
والسبب نادراً ما يكون أن النواة تتحرك بسرعة أكبر مما ينبغي. فووردبريس متحفّظ في كسر ما هو قائم، وكثير من الإضافات المكتوبة جيداً قبل خمس سنوات ما زال يعمل دون تعديل على ووردبريس 7.1. الإضافات تنكسر بسبب قرارات اتُّخذت في الأسبوع الأول: وظائف وُضعت في القالب، وملفات نواة عُدِّلت بدل استخدام الخطافات، وبيانات خُزِّنت في أقرب بنية متاحة، ولا أحد يختبر مقابل نسخة مرشّحة للإصدار.
ما الذي يجعل إضافة ووردبريس مخصصة تنجو من تحديثات النواة؟ أربعة أشياء. الكود يعيش داخل إضافة لا داخل القالب. ويوسّع ووردبريس عبر الإجراءات والمرشّحات بدل تعديل ملفات النواة. ويخزّن كل نوع من البيانات في البنية التي تناسب شكل تلك البيانات. وهناك من يختبره مقابل كل نسخة مرشّحة للإصدار قبل صدور ذلك الإصدار.
لماذا ينتمي تطوير إضافات ووردبريس إلى إضافة لا إلى القالب
الموطن الافتراضي للكود المخصص هو ملف functions.php في القالب، لأنه موجود أصلاً ويعمل أصلاً. وهو كذلك الملف الذي يختفي عند إعادة التصميم التالية.
القالب عرضٌ ومظهر. غيّر القالب فيتوقف كل ما كان القالب القديم يفعله. تتوقف أنواع المحتوى المخصصة عن التسجيل، فيجلس المحتوى في قاعدة البيانات بلا شاشة إدارة وبلا رابط دائم. وتظهر الأكواد المختصرة نصاً خاماً في منتصف الصفحة. ويذهب مقتطف التحليلات وترميز schema والاتصال الليلي بنظام إدارة العملاء، ولا شيء يرفع خطأً.
القاعدة بسيطة بما يكفي لوضعها في كرّاسة الشروط. كل ما يجب أن يبقى صحيحاً بعد إعادة التصميم ينتمي إلى إضافة: أنواع المحتوى والتصنيفات المخصصة، والتكامل مع أي طرف خارجي، والأكواد المختصرة والكتل، وقواعد العمل، والمهام المجدولة، وكل ما يكتب في قاعدة البيانات. أما القالب فتبقى له القوالب الجزئية والأنماط وأجزاء العرض.
الثمن يصل متأخراً. عند إعادة التصميم التالية إما أن تدفع من جديد لإعادة بناء ما كان موجوداً، أو أن تنقل ملف functions.php القديم كما هو. وعلى موقع تراكمت فيه المقتطفات لسنوات، هذا يعني آلاف الجنيهات من عمل كان يمكن تفاديه، وهو سبب عودة عرض سعر إعادة التصميم بضعف ما توقعه العميل. والقالب الابن يبقى قالباً.
نموذج التوسيع، والقاعدة الوحيدة التي تهم
بُني ووردبريس ليُغيَّر من الخارج. والآلية هي الخطافات، وتوثيق الخطافات يصفها بأنها المواضع المحددة سلفاً حيث يمكن لقطعة من الكود أن تتفاعل مع أخرى أو تعدّلها. الإجراء ينطلق في لحظة محددة ويتيح لك أن تفعل شيئاً: إرسال إشعار بعد نشر مقالة، أو تسجيل نوع محتوى. أما المرشّح فيسلّمك قيمة، ويتوقع أن تغيّرها أو تتركها كما هي، ويتوقع أن تعيدها إليه.
القاعدة المترتبة على ذلك مطلقة. إن كنت تعدّل ملفاً داخل wp-admin أو wp-includes أو داخل مجلد إضافة أخرى، فقد خسرت سلفاً. تلك التعديلات يمحوها التحديث التالي، بلا تحذير وبلا خطأ وغالباً بلا اكتشاف حتى يبلّغ عميل بأن شيئاً توقف عن العمل. اسأل المطوّر عن هذا مباشرة قبل التعاقد معه.
وحين لا يوجد الخطاف الذي تحتاجه، غلّف السلوك بدل استبداله، أو اصعد إلى خطاف أوسع، أو انسخ إضافة الطرف الثالث تحت إدارة إصدارات مع توثيق الاختلاف، أو اطلب الخطاف من المصدر الأصلي، فهكذا أُضيف معظمها.
التسمية والبادئات ونطاق أسماء شديد الازدحام
يعمل PHP داخل ووردبريس في نطاق أسماء عام واحد تتشاركه النواة والقالب النشط وكل إضافة نشطة أخرى. وإضافتان تعلن كل منهما دالة باسم get_settings() لا تتنافسان بلطف: الثانية خطأ قاتل والموقع يصير أبيض.
البادئات أطول مما تظن
صفحة أفضل الممارسات للإضافات في الدليل تطلب بادئة فريدة لكل ما هو متاح عالمياً، أربعة أحرف على الأقل وخمسة إن أمكن، مع تجنب الكلمات الإنجليزية الشائعة وعدم استخدام wp_ أو _ أو WordPress نفسها أبداً. ومع عشرات الآلاف من الإضافات المتداولة، فإن ثلاثة أحرف من الحروف الأولى لاسم العميل رهانٌ على قذف عملة.
نطاقات الأسماء والتحميل التلقائي
الممارسة الحديثة تحل نصف المشكلة. أعلن نطاق أسماء في PHP، وضع صنفاً واحداً في ملف واحد، ودع محمّلاً تلقائياً بمعيار PSR-4 يعثر عليها، فلا تبقى تعليمات require مكتوبة يدوياً ولا فرصة لتصادم اسم صنف مع اسم في إضافة أخرى. وهذا يجعل الكود قابلاً للاختبار أيضاً، لأن الأصناف التي تتلقى اعتمادياتها في الباني يمكن إنشاؤها دون تحميل ووردبريس.
والتحميل التلقائي لا يعالج أن تشحن إضافتان نسختين مختلفتين من المكتبة نفسها. تفوز الأسبق تحميلاً. أضف بادئة إلى نطاقات أسماء المكتبات الخارجية عند البناء لكل ما يوزَّع.
السلاسل النصية التي لا تنفع معها نطاقات الأسماء
نطاق الأسماء يغطي رموز PHP. لكن كثيراً مما تسجله الإضافة ليس رمز PHP بل سلسلة نصية في سجل مشترك، وتلك ما زالت تحتاج عرف البادئة القديم: أسماء الخطافات، ومفاتيح الخيارات والمؤقتات، ومفاتيح البيانات الوصفية للمقالات، وأسماء أنواع المحتوى والتصنيفات، ووسوم الأكواد المختصرة، وأسماء أحداث cron، ونطاقات أسماء REST، وأسماء الجداول المخصصة. تعيش هذه في فضاء مسطح يفوز فيه آخر تسجيل، أو تتشارك فيه إضافتان حالة واحدة في صمت.
هناك حدّان يستحقان المعرفة قبل تسمية أي شيء. مفتاح نوع المحتوى يجب ألا يتجاوز 20 حرفاً، ومفتاح التصنيف يجب ألا يتجاوز 32، وكلاهما بأحرف صغيرة وأرقام مع الشرطات والشرطات السفلية. وبادئة من خمسة أحرف تترك 15 حرفاً لاسم نوع المحتوى، وهي مساحة أضيق مما تبدو.
اختيار المكان الذي تعيش فيه البيانات
هذا هو القرار صاحب أطول ذيل. إن أخطأته عملت الإضافة على ما يرام عند الإطلاق، ثم صارت أبطأ كل شهر مع نمو البيانات، وحين ينتبه أحد يكون العلاج ترحيلاً لا تعديلاً.
الخيارات والمؤقتات
الخيارات مخصصة للإعدادات على مستوى الموقع: حفنة مفاتيح، وقيم صغيرة، تُقرأ في معظم الطلبات. والفخ هو التحميل التلقائي، لأن كل خيار محمّل تلقائياً يُجلب في كل طلب مهما كان، بما في ذلك نداءات admin-ajax وREST، سواء استخدمه شيء أم لا.
غيّر ووردبريس 6.6 هذه الآلية، كما يوضح منشور مدونة Make WordPress Core عن تعطيل التحميل التلقائي للخيارات الكبيرة. صارت القيمة المخزّنة on أو off أو auto، والخيار الأكبر من 150,000 بايت لا يُحمَّل تلقائياً افتراضياً، مع إمكانية ضبط العتبة عبر المرشّح wp_max_autoloaded_option_size. عامل ذلك سقفاً لا هدفاً. والمؤقتات خيارات لها مدة صلاحية، وهي الموطن الصحيح لكل ما يُجلب من مكان آخر.
البيانات الوصفية للمقالة ليست مخزن مفتاح وقيمة
البيانات الوصفية للمقالة مخصصة لخصائص مقالة واحدة: عنوان فرعي، أو سعر، أو مرجع مورّد. وهي ليست مخزن مفتاح وقيمة لأغراض عامة، والسبب ظاهر في تعريف الجدول. جدول wp_postmeta فيه أربعة أعمدة وثلاثة مفاتيح. والمفهرس منه هو post_id وأول 191 حرفاً من meta_key فقط. أما عمود meta_value فهو من نوع longtext بلا أي فهرس عليه.
لذلك لا يستطيع الاستعلام الذي يرشّح على قيمة وصفية أن يستخدم فهرساً. وكل شرط في استعلام البيانات الوصفية يضيف وصلة أخرى، وعلى موقع فيه 50,000 مقالة تحمل كل واحدة 20 صفاً وصفياً يبلغ الجدول مليون صف. ثلاثة شروط تعني ثلاث وصلات على مليون صف في كل تحميل صفحة. وهذا من أكثر أسباب أن يكون الموقع سريعاً في عامه الأول وغير قابل للاستخدام في عامه الثالث، ويظهر باستمرار في العمل على أداء WooCommerce.
أنواع المحتوى والتصنيفات المخصصة
نوع المحتوى المخصص هو الصواب حين يكون الشيء محتوى. فهو يحتاج شاشة قائمة خاصة به وروابط دائمة ومراجعات وسير عمل تحريري، وله معنى كصفحة قد يزورها أحد. والتصنيف المخصص هو الصواب حين تحتاج مفردات مشتركة تجمع تلك الأشياء وتستحق صفحات أرشيف خاصة بها.
وكلاهما يجلب آلات جاهزة بلا مقابل: شاشات إدارة، وصلاحيات، وبحث، ومحرر الكتل، وواجهة REST. اضبط show_in_rest على true وإلا فلن يتعامل محرر الكتل مع النوع، وسجّل كليهما على الخطاف init ولا تسجّلهما قبله أبداً.
متى تحتاج فعلاً جدولاً خاصاً بك
الجدول الخاص بك هو الصواب حين لا تكون البيانات محتوى: سجلات ضخمة الحجم تُضاف ولا تُعدَّل، مثل سجلات الأحداث وطوابير الاستيراد وتاريخ الأسعار ومسارات التدقيق، أو أي شيء سترشّحه وترتّبه بحقل ليس عموداً من أعمدة المقالة. وبعد بضع مئات الآلاف من الصفوف التي يُستعلَم عنها بحقولها الخاصة، يتفوق جدول بفهارس صحيحة على البيانات الوصفية للمقالة بمراتب من الفارق، ويبقى متوقَّع السلوك وهو ينمو.
والثمن أن كل شيء يصير مسؤوليتك: إنشاء الجدول والترحيلات المرقّمة، والتنظيف في uninstall.php، وشاشات الإدارة ونقاط REST والتخزين المؤقت، كلها من صنعك. ولهذا يبقى الجواب الأمين لمعظم الإضافات هو نوع محتوى مخصص.
الأمان أربع عادات، وثلاث منها تُتخطى
دليل أمان ووردبريس يقول المبدأ صراحة: لا تثق بمدخلات المستخدم، ولا بواجهات الأطراف الثالثة، ولا بالبيانات الجالسة في قاعدة بياناتك أصلاً. أربع عادات تحمل الخطر كله تقريباً، وفي الإضافات التي ندقّقها تُتخطى بترتيب ثابت. فحوص الصلاحيات أولاً، ثم رموز nonce، ثم تهريب المخرجات ثالثاً. أما العبارات المُجهَّزة فتأتي أخيراً، لأن غيابها يُلتقط في المراجعة.
فحوص الصلاحيات
كل معالج يغيّر شيئاً يجب أن يسأل إن كان هذا المستخدم مخوّلاً، وهذا يعني current_user_can() مع الصلاحية المحددة، مفحوصة داخل المعالج نفسه لا حول الزر الذي يستدعيه فقط.
وis_admin() ليست فحص صلاحيات. إنها تخبرك بأي جانب من الموقع جاء الطلب، وتعيد true لأي مشترك مسجل الدخول يصل إلى نقطة admin-ajax. وإجراء admin_post_ أو wp_ajax_ بلا فحص صلاحيات متاح لكل مستخدم مسجل، وهو في متجر يعني كل عميل طلب من قبل. وقائمة تعزيز أمان ووردبريس لدينا تغطي الضوابط على مستوى الموقع حول هذا الموضوع.
رموز nonce
يحمي رمز nonce نموذجاً أو رابطاً من طلب لم يقصد المستخدم إرساله. استخدم wp_nonce_field() في النموذج وcheck_admin_referer() في المعالج، أو check_ajax_referer() مع AJAX. ورغم الاسم فهي ليست لمرة واحدة: إنها بصمات صالحة لنافذة زمنية، يوم واحد افتراضياً، ضمن مخطط بنبضتين يجعل العمر الحقيقي بين اثنتي عشرة وأربع وعشرين ساعة.
وتوثيق رموز nonce صريح في أنه لا يجوز الاعتماد عليها أبداً للاستيثاق أو التخويل أو التحكم في الوصول. رمز nonce يثبت أن الطلب جاء من نموذجك. ولا يقول شيئاً عن أحقية ذلك الشخص في فعل ما يفعله.
نظّف عند الدخول وهرّب عند الخروج
تحقّق حيث تستطيع، لأن التحقق محدد: الرمز البريدي إما يطابق النمط أو لا يطابقه. ونظّف حيث لا تستطيع التحقق، باستخدام sanitize_text_field() أو sanitize_email() أو sanitize_key() أو absint() أو wp_kses_post() بحسب الحقل.
ثم هرّب عند نقطة الإخراج، في كل مرة، باستخدام esc_html() أو esc_attr() أو esc_url() أو wp_kses_post(). وتوثيق التهريب يطلب أن يكون ذلك في أقصى وقت متأخر ممكن، حتى يرى المراجع التهريب والإخراج في السطر نفسه. والتهريب هو الأكثر تخطياً من أي شيء آخر، لأن لا شيء يبدو خاطئاً حين تتخطاه. تُعرض الصفحة على أكمل وجه حتى يضع أحدهم وسم سكربت في حقل.
العبارات المُجهَّزة
كل استعلام تكتبه بنفسك يمر عبر $wpdb->prepare()، التي تأخذ %d للأعداد الصحيحة و%f للأعداد العشرية و%s للسلاسل النصية و%i للمعرّفات مثل أسماء الجداول والأعمدة. تبقى العناصر النائبة بلا علامات اقتباس، وتُكتب علامة النسبة المئوية الحرفية مرتين، ويُمرَّر محرف البدل الخاص بـ LIKE داخل وسيط الاستبدال لا مكتوباً في الاستعلام. ودمج متغير داخل SQL ليس خلافاً في الأسلوب، بل هو الثغرة نفسها.
واجهة REST ومحرر الكتل
الإضافة المكتوبة هذا العام ينبغي أن تعرض بياناتها عبر واجهة REST وإعداداتها عبر المحرر، لا عبر صفحة خيارات مصنوعة يدوياً.
تُسجَّل المسارات بـ register_rest_route() على الخطاف rest_api_init. ومنذ ووردبريس 5.5 صار وسيط permission_callback إلزامياً، وإغفاله يطلق تنبيه _doing_it_wrong() الذي يسمّي المسار. والنقطة العامة فعلاً تستخدم __return_true، وهذا هو مقصد التصميم: جعل مسار ما عاماً يصير سطر كود متعمداً بدل أن يكون سهواً. وتوثيق النقاط المخصصة يغطي أيضاً مخطط الوسائط، حيث تنتمي دوال التنظيف والتحقق، حتى لا تصل المدخلات السيئة إلى معالجك أبداً.
وتُسجَّل الإعدادات بـ register_setting() مع ضبط show_in_rest على true. وهذا يضعها على نقطة الإعدادات في النواة، فيستطيع محرر الكتل أو سكربت خارجي قراءتها وكتابتها عبر واجهة تتولى الاستيثاق والصلاحيات والتحقق أصلاً. وهو يلغي صفحة خيارات ورمز nonce الخاص بها ومعالج نموذجها والعلل الساكنة فيها.
وتُسجَّل الكتل من ملف block.json، وهو الطريقة المعيارية الموصى بها منذ ووردبريس 5.8. وتوثيق بيانات الكتلة الوصفية يبيّن الفائدة: الموارد المعلنة هناك تُحمَّل فقط على الصفحات التي تظهر فيها الكتلة، لا على الموقع كله لمجرد أن إضافة مفعّلة.
انضباط الأداء داخل الإضافة
أربعة أمور تفسر معظم البطء الناتج عن الإضافات الذي نجده في التدقيقات، وأربعتها رخيصة التفادي وباهظة المعالجة لاحقاً. الأول الخيارات المحمّلة تلقائياً، لأنها تكلّف شيئاً في كل طلب وإلى الأبد.
والثاني الطلبات البعيدة غير المخزّنة مؤقتاً أثناء تحميل الصفحة. فاستدعاء wp_remote_get() لواجهة مورّد بلا تخزين مؤقت يعني أن كل زائر ينتظر ذلك المورّد. حين يبطئ المورّد يبطؤ موقعك، وحين يتوقف يعلّق موقعك حتى تنتهي مهلة الانتظار. خزّن الاستجابة في مؤقت، واضبط مهلة صريحة، وقرّر مسبقاً ما تعرضه الصفحة حين يفشل النداء.
والثالث الاستعلامات داخل حلقة. فاستدعاء get_post_meta() لكل صف من 200 صف هو 200 رحلة ذهاب وإياب ما لم تكن ذاكرة البيانات الوصفية قد هُيِّئت مسبقاً، وWP_Query تهيّئها نيابة عنك إن تركتها. والعلاج عادة أن تكف عن تعطيل شيء ما، وهو ما يصدق على معظم ما يظهر في تدقيق Core Web Vitals.
والرابع العمل المنجز داخل طلب أحد الزوار. فـ WP-Cron ليس cron النظام: يُطلَق عند تحميل الصفحة، فتجري المهمة المجدولة داخل طلب زائر، وعلى موقع هادئ لا تعمل مهمة الثانية فجراً حتى يمر أحدهم في الخامسة. عرّف DISABLE_WP_CRON، وشغّل wp-cron.php من مجدول نظام حقيقي، وأبقِ المهام قصيرة وقابلة للتكرار دون أثر إضافي.
النجاة من تحديثات النواة: الجزء الذي لا يضع له أحد ميزانية
النواة نادراً ما تحذف شيئاً دفعة واحدة. تُهجَر الدوال فتظل تعمل وتصدر تنبيهاً، ولهذا فإن تشغيل بيئة تجريبية مع تفعيل WP_DEBUG هو أرخص نظام إنذار مبكر متاح. وتنبيه الهجر دعوة مؤرخة لإصلاح شيء ما وهو ما يزال رخيصاً.
والعملية التي تمنع المفاجآت تكلف نحو ساعة كل ربع سنة. تابع مدونة تطوير النواة لتعرف متى توجد نسخة تجريبية ثم نسخة مرشّحة للإصدار. واقرأ الـ Field Guide الذي يُنشر في مرحلة النسخة المرشّحة، ويسرد ما في ذلك الإصدار من مزايا تخص المطورين ومن تغييرات كاسرة. ثم ضع النسخة المرشّحة على نسخة تجريبية من الموقع وأجرِ اختبار دخان مكتوباً على وظائف الإضافة الحقيقية.
ودعم الإصدارات لا يقل أهمية عن الكود. يشترط ووردبريس PHP 7.4 حداً أدنى مطلقاً ويوصي بـ 8.3 أو أحدث، إلى جانب MariaDB 10.11 أو MySQL 8.0. صرّح بصدق عن Requires PHP وRequires at least في ترويسة الإضافة، ثم اختبر على أدنى إصدار صرّحت به بدل الاختبار على ما يعمل على حاسوب المطوّر.
ورقّم إصدارات إضافتك ترقيماً دلالياً والتزم بذلك. الترقيع يصلح شيئاً، والإصدار الأصغر يضيف سلوكاً دون كسر أي شيء، والإصدار الأكبر يجوز أن يكسر شرط أن يقول ما الذي كسره. والعملاء الذين يعتمدون التحديث التلقائي يتكئون على هذا الوعد.
التوزيع والترخيص وكيف تصل التحديثات إلى الموقع
يصدر ووردبريس تحت رخصة GPL الإصدار 2 أو ما بعده، وصفحة الترخيص على wordpress.org تعرض موقف المشروع بأن الإضافات والقوالب أعمال مشتقة ترث الرخصة، مع الإقرار بوجود منطقة رمادية قانونياً حول ما يُعد مشتقاً.
تحصل على الشيفرة المصدرية دائماً، ويمكنك التعاقد مع أي شخص آخر لتعديلها. وما لا تفعله الرخصة هو إجبارك على نشرها، فالإضافة المبنية لشركة واحدة يمكن أن تبقى خاصة. وهي كذلك لا تمنع المطوّر من بيع العمل نفسه لجهة أخرى. فإن كانت الحصرية مهمة فهي بند في العقد لا بند في الرخصة.
وإن ذهبت الإضافة إلى الدليل العام فعليها أن تستوفي إرشادات دليل الإضافات، وهي ثمانية عشر إرشاداً. الأول يشترط ترخيصاً متوافقاً مع GPL لكل ما في الحزمة، والصور من ضمنها. وغيره يستبعد البرمجيات التجريبية، أي الوظائف المقفلة خلف دفع أو ترقية، ويحظر الكود المُعمّى، ويمنع تتبع المستخدمين دون موافقة، ويمنع الروابط أو الإشارات المضافة إلى الموقع العام دون إذن.
وإن بقيت خاصة صارت التحديثات مشكلتك أنت. اضبط ترويسة Update URI، الموجودة لمنع أن تُستبدل إضافة خاصة بأخرى مشابهة الاسم من الدليل، وقدّم التحديثات من نقطتك الخاصة. وتأجيل هذا إلى النهاية هو الطريق الذي ينتهي بعميل يحدّث عبر FTP.
كم تكلّف إضافة ووردبريس المخصصة
النطاقات أدناه أسعار وكالات بريطانية بالجنيه الإسترليني، لعمل يُسلَّم بالمعيار الموصوف هنا: باختبارات وتوثيق وشخص مسمّى مسؤول بعد الإطلاق. ومطوّر ووردبريس وPHP الكفء يحاسب على نحو 400 إلى 600 جنيه في اليوم، فهذه إذن عبارات عن النطاق لا عن السعر اليومي.
الإضافة المساعدة الصغيرة تتراوح بين 1,500 و3,000 جنيه. مهمة واحدة، وبضعة خطافات، وربما مفتاح إعداد: معالجة إعادة التوجيه، أو حقل إضافي على الطلب، أو تصدير ليلي إلى مورّد.
والتكامل المتوسط الحجم يتراوح بين 3,000 و15,000 جنيه. واجهة طرف ثالث مع استيثاق وإعادة محاولة ومعالجة أخطاء، ونوع محتوى مخصص، وشاشات إدارة، ومعالجة في الخلفية. وهذا هو الحجم الأكثر طلباً والأكثر استهانة به، لأن التكامل أسبوع ومعالجة الإخفاق أسبوعان.
وإضافة المنتج الكبيرة تتراوح بين 20,000 و75,000 جنيه وما فوق. جداول خاصة بها، وواجهات في محرر الكتل، وبنية ترخيص وتحديث، ودعم تعدد المواقع، وعبء دعم يبدأ يوم إطلاقها.
والدفع عند الطرف الأدنى ليس خطأ بالضرورة. يصير خطأ حين يأتي السعر من نطاق استبعد بصمت المخرجات المذكورة أدناه. ودليلنا عن أسعار مطوّري ووردبريس وما ينبغي سؤاله يشرح كيف يُقرأ عرض السعر، وصفحة تطوير ووردبريس لدينا تبيّن كيف نحدد نطاق هذا العمل.
ما ينبغي أن يتضمنه التسليم
اطلب كل هذا كتابةً قبل بدء العمل، لأن كل بند منه رخيص عند التضمين وباهظ عند الإضافة لاحقاً. الشيفرة المصدرية، في مستودع تملكه أنت، بتاريخها كاملاً، لا ملفاً مضغوطاً يُرسل بالبريد في اليوم الأخير. واختبارات وحدة لقواعد العمل واختبار تكامل لكل ما يكتب في قاعدة البيانات أو ينادي خدمة خارجية، وهو ما يجعل تغييره آمناً بعد عامين على يد شخص لم يكن حاضراً.
وملف readme يقول ماذا تفعل الإضافة، وبأي شيء ترتبط، وماذا تخزّن وأين، وأي خدمات خارجية تنادي وماذا يحدث حين يسقط كل منها. صفحتان تكفيان، وغيابه هو سبب استبدال الإضافات بدل صيانتها. وملف uninstall.php يزيل الخيارات والجداول وأحداث cron والبيانات الوصفية. واتفاق دعم بشخص مسمّى يغطي الاختبار مقابل كل إصدار من النواة وإصلاح ما يكشفه ذلك الاختبار.
كيف نبنيها
تبني Mecanik الإضافات بالأحجام الثلاثة أعلاه، وتتسلّم إضافات كتبها غيرها، وهي غالباً المهمة الأنفع. وصفحتا مطوّر ووردبريس وتطوير البرمجيات لدينا تشرحان كيف نحدد النطاق ونسلّم. وإن كانت لديك إضافة لا يريد أحد الاقتراب منها، فتدقيقها وفق الممارسات أعلاه يستغرق نحو يوم واحد ويخبرك إن كانت قابلة للإصلاح أم للاستبدال.
الأسئلة الشائعة
هل توضع الوظائف المخصصة في إضافة أم في القالب؟ في إضافة، ما لم تكن شكلية بحتة. فالقالب يُستبدل عند إعادة التصميم التالية ويتوقف كل ما كان يفعله: تفقد أنواع المحتوى المخصصة شاشات الإدارة، وتظهر الأكواد المختصرة نصاً خاماً، وتتوقف عمليات التكامل في صمت. وكل ما يجب أن يبقى صحيحاً بعد إعادة التصميم ينتمي إلى إضافة.
كم تكلّف إضافة ووردبريس مخصصة في المملكة المتحدة؟ الإضافة المساعدة الصغيرة تكلّف عادة بين 1,500 و3,000 جنيه، والتكامل المتوسط مع واجهة طرف ثالث وشاشات إدارة يكلّف بين 3,000 و15,000 جنيه، وإضافة المنتج الكبيرة بجداولها الخاصة وبنية التحديث تكلّف بين 20,000 و75,000 جنيه أو أكثر. والمطورون القادرون على هذا العمل يحاسبون على نحو 400 إلى 600 جنيه في اليوم.
هل يقبل يوماً تعديل نواة ووردبريس أو ملفات إضافة أخرى؟ لا. تلك التعديلات يمحوها التحديث التالي، بلا خطأ وغالباً بلا اكتشاف حتى يتوقف شيء عن العمل. استخدم الإجراءات والمرشّحات بدلاً من ذلك. وإن لم يوجد الخطاف الذي تحتاجه، فغلّف السلوك، أو انسخ الإضافة تحت إدارة إصدارات، أو اطلب الخطاف من المصدر الأصلي.
هل أملك إضافة دفعت لأحدهم كي يبنيها؟ تملك نسختك وما ينص عليه العقد. رخصة GPL تمنحك الشيفرة المصدرية وحق تعديلها وحق التعاقد مع أي شخص آخر لصيانتها، ولا تلزمك بنشرها، فالإضافة المبنية لشركة واحدة يمكن أن تبقى خاصة. وهي لا تمنع المطوّر من إعادة بيع العمل نفسه، فضع الحصرية في العقد إن كانت تهمك.
كيف تمنع انكسار إضافة عند تحديث ووردبريس؟ اختبرها مقابل كل نسخة مرشّحة للإصدار على نسخة تجريبية قبل صدور ذلك الإصدار، وشغّل البيئة التجريبية مع تفعيل WP_DEBUG كي تظهر تنبيهات الهجر مبكراً، وصرّح في الترويسة عن إصدارات PHP وووردبريس التي تدعمها الإضافة. ويشترط ووردبريس PHP 7.4 حداً أدنى ويوصي بـ 8.3 أو أحدث.
التعليقات