تجريد وورد بريس: أفضل الممارسات والإضافات التجريدية لـ وورد بريس

وورد بريس هو نظام إدارة محتوى قديم ، ولكنه أيضًا الأكثر استخدامًا . بفضل تاريخها في دعم إصدارات PHP القديمة والكود القديم ، فإنها لا تزال تفتقر إلى تنفيذ ممارسات الترميز الحديثة – يعد تجريد وورد بريس أحد الأمثلة.

على سبيل المثال ، سيكون من الأفضل تقسيم قاعدة كود وورد بريس الأساسية إلى حزم يديرها Composer. أو ربما ، لتحميل فئات وورد بريس تلقائيًا من مسارات الملفات.

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

مشاكل تتعلق بدمج أدوات وورد بريس و PHP

نظرًا لبنيتها القديمة ، نواجه أحيانًا مشكلات عند دمج وورد بريس مع الأدوات الخاصة بقواعد أكواد PHP ، مثل المحلل الثابت PHPStan ، ومكتبة اختبار الوحدة PHPUnit ، ومكتبة نطاق مساحة الاسم PHP-Scoper . على سبيل المثال ، ضع في اعتبارك الحالات التالية:

قبل إصدار وورد بريس 5.6 مع دعم PHP 8.0 ، وصف تقرير صادر عن Yoast كيف سيؤدي تشغيل PHPStan على نواة وورد بريس إلى ظهور آلاف المشكلات .

نظرًا لاستمرار دعمها لـ PHP 5.6 ، فإن مجموعات اختبار وورد بريس تدعم حاليًا فقط PHPUnit حتى الإصدار 7.5 ، والذي وصل إلى نهاية العمر الافتراضي.

يعد تحديد نطاق مكونات وورد بريس الإضافية عبر PHP-Scoper أمرًا صعبًا للغاية .

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

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

ما هو تجريد الكود؟

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

كود مقابل واجهات ، وليس تطبيقات.

إنشاء الحزم وتوزيعها عبر Composer.

ألصق جميع الأجزاء معًا عن طريق حقن التبعية.

البرمجة ضد الواجهات وليس التطبيقات

الترميز مقابل الواجهات هو ممارسة استخدام العقود لجعل أجزاء من التعليمات البرمجية تتفاعل مع بعضها البعض. العقد هو ببساطة واجهة PHP (أو أي لغة مختلفة) تحدد الوظائف المتاحة وتوقيعاتها ، أي المدخلات التي يتلقونها ومخرجاتها.

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

مثال على العقود

يستخدم الكود التالي عقد Symfony وعقد CacheInterfaceتوصية PHP القياسية (PSR) CacheItemInterfaceلتنفيذ وظيفة التخزين المؤقت:

use Psr\Cache\CacheItemInterface;
use Symfony\Contracts\Cache\CacheInterface;

$value = $cache->get('my_cache_key', function (CacheItemInterface $item) {
    $item->expiresAfter(3600);
    return 'foobar';
});

$cacheالأدوات CacheInterface، والتي تحدد طريقة getاسترداد كائن من ذاكرة التخزين المؤقت. من خلال الوصول إلى هذه الوظيفة عبر العقد ، يمكن أن يكون التطبيق غافلًا عن مكان ذاكرة التخزين المؤقت. سواء كان ذلك في الذاكرة أو القرص أو قاعدة البيانات أو الشبكة أو في أي مكان آخر. لا يزال ، يجب أن تؤدي الوظيفة. CacheItemInterfaceيحدد طريقة expiresAfterللإعلان عن المدة التي يجب أن يتم الاحتفاظ فيها بالعنصر في ذاكرة التخزين المؤقت. يمكن للتطبيق استدعاء هذه الطريقة دون الاهتمام بالكائن المخزن مؤقتًا ؛ إنه يهتم فقط بالوقت الذي يجب أن يتم تخزينه مؤقتًا فيه.

الترميز مقابل الواجهات في وورد بريس

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

/**
 * @param array $args
 * @return WP_Post[]|int[] Array of post objects or post IDs.
 */
function get_posts( $args = null )

بدلاً من استدعاء هذه الطريقة مباشرةً ، يمكننا الوصول إليها عبر العقد Owner\MyApp\Contracts\PostsAPIInterface:

namespace Owner\MyApp\Contracts;

interface PostAPIInterface
{
  public function get_posts(array $args = null): PostInterface[]|int[];
}

لاحظ أن وظيفة وورد بريس get_postsيمكنها إرجاع كائنات من الفئة WP_Postالخاصة بـ وورد بريس. عند تجريد الكود ، نحتاج إلى إزالة هذا النوع من التبعية الثابتة. تقوم الطريقة get_postsفي العقد بإرجاع كائنات من النوع PostInterface، مما يسمح لك بالإشارة إلى الفئة WP_Postدون توضيحها. PostInterfaceسيحتاج الفصل إلى توفير الوصول إلى جميع الأساليب والسمات من WP_Post:

namespace Owner\MyApp\Contracts;

interface PostInterface
{
  public function get_ID(): int;
  public function get_post_author(): string;
  public function get_post_date(): string;
  // ...
}

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

إنشاء وتوزيع الحزم

Composer هو مدير حزم لـ PHP. يسمح لتطبيقات PHP باسترداد الحزم (أي أجزاء من التعليمات البرمجية) من المستودع وتثبيتها على أنها تبعيات. لفصل التطبيق عن وورد بريس ، يجب علينا توزيع الكود الخاص به في حزم من نوعين مختلفين: تلك التي تحتوي على كود وورد بريس والأخرى التي تحتوي على منطق الأعمال (أي لا يوجد كود وورد بريس).

أخيرًا ، نضيف جميع الحزم كاعتماديات في التطبيق ، ونقوم بتثبيتها عبر Composer. نظرًا لأنه سيتم تطبيق الأدوات على حزم رمز العمل ، يجب أن تحتوي هذه على معظم كود التطبيق ؛ كلما زادت النسبة ، كان ذلك أفضل. إن جعلهم يديرون حوالي 90٪ من الكود الكلي هو هدف جيد.

استخراج كود وورد بريس في حزم

اقتداء من السابقة على والعقود PostAPIInterfaceو PostInterfaceستضاف إلى حزمة تحتوي على رمز العمل، وسوف تشمل حزمة أخرى تنفيذ ورد من هذه العقود. للإرضاء PostInterface، نقوم بإنشاء PostWrapperفئة تسترد جميع السمات من WP_Postكائن:

namespace Owner\MyAppForWP\ContractImplementations;

use Owner\MyApp\Contracts\PostInterface;
use WP_Post;

class PostWrapper implements PostInterface
{
  private WP_Post $post;
  
  public function __construct(WP_Post $post)
  {
    $this->post = $post;
  }

  public function get_ID(): int
  {
    return $this->post->ID;
  }

  public function get_post_author(): string
  {
    return $this->post->post_author;
  }

  public function get_post_date(): string
  {
    return $this->post->post_date;
  }

  // ...
}

عند التنفيذ PostAPI، نظرًا لأن الطريقة get_postsترجع PostInterface[]، يجب علينا تحويل الكائنات من WP_Postإلى PostWrapper:

namespace Owner\MyAppForWP\ContractImplementations;

use Owner\MyApp\Contracts\PostAPIInterface;
use WP_Post;

class PostAPI implements PostAPIInterface
{
  public function get_posts(array $args = null): PostInterface[]|int[]
  {
    // This var will contain WP_Post[] or int[]
    $wpPosts = \get_posts($args);

    // Convert WP_Post[] to PostWrapper[]
    return array_map(
      function (WP_Post|int $post) {
        if ($post instanceof WP_Post) {
          return new PostWrapper($post);
        }
        return $post
      },
      $wpPosts
    );
  }
}

استخدام حقن التبعية

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

ببساطة عن طريق تغيير التكوين ، يمكننا التبديل بسهولة من مزود عقد إلى مزود آخر. هناك العديد من مكتبات حقن التبعية التي يمكننا الاختيار من بينها. ننصح باختيار واحدة تلتزم بتوصيات PHP القياسية (يشار إليها غالبًا باسم “PSR”) ، حتى نتمكن بسهولة من استبدال المكتبة بمكتبة أخرى إذا دعت الحاجة. فيما يتعلق بحقن التبعية ، يجب أن تفي المكتبة بـ PSR-11 ، الذي يوفر مواصفات “واجهة الحاوية”. من بين أمور أخرى ، تتوافق المكتبات التالية مع PSR-11:

تبعية Symfony’s DependencyInjection

PHP-DI

هالة

حاوية (حقن التبعية)

Yii التبعية الحقن

الوصول إلى الخدمات عبر حاوية الخدمة

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

$posts = get_posts();

… مع حاوية الخدمة ، يجب أولاً الحصول على الخدمة التي ترضي PostAPIInterface وتنفيذ الوظيفة من خلالها:

use Owner\MyApp\Contracts\PostAPIInterface;

// Obtain the service container, as specified by the library we use
$serviceContainer = ContainerBuilderFactory::getInstance();

// The obtained service will be of class Owner\MyAppForWP\ContractImplementations\PostAPI
$postAPI = $serviceContainer->get(PostAPIInterface::class);

// Now we can invoke the WordPress functionality
$posts = $postAPI->get_posts();

استخدام DependencyInjection في Symfony

يعد مكون DependencyInjection من Symfony حاليًا مكتبة حقن التبعية الأكثر شيوعًا. يسمح لك بتكوين حاوية الخدمة عبر كود PHP أو YAML أو XML. على سبيل المثال ، لتعريف هذا العقد PostAPIInterfaceيتم استيفاءه من خلال PostAPI تكوين الفئة في YAML على النحو التالي:

services:
  Owner\MyApp\Contracts\PostAPIInterface:
    class: \Owner\MyAppForWP\ContractImplementations\PostAPI

يسمح Symfony’s DependencyInjection أيضًا بحقن مثيلات من خدمة واحدة تلقائيًا (أو “تلقائية”) في أي خدمة أخرى تعتمد عليها. بالإضافة إلى ذلك ، فإنه يجعل من السهل تحديد أن الفئة هي تنفيذ للخدمة الخاصة بها. على سبيل المثال ، ضع في اعتبارك تكوين YAML التالي :

services:
  _defaults:
    public: true
    autowire: true

  GraphQLAPI\GraphQLAPI\Registries\UserAuthorizationSchemeRegistryInterface:
    class: '\GraphQLAPI\GraphQLAPI\Registries\UserAuthorizationSchemeRegistry'

  GraphQLAPI\GraphQLAPI\Security\UserAuthorizationInterface:
    class: '\GraphQLAPI\GraphQLAPI\Security\UserAuthorization'
    
  GraphQLAPI\GraphQLAPI\Security\UserAuthorizationSchemes\:
    resource: '../src/Security/UserAuthorizationSchemes/*'

يحدد هذا التكوين ما يلي:

UserAuthorizationSchemeRegistryInterfaceيتم إرضاء العقد عن طريق الفصلUserAuthorizationSchemeRegistry

UserAuthorizationInterfaceيتم إرضاء العقد عن طريق الفصلUserAuthorization

جميع الفئات الموجودة في المجلد UserAuthorizationSchemes/هي تنفيذ لأنفسهم

يجب إدخال الخدمات تلقائيًا في بعضها البعض ( autowire: true)

دعونا نرى كيف يعمل التمديد التلقائي. UserAuthorizationتعتمد الفئة على الخدمة بالعقد UserAuthorizationSchemeRegistryInterface:

class UserAuthorization implements UserAuthorizationInterface
{
  public function __construct(
      protected UserAuthorizationSchemeRegistryInterface $userAuthorizationSchemeRegistry
  ) {
  }

  // ...
}

بفضل autowire: true، سيتلقى مكون DependencyInjection الخدمة تلقائيًا UserAuthorizationلتلقي التبعية المطلوبة ، وهو مثيل لـ UserAuthorizationSchemeRegistry.

متى الملخص

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

الوصول إلى الأدوات

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

تقليل الوقت والتكلفة في الأدوات

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

لا حاجة لإعادة بناء ديون ثقيلة

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

إنتاج كود لمنصات متعددة

من خلال استخراج 90٪ من الكود في حزمة CMS-agnostic ، يمكننا إنتاج إصدار مكتبة يعمل مع CMS أو إطار عمل مختلف عن طريق استبدال 10٪ فقط من قاعدة التعليمات البرمجية الإجمالية.

الهجرة إلى منصة مختلفة

إذا احتجنا إلى ترحيل مشروع من Drupal إلى وورد بريس أو وورد بريس إلى Laravel أو أي مجموعة أخرى ، فيجب إعادة كتابة 10٪ فقط من الكود – وهو توفير كبير.

أفضل الممارسات

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

الالتزام بـ PSR-12

عند تحديد الواجهة للوصول إلى طرق وورد بريس ، يجب الالتزام بـ PSR-12 . تهدف هذه المواصفات الحديثة إلى تقليل الاحتكاك المعرفي عند مسح الكود من مؤلفين مختلفين. الانضمام إلى PSR-12 يعني إعادة تسمية وظائف وورد بريس.

تعمل أسماء وورد بريس باستخدام snake_case ، بينما تستخدم PSR-12 حالة الجمل . ومن ثم ، get_postsستصبح الوظيفة getPosts:

interface PostAPIInterface
{
  public function getPosts(array $args = null): PostInterface[]|int[];
}

…و:

class PostAPI implements PostAPIInterface
{
  public function getPosts(array $args = null): PostInterface[]|int[]
  {
    // This var will contain WP_Post[] or int[]
    $wpPosts = \get_posts($args);

    // Rest of the code
    // ...
  }
}

طرق الانقسام

لا يلزم أن تكون الأساليب في الواجهة نسخة طبق الأصل من تلك الموجودة في وورد بريس. يمكننا تحويلها كلما كان ذلك منطقيًا. على سبيل المثال، وظيفة وورد get_user_by($field, $value)يعرف كيفية استرداد المستخدم من قاعدة البيانات عن طريق المعلمة $field، التي تقبل القيم “id”، “ID”، “slug”، “email”أو “login”. يحتوي هذا التصميم على بعض المشكلات:

لن تفشل في وقت الترجمة إذا مررنا سلسلة خاطئة

$valueتحتاج المعلمة إلى قبول جميع الأنواع المختلفة لجميع الخيارات ، على الرغم من “ID”أنها تتوقع intعند اجتيازها ، عند اجتيازها “email”، يمكن فقط تلقي علامةstring

يمكننا تحسين هذا الموقف عن طريق تقسيم الوظيفة إلى عدة وظائف:

namespace Owner\MyApp\Contracts;

interface UserAPIInterface
{
  public function getUserById(int $id): ?UserInterface;
  public function getUserByEmail(string $email): ?UserInterface;
  public function getUserBySlug(string $slug): ?UserInterface;
  public function getUserByLogin(string $login): ?UserInterface;
}

يتم حل العقد لورد مثل هذا (على افتراض أننا قد خلقت UserWrapperو UserInterface، كما هو موضح في وقت سابق يوم):

namespace Owner\MyAppForWP\ContractImplementations;

use Owner\MyApp\Contracts\UserAPIInterface;

class UserAPI implements UserAPIInterface
{
  public function getUserById(int $id): ?UserInterface
  {
    return $this->getUserByProp('id', $id);
  }

  public function getUserByEmail(string $email): ?UserInterface
  {
    return $this->getUserByProp('email', $email);
  }

  public function getUserBySlug(string $slug): ?UserInterface
  {
    return $this->getUserByProp('slug', $slug);
  }

  public function getUserByLogin(string $login): ?UserInterface
  {
    return $this->getUserByProp('login', $login);
  }

  private function getUserByProp(string $prop, int|string $value): ?UserInterface
  {
    if ($user = \get_user_by($prop, $value)) {
      return new UserWrapper($user);
    }
    return null;
  }
}

إزالة تفاصيل التنفيذ من توقيع الوظيفة

قد توفر الوظائف في وورد بريس معلومات حول كيفية تنفيذها في توقيعها الخاص. يمكن إزالة هذه المعلومات عند تقييم الوظيفة من منظور مجرد. على سبيل المثال ، يتم الحصول على الاسم الأخير للمستخدم في وورد بريس عن طريق الاتصال get_the_author_meta، مما يوضح أن الاسم الأخير للمستخدم يتم تخزينه كقيمة “meta” (في الجدول wp_usermeta):

$userLastname = get_the_author_meta("user_lastname", $user_id);

لا يتعين عليك نقل هذه المعلومات إلى العقد. الواجهات تهتم فقط بماذا وليس كيف. وبالتالي ، يمكن أن يحتوي العقد بدلاً من ذلك على طريقة getUserLastnameلا توفر أي معلومات حول كيفية تنفيذه:

تتضمن جميع خطط استضافة Kinsta دعمًا على مدار الساعة طوال أيام الأسبوع من مطوري ومهندسي وورد بريس المخضرمين. تحدث مع نفس الفريق الذي يدعم عملاء Fortune 500 لدينا. تحقق من خططنا !

interface UserAPIInterface
{
  public function getUserLastname(UserWrapper $userWrapper): string;
  ...
}

أضف أنواعًا أكثر صرامة

يمكن لبعض وظائف وورد بريس تلقي المعلمات بطرق مختلفة ، مما يؤدي إلى الغموض. على سبيل المثال ، add_query_argيمكن أن تتلقى الوظيفة إما مفتاحًا واحدًا وقيمة:

$url = add_query_arg('id', 5, $url);

… أو مجموعة من key => value:

$url = add_query_arg(['id' => 5], $url);

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

public function addQueryArg(string $key, string $value, string $url);
public function addQueryArgs(array $keyValues, string $url);

القضاء على الديون الفنية

لا تعرض وظيفة وورد بريس get_posts”منشورات” فحسب ، بل تعرض أيضًا “صفحات” أو أي كيان من نوع “منشورات مخصصة” ، وهذه الكيانات غير قابلة للتبادل. كل من المنشورات والصفحات هي منشورات مخصصة ، لكن الصفحة ليست منشورًا وليست صفحة. لذلك ، get_postsيمكن أن يؤدي التنفيذ إلى إرجاع الصفحات. هذا السلوك هو تناقض مفاهيمي.

لجعله مناسبًا ، get_postsيجب بدلاً من ذلك الاتصال به get_customposts، ولكن لم تتم إعادة تسميته مطلقًا في نواة وورد بريس. إنها مشكلة شائعة مع معظم البرامج طويلة الأمد وتسمى “الدين الفني” – رمز به مشاكل ، ولكن لا يتم إصلاحه أبدًا لأنه يقدم تغييرات جذرية.

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

interface ModelAPIInterface
{
  public function getPosts(array $args): array;
  public function getPages(array $args): array;
  public function getCustomPosts(array $args): array;
}

بهذه الطريقة ، لن يحدث التناقض بعد الآن ، وسترى هذه النتائج:

getPosts إرجاع المشاركات فقط

getPages يسترجع الصفحات فقط

getCustomPosts يعرض كلاً من المشاركات والصفحات

فوائد استخلاص الكود

المزايا الرئيسية لاستخراج رمز التطبيق هي:

يعد تشغيل الأدوات على الحزم التي تحتوي على رمز العمل فقط أسهل في الإعداد وسيستغرق وقتًا أقل (وأموالًا أقل) للتشغيل.

يمكننا استخدام الأدوات التي لا تعمل مع وورد بريس ، مثل تحديد نطاق مكون إضافي باستخدام PHP-Scoper.

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

يصبح ترحيل تطبيق إلى أنظمة أساسية أخرى أسهل.

يمكننا تغيير طريقة تفكيرنا من التفكير في وورد بريس إلى التفكير في منطق أعمالنا.

تصف العقود الغرض من التطبيق ، مما يجعلها أكثر قابلية للفهم.

يتم تنظيم التطبيق من خلال الحزم ، مما يؤدي إلى إنشاء تطبيق بسيط يحتوي على الحد الأدنى ويعززه تدريجيًا حسب الحاجة.

يمكننا تصفية الديون الفنية.

مشاكل مع كود التجريد

مساوئ استخلاص كود التطبيق هي:

أنها تنطوي على قدر كبير من العمل في البداية.

يصبح الرمز أكثر تفصيلاً ؛ أضف طبقات إضافية من التعليمات البرمجية لتحقيق نفس النتيجة.

قد ينتهي بك الأمر إلى إنتاج العشرات من الحزم التي يجب بعد ذلك إدارتها وصيانتها.

قد تحتاج إلى monorepo لإدارة جميع الحزم معًا.

قد يكون حقن التبعية مبالغة في استخدام التطبيقات البسيطة (تناقص الغلة).

لن يتم الانتهاء من استخلاص الكود بالكامل نظرًا لوجود تفضيل عام ضمني في بنية CMS.

خيارات البرنامج المساعد ووردبريس الملخص

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

1. WPide

من إنتاج WebFactory Ltd ، يعمل المكون الإضافي الشهير WPide على توسيع وظائف محرر الكود الافتراضي في وورد بريس بشكل كبير. إنه بمثابة مكون إضافي لبرنامج وورد بريس من خلال السماح لك بمشاهدة التعليمات البرمجية الخاصة بك في الموقع لتصور بشكل أفضل ما يحتاج إلى الاهتمام.

WPide خلاصة البرنامج المساعد وورد

ملحق WPide.

يحتوي WPide أيضًا على وظيفة البحث والاستبدال لتحديد موقع التعليمات البرمجية القديمة أو منتهية الصلاحية بسرعة واستبدالها بترجمة معاد تصنيعها.

علاوة على ذلك ، يوفر WPide الكثير من الميزات الإضافية ، بما في ذلك:

تمييز التركيب والكتل

نسخ احتياطي تلقائي

إنشاء الملفات والمجلدات

متصفح شجرة الملفات الشامل

الوصول إلى واجهة برمجة تطبيقات نظام ملفات وورد بريس

2. Ultimate DB Manager

و البرنامج المساعد في نهاية المطاف WP DB مدير  من WPHobby يتيح لك طريقة سريعة لتحميل قواعد البيانات بالكامل لاستخراج وإعادة الهيكلية.

لقطة شاشة لشعار البرنامج المساعد Ultimate DB Manager بالكلمات:

البرنامج المساعد Ultimate DB Manager.

بالطبع ، لا تعد المكونات الإضافية من هذا النوع ضرورية لمستخدمي Kinsta ، حيث توفر Kinsta وصولاً مباشرًا إلى قاعدة البيانات  لجميع العملاء. ومع ذلك ، إذا لم يكن لديك وصول كافٍ إلى قاعدة البيانات من خلال موفر الاستضافة ، فقد يكون Ultimate DB Manager مفيدًا كمكوِّن إضافي لبرنامج وورد بريس.

3. البرنامج المساعد ووردبريس الملخص المخصص الخاص بك

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

القيام بذلك له فوائد واضحة:

يلخص وظائفك من ملفات السمات الخاصة بك

يحافظ على التعليمات البرمجية الخاصة بك من خلال تغييرات السمات وتحديثات قاعدة البيانات

يمكنك معرفة كيفية إنشاء مكون وورد بريس الإضافي من خلال وورد بريس ‘Plugin Developer Handbook .

ملخص

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

لقد تعلمت كل ما تحتاج إلى معرفته لتبدأ في استخراج كود وورد بريس.