إدارة بيئات تطوير WordPress باستخدام WP-CLI و Robo

نشرت: 2022-09-13

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

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

جدول المحتويات

  1. ما هو الروبوت؟
    1. Robo يبسط سطر الأوامر PHP
    2. تثبيت Robo
    3. أوامتك الأولى
    4. المدخلات والمخرجات
    5. مساعدين رائعين
    6. فوائد Robo
  2. صيانة WordPress باستخدام Robo
    1. الملفات المهمة
    2. بيئتي
    3. مستخدم قاعدة البيانات
    4. قاعدة بيانات للانترنت
    5. رعاية التبعيات
  3. الاستفادة من ملف wp-cli.yml
    1. ما هو الاسم المستعار في WP-CLI؟
    2. افتراضيات الأمر
  4. إنشاء أوامر مخصصة لـ Robo
    1. تكوين الأوامر
    2. reset التعيين
    3. خطوات ما بعد التثبيت
    4. قيادة profile
  5. تغليف

ما هو الروبوت؟

Robo هو عداء مهام حديث مفتوح المصدر يستخدمه عدد من المشاريع بما في ذلك Drush و Codeception.

Robo مشابه لـ Gulp و Grunt ، ولكنه يستخدم PHP بدلاً من JavaScript.

الفكرة هي أنه يمكنك إنشاء أوامر صغيرة أنيقة مثل هذا:

# إعادة تعيين بيئة تطوير WP الخاصة بي وجعلها متعددة المواقع
إعادة تعيين الروبوت - متعدد

# تثبيت وإعداد المكون الإضافي WP Offload Media
ملف تعريف robo ome-dev

يعمل عداء المهام Robo على تسهيل توثيق الأوامر التي تنشئها عن طريق إضافة تعليقات DocBlock إلى أوامرك ، حتى تتمكن من تقديم المساعدة للإصدارات المستقبلية من نفسك:

# Robo بدون أي وسيطات ستظهر الأوامر المتاحة.
robo

الأوامر المتوفرة:
  help يعرض التعليمات للأمر
  يسرد قائمة الأوامر
  الملف الشخصي قم بتشغيل مجموعة من أوامر wp-cli في بيئة WordPress موجودة
  إعادة تعيين إعادة تعيين بيئة WordPress إلى حالة معروفة

طلب مزيد من المعلومات حول أمر معين:

إعادة تعيين robo

وصف:
  إعادة تعيين بيئة WordPress إلى حالة معروفة. يقرأ البيئات والتكوين 
  من robo.yml

استعمال:
  خيارات إعادة تعيين]

خيارات:
      --env [= ENV] البيئة (dev ، test ، إلخ) [افتراضي: "dev"]
      --متعدد إجراء تثبيت متعدد المواقع
      - أكثر من [= VER] إصدار WordPress [الافتراضي: "الأحدث"]

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

Robo يبسط سطر الأوامر PHP

دعونا نتحقق من مرآة الرؤية الخلفية قليلاً. من المؤكد أن كتابة أوامر PHP لسطر الأوامر ليست جديدة. كان من الممكن دائمًا تشغيل نص PHP من سطر الأوامر مثل هذا:

php myscript.php

وكان PHP متاحًا كبيئة سطر أوامر في معظم بيئات * NIX لأطول فترة يمكنني تذكرها. ستعمل إضافة PHP shebang في معظم البيئات التي تم تثبيت مترجم PHP عليها.

 // file: myscript #!/usr/bin/env php <?php // do stuff here…

مما يجعل من الممكن تنفيذ البرنامج النصي من سطر الأوامر دون تحديد أنه يجب تحليله بواسطة PHP (أو بما في ذلك امتداد الملف .php):

myscript

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

يهدف Robo إلى تسهيل كتابة سطر أوامر PHP من خلال الاهتمام بالكثير من "السباكة" القياسية التي تحتاجها معظم البرامج النصية. يتيح لك هذا التركيز على الوظائف الأساسية لنصوصك.

تثبيت Robo

ستحتاج إلى تثبيت Robo قبل أن نبدأ. أحافظ على تثبيت Robo عالميًا على جهازي ، لذلك قمت بتثبيته على النحو التالي:

يتطلب الملحن العالمي دمج / robo

ولكن كما هو الحال مع أي شيء تم تثبيته عبر Composer ، يمكنك الاحتفاظ به كعنصر تابع للمشروع إذا كنت مرتاحًا أكثر لذلك. بدلاً من ذلك ، يحتوي GitHub على إرشادات حول تثبيته عن طريق تنزيل robo.phar .

أوامتك الأولى

أولاً ، نحتاج إلى تهيئة Robo في مجلد المشروع:

القرص المضغوط / المسار / إلى / myproject
صيغة robo

يؤدي هذا إلى إنشاء RoboFile.php جديد في مجلدك بالمحتوى التالي:

 <?php class RoboFile extends \Robo\Tasks { }

لإضافة أمرنا الأول ، نضيف فقط طريقة عامة:

 <?php class RoboFile extends \Robo\Tasks { public function hello($world) { $this->say("Hello, $world"); } }

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

اعراب الحجج

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

لنوضح لك ما أعنيه ، دعنا نحاول تشغيل هذا الأمر:

مرحبا يا روبو

لا توجد حجج كافية (مفقودة: "العالم").

مرحبًا [-h | --مساعدة] [-q | - هادئ] [-v | vv | vvv | - الإسراف] [-V | - الإصدار] [--ansi] [- no-ansi] [ -n | --لا
-التفاعل] [- محاكاة] [- تأخير التقدم - تأخير التقدم] [-D | - تعريف التحديد] [-]

آها! يعطيني Robo رسالة خطأ لأن الأمر hello يتوقع بالفعل معلمة $world ثم يتابع لكتابة صيغة الاستخدام الكاملة للأمر.

دعنا نغير الطريقة قليلاً ونجعل المعلمة اختيارية:

 public function hello($world = 'from Robo') { $this->say("Hello, $world"); }

... والآن لنقم بتشغيله مرة أخرى:

# بدون حجج
مرحبا يا روبو
مرحبًا من Robo

# بحجة بسيطة
مرحبا يا روبو هناك!
أهلاً بك!

# مع وجود مسافات تحتوي على arg
robo مرحبًا "أنا أعيش في سطر الأوامر"
مرحبًا ، أنا أعيش في سطر الأوامر

هذا أفضل! بجعل المعلمة اختيارية ، ينفذ Robo الآن طريقتنا بسعادة حتى بدون تمرير أي وسيط. لقد رأينا أيضًا أنه يمكننا تمرير حجة بسيطة وحجة داخل علامات الاقتباس وهي تعمل فقط.

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

يستخدم الأمر example hello وسيطة موضعية واحدة. يدعم Robo أيضًا استخدام العلامات والوسيطات المسماة عن طريق إنشاء وسيطة مصفوفة ببعض القيم الافتراضية.

دعنا نعدل الوظيفة أكثر لطباعة بعض الأحرف الإضافية اختياريًا:

 public function hello( $world = 'from Robo', $flags = [ 'stars' => false, 'stripes' => false ] ) { if ( $flags['stars'] ) $this->say( '***************' ); if ( $flags['stripes'] ) $this->say( '===============' ); $this->say( "Hello, $world" ); if ( $flags['stripes'] ) $this->say( '==============='); if ( $flags['stars'] ) $this->say( '***************' ); }

سيخبر هذا Robo أنه يمكننا اختياريًا تمرير وسيطات مسماة باستخدام شرطات مزدوجة:

# فقط من خلال تضمين وسيطة مسماة ، ستحصل على القيمة "true"
مرحبا روبو - النجوم
 *****************
 مرحبًا من Robo
 *****************

المدخلات والمخرجات

لقد رأينا أيضًا مثالًا باستخدام IO. تقوم وظيفة say() الخاصة بكائن مهمة Robo بإخراج سلسلة نصية إلى المستخدم. هناك أيضًا وظيفة ask() تتيح لك مطالبة المستخدم بالإدخال:

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
مرحبا يا روبو
؟ قل لي ماذا أقول: foobar
فوبار

يستخدم Robo وحدة تحكم Symfony لإنشاء تفاعلات المستخدم. هذا يعني أنه بالإضافة إلى وظيفتي say() و ask() البسيطتين ، يمكننا الوصول إلى أي وظيفة من Symfony Console ، مثل table() :

 public function table() { $this->io()->table( ['Header 1', 'Header 2'], [ ['Cell 1-1', 'Cell 1-2'], ['Cell 2-1', 'Cell 2-2'], ['Cell 3-1', 'Cell 3-2'], ] ); }
طاولة روبو
---------- ----------
 الرأس 1 الرأس 2
---------- ----------
 الخلية 1-1 الخلية 1-2
 الخلية 2-1 الخلية 2-2
 الخلية 3-1 الخلية 3-2
---------- ----------

رائع جدًا ، أليس كذلك؟

مساعدين رائعين

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

 # Create a directory, and switch to it: $this->taskExecStack() ->stopOnFail() ->exec('mkdir site') ->exec('cd site') ->run(); # Search and replace inside a text file: $this->taskReplaceInFile('VERSION') ->from('0.2.0') ->to('0.3.0') ->run(); # Run composer update: $this->taskComposerUpdate()->run(); # SSH into a server, go to a specific directory, list the contents of the directory, and set permissions on the logs subdirectory $this->taskSshExec('remote.example.com', 'user') ->remoteDir('/var/www/html') ->exec('ls -la') ->exec('chmod g+x logs') ->run();

كل ما سبق ممكن باستخدام دالة PHP و exec() العادية ، ولكن غالبًا ما يصبح هذا تمرينًا ميؤوسًا منه لمحاولة لصق سلاسل الأوامر معًا والهروب من الحجج بشكل صحيح دون العبث بالأشياء بشكل سيء للغاية.

إلى جانب الأمثلة المذكورة أعلاه ، هناك أيضًا دعم مماثل لـ Git و Subversion و Rsync و Bower و Gulp و Docker و NPM وغيرها من الأدوات التي غالبًا ما تستخدم في بيئات التطوير.

فوائد Robo

مجتمعة ، تجعل Robo إنشاء نصوص سطر الأوامر أسهل كثيرًا والنتيجة النهائية عادةً ما تكون أكثر جاذبية من الناحية الدلالية من PHP العادي.

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

صيانة WordPress باستخدام Robo

تفترض بقية هذه المقالة أنك على دراية إلى حد ما بـ WP-CLI ، باستخدام Composer ، وتعمل مع سطر الأوامر.

الملفات المهمة

هناك أربعة ملفات مهمة في هذا الإعداد. سأغطي كل واحد منهم خلال هذا المنشور:

  1. wp-cli.yml - ملف تكوين WP-CLI القياسي. أنا أستخدم هذا للاستفادة من العديد من الميزات المضمنة الرائعة في WP-CLI عندما يتعلق الأمر بإدارة بيئات متعددة.
  2. RoboFile.php - هذا هو الملف الأساسي لتنفيذ أوامر robo.
  3. robo.yml - ملف YAML مخصص لبعض معلمات التكوين الإضافية لأوامر Robo الخاصة بنا.
  4. composer.json - ملف تكوين Composer القياسي.

بيئتي

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

~ / src
├── ديفينف /
│ ├── RoboFile.php
│ ├── الملحن. json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── ووردبريس-ديف /
│ └── اختبار ووردبريس /    
├── المساعد 1 /
│ ├── الأصول /
│ └── تشمل /
└── البرنامج المساعد 2
    └── ...

مجلد src هو المكان الذي يتم فيه تخزين كل ما يتعلق بالتطوير ، ويحتوي مجلد devenv على ملفات خاصة ببيئة وقت التشغيل الفعلية. نظرًا لأن لدي عادةً أكثر من بيئة WordPress تعمل في نفس الوقت ، فإن كل تثبيت WordPress له مجلد فرعي خاص به ، يسمى wordpress-dev و wordpress-test في هذا المثال.

كل مكون إضافي أعمل عليه موجود في مجلد منفصل لكل مكون إضافي.

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

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

لإنجاح كل شيء ، قمت أيضًا بإنشاء قواعد بيانات محلية لكل من تثبيتات WordPress في تثبيت MySQL المحلي الخاص بي وهناك مستخدم قاعدة بيانات ، يُسمى بشكل مناسب wordpress ، مع الوصول الصحيح إلى قواعد البيانات هذه. يتم تخزين التفاصيل الدقيقة لقواعد البيانات وكذلك بيانات اعتماد المستخدم في ملف wp-cli.yml .

قاعدة بيانات للانترنت

أنا أستخدم nginx كخادم ويب محلي ، لكنك ستجد أن Apache2 يعمل أيضًا. تم إعداد إعداد nginx الخاص بي بحيث يقوم http://www.wordpress-dev.local و http://www.wordpress-test.local إلى مجلدي WordPress المذكورين أعلاه.

رعاية التبعيات

لجعل نصوص Robo النصية أكثر مرونة ، أستخدم بعض الوظائف الإضافية المثبتة عبر Composer ، وتحديداً محلل Symfony Yaml. نظرًا لأن RoboFile.php هو في الحقيقة مجرد ملف PHP عادي ، فأنا حر في تضمين أي مكتبات أريدها وأستخدم Composer بشكل طبيعي للقيام بذلك. يبدو ملف composer.json لهذا المشروع كما يلي:

 { "require": { "symfony/yaml": "^5.2" } }

إذا قمت بنسخ ذلك ، فلا تنس تثبيت المكتبة بالفعل باستخدام composer update .

الاستفادة من ملف wp-cli.yml

عند العمل مع WP-CLI ، يمكنك جعل الحياة أكثر بساطة باستخدام ملف تكوين مثل wp-cli.yml . أستخدم ملف تكوين WP-CLI لسببين رئيسيين: الأسماء المستعارة وإعداد الإعدادات الافتراضية للعديد من الأوامر الفرعية.

ما هو الاسم المستعار في WP-CLI؟

في جوهره ، يعد الاسم المستعار WP-CLI مجرد تسمية في ملف التكوين يتيح لك تجاوز بعض الإعدادات الافتراضية.

من المحتمل أن يكون الاستخدام الأكثر شيوعًا للأسماء المستعارة هو تجاوز path الافتراضي بحيث يشير كل اسم مستعار إلى تثبيت WordPress منفصل. نظرًا لأن كل تثبيت WordPress يحتفظ بملف التكوين الخاص به مع بيانات اعتماد قاعدة البيانات ، فإن الاسم المستعار المستخدم بهذه الطريقة يمثل أيضًا قاعدة بيانات منفصلة. يمكن أن يتجاوز الاسم المستعار في ملف تكوين WP-CLI إعدادات url path user و ssh و http ، لكن لا يمكنه تجاوز القيم الافتراضية للأوامر الفرعية.

يتيح لي إنشاء بيئة WordPress إضافية باسم @test تشغيل أوامر WP-CLI مثل هذا:

# ضع قائمة بجميع الإضافات في تثبيت dev WordPress
قائمة المكونات الإضافية wp

# ضع قائمة بجميع الإضافات في اختبار تثبيت WordPress
wptest قائمة المكونات الإضافية

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

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

$ wp config create --dbname = somedb --dbuser = myuser --dbpass = secret

إذا سئمت من كتابة هذا ، يمكنك لصق المعلمات في ملف wp-cli.yml :

 config create: dbuser: myuser dbpass: secret dbname: somedb

بمجرد القيام بذلك ، يمكنك فقط استخدام wp config create وسيقوم بالتقاط المعلمات الصحيحة من ملف wp-cli.yml الخاص بك.

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

يبدو ملف التكوين WP-CLI الخاص بي كما يلي:

 # Global parameter defaults path: wordpress-dev url: http://www.wordpress-dev.local user: admin @test: path: wordpress-test url: www.wordpress-test.local # Subcommand defaults config create: dbuser: wordpress dbpass: ***** dbname: wordpress extra-php: | define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true); define( 'SCRIPT_DEBUG', true ); core install: admin_user: admin admin_password: admin admin_email: [email protected] title: WordPress Dev core multisite-install: admin_user: admin admin_password: admin admin_email: [email protected]

مع وجود ملف التكوين هذا في مكانه ، يمكنني تشغيل أوامر مشتركة دون الحاجة إلى تحديد المعلمات الفردية في كل مرة:

# إعادة تعيين قاعدة البيانات في بيئة الاختبار
إعادة تعيين wptest db - نعم

# قم بتنزيل أحدث إصدار وأنشئ ملف wp-config.php
wp @ اختبار الأساسية تنزيل
wptest config create

# تثبيت WordPress
wptest core install --title = "اختبار WordPress"

نظرًا لأن WP-CLI يلتقط معظم المعلمات من ملف التكوين ، فلا يتعين علي كتابة جميع معلمات سطر الأوامر مثل --dbuser و --admin_email التي سأضطر إليها عادةً.

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

إنشاء أوامر مخصصة لـ Robo

لا يكفي أبدًا إعداد تثبيت جديد لـ WordPress. عادةً ما يكون هناك مكون إضافي واحد أو أكثر يلزم تثبيته وتنشيطه وغالبًا ما يكون هناك عدد قليل من الإعدادات لإصلاحها هنا وهناك.

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

# إعادة تعيين بيئة التطوير الخاصة بي
إعادة تعيين wp db - نعم
rm -rf path / to / wordpress
تنزيل wp core
wp config إنشاء
تثبيت wp core
مسار ln -s / إلى / my / plugin1 path / to / wordpress / wp-content / plugins /
wp plugin بتنشيط plugin1

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

  • إعادة تعيين - إعادة تعيين بيئة WordPress إلى حالة معروفة.
  • ملف التعريف - يقوم بتشغيل مجموعة من الأوامر في بيئة موجودة.

نظرًا لأن المعلمات الافتراضية للأوامر الفرعية WP-CLI لا تمتد إلى بيئات سطر أوامر مختلفة ، يمكننا استخدام Robo لقتل هذا الطائر بنفس الحجر. دعونا نرى كيف.

تكوين الأوامر

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

 wordpress-dev: cli-prefix: "" path: "wordpress" core-multisite-install: title: WordPress Multisite post-install: - ln -s $cwd/../plugins1 $path/wp-content/plugins/ - ln -s $cwd/../plugins2 $path/wp-content/plugins/ wordpress-test: cli-prefix: "@test" path: "wordpress-test" config-create: dbname: wordpress-test core-install: title: WordPress Test core-multisite-install: title: WordPress Test Multisite post-install: - ln -s $cwd/../plugins1 $path/wp-content/plugins/ profiles: woocommerce: - $wp plugin install --activate woocommerce - $wp wc payment_gateway update cheque --enabled=true --user=admin - $wp option update woocommerce_calc_taxes yes - $wp wc tax create --name=VAT --rate=10 --user=admin - $wp wc shipping_zone_method create 0 --method_id=flat_rate --user=admin - $wp option update --format=json woocommerce_flat_rate_1_settings '{"title":"Flat rate","tax_status":"taxable","cost":"15"}' imageimport: - $wp media import $cwd/../media/lots-of-images/* issue2530: - $wp plugin install --activate some_plugin - $wp config set FOOBAR true --raw

يتم تحديد كل بيئة WordPress باستخدام مفتاح wordpress-$env . يمكن أن يحتوي كل مفتاح على عدة قيم تكوين.

reset التعيين

يتم reset الأمر الأول. يتم استخدامه من سطر الأوامر مثل هذا:

# إعادة تعيين بيئة dev (الافتراضية)
إعادة تعيين الروبوت

# أو أن تكون أكثر صراحة
إعادة تعيين robo –env = dev

# إعادة ضبط بيئة الاختبار
إعادة تعيين robo –env = اختبار

# إعادة ضبط بيئة التطوير وتثبيت موقع WordPress متعدد المواقع
إعادة تعيين الروبوت - متعدد

# إعادة تعيين بيئة التطوير إلى إصدار معين من WordPress
إعادة تعيين robo --ver = 5.6.1

أول شيء يفعله هذا الأمر هو حذف جميع الملفات والمجلدات الموجودة في دليل تثبيت WordPress الهدف وإعادة تعيين قاعدة بيانات WordPress التي تم تكوينها.

بعد ذلك ، يستخدم أمر reset التعيين core download لأوامر WP-CLI ، config create وأحد core install core multisite-install اعتمادًا على الخيار --multi المواقع.

إلى أقصى حد ممكن ، يستخدم هذا الإعدادات الافتراضية لمعلمات الأمر الموجودة في ملف wp-cli.yml . والسبب في ذلك هو أن هذه الإعدادات الافتراضية مفيدة أيضًا عند تشغيل WP-CLI مباشرةً بدون غلاف Robo. ولكن كما نوقش أعلاه ، في بعض الحالات لا يكون ذلك ممكنًا.

لذلك يوفر ملف التكوين robo.yml إمكانية تحديد تجاوزات الإعدادات الافتراضية في wp-cli.yml. على سبيل المثال ، عند تثبيت بيئة الاختبار @ ، نريد تجاوز المعلمات الخاصة --title core install - العنوان. يمكننا القيام بذلك عن طريق إضافة ما يلي في robo.yml :

 wordpress-test: ... ... core-install: title: WordPress Test ... ...

الصيغة هنا سهلة للغاية: اسم أمر CLI (تم استبدال المسافات بشرطات) كمفتاح ومفتاح فرعي واحد لكل معلمة مسماة. يُنشئ المثال أعلاه المعلمة الإضافية التالية لأمر core install cli:

wptest core install --title = "اختبار WordPress"

خطوات ما بعد التثبيت

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

سلسلة تم استبداله ب
دولار كندي دليل العمل الحالي
المسار $ مسار تثبيت WordPress الهدف
$ wp الأمر wp-cli ، بما في ذلك بادئة الاسم المستعار ، أي wptest
~ (رمز التلدة) دليل HOME للمستخدم الحالي

لذا فإن خطوة ما بعد التثبيت من ln -s $cwd/../plugin1 $path/wp-content/plugins/ من أحد مجلدات الإضافات الخاصة بي إلى المجلد الفرعي للمكونات الإضافية في تثبيت WordPress الهدف.

قيادة profile

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

# إعادة تعيين بيئة التطوير
إعادة تعيين الروبوت

# قم بتثبيت WooCommerce وقم بإجراء بعض تغييرات الإعداد
ملف تعريف robo woocommerce

يحتوي نموذج ملف robo.yml أعلاه على ملف تعريف WooCommerce. سيؤدي تطبيق هذا الملف الشخصي إلى:

  • قم بتثبيت وتنشيط WooCommerce باستخدام WP-CLI.
  • استخدم الأمر wc الفرعي لإعداد بوابة الدفع والمنطقة الضريبية وإعدادات الشحن.
  • استخدم الأمر الفرعي option لتعديل بعض الإعدادات مباشرة في جدول خيارات WordPress.

استخدام ملفات تعريف مختلفة مفيد للغاية. أقضي معظم أيامي في العمل على المكون الإضافي WP Offload Media وغالبًا ما أحتاج إلى استيراد الكثير من الصور إلى مكتبة وسائط WordPress. WP-CLI لديه أمر مناسب حقًا لهذا:

وسائط استيراد wp / بعض / طويل / مسار / I / غالبًا / ننسى / *

نظرًا لأنني غالبًا ما أنسى الكثير من الأشياء بشكل عام وأسماء المسارات الطويلة على وجه الخصوص ، أجد أنه من الأسهل تذكر:

ملف robo imageimport

هنا مثال آخر. لقد كنت أعمل على مشكلة GitHub معينة حيث نحاول إصلاح مشكلة التوافق بين المكون الإضافي الخاص بنا ومكوِّن إضافي مشهور آخر في WordPress. عندما أعمل على هذه المشكلة ، أحتاج إلى تثبيت هذا المكون الإضافي وتعيين قيمة التكوين في wp-config.php. لذلك قمت بإنشاء ملف تعريف لها:

 .... issue2530: - $wp plugin install --activate some_plugin - $wp config set FOOBAR value

الآن يمكنني تجهيز بيئتي للعمل في خطوة واحدة ، فقط robo profile issue2530 .

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

المصدر

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

 <?php use Robo\Symfony\ConsoleIO; use Robo\Tasks; use Symfony\Component\Yaml\Yaml; require_once 'vendor/autoload.php'; /** * Class RoboFile */ class RoboFile extends Tasks { /** * Reset the WordPress environment to a known state. Reads environments * and configuration from robo.yml * * @option env Environment (dev, test etc) * @option multi Make a multi site install * @option ver WordPress version * * @return bool */ public function reset( $opts = [ 'env' => 'dev', 'multi' => false, 'ver' => 'latest' ] ) { $env = $opts['env']; $version = $opts['ver']; $multi = $opts['multi']; $all_config = $this->read_yaml(); $key = "wordpress-$env"; if ( ! $this->ensure_basic_config( $all_config, $env ) ) { return false; } if ( ! isset( $all_config[ $key ]['path'] ) ) { $this->say( "No path set for environment $env." ); } $config = $all_config[ $key ]; $prefix = $config['cli-prefix']; $wp = trim( "wp $prefix" ); $path = $config['path']; $path = substr( $path, 0, 1 ) !== '/' ? __DIR__ . '/' . $path : $path; $version = $version === 'latest' ? '' : "--version=$version"; $config_create = $this->additional_parameters( 'config create', $config ); $install_cmd = $multi ? 'core multisite-install' : 'core install'; $install_params = $this->additional_parameters( $install_cmd, $config ); echo "$wp $install_cmd $install_params\n"; $this->taskExec( "$wp db reset --yes" )->run(); $this->taskExecStack() ->exec( "rm -rf $path/*" ) ->exec( "$wp core download $version" ) ->exec( "$wp config create $config_create" ) ->exec( "$wp config delete WP_DEBUG" ) ->exec( "$wp $install_cmd $install_params" ) ->run(); foreach ( $config['post-install'] as $cmd ) { $cmd = str_replace( '$wp', $wp, $cmd ); $cmd = str_replace( '$path', $path, $cmd ); $cmd = str_replace( '$cwd', __DIR__, $cmd ); $cmd = str_replace( '~', getenv( "HOME" ), $cmd ); echo $cmd . "\n"; $this->taskExec( $cmd )->run(); } } /** * Run a set of wp-cli commands on an existing WordPress environment * * @param string $profileName Name of the profile in robo.yml * * @option env Environment (dev, test etc) */ public function profile( $profileName, $opts = ['env' => 'dev']) { $env = $opts['env']; $all_config = $this->read_yaml(); $key = "wordpress-$env"; if ( ! $this->ensure_basic_config( $all_config, $env ) ) { return false; } $config = $all_config[ $key ]; $prefix = $config['cli-prefix']; $wp = trim( "wp $prefix" ); $path = $config['path']; $path = substr( $path, 0, 1 ) !== '/' ? __DIR__ . '/' . $path : $path; if ( ! isset( $all_config['profiles'][ $profileName ] ) ) { $this->say( "Profile $profileName not found" ); return false; } $profile = $all_config['profiles'][ $profileName ]; foreach ( $profile as $cmd ) { $cmd = str_replace( '$wp', $wp, $cmd ); $cmd = str_replace( '$path', $path, $cmd ); $cmd = str_replace( '$cwd', __DIR__, $cmd ); $cmd = str_replace( '~', getenv( "HOME" ), $cmd ); // Quick and dirty. If the cmd exactly matches another profile, run it! if ( isset( $all_config['profiles'][ $cmd ] ) ) { $this->profile( $cmd, $env ); continue; } echo $cmd . "\n"; $this->taskExec( $cmd )->run(); } } /** * @return array */ private function read_yaml() { return Yaml::parseFile( __DIR__ . '/robo.yml' ); } /** * @param $config * @param $env * * @return bool */ private function ensure_basic_config( $config, $env ) { $key = "wordpress-$env"; if ( ! isset( $config[ $key ] ) ) { $this->say( "No path set for environment $env." ); return false; } if ( ! isset( $config[ $key ]['cli-prefix'] ) ) { $this->say( "No wp-cli prefix set for environment $env." ); return false; } return true; } /** * @param string $name * @param array<string, string> $config * * @return string */ private function additional_parameters( $name, $config ) { $name = str_replace( ' ', '-', $name ); if ( ! isset( $config[ $name ] ) ) { return ''; } return implode( ' ', array_map( function ( $v, $k ) { return sprintf( "--%s='%s'", $k, $v ); }, $config[ $name ], array_keys( $config[ $name ] ) ) ); } }

تغليف

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

أتمتة بعض هذه المهام باستخدام مزيج من WP-CLI و Robo التي أوضحتها هنا قد وفر لي الوقت كل يوم كمطور للمكونات الإضافية. لا يمكنني العودة إلى القيام بهذه الأشياء يدويًا مرة أخرى.

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