كيفية التعامل مع تطوير WordPress الحديث (الجزء الثاني)

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

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

إذن ، ما هي مبادئ تصميم البرامج الحديثة وميزات PHP والتي ستمنحك أفضل قيمة لوقتك؟ فيما يلي 10 ممارسات لتطوير WordPress و PHP أوصي بها بشدة.

أفضل الممارسات الحديثة لتطوير WordPress # 1: اتبع "فصل المخاوف"

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

الهدف النهائي لاتباع هذه المبادئ هو إنتاج رمز معياري ، وبالتالي يمكن صيانته ، وقابل للتوسيع ، وقابل لإعادة الاستخدام.

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

 $id = isset( $_REQUEST['id'] ) ? intval( $_REQUEST['id'] ) : 0; <table class="form-table"> <?php $blog_prefix = $wpdb->get_blog_prefix( $id ); $sql = "SELECT * FROM {$blog_prefix}options WHERE option_name NOT LIKE %s AND option_name NOT LIKE %s"; $query = $wpdb->prepare( $sql, $wpdb->esc_like( '_' ) . '%', '%' . $wpdb->esc_like( 'user_roles' ) ); $options = $wpdb->get_results( $query ); foreach ( $options as $option ) { if ( strpos( $option->option_value, "\n" ) === false ) { ?> <tr class="form-field"> <th scope="row"><label for="<?php echo esc_attr( $option->option_name ); ?>"><?php echo esc_html( ucwords( str_replace( '_', ' ', $option->option_name ) ) ); ?></label></th> <?php if ( $is_main_site && in_array( $option->option_name, array( 'siteurl', 'home' ) ) ) { ?> <td><code><?php echo esc_html( $option->option_value ); ?></code></td> <?php } else { ?> <td><input class="<?php echo $class; ?>" name="option[<?php echo esc_attr( $option->option_name ); ?>]" type="text" value="<?php echo esc_attr( $option->option_value ); ?>" size="40" <?php disabled( $disabled ); ?> /></td> <?php } ?> </tr> <?php } } // End foreach </table>

بادئ ذي بدء ، إنه أمر غير مفهوم تمامًا. وأنا أحب أن التعليق الوحيد هو End foreach ، وهو أمر لا لزوم له تمامًا. لدينا استعلام عن قاعدة البيانات ، ومعالجة نتائج الاستعلام ، ومعالجة إضافية مضمنة في HTML (هناك if / else متداخلة هناك إذا لم تكن قد لاحظت ذلك) ، وإخراج الهروب ، ونمذجة HTML كلها مهروسة معًا. هناك مشكلة أخرى تتمثل في أن المعلمة $id تأتي مباشرة من $_REQUEST بدلاً من تمرير معامل فعلي إلى دالة.

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

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

• يجب أن تكون استعلامات SQL في وحدة منفصلة ، من الواضح. يحتوي WordPress بالفعل على فئة WP_Query مجردة بشكل جيد والتي يجب استخدامها كمثال.
• ينتقل كل HTML إلى قالب. سنغطي قوالب PHP بشكل أكبر أدناه.
• يجب أن يتم تغليف كود PHP المتبقي في دالة — وظائف متعددة إذا كانت الشفرة طويلة جدًا أو معقدة لدالة واحدة. يتم تمرير المعلمات مثل $id عبر وسيطات الوظيفة.

هذه إعادة كتابة مبسطة للمثال أعلاه:

 function betterSiteSettings($args) { $data = WP_Settings_Query($args); // process $data here $context = array_merge([], $data_processed, $other_data); return Template::render('template.name', $context); }

أفضل ممارسات تطوير WordPress الحديثة رقم 2: تجنب المتغيرات العالمية

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

لننظر إلى هذا من زاوية عملية. يأتي هذا المثال من WooCommerce. ربما يعرف كل مطور WordPress ما هو - الحلقة:

 <?php while ( have_posts() ) : the_post(); ?> <?php wc_get_template_part( 'content', 'single-product' ); ?> <?php endwhile; // end of the loop. ?>

يعرض المقتطف أعلاه قالب منتج. كيف تعرف المنتج الذي تريد عرضه ، في ظل عدم وجود معلمات تم تمريرها إلى wc_get_template_part ؟ بالنظر إلى القالب ، نرى أنه يبدأ بـ global $product; ، لذلك هذا هو المكان الذي يتم فيه تخزين كائن المنتج الحالي.

تخيل الآن أن لدينا صفحة كتالوج تبحث عن المنتجات وتصفيتها ، ونريد إظهار نافذة منبثقة "تفاصيل المنتج" أثناء البقاء على نفس الصفحة. خلف الكواليس ، يقوم البرنامج النصي للواجهة الأمامية بطلب AJAX للحصول على قالب المنتج المحدد هذا. لا يمكننا ببساطة استدعاء wc_get_template_part('content', 'single-product') لأنه لا يستخدم معلمات ، لذلك نحتاج إلى تعيين متغيرين عالميين حتى يعمل هذا.

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

ألن يكون من المنطقي تمرير معرف المنتج هذا كمعامل؟ ثم يمكننا إعادة استخدام هذا القالب دون القلق بشأن العبث بالمتغيرات العالمية التي يستخدمها WordPress.

أفضل الممارسات الحديثة لتطوير WordPress # 3: استخدام البرمجة الشيئية (OOP)

النمطية تؤدي إلى مفهوم الأشياء والبرمجة الشيئية. على المستوى الأساسي للغاية ، OOP هي طريقة لتنظيم الكود. يتم تجميع الوظائف والمتغيرات معًا في فئات وتسمى طرق وخصائص الفئات على التوالي. يوصي دليل البرنامج المساعد WordPress باستخدام OOP لتنظيم كود PHP المخصص لـ WordPress.

يتمثل أحد المبادئ المهمة في OOP في تقييد الوصول إلى الأساليب والخصائص - أو في مصطلحات PHP ، للإشارة إليها على أنها private أو protected - لذلك فقط طرق الفئات الأخرى يمكنها الوصول إليها وتغييرها. مصطلح OOP لهذا هو التغليف : يتم تغليف البيانات داخل الفصل ، والطريقة الوحيدة لتغيير تلك البيانات هي باستخدام طرق الفصل المتوفرة.

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

هذا مجرد وصف أساسي جدًا لـ OOP وكيف يمكن استخدامه في تطوير WordPress الحديث. لمزيد من الدراسة ، أوصي بشدة بالكتاب الإلكتروني لـ Carl Alexander ، اكتشف البرمجة الموجهة للكائنات باستخدام WordPress ، والذي يحتوي على المحتوى الأكثر شمولاً وفائدة حول موضوع OOP في WordPress.

من المهم أن تتذكر أن OOP ليس رصاصة فضية: يمكن كتابة كود خاطئ باستخدام OOP بسهولة كما هو الحال مع أي نموذج برمجة آخر.

دعنا نتعمق في بعض النصائح المحددة حول استخدام PHP لتطوير WordPress.

أفضل ممارسات PHP الحديثة رقم 1: الهدف PHP 7.0+

يتطلب استخدام ميزات PHP الحديثة إصدارًا حديثًا من PHP. ببساطة لا يوجد سبب لدعم إصدارات PHP الأقل من 7.0. حتى نواة WordPress ستتطلب PHP 7.0 في وقت مبكر من نهاية عام 2019.

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

 <?php /** * Plugin Name: My Awesome Plugin * Requires PHP: 7.0 */ // bails if PHP version is lower than required if (version_compare(PHP_VERSION, '7.0.0', '<')) { // add admin notice here return; } // the rest of the actual plugin here

أفضل الممارسات الحديثة في PHP رقم 2: اعتماد معايير صناعة PHP (دليل أسلوب الترميز PSR-2)

PSRs هي توصيات تنشرها PHP Framework Interop Group. إنها معايير الصناعة الفعلية في أي سير عمل PHP حديث ، ويمكن القول بأمان أن مجتمع PHP ككل يتبع هذه المعايير. PSR-2 هي توصية تصف أسلوب الترميز. أطر PHP الشائعة مثل Symfony و Laravel تتبع PSR-2.

لماذا قد تستخدم PSR-2 بدلاً من معيار ترميز WordPress؟ يرجع ذلك أساسًا إلى أن معايير WordPress عفا عليها الزمن ولا تستخدم أيًا من ميزات اللغة الأحدث. هذا مفهوم لأن WordPress الأساسية يجب أن تتبع معاييرها الخاصة. كان عليه أن يدعم PHP 5.2 حتى وقت قريب جدًا ، و PSR-2 غير متوافق مع PHP 5.2.

قد لا يكون الأمر واضحًا ، لكن لا يوجد شرط لاستخدام معايير ترميز WordPress إلا إذا كنت ملتزمًا بالجوهر. لن تكون هناك مشكلة في إرسال مكون إضافي يتبع معيار PSR-2 إلى دليل البرنامج المساعد WordPress. في الواقع ، هناك بعض الحجج الجيدة جدًا للقيام بذلك.

أفضل الممارسات الحديثة في PHP # 3: استخدم محرك قوالب PHP

PHP ليس محرك قالب. لقد بدأت كلغة واحدة ، لكنها تطورت بعد ذلك إلى لغة برمجة كاملة الميزات ، ولا يوجد سبب لمواصلة استخدامها في القوالب. أشهر محركي قوالب PHP هما Twig و Blade اللذان يستخدمهما Symfony و Laravel على التوالي. ستستخدم هذه المقالة Twig كمثال لمحرك قوالب ؛ ومع ذلك ، فإن Blade لها ميزات ووظائف قابلة للمقارنة. أناشدك أن تنظر في كليهما وتقرر بنفسك ما يناسبك أكثر.

يقارن المثال أدناه بين قالب PHP ونموذج Twig المقابل له. عرض المخرجات وإفلاتها مطول بشكل خاص في مثال PHP:

 foreach ( $options as $option ) { ?> <tr class="form-field"> <th scope="row"> <label for="<?php echo esc_attr( $option->option_name ); ?>"> <?php echo esc_html( strtolower( $option->option_name ) ); ?> </label> </th> </tr> <?php } // End foreach

في Twig ، هذا أكثر إيجازًا وقابلية للقراءة:

 {% for option in options %} <tr class="form-field"> <th scope="row"> <label for="{{ option.option_name }}"> {{ option.option_name }} </label> </th> </tr> {% endfor %}

المزايا الرئيسية لـ Twig هي:

• تركيب مقروء ومختصر
• هروب الإخراج التلقائي
• تمديد القالب عن طريق الميراث والكتل

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

حتى أن هناك Twig for WordPress موجود. إنها تسمى Timber ، وهي طريقة رائعة للبدء في إنشاء قوالب أفضل. يعد موضوع Timber starter مثالًا رائعًا على تنظيم السمات بطريقة OOP.

أفضل الممارسات الحديثة في PHP # 4: استخدام الملحن

Composer هو مدير تبعية لـ PHP. إنها أداة تسمح بالتصريح عن المكتبات التي يستخدمها المشروع ، ومن ثم أتمتة التنزيلات والتثبيتات والتحديثات. بعد ذلك ، تحتاج فقط إلى تضمين vendor/autoload.php الخاص ببرنامج Composer بدلاً من طلب كل مكتبة يدويًا.

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

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

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

أفضل الممارسات الحديثة في PHP # 5: استخدام مساحات الأسماء

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

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

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

تسمى أجزاء مساحة الاسم هذه مساحات الأسماء الفرعية. سيكون فصلنا المثال Akrte_Awesome_Plugin_Order هو Akrte\Awesome_Plugin\Order إذا تم ذلك باستخدام مساحات الأسماء. هنا Akrte و Awesome_Plugin هما أجزاء مساحة الاسم (أو مساحات الأسماء الفرعية) Order هو اسم الفئة. ثم يمكنك إضافة بيان use واستخدام اسم الفئة فقط بعد ذلك. يبدو بالتأكيد أفضل:

 use Akrte\Awesome_Plugin\Order; $a = new Order;

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

 namespace WooCommerce\RestApi\V2\Controllers; class OrderNotes {}

تستخدم قاعدة كود WooCommerce في الوقت الحاضر مساحات الأسماء ؛ على سبيل المثال ، في WooCommerce REST API الإصدار 4.

أفضل الممارسات الحديثة في PHP # 6: استخدام أداة التحميل التلقائي

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

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

تحتاج وظيفة التحميل التلقائي إلى معرفة الملفات التي تعيش فيها فئاتك ووظائفك. وهناك معيار PHP-FIG ، PSR-4 ، لذلك.

تقول أن جزءًا من مساحة الاسم ، البادئة ، مخصص للتوافق مع المجلد الأساسي. تتوافق مساحات الأسماء الفرعية التي تليها مع المجلدات الموجودة داخل المجلد الأساسي. أخيرًا ، يتوافق اسم الفئة مع اسم الملف. ستحتاج فئة المثال Akrte\AwesomePlugin\Models\Order إلى بنية المجلد أدناه:

 /awesome-plugin awesome-plugin.php /includes /Models Order.php

تتوافق بادئة مساحة الاسم Akrte\AwesomePlugin\ includes مجلد التضمين كما هو محدد في تكوين أداة التحميل التلقائي الموضحة أدناه. تحتوي مساحة الأسماء الفرعية Models على مجلد Models مطابق ، ويتم تضمين فئة Order في Order.php .

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

1. قم بتثبيت Composer
2. أنشئ ملف composer.json في المجلد الجذر لمشروعك. يجب أن تحتوي على هذه الأسطر:

 { "name": "vendor-name/plugin-name", "require": {}, "autoload": { "psr-4": { "Akrte\\AwesomePlugin\\": "includes/" } } }

1. composer install .
2. قم بتضمين vendor/autoload.php أعلى ملف PHP للمكون الإضافي الرئيسي مثل هذا:

 <?php /** * Plugin Name: My Awesome Plugin */ defined('ABSPATH') || exit; require __DIR__ . '/vendor/autoload.php'; // do stuff

إلى جانب مساحات الأسماء ، تستخدم أحدث قاعدة بيانات لـ WooCommerce أيضًا أداة التحميل التلقائي للملحن.

مع تغطية مبادئ تصميم PHP هذه ، حان الوقت لربط جميع دروس PHP الخاصة بنا إلى التخصيص الخلفي لـ WordPress مع توصية نهائية واحدة.

أفضل الممارسات الرابعة لتطوير WordPress الحديثة: ضع في اعتبارك استخدام Roots Stack

Roots هو سير عمل تطوير WordPress الأكثر شمولاً. ومع ذلك ، أود أن أقول إنه لا ينبغي بالضرورة استخدامه في كل مشروع WordPress ، للأسباب التالية:

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

بشكل عام ، قد ترغب في فهم جميع مزايا وعيوب أي مشروع قوي الرأي قبل الالتزام باستخدامه.

مبادئ PHP والبرمجيات الحديثة: جعل تطوير WordPress الخلفية قويًا

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

تقدم سريعًا لعقد من الزمان: تستخدم تطبيقات JavaScript الحالية المكونات كتنفيذ لفصل الاهتمامات. ينجذب مطورو الواجهة الأمامية نحو CSS-in-JS ، وهذا يعني في الأساس تضمين CSS في HTML مرة أخرى (حسنًا ، الأمر ليس بهذه البساطة ، لكنك تحصل على الفكرة). الدائرة كاملة!

لطالما كانت أفضل الممارسات تدور حول تحسين تجربة المطور:

يجب كتابة البرامج ليقرأها الأشخاص ، وفقط بالمصادفة حتى تتمكن الأجهزة من تنفيذها.

أبيلسون وسوسمان ، هيكل وتفسير برامج الكمبيوتر

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