بعض الأخطاء الشائعة التي يرتكبها بعض مطوري ووردبريس

raheel · 01-04-2019, 03:34 PM

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

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

عدم المعرفة الجيدة بإمكانات وميزات ووردبريس يقود عددا من المطورين للبحث عن إضافات أو حلول خارجية للقيام بوظائف هي مدعومة أصلا من ووردبريس! نسبة كبيرة منهم مازالوا يقومون بإضافة مكتبات جافاسكريبت مثل جيكويري لمجلد القالب الخاص بهم واستدعاؤها وهم لا يعلمون بأن ووردبريس يعتمد افتراضيا على جيكويري ويقوم بتحميلها نيابة عنا، كل ما علينا فعله هو إضافة محدد id مكتبة جيكويري (jquery) لمصفوفة التبعيات Dependencies التي يحتاجها السكريبت الخاص بك وذلك على هذا النحو :
wp_enqueue_script('my-custom-script', get_template_directory_uri() .'/js/my-custom-script.js', array('jquery'), null, true);
1
2
3

wp_enqueue_script('my-custom-script',
get_template_directory_uri() .'/js/my-custom-script.js',
array('jquery'), null, true);

هذا فقط مثال بسيط للغاية عما يمكن أن يؤدي إليه جهل المطور بإمكانيات ووردبريس الإفتراضية.
هذا الكلام كله يجعلنا نؤكد على ضرورة التحديث الدوري والمستمر لجميع الإضافات والقوالب التي تقوم باستخدامها وطبعا تحديث نواة ووردبريس يدخل كذلك ضمن هذا الإطار. فمع كل تحديث هناك إما إضافة ميزات جديدة أو إصلاح عيوب قديمة بعض منها قد يكون خطيرا إذا ما تعلق بالجانب الأمني للسكريبت.
3. ترك الثابت WP_DEBUG على قيمته الإفتراضية false أثناء التطوير

يتوفر ووردبريس على ثابت اسمه WP_DEBUG يمكن المطور من إظهار الأخطاء Erros أو التحذيرات Warnings البرمجية في واجهة المستخدم، وذلك للتأكد من عدم وجود أي خطأ في الموقع أو تتبع مصدر الأخطاء في حالة وجودها.
القيمة الإفتراضية لهذا الثابت، الذي نجده في الملف wp-config.php، هي false أي أن الأخطاء لن تظهر إلا إذا تم تغيير القيمة إلى true، وهذا طبيعي لأننا لا نريد أن يرى زوار الموقع أخطاءً أو تحذيرات على شاشاتهم
يجب على المطور أن يغير قيمة WP_DEBUG إلى true في المشروع على الخادم المحلي وعند الإنتهاء من التطوير يعيد القيمة إلى حالتها الإفتراضية false قبل نشر التغييرات على خادم الإنتاج Production Server.
4. عدم حفظ نسخ ملفات المشروع عن طريق برنامج احترافي وعملي لإدارة النسخ

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

كل طلب HTTP يتم إرساله يعني زيادة في وقت تحميل الصفحة. يجب التفكير دائما عند استدعاء أي ملف CSS أو JavaScript طرح السؤال فيما إذا كنت أحتاج إليه في جميع صفحات موقعي أم في صفحات معينة فقط. ووردبريس يضع بين أيدينا واجهة برمجية ممتازة وسهلة لمساعدة المطورين على تنفيذ أكوادهم في الوقت والمكان المناسب.
الكود التالي يقول لووردبريس قم باستدعاء ملف my_style.min.css فقط في صفحات single حيث يعرض محتوى المقال :
function register_my_style() { if ( is_single() ) { wp_enqueue_style( 'my-style', get_stylesheet_directory_uri() . '/css/my_style.min.css' ); } } add_action( 'wp_enqueue_scripts', 'register_my_style' );
1
2
3
4
5
6
7

function register_my_style() {
if ( is_single() ) {
wp_enqueue_style( 'my-style',
get_stylesheet_directory_uri() . '/css/my_style.min.css' );
}
}
add_action( 'wp_enqueue_scripts', 'register_my_style' );

6. عدم تنظيم الكود وفقا لأنماط التصميم البرمجي المعروفة

عندما تقوم بتصميم إضافة أو قالب ووردبريس بسيط فإننا لا نجد أنفسنا مجبرين لوضع خطة أو بنية محكمة لتنظيم الكود، ففي هذه الحالة تكون الملفات قليلة وكذلك وظائف القالب أو الإضافة معدودة وغير معقدة.
ولكن عندما نبدأ العمل على مشروع متوسط أو كبير فلن يكون من الحكمة جمع الأكواد البرمجية كلها في ملف functions.php، فمع التقدم في العمل سترى بأنك أمام ملف طويل وغير منظم وصعب القراءة خاصة على الآخرين.
البرمجة الكائنية تصبح محمودة للغاية في مثل هذا النوع من المشاريع، فجمع أكواد shortcodes مثلا في كلاس اسمه class.shortcodes.php أفضل من وضعها في ملف functions.php مع كل الوظائف والدوال الأخرى. نفس الكلام يمكن قوله عن ال widgets و استدعاء سكريبتات الجافاسكريبت وأكواد CSS إلخ…
هذا ويفضل دائما عدم خلط أكواد HTML وPHP في نفس الملفات، ما المانع من استخدام نمط ال MVC لفصل المشاهد Views عن منطق المشروع (كود PHP) ؟ لا مانع بالطبع، إضافة WooCommerce التي يعرفها الجميع يعتمد مطوروها على هذا النمط ويمكن للمستخدم التعديل على قوالب المشاهد Views المعزولة عن متاهات وصداع ال PHP.
الإعتماد على أنماط التصميم Design Patterns في البرمجة بصفة عامة غاية في الأهمية، وفي ووردبريس تتكرس هذه الحاجة بمرور السنوات مع تطور نوعية المشاريع وزيادة درجة تعقيدها.
7. استعمال مقتطفات من شفرات برمجية دون فهمها

يلجأ معظم المبرمجين، إن لم نقل كلهم، للبحث في غوغل أو StackOverflow عن حلول لمشاكل برمجية قد يصادفونها في مشاريعهم، وعند إيجادها تكون عبارة عن أسطر من أكواد برمجية والواجب هنا هو قراءتها وفهم كل سطر على حدة. التقاط مجموعة من الأكواد من هنا وهناك ولصقها في المشروع دون استيعابها لمجرد أنها تعمل من دون مشاكل آنية قد يسبب مشاكل في وقت لاحق، خاصة عندما نريد تطوير وتوسيع Scale بعض الوظائق المتعلقة بهذه الأكواد مع تطور المشروع.
هذا دون أن ننسى أن الواجهات البرمجية API لووردبريس تتعرض للتطوير والتحسين بكيفية مستمرة، وبالتالي قد تكون الأكواد التي وجدتها في StackOverflow تستخدم دوالا functions مهملة Deprecated أو منسوخة ولم يعد ينصح باستخدامها إما لدواعي أمنية أو لأسباب تتعلق بالأداء والفعالية.
المطور الذي يحترم عمله يعي جيدا ضرورة فهم كل سطر برمجي يقوم بكتابته حتى يكون بوسعه تحمل كافة المسؤوليات والتعهدات بينه وبين العميل والمتعلقة بالمشروع.
8. إهمال الجوانب الأمنية

لا تثق أبدا في مدخلات المستخدمين Do not trust users input، هذه مقولة شهيرة في ميدان البرمجة وهي صحيحة ومنطقية لأبعد الحدود، فمستخدمو تطبيقك منهم الصالح والطالح، الطيب والخبيث ولذلك عليك معالجة جميع المدخلات Inputs التي تأتي من المستخدمين قبل حفظها في قاعدة البيانات على سبيل المثال.
هناك العديد من الدوال في ووردبريس لهذا الغرض، لعل أكثرها استخداما sanitize_field_text التي تقوم بتطهير جميع القيم التي يتم إرسالها من قبل المستخدمين عبر الفورمات في موقعك وذلك لتفادي وقوعك كضحية لهجمات XSS التي تكون في بعض الأحيان غاية في الخطورة.
هذا ويفضل دائما الإستعانة بما يصطلح عليه nonces وهي بمثابة حقول تحتوي على نصوص على شكل أرقام وتستخدم مرة واحدة فقط للتأكد من كون المستخدم أرسل البيانات فعلا من الفورم وليس من مكان آخر. بدون استخدامها، ستعرض تطبيق لخطر هجمات خطيرة تعرف ب CSRF Attacks.
وهنا تجدون دليلا مفصلا من ووردبريس يحتوي على أهم الطرق والممارسات التي يجب اتباعها لتأمين مشاريعكم.
النهاية

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

المصدر: منتديات رحيل لكل العرب - من قسم: قسم تطوير المواقع ومحركات البحث والسيو Seo والووردبريس WordPress

01-04-2019, 03:34 PM	#1
raheel تاريخ التسجيل: Feb 2019 العمر: 38 المشاركات: 1,149 التقييم: 10	raheel تاريخ التسجيل: Feb 2019 العمر: 38 المشاركات: 1,149 التقييم: 10 بعض الأخطاء الشائعة التي يرتكبها بعض مطوري ووردبريس بعض الأخطاء الشائعة التي يرتكبها بعض مطوري ووردبريس لا يخفى على أحد الإقبال الكبير من مطوري الويب على برنامج إدارة المحتوى ووردبريس لكونه الأكثر استخداما والأكثر طلبا في سوق العمل، ولقد بينا في مقال سابق أن ووردبريس ينعش تجارة ضخمة على شبكة الإنترنت تقدر بعشرات الملايين من الدولارات. يجذب ووردبريس المطورين بجميع المستويات والخبرات، فمن مميزاته أنه سهل ولا يتطلب سوى معرفة متوسطة بلغة البرمجة PHP و بطبيعة الحال HTML و CSS حتى يبدأ المطور مغامرته مع هذا السكريبت. نسبة معتبرة من هؤلاء المطورين لا يكلفون أنفسهم عناء زيارة التوثيق الخاص بووردبريس، والمعروف ب WordPress Codex، مما يؤدي بهم لإرتكاب أخطاء قد تكون في بعض الأحيان فادحة نتيجة لمخالفتهم عدد من الممارسات الجيدة التي يوصي بها القائمون على هذا البرنامج. من خلال هذا المقال سوف ألقي الضوء على أبرز الأخطاء الشائعة التي يقع فيها مطورو ووردبريس في مشاريعهم، والهدف هو المساعدة في تفاديها وتداركها في أعمالكم القادمة. 1. استخدام أسماء شائعة للمتغيرات والدوال وكذلك الكلاسات ووردبريس برنامج مرن قابل للتخصيص والإمتداد بفضل نظامي الإضافات والقوالب اللذان يتشكل منهما كل موقع ووردبريس. يستطيع المطور التعديل على القالب أو إنشاء قالب جديد وتطوير إضافاته Plugins الخاصة لإضافة خواص وميزات جديدة لمشروعه، والخطأ الذي قد يقع فيه هنا هو استخدام أسماء عامة للدوال أو المتغيرات التي قام بإستخدامها في الكود البرمجي الخاص به والتي قد تكون إضافات أخرى في نفس الموقع تستخدمها مما قد يسبب تعارضا وتضاربا بين الإضافتين وبالتالي ظهور خلل في وظائفهما. يجب على كل مطور تخصيص أسماء المتغيرات في أكواده البرمجية، فمثلا عوض استخدام دالة باسم get_username() في الشفرة البرمجية للقالب أو الإضافة يفضل استخدام اسم مسبوق باسم المشروع، على سبيل المثال tutomena_get_username() ، والهدف كما قلنا عدم ترك المجال وأي فرصة لإضافة أو أي طرف ثالث لاستخدام نفس الإسم. الحل الآخر لهذه المشكلة هو استخدام مساحات الأسماء أو Namespaces التي تدعمها لغة البرمجة PHP افتراضيا والإستفادة من إيجابياتها الكثيرة. فقط يجب معرفة كيفية التعامل معها لتفادي استخدامها بشكل خاطئ وعدم الإستفادة منها بشكل كامل. 2. عدم الإستفادة القصوى من إمكانيات ووردبريس الإفتراضية عدم المعرفة الجيدة بإمكانات وميزات ووردبريس يقود عددا من المطورين للبحث عن إضافات أو حلول خارجية للقيام بوظائف هي مدعومة أصلا من ووردبريس! نسبة كبيرة منهم مازالوا يقومون بإضافة مكتبات جافاسكريبت مثل جيكويري لمجلد القالب الخاص بهم واستدعاؤها وهم لا يعلمون بأن ووردبريس يعتمد افتراضيا على جيكويري ويقوم بتحميلها نيابة عنا، كل ما علينا فعله هو إضافة محدد id مكتبة جيكويري (jquery) لمصفوفة التبعيات Dependencies التي يحتاجها السكريبت الخاص بك وذلك على هذا النحو : wp_enqueue_script('my-custom-script', get_template_directory_uri() .'/js/my-custom-script.js', array('jquery'), null, true); 1 2 3 wp_enqueue_script('my-custom-script', get_template_directory_uri() .'/js/my-custom-script.js', array('jquery'), null, true); هذا فقط مثال بسيط للغاية عما يمكن أن يؤدي إليه جهل المطور بإمكانيات ووردبريس الإفتراضية. هذا الكلام كله يجعلنا نؤكد على ضرورة التحديث الدوري والمستمر لجميع الإضافات والقوالب التي تقوم باستخدامها وطبعا تحديث نواة ووردبريس يدخل كذلك ضمن هذا الإطار. فمع كل تحديث هناك إما إضافة ميزات جديدة أو إصلاح عيوب قديمة بعض منها قد يكون خطيرا إذا ما تعلق بالجانب الأمني للسكريبت. 3. ترك الثابت WP_DEBUG على قيمته الإفتراضية false أثناء التطوير يتوفر ووردبريس على ثابت اسمه WP_DEBUG يمكن المطور من إظهار الأخطاء Erros أو التحذيرات Warnings البرمجية في واجهة المستخدم، وذلك للتأكد من عدم وجود أي خطأ في الموقع أو تتبع مصدر الأخطاء في حالة وجودها. القيمة الإفتراضية لهذا الثابت، الذي نجده في الملف wp-config.php، هي false أي أن الأخطاء لن تظهر إلا إذا تم تغيير القيمة إلى true، وهذا طبيعي لأننا لا نريد أن يرى زوار الموقع أخطاءً أو تحذيرات على شاشاتهم يجب على المطور أن يغير قيمة WP_DEBUG إلى true في المشروع على الخادم المحلي وعند الإنتهاء من التطوير يعيد القيمة إلى حالتها الإفتراضية false قبل نشر التغييرات على خادم الإنتاج Production Server. 4. عدم حفظ نسخ ملفات المشروع عن طريق برنامج احترافي وعملي لإدارة النسخ من الأفضل دائما الإستعانة ببرنامج لإدارة النسخ، مثل Git، عند العمل على أي مشروع برمجي مهما كان نوعه. الإستعانة بهذا النوع من البرامج تبدو أكثر إلحاحا عند العمل على مشروع من طرف أكثر من مطور، كل مطور يقوم بعمله وبواسطة Git يستطيع مدير الفريق البرمجي دمج التغييرات جميعها. الأكثر من ذلك، عند ظهور أي خطأ أو طارئ في أي مرحلة من مراحل التطوير يستطيع الفريق الرجوع بملفات المشروع للنقطة التي تسبق ظهور هذا الخطأ من أجل تداركه و إعادة عملية الدمج Merging. 5. استدعاء ملفات CSS وجافاسكريبت دون الحاجة إليها كل طلب HTTP يتم إرساله يعني زيادة في وقت تحميل الصفحة. يجب التفكير دائما عند استدعاء أي ملف CSS أو JavaScript طرح السؤال فيما إذا كنت أحتاج إليه في جميع صفحات موقعي أم في صفحات معينة فقط. ووردبريس يضع بين أيدينا واجهة برمجية ممتازة وسهلة لمساعدة المطورين على تنفيذ أكوادهم في الوقت والمكان المناسب. الكود التالي يقول لووردبريس قم باستدعاء ملف my_style.min.css فقط في صفحات single حيث يعرض محتوى المقال : function register_my_style() { if ( is_single() ) { wp_enqueue_style( 'my-style', get_stylesheet_directory_uri() . '/css/my_style.min.css' ); } } add_action( 'wp_enqueue_scripts', 'register_my_style' ); 1 2 3 4 5 6 7 function register_my_style() { if ( is_single() ) { wp_enqueue_style( 'my-style', get_stylesheet_directory_uri() . '/css/my_style.min.css' ); } } add_action( 'wp_enqueue_scripts', 'register_my_style' ); 6. عدم تنظيم الكود وفقا لأنماط التصميم البرمجي المعروفة عندما تقوم بتصميم إضافة أو قالب ووردبريس بسيط فإننا لا نجد أنفسنا مجبرين لوضع خطة أو بنية محكمة لتنظيم الكود، ففي هذه الحالة تكون الملفات قليلة وكذلك وظائف القالب أو الإضافة معدودة وغير معقدة. ولكن عندما نبدأ العمل على مشروع متوسط أو كبير فلن يكون من الحكمة جمع الأكواد البرمجية كلها في ملف functions.php، فمع التقدم في العمل سترى بأنك أمام ملف طويل وغير منظم وصعب القراءة خاصة على الآخرين. البرمجة الكائنية تصبح محمودة للغاية في مثل هذا النوع من المشاريع، فجمع أكواد shortcodes مثلا في كلاس اسمه class.shortcodes.php أفضل من وضعها في ملف functions.php مع كل الوظائف والدوال الأخرى. نفس الكلام يمكن قوله عن ال widgets و استدعاء سكريبتات الجافاسكريبت وأكواد CSS إلخ… هذا ويفضل دائما عدم خلط أكواد HTML وPHP في نفس الملفات، ما المانع من استخدام نمط ال MVC لفصل المشاهد Views عن منطق المشروع (كود PHP) ؟ لا مانع بالطبع، إضافة WooCommerce التي يعرفها الجميع يعتمد مطوروها على هذا النمط ويمكن للمستخدم التعديل على قوالب المشاهد Views المعزولة عن متاهات وصداع ال PHP. الإعتماد على أنماط التصميم Design Patterns في البرمجة بصفة عامة غاية في الأهمية، وفي ووردبريس تتكرس هذه الحاجة بمرور السنوات مع تطور نوعية المشاريع وزيادة درجة تعقيدها. 7. استعمال مقتطفات من شفرات برمجية دون فهمها يلجأ معظم المبرمجين، إن لم نقل كلهم، للبحث في غوغل أو StackOverflow عن حلول لمشاكل برمجية قد يصادفونها في مشاريعهم، وعند إيجادها تكون عبارة عن أسطر من أكواد برمجية والواجب هنا هو قراءتها وفهم كل سطر على حدة. التقاط مجموعة من الأكواد من هنا وهناك ولصقها في المشروع دون استيعابها لمجرد أنها تعمل من دون مشاكل آنية قد يسبب مشاكل في وقت لاحق، خاصة عندما نريد تطوير وتوسيع Scale بعض الوظائق المتعلقة بهذه الأكواد مع تطور المشروع. هذا دون أن ننسى أن الواجهات البرمجية API لووردبريس تتعرض للتطوير والتحسين بكيفية مستمرة، وبالتالي قد تكون الأكواد التي وجدتها في StackOverflow تستخدم دوالا functions مهملة Deprecated أو منسوخة ولم يعد ينصح باستخدامها إما لدواعي أمنية أو لأسباب تتعلق بالأداء والفعالية. المطور الذي يحترم عمله يعي جيدا ضرورة فهم كل سطر برمجي يقوم بكتابته حتى يكون بوسعه تحمل كافة المسؤوليات والتعهدات بينه وبين العميل والمتعلقة بالمشروع. 8. إهمال الجوانب الأمنية لا تثق أبدا في مدخلات المستخدمين Do not trust users input، هذه مقولة شهيرة في ميدان البرمجة وهي صحيحة ومنطقية لأبعد الحدود، فمستخدمو تطبيقك منهم الصالح والطالح، الطيب والخبيث ولذلك عليك معالجة جميع المدخلات Inputs التي تأتي من المستخدمين قبل حفظها في قاعدة البيانات على سبيل المثال. هناك العديد من الدوال في ووردبريس لهذا الغرض، لعل أكثرها استخداما sanitize_field_text التي تقوم بتطهير جميع القيم التي يتم إرسالها من قبل المستخدمين عبر الفورمات في موقعك وذلك لتفادي وقوعك كضحية لهجمات XSS التي تكون في بعض الأحيان غاية في الخطورة. هذا ويفضل دائما الإستعانة بما يصطلح عليه nonces وهي بمثابة حقول تحتوي على نصوص على شكل أرقام وتستخدم مرة واحدة فقط للتأكد من كون المستخدم أرسل البيانات فعلا من الفورم وليس من مكان آخر. بدون استخدامها، ستعرض تطبيق لخطر هجمات خطيرة تعرف ب CSRF Attacks. وهنا تجدون دليلا مفصلا من ووردبريس يحتوي على أهم الطرق والممارسات التي يجب اتباعها لتأمين مشاريعكم. النهاية ليس هناك مبرمج لم يخطأ في يوم من الأيام، العيب ليس في الخطأ ولكن العيب هو التمادي في الخطأ وعدم الإستفادة منه وتصحيحه. مع تراكم التجارب والمشاريع نتعلم ونستطيع معرفة أفضل الطرق للقيام بالأشياء. المصدر: منتديات رحيل لكل العرب - من قسم: قسم تطوير المواقع ومحركات البحث والسيو Seo والووردبريس WordPress
	اقتباس

المواضيع المتشابهه
الموضوع	كاتب الموضوع	المنتدى	مشاركات	آخر مشاركة
ما الذي تحتاج معرفته قبل الشروع في التطوير على ووردبريس	مهرة النجدية	قسم تطوير المواقع ومحركات البحث والسيو Seo والووردبريس WordPress	1	28-07-2019 11:12 AM
برمجة إضافات ووردبريس: الخُطّافات (Hooks)	مهرة النجدية	قسم تطوير المواقع ومحركات البحث والسيو Seo والووردبريس WordPress	1	27-07-2019 11:06 PM
تعرف علي أفضل إضافات ووردبريس لعام 2019	raheel	قسم تطوير المواقع ومحركات البحث والسيو Seo والووردبريس WordPress	0	27-03-2019 10:08 PM
دليلك الشامل لتأمين موقع ووردبريس	raheel	قسم تطوير المواقع ومحركات البحث والسيو Seo والووردبريس WordPress	0	27-03-2019 06:58 PM
تعرف علي الأخطاء شائعة في ووردبريس و طريقة إصلاحها	raheel	قسم تطوير المواقع ومحركات البحث والسيو Seo والووردبريس WordPress	0	27-03-2019 06:32 PM

اسم العضو		حفظ البيانات؟
كلمة المرور

الذين يشاهدون محتوى الموضوع الآن : 1 ( الأعضاء 0 والزوار 1)