قد يبدأ التعديل المطلوب بجملة بسيطة: «غيّر الرسالة التي تصل إلى العميل بعد الدفع». ثم يقضي المطور وقتًا في البحث عن مصدر الرسالة: القالب، أم إضافة لإدارة مقتطفات الكود، أم عنصر داخل منشئ الصفحات، أم إضافة أخرى؟ المشكلة هنا ليست مكان الملف فقط، بل غياب إجابة واضحة عن الجزء المسؤول عن السلوك.
عند بداية عملي على OVZA، كانت هناك صفحات دفع بسيطة، مع كود موزع بين ملف functions.php وإضافة snippets وعناصر HTML في Elementor. أنشأت الإضافات المخصصة التي أتناولها في دراسة الحالة وطورت من خلالها وظائف الخدمة. لا يعني ذلك أن كل كود سابق أُزيل، أو أن تحويل الكود إلى إضافة يكفي وحده لضمان جودته.
أعطِ الوظيفة مسؤولية واضحة
لنأخذ مثالًا افتراضيًا لشركة خدمات تطلب مستندات بعد الدفع، ثم تخبر الموظف عند وصولها. هذه قواعد تخص تشغيل الخدمة، حتى لو ظهر النموذج داخل صفحة ذات تصميم معين.
أميل إلى وضع هذه المسؤولية داخل إضافة واضحة الحدود، بحيث يمكن تغيير تصميم الصفحة دون إعادة اكتشاف قواعد قبول المستندات وإرسال الإشعارات. يمكن للإضافة إظهار الوظيفة عبر وسيلة تناسب الموقع؛ المهم أن يبقى القرار التشغيلي في مكان معروف.
هذا لا يجعل كل snippet خطأ. تعديل صغير يخص عرض عنصر في القالب قد يكون مناسبًا في موضعه إذا كان موثقًا ومفهومًا. أسأل بدلًا من ذلك: كم سيعيش هذا السلوك؟ ومن يحتاج إلى تغييره؟ وما الذي سيتعطل إذا تغير القالب؟ الإجابات تساعد على تحديد المكان المناسب.
نظّم الملفات وفق الأسئلة المتوقعة
يمكن أن تتحول الإضافة نفسها إلى ملف ضخم يصعب فهمه. لذلك أفضّل فصل ما يستقبل البيانات، وما يطبق القواعد، وما يرسل الرسائل، وما يعرض أدوات الموظفين. الهدف أن يجد المطور إجابة عن سؤاله دون قراءة المشروع كله.
توصي وثائق ووردبريس بتجنب تعارض الأسماء وتجميع الملفات المرتبطة، وتربط مستوى التعقيد بحجم الإضافة؛ فالوظيفة الصغيرة لا تحتاج بالضرورة إلى هيكل معقد من الأصناف. إرشادات تنظيم إضافات ووردبريس.
وفي موقع يخدم عملاء بالعربية والإنجليزية، أفصل صياغة الرسائل عن شروط إرسالها. ينبغي أن يميّز المراجع بين تعديل لغوي فقط وتعديل يغيّر مستلم الرسالة أو توقيت إرسالها. هذا فرق عملي يهم فريق التشغيل بقدر ما يهم المطور.
انقل سلوكًا كاملًا في كل خطوة
نقل الكود يحتاج أولًا إلى حصر نقاط تشغيله. ما الحدث الذي يستدعيه؟ أين تُحفظ إعداداته؟ وهل توجد قطعة أخرى تنفذ التصرف نفسه؟ تجاهل السؤال الأخير قد يترك مسارين يعملان معًا بعد النقل.
في مثال طلب المستندات، أوثق السلوك الحالي وأجربه ببيانات اختبار، ثم أنقله إلى الإضافة مع تعطيل نقطة التشغيل القديمة ضمن التغيير نفسه. إذا ظلت النسختان تعملان، قد تصل الرسالة مرتين رغم أن كل ملف يبدو صحيحًا عند مراجعته منفردًا.
يمكن تنفيذ الانتقال تدريجيًا إذا احتاج الموقع إلى الاستمرار في العمل. لكن يجب تسجيل ما انتقل وما بقي، ومن المسؤول عن الجزء المتبقي. الحالة المؤقتة غير الموثقة يسهل أن تصبح وضعًا دائمًا يربك كل من يأتي بعدها.
راجع الصلاحية عند تنفيذ الإجراء
وجود زر داخل لوحة الإدارة لا يثبت أن كل من يستطيع إرسال الطلب مسموح له بتنفيذ الإجراء. إذا كانت الإضافة تسمح باعتماد مستند، يجب مراجعة المعالج الذي يستقبل الطلب، لا مظهر الزر وحده.
يوفر ووردبريس فحوص capabilities للتحقق من صلاحية المستخدم. وتوضح وثائق nonce أنه ليس بديلًا عن التحقق من الإذن.
أقترح تجربة موظف يملك الإذن، وحساب لا يملكه، وعميل يحاول الوصول إلى طلب يخص شخصًا آخر. المقصود التأكد من حدود الوظيفة الفعلية، بدل افتراض أن مجرد تسجيل الدخول كافٍ.
اترك مع الكود ما يساعد على استلامه
ملاحظة تسليم قصيرة ينبغي أن توضح مسؤولية الإضافة، وإعداداتها، والخدمات الخارجية التي تعتمد عليها، وطريقة تجربة المسار الأساسي. أضيف أيضًا ما سيحدث إذا عُطلت: أي خطوة ستتوقف، ومن سيتأثر بها؟
القيمة ليست في عدد الملفات ولا في اسم النمط البرمجي. القيمة أن يستطيع الفريق إجراء التعديل التالي، وفهم أثره، والرجوع عنه عند الحاجة، دون البحث العشوائي في أجزاء الموقع. هذه قابلية للصيانة يمكن مناقشتها والتحقق منها.
اطّلع على دراسة حالة OVZA لمعرفة حدود مساهمتي في الإضافات ومسارات العمل.
أسئلة شائعة
متى تكون إضافة ووردبريس خاصة خيارًا مناسبًا؟
عندما تحتاج وظيفة تجارية إلى مكان واضح لقواعدها، وتحتاج إلى الاستمرار مع تغيير القالب أو تصميم الصفحات. يتناسب حجم البنية مع حجم الوظيفة.
هل يجب تحويل كل مقتطف كود إلى إضافة؟
لا. ننظر إلى مسؤوليته واعتمادياته وعمره المتوقع. تعديل العرض البسيط قد يبقى بسيطًا، بينما يحتاج مسار العمل المترابط إلى حدود أوضح.