الأخطاء الـ 12 الأسوأ التي يرتكبها مطورو WordPress المتقدمون

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

1. وضع كود JavaScript لقالب WordPress في ملف رئيسي واحد

ذات مرة ، أثناء القيام بتحسين سرعة الصفحة لمواقع الويب الخاصة بالعميل ، لاحظت أنهم كانوا يستخدمون سمة مميزة تحتوي على جميع المكتبات التي كانوا يستخدمونها ، بما في ذلك الشفرة المخصصة ، في ملف واحد يسمى main.js أو theme.js أو custom.js . هذه الممارسة سيئة للأسباب التالية:

1. يمكن للملف ، بمرور الوقت ، أن يصبح كبيرًا حقًا لأن المظهر ، الذي يتم تطويره بنشاط ، سينمو في الميزات وأحيانًا سترى ملفات بحجم 1 ميغابايت. سيتم تحميل الملف على مستوى الموقع حتى إذا كانت هناك حاجة إلى 10٪ فقط من التعليمات البرمجية من الملف في بعض الصفحات. سيؤدي هذا إلى جعل الصفحات تستغرق وقتًا أطول للتنزيل ويبطئ عرضها ، خاصةً إذا كانت تعرض رمز الحظر داخل قسم الرأس بالصفحة.
2. يجعل إدارة الكود داخل الملف أكثر صعوبة ، حيث لا يمكنك استخدام وظائف مثل wp_dequeue_script() لتفريغ بعض التعليمات البرمجية في بعض الصفحات إما لتحسين سرعة الصفحة أو لمنع التعارض مع تعليمات JavaScript البرمجية الأخرى التي يمكن أن تكون تم تحميله بواسطة أحد المكونات الإضافية النشطة. بالتأكيد ، يمكن تقسيم الملف إلى عدة ملفات وإدراجها في قائمة الانتظار في WordPress ، ولكن إذا قام مسؤول الموقع في وقت لاحق بإجراء تحديث لملف main.js الخاص بالسمة ، فيجب أن تبدأ العملية برمتها من جديد.

2. استخدام الأسماء الشائعة جدًا للمتغيرات أو الوظائف أو الثوابت أو الفئات

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

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

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

أوصي بفهم جيد لمساحات الأسماء قبل استخدامها حيث يمكن استخدامها في كثير من الأحيان بطريقة خاطئة.

اعتمادًا على المشروع الذي ستتكفل به ، من المحتمل أنه سيتعين عليك الالتزام بأسلوب الترميز الحالي ، ما لم يكن عملك منفصلاً في الغالب عن العمل الحالي. في حال اضطررت إلى تمديد مكون إضافي أو سمة موجودة بالفعل تتبع معايير ترميز PHP لـ WordPress ، فمن الأفضل التمسك بها من أجل الحصول على نمط متسق حتى تصبح الشفرة نظيفة وسهلة القراءة. لاحظ أنه يتم تطبيق بعض القواعد عالميًا من أجل تحسين الأداء ، بغض النظر عن أسلوب الترميز. على سبيل المثال ، من الأفضل دائمًا استخدام علامات الاقتباس المفردة (بدلاً من علامات الاقتباس المزدوجة) إذا لم تكن تقيم أي شيء في السلسلة. أيضًا ، يجب وضع مسافة بادئة للشفرة لتتم قراءتها ، خاصةً إذا كانت تحتوي على كود متداخل (على سبيل المثال ، IF s ضمن IF s ، FOREACH s و FOR s).

3. عدم الاستفادة من وظائف WordPress الأساسية الحالية لإمكانياتها الحقيقية

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

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

4. عدم جعل المكون الإضافي أو السمة سهلة التغيير من خلال الإجراءات والفلاتر

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

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

5. التطوير باستخدام WP_DEBUG اضبط على false

افتراضيًا ، يتم تعيين ثابت WP_DEBUG على "خطأ" لتجنب طباعة أي أخطاء وتحذيرات وإشعارات PHP. في بيئة حية ، يعد هذا اختيارًا موصى به لأنه يحافظ على مسارات الخادم الخاصة والبرامج النصية مخفية عن العرض العام ، وهو أمر رائع لأسباب أمنية. ومع ذلك ، أثناء مرحلة التطوير ، من الأفضل ضبطها على "true" لأنها ستعلمنا بأي أخطاء في الكود الخاص بنا. حتى إذا لم تؤثر الأخطاء بشكل مباشر على الوظيفة ، فغالبًا ما يجبرك على كتابة كود أفضل وتطوير عادات تشفير أفضل. هذا ما حدث معي. سيضمن هذا أيضًا أن المكون الإضافي أو السمة التي تقوم بتطويرها لا تولد أخطاء PHP في أي تثبيت WordPress.

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

6. كتابة كود PHP دون النظر إلى إمكانية تخزين الصفحة في ذاكرة التخزين المؤقت يومًا ما

هذا خطأ شائع في PHP ، ومثل الخطأ السابق ، من السهل نسبيًا تجنبه إذا التزمت بمعايير تشفير PHP.

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

إذا قام عميلك بتثبيت مكون إضافي يقوم بتخزين الصفحة مؤقتًا (على سبيل المثال ، W3 Total Cache أو WP Rocket) دون تشغيل الشروط في قالبك أو المكونات الإضافية ، فسيصبح كود PHP الخاص بك عديم الفائدة. إذا كان القصد هو جعل الصفحات تستجيب ، فيجب أن يتم ذلك على الجانب الأمامي من خلال استعلامات الوسائط وجافا سكريبت. هذا الأخير ، فقط إذا كان مطلوبًا حقًا. من الناحية المثالية ، تريد تجنب استخدام JavaScript لجعل موقعك مستجيبًا.

7. عدم تتبع التغييرات التي تم إجراؤها بطريقة احترافية من خلال نظام التحكم في الإصدار مثل Git

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

على الرغم من أنه قد يكون أمرًا مخيفًا في البداية ، خاصة للمطورين المبتدئين ، إلا أن فهم Git يستحق الوقت وستكون برامج Git GUI مثل SourceTree (أحد المفضلات لدي) هي الطريقة التي تتفاعل بها مع مستودعات Git الخاصة بك ، مما يجعل الكل منحنى التعلم أكثر إمتاعا. بمجرد أن تفهم كيفية عملها ، ضع في اعتبارك مراجعة Git Best Practices and Tips بواسطة Toptal Developers الذي يشرح بمزيد من العمق بعض الطرق لاستخدام Git.

8. إدراج ملفات CSS و JavaScript عند عدم الحاجة إليها

سيؤدي وجود العديد من طلبات HTTP إلى جعل موقع الويب أبطأ في التحميل ، وبالتالي الحصول على درجة أقل في Google PageSpeed ​​مما قد يؤثر على ترتيب البحث. يمكن أن يؤدي أيضًا إلى أخطاء JavaScript بسبب التعارض بين المكونات الإضافية. على سبيل المثال ، يمكن أن يكون هناك مكونان إضافيان يستخدمان مكتبة jQuery شائعة ، والتي يمكن تحميلها مرتين ويمكن أن تسبب مشاكل. وفي الحقيقة ، هذا هو أفضل مثال ، حيث يتم تحميل jQuery بشكل شائع على مواقع الويب الحية عدة مرات. ربما يحدث هذا بسبب المكونات الإضافية أو السمات المكتوبة بشكل سيئ.

9. استخدام ملفات .php لإخراج كود CSS أو JavaScript بدلاً من ملفات .css و .js الثابتة

لقد رأيت سمات وحتى إضافات WordPress التي تحتوي على ملفات مثل style.php والتي تم استخدامها فقط لإنشاء كود CSS مخصص وطباعته. تم تعيين أشياء مثل الألوان وأحجام الخطوط والتباعد حول العناصر في إعدادات السمة ثم حفظها في قاعدة البيانات. ثم تتم قراءة style.php (على سبيل المثال ، <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) وتقوم بإنشاء كود CSS بناءً على الإعدادات المخصصة التي تم تحديثها في لوحة القيادة.

هذه ممارسة سيئة حقًا من حيث أداء WordPress. فيما يلي العيوب الرئيسية التي تأتي معها:

1. نظرًا لأنه يتم تحميل ملف CSS داخل علامة head (وهو أمر طبيعي ويتم تحميل معظمها على هذا النحو) ، فهناك مشكلة في الأداء تأتي مع هذا حيث يتعين على المتصفح تنزيل الملف بالكامل قبل عرض الصفحة. إذا كانت بيئة WordPress بطيئة بسبب بعض المكونات الإضافية ، فسيؤدي ذلك إلى تأخير وقت التحميل إلى حد كبير. حتى إذا تم استخدام تقنيات التخزين المؤقت أو تم تحميل جزء فقط من بيئة WordPress لاسترداد القيم من قاعدة البيانات. من الأفضل استخدام ملف .css ثابت بدلاً من ذلك.
2. في ملف PHP ، سيكون من الصعب قراءة الكود (قواعد CSS الممزوجة بمتغيرات PHP والجمل الشرطية) من قبل المطورين عندما يحتاجون إلى التحقق من شيء ما. بالتأكيد ، يمكن تشغيل الملف في المتصفح (على الرغم من أنني متأكد من أنه عند طباعته ، فلن يكون هناك مسافة بادئة أو مظهر جميل) ولكن إذا كان لديك نسخة محلية من المشروع وتصفح من خلال رمز الموضوع وتحتاج للعثور على بناء جملة CSS أو JavaScript (في حالة استخدام script.php) ، فإن ذلك سيجعل قابلية القراءة أكثر صعوبة.

الحل: احفظ أي CSS مخصص خارج دليل البرنامج المساعد. مثال: /wp-content/uploads/theme-name-custom-css/style-5.css . بهذه الطريقة ، في حالة تحديث السمة أو المكون الإضافي ، فلن يتم فقد الملف المخصص.

10. عدم استخدام البنية الصحيحة (منظمة الكود) لملحقات و ثيمات WordPress

اعتمادًا على حجم وطبيعة المكون الإضافي (على سبيل المثال ، مكون إضافي مستقل أو ملحق إضافي يعمل فقط إذا تم تنشيط مكون إضافي رئيسي مثل WooCommerce) ، يجب إعداد البنية الصحيحة وتنظيم الكود.

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

إذا كان المكون الإضافي سيظهر غنيًا بالكثير من التعليمات البرمجية ، فإن استخدام نهج البرمجة الشيئية (OOP) (مع وجود الكثير من الفئات) سيكون منطقيًا. على سبيل المثال ، إذا كان لديك الكثير من الرموز القصيرة ، فيمكنك الاحتفاظ بها جميعًا في ملف فئة منفصل مثل class.shortcodes.php أو إذا كانت هناك ملفات CSS و JavaScript من المفترض أن يتم تحميلها داخل لوحة التحكم وعرض الواجهة الأمامية ثم يمكن استخدام فئة واحدة مثل class.scripts.php ملفات الواجهة الأمامية في قائمة الانتظار ضمن طريقة مثل enqueue_public_scripts() أثناء وضع قائمة بالملفات المعدة للتحميل في منطقة المسؤول داخل طريقة enqueue_admin_scripts() .

بدلاً من مزج HTML مع كود PHP ، من الأفضل فصلها عن طريق تطبيق نمط MVC في المكونات الإضافية والسمات. وخير مثال على ذلك هو البرنامج المساعد WooCommerce. يحتوي على قوالب لتخطيطات مختلفة يمكن أيضًا الكتابة فوقها بسهولة من خلال السمة أو عوامل التصفية المختلفة لمجرد فصل المنطق عن التصميم. يستخدم النموذج الذي يحتوي على تنسيق HTML في الغالب لطباعة المعلومات التي تمت معالجتها بالفعل. عادةً ما يكون وجود كود HTML ضمن طرق PHP ممارسة سيئة (هناك استثناءات بالطبع للقطع الصغيرة من كود HTML) ، خاصة بالنسبة للمكوِّن الإضافي الذي يحتفظ به أكثر من مطور واحد مع نمو حجمه.

وفقًا لكتيب WordPress Plugin ، في حين أن هناك عددًا من أنماط البنية الممكنة ، يمكن تجميعها على نطاق واسع في ثلاثة أشكال:

• ملف ملحق واحد يحتوي على وظائف
• ملف مكون إضافي واحد ، يحتوي على فئة ، وكائن مُنشأ ، ووظائف اختياريًا
• ملف البرنامج المساعد الرئيسي ، ثم ملف فئة واحد أو أكثر

11. عدم أخذ أمان WordPress على محمل الجد عند كتابة التعليمات البرمجية

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

بعض أهم نصائح الأمان هي:

ثغرات XSS: لتجنب ذلك ، يجب القيام بأمرين: تعقيم إدخال البيانات وتعقيم بيانات الإخراج. اعتمادًا على البيانات والسياق المستخدم فيه ، هناك عدة طرق في WordPress لتعقيم الكود. لا ينبغي للمرء أن يثق في أي بيانات إدخال ، ولا أي بيانات سيتم طباعتها. إحدى الوظائف الشائعة لتعقيم إدخال البيانات هي sanitize_text_field() . يقوم بالتحقق من عدم صلاحية أحرف UTF-8 ، وتحويل الأحرف <الفردية إلى كيانات HTML ، وإزالة جميع العلامات ، وإزالة فواصل الأسطر ، وعلامات التبويب ، والمسافة البيضاء الزائدة ، وثمانيات الشريط. بالنسبة إلى طباعة البيانات ، فإن أحد الأمثلة الجيدة لإخراج الروابط هو وظيفة esc_url() ، التي ترفض عناوين URL غير الصالحة ، وتزيل الأحرف غير الصالحة ، وتزيل الأحرف الخطرة.

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

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

إذا لم يتم تعريف ABSPATH الثابت (والذي يجب أن يكون لأي تثبيت WordPress) ، فسيخرج البرنامج النصي ولا يطبع أي شيء.

استخدام Nonces: كما هو مذكور في وثائق WordPress ، فإن nonce هو "رقم يُستخدم مرة واحدة" للمساعدة في حماية عناوين URL والنماذج من أنواع معينة من إساءة الاستخدام ، ضارة أو غير ذلك.

على سبيل المثال ، سيتم استخدام عنوان URL التالي داخل لوحة التحكم لإرسال منشور إلى المهملات: http://example.com/wp-admin/post.php?post=123&action=trash —عند الوصول إلى عنوان URL هذا ، سيقوم WordPress بالتحقق من صحة معلومات ملفات تعريف الارتباط الخاصة بالمصادقة وإذا كان لديك الإذن الصحيح (على سبيل المثال ، أنت مسؤول مع جميع الامتيازات) ، فسيتم حذف هذا المنشور.

ما يمكن للمهاجم فعله هو جعل المستعرض الخاص بك يصل إلى عنوان URL هذا دون علمك عن طريق إنشاء ارتباط على صفحة جهة خارجية كما في المثال التالي: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> عند تقديم هذا الطلب إلى WordPress ، سيقوم المتصفح تلقائيًا بإرفاق ملف تعريف ارتباط المصادقة الخاص بك وسيعتبر WordPress الطلب صالحًا.

هذا عندما يأتي nonce في مكانه حيث لن يتمكن المهاجم من الحصول على قيمة nonce (التي تم إنشاؤها للمسؤول الذي قام بتسجيل الدخول بالفعل إلى WordPress) بهذه السهولة. سيظهر عنوان URL الجديد للطلب بالشكل التالي: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

بدون رقم nonce صالح ، سيتم إرسال رد 403 Forbidden إلى المتصفح بواسطة WordPress مع رسالة الخطأ المعروفة: "هل أنت متأكد أنك تريد القيام بذلك؟"

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

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

12. استخدام وظائف WordPress ومقتطفات التعليمات البرمجية دون فهمها

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

لقد رأيت هذه الممارسة عدة مرات عندما يتم نسخ مقتطفات من التعليمات البرمجية داخل نصوص PHP عندما يتم استخدام ثلث هذا الرمز فقط بالفعل.

يمكن أن يكون لهذا بعض العيوب ، بما في ذلك:

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

التحسين المستمر

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

هل تختلف مع أي من الأخطاء التي أشرت إليها ، أو تعتقد أني فاتني أحد؟ اسمحوا لي أن أعرف في التعليقات وسنناقش.