การจัดการสภาพแวดล้อม WordPress Dev ด้วย WP-CLI และ Robo

เผยแพร่แล้ว: 2022-09-13

การทำงานซ้ำๆ โดยอัตโนมัติเป็นวิธีที่ดีที่สุดวิธีหนึ่งในการประหยัดเวลาในขั้นตอนการพัฒนาของคุณ ในแต่ละวันของฉันทำงานเป็นนักพัฒนาปลั๊กอิน ฉันมักจะต้องรีเซ็ตฐานข้อมูล ติดตั้ง WordPress เวอร์ชันเฉพาะใหม่ ติดตั้งปลั๊กอินอย่างน้อยหนึ่งตัว และอัปเดตการตั้งค่า สิ่งนี้เริ่มน่าเบื่อหน่ายอย่างรวดเร็ว ดังนั้นจึงเหมาะอย่างยิ่งสำหรับระบบอัตโนมัติ ในบทความนี้ ฉันจะแสดงให้คุณเห็นถึงวิธีที่ฉันใช้ WP-CLI ร่วมกับ Robo เพื่อทำให้งานที่จำเป็นในการจัดการสภาพแวดล้อมการพัฒนา WordPress เป็นไปโดยอัตโนมัติ

เครื่องมือบรรทัดคำสั่ง WordPress WP-CLI เป็นจุดเริ่มต้นที่ดีในการเร่งเวิร์กโฟลว์ของคุณ หากคุณไม่คุ้นเคย เราขอแนะนำให้คุณอ่านบทความในบล็อกของเรา คู่มือการติดตั้งของเราเป็นจุดเริ่มต้นที่ดี โดยจะอธิบายวิธีติดตั้งบนระบบปฏิบัติการของคุณ ตั้งค่าแท็บให้สมบูรณ์ และสร้างไฟล์การกำหนดค่า

สารบัญ

  1. Robo คืออะไร?
    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 คืออะไร?

Robo เป็นโอเพ่นซอร์สวิ่งงานสมัยใหม่ที่ใช้โดยหลายโครงการรวมถึง Drush และ Codeception

Robo นั้นคล้ายกับ Gulp และ Grunt แต่ใช้ PHP มากกว่า JavaScript

แนวคิดก็คือคุณสามารถสร้างคำสั่งเล็กๆ น้อยๆ ได้ดังนี้:

# รีเซ็ตสภาพแวดล้อม WP dev ของฉันและทำให้เป็นหลายไซต์
โรโบรีเซ็ต --multi

# ติดตั้งและตั้งค่าปลั๊กอิน WP Offload Media
โปรไฟล์โรโบ ome-dev

Robo task runner ทำให้ง่ายต่อการบันทึกคำสั่งที่คุณสร้างโดยการเพิ่มความคิดเห็น DocBlock ให้กับคำสั่งของคุณ ดังนั้นคุณจึงสามารถให้ความช่วยเหลือสำหรับตัวคุณเองในเวอร์ชันต่อๆ ไป:

# Robo โดยไม่มีข้อโต้แย้งจะแสดงคำสั่งที่มีอยู่
หุ่นยนต์

คำสั่งที่ใช้ได้:
  help แสดงความช่วยเหลือสำหรับคำสั่ง
  รายการ รายการคำสั่ง
  profile เรียกใช้ชุดคำสั่ง wp-cli บนสภาพแวดล้อม WordPress ที่มีอยู่
  รีเซ็ต รีเซ็ตสภาพแวดล้อม WordPress เป็นสถานะที่รู้จัก

ขอข้อมูลเพิ่มเติมเกี่ยวกับคำสั่งเฉพาะ:

โบช่วยรีเซ็ต

คำอธิบาย:
  รีเซ็ตสภาพแวดล้อม WordPress เป็นสถานะที่รู้จัก อ่านสภาพแวดล้อมและการกำหนดค่า 
  จาก robo.yml

การใช้งาน:
  รีเซ็ต [ตัวเลือก]

ตัวเลือก:
      --env[=ENV] สภาพแวดล้อม (dev, ทดสอบ ฯลฯ ) [ค่าเริ่มต้น: "dev"]
      --multi ทำการติดตั้งหลายไซต์
      --ver[=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 ในโฟลเดอร์โครงการ:

cd /path/to/myproject
หุ่นยนต์เริ่มต้น

นี่เป็นเพียงการสร้าง 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|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [ -n|--ไม่
-ปฏิสัมพันธ์] [--จำลอง] [--ความคืบหน้า-ล่าช้า ความคืบหน้า-ล่าช้า] [-D|--กำหนดกำหนด] [--]

อ้า! Robo ให้ข้อความแสดงข้อผิดพลาดแก่ฉันเนื่องจากคำสั่ง hello คาดว่าจะมีพารามิเตอร์ $world จากนั้นจึงดำเนินการเขียนไวยากรณ์การใช้งานแบบเต็มสำหรับคำสั่ง

มาเปลี่ยนวิธีการเล็กน้อยและทำให้พารามิเตอร์เป็นทางเลือก:

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

…และตอนนี้เรามาเริ่มกันใหม่อีกครั้ง:

#ไม่มีข้อโต้แย้ง
สวัสดีโรโบ
สวัสดี จาก Robo

#ด้วยอาร์กิวเมนต์ง่ายๆ
โบ สวัสดีที่นั่น!
สวัสดี!

# ด้วย arg ที่มีช่องว่าง
robo สวัสดี“ ฉันอยู่บนบรรทัดคำสั่ง”
สวัสดี ฉันอยู่บนบรรทัดคำสั่ง

มันดีกว่า! ด้วยการทำให้พารามิเตอร์เป็นทางเลือก ตอนนี้ Robo ดำเนินการตามวิธีการของเราอย่างมีความสุขโดยไม่ต้องผ่านการโต้แย้ง เรายังเห็นว่าเราสามารถส่งผ่านอาร์กิวเมนต์ง่ายๆ และอาร์กิวเมนต์ภายในเครื่องหมายคำพูดได้ และมันใช้ได้ผล

หากคุณเคยใช้เวลาในการเขียนอาร์กิวเมนต์ตรวจสอบตรรกะสำหรับสคริปต์บรรทัดคำสั่ง คุณอาจรู้ว่าเหตุใดจึงเป็นคุณลักษณะที่ดี มันใช้เวลามากความเจ็บปวดออกไป

ตัวอย่างคำสั่ง 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 ว่าเราอาจเลือกที่จะส่งผ่านอาร์กิวเมนต์ที่มีชื่อโดยใช้ขีดกลางคู่:

#เพียงใส่อาร์กิวเมนต์ที่มีชื่อก็จะได้รับค่า 'จริง'
โบ สวัสดี --stars
 ***************
 สวัสดี จาก Robo
 ***************

อินพุตและเอาต์พุต

เราได้เห็นตัวอย่างการใช้ IO แล้ว ฟังก์ชัน say() ของวัตถุงาน Robo เพียงแค่ส่งออกสตริงกลับไปยังผู้ใช้ นอกจากนี้ยังมีฟังก์ชั่น ask() ที่ให้คุณถามผู้ใช้สำหรับการป้อนข้อมูล:

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
สวัสดีโรโบ
? บอกหน่อยซิว่าฟูบาร์
ฟูบาร์

Robo ใช้ Symfony Console เพื่อสร้างการโต้ตอบกับผู้ใช้ ซึ่งหมายความว่านอกเหนือจากฟังก์ชัน 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
├── devenv/
│ ├── RoboFile.php
│ ├── นักแต่งเพลง.json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── wordpress-dev/
│ └── wordpress-test/    
├── ปลั๊กอิน1/
│ ├── ทรัพย์สิน/
│ └── รวม/
└── plugin2
    └── ...

โฟลเดอร์ 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 โดยเฉพาะ Parser 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
wp @test รายการปลั๊กอิน

ค่าเริ่มต้นของคำสั่ง

หากคุณไม่เคยลองมาก่อน การตั้งค่าพารามิเตอร์เริ่มต้นสำหรับคำสั่งย่อยจะสะดวกมาก ตัวอย่างเช่น เมื่อคุณสร้างไฟล์การกำหนดค่า 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]

ด้วยไฟล์การกำหนดค่านี้ ฉันสามารถเรียกใช้คำสั่งทั่วไปโดยไม่ต้องระบุพารามิเตอร์แต่ละรายการทุกครั้ง:

# รีเซ็ตฐานข้อมูลในสภาพแวดล้อมการทดสอบ
wp @test db reset --ใช่

# ดาวน์โหลดเวอร์ชันล่าสุดและสร้างไฟล์ wp-config.php
wp @test core ดาวน์โหลด
wp @test config create

# ติดตั้ง WordPress
wp @test core install --title="ทดสอบ WordPress"

เนื่องจาก WP-CLI รับพารามิเตอร์ส่วนใหญ่จากไฟล์การกำหนดค่า ฉันจึงไม่ต้องพิมพ์พารามิเตอร์บรรทัดคำสั่งทั้งหมด เช่น --dbuser และ --admin_email ที่ปกติแล้วฉันจะต้องทำ

โปรดทราบว่าในตัวอย่างสุดท้ายข้างต้น ฉันได้ระบุพารามิเตอร์ title แยกต่างหาก เนื่องจากฉันต้องการให้ชื่อไซต์แตกต่างกันในสภาพแวดล้อมการทดสอบ แต่ไม่สามารถแทนที่พารามิเตอร์นี้โดยใช้นามแฝงได้

การสร้างคำสั่ง Robo แบบกำหนดเอง

การตั้งค่าการติดตั้ง WordPress ใหม่แทบไม่เคยเพียงพอ โดยปกติจะมีปลั๊กอินอย่างน้อยหนึ่งตัวที่ต้องติดตั้งและเปิดใช้งาน และมักจะมีการตั้งค่าบางอย่างที่ต้องแก้ไขที่นี่และที่นั่น

แม้จะมีไฟล์การกำหนดค่า WP-CLI ที่เขียนอย่างระมัดระวัง ฉันก็ยังต้องลงเอยด้วยคำสั่งยาวๆ หากฉันต้องการรีเซ็ตสภาพแวดล้อม WordPress ของฉันและเตรียมทุกอย่างให้พร้อม ฉันมักจะทำซีเควนซ์แบบนี้ซ้ำแล้วซ้ำเล่า:

# รีเซ็ตสภาพแวดล้อมการพัฒนาของฉัน
wp db รีเซ็ต --ใช่
rm -rf เส้นทาง/to/wordpress
ดาวน์โหลดแกน wp
wp config สร้าง
wp core ติดตั้ง
ln -s path/to/my/plugin1 path/to/wordpress/wp-content/plugins/
ปลั๊กอิน wp เปิดใช้งาน plugin1

แม้จะใช้ประโยชน์จากไฟล์กำหนดค่า WP-CLI อย่างเต็มที่ แต่ก็เป็นการพิมพ์จำนวนมาก เพื่อหลีกเลี่ยงการพิมพ์ซ้ำแล้วซ้ำอีกและทำให้ผิดพลาดเป็นระยะๆ ฉันได้สร้างคำสั่งพิเศษสองคำสั่งโดยใช้ Robo เพื่อทำสิ่งนี้ให้กับฉัน:

  • รีเซ็ต – รีเซ็ตสภาพแวดล้อม WordPress เป็นสถานะที่รู้จัก
  • profile – เรียกใช้ชุดคำสั่งในสภาพแวดล้อมที่มีอยู่

เนื่องจากพารามิเตอร์เริ่มต้นของคำสั่งย่อย 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 (ค่าเริ่มต้น)
โรโบรีเซ็ต

#หรือมีความชัดเจนมากขึ้น
โรโบรีเซ็ต –env=dev

# รีเซ็ตสภาพแวดล้อมการทดสอบ
โรโบรีเซ็ต –env=test

# รีเซ็ตสภาพแวดล้อม dev และติดตั้ง WordPress multisite
โรโบรีเซ็ต --multi

# รีเซ็ตสภาพแวดล้อม dev เป็น WordPress เวอร์ชันเฉพาะ
โรโบรีเซ็ต --ver=5.6.1

สิ่งแรกที่คำสั่งนี้ทำคือการลบไฟล์และโฟลเดอร์ที่มีอยู่ทั้งหมดในไดเรกทอรีการติดตั้ง WordPress เป้าหมายและรีเซ็ตฐานข้อมูล WordPress ที่กำหนดค่าไว้

จากนั้นคำสั่ง reset จะใช้คำสั่ง WP-CLI core download , config create และหนึ่งในการ core install หรือการติดตั้ง core multisite-install ขึ้นอยู่กับตัวเลือก --multi

ในขอบเขตที่ใหญ่ที่สุดเท่าที่จะเป็นไปได้ ค่านี้ใช้ค่าดีฟอลต์ของพารามิเตอร์คำสั่งที่อยู่ใน wp-cli.yml เหตุผลก็คือว่าค่าเริ่มต้นเหล่านั้นยังมีประโยชน์เมื่อรัน WP-CLI โดยตรงโดยไม่ต้องใช้ตัวห่อ Robo แต่อย่างที่กล่าวไว้ข้างต้น ในบางกรณีก็เป็นไปไม่ได้

ดังนั้นไฟล์กำหนดค่า robo.yml จึงมีความเป็นไปได้ในการระบุการแทนที่สำหรับค่าเริ่มต้นใน wp-cli.yml. ตัวอย่างเช่น เมื่อติดตั้งสภาพแวดล้อม @test เราต้องการแทนที่พารามิเตอร์สำหรับพารามิเตอร์การ core install --title เราสามารถทำได้โดยเพิ่มสิ่งต่อไปนี้ใน robo.yml :

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

ไวยากรณ์ที่นี่ค่อนข้างง่าย: ชื่อคำสั่ง CLI (ช่องว่างถูกแทนที่ด้วยขีดกลาง) เป็นคีย์และหนึ่งคีย์ย่อยสำหรับพารามิเตอร์ที่มีชื่อแต่ละตัว ตัวอย่างข้างต้นจะสร้างพารามิเตอร์พิเศษต่อไปนี้ให้กับคำสั่ง core install cli:

wp @test core install --title="ทดสอบ WordPress"

ขั้นตอนหลังการติดตั้ง

คีย์สภาพแวดล้อมแต่ละรายการในไฟล์กำหนดค่าสามารถเลือกระบุอาร์เรย์ด้วยขั้นตอนหลังการติดตั้งได้ นี่เป็นเพียงรายการคำสั่งทุบตีที่ดำเนินการเมื่อการติดตั้ง WordPress เสร็จสิ้น เพื่อความยืดหยุ่นที่เพิ่มขึ้น มีการแทนที่สตริงสองสามรายการก่อนที่จะดำเนินการคำสั่ง:

สตริง แทนที่ด้วย
$cwd ไดเร็กทอรีการทำงานปัจจุบัน
$เส้นทาง เส้นทางของการติดตั้ง WordPress เป้าหมาย
$wp คำสั่ง wp-cli รวมถึงคำนำหน้านามแฝง เช่น wp @test
~ (สัญลักษณ์ตัวหนอน) ไดเร็กทอรี HOME ของผู้ใช้ปัจจุบัน

ดังนั้นขั้นตอนหลังการติดตั้งของ ln -s $cwd/../plugin1 $path/wp-content/plugins/ จะสร้าง symlink จากโฟลเดอร์ปลั๊กอินของฉันไปยังโฟลเดอร์ย่อยของปลั๊กอินในการติดตั้ง WordPress เป้าหมาย

คำสั่ง profile

คำสั่ง profile ค่อนข้างคล้ายกับขั้นตอนหลังการติดตั้ง แต่จุดประสงค์ในการใช้งานคือการเรียกใช้ชุดคำสั่งบนการติดตั้ง WordPress ที่มีอยู่ สมมติว่าคุณมีสภาพแวดล้อมการพัฒนาที่ธรรมดามากซึ่งคุณทำงานเป็นส่วนใหญ่ อย่างไรก็ตาม บางครั้งคุณจำเป็นต้องติดตั้งปลั๊กอิน WooCommerce และทำการตั้งค่าพื้นฐานบางอย่าง นี่คือสิ่งที่คำสั่ง profile ใช้สำหรับ สามารถใช้ได้ดังนี้:

# รีเซ็ตสภาพแวดล้อมการพัฒนา
โรโบรีเซ็ต

# ติดตั้ง WooCommerce และทำการเปลี่ยนแปลงการตั้งค่า
โปรไฟล์โรโบ woocommerce

ไฟล์ robo.yml ตัวอย่างด้านบนมีโปรไฟล์ WooCommerce การใช้โปรไฟล์นั้นจะ:

  • ติดตั้งและเปิดใช้งาน WooCommerce โดยใช้ WP-CLI
  • ใช้คำสั่งย่อย wc เพื่อตั้งค่าเกตเวย์การชำระเงิน เขตภาษี และการตั้งค่าการจัดส่ง
  • ใช้คำสั่งย่อย option เพื่อแก้ไขการตั้งค่าบางอย่างโดยตรงในตารางตัวเลือกของ WordPress

การใช้โปรไฟล์ที่แตกต่างกันนั้นค่อนข้างมีประโยชน์ ฉันใช้เวลาส่วนใหญ่ไปกับการทำงานกับปลั๊กอิน WP Offload Media และมักจะต้องนำเข้ารูปภาพจำนวนมากไปยังไลบรารีสื่อของ WordPress WP-CLI มีคำสั่งที่สะดวกมากสำหรับสิ่งนี้:

wp สื่อนำเข้า /some/long/path/I/often/forget/*

เนื่องจากฉันมักจะลืมสิ่งต่างๆ มากมายโดยทั่วไปและโดยเฉพาะอย่างยิ่งชื่อเส้นทางที่ยาวไกล ฉันจึงจำได้ง่ายกว่า:

รูปโปรไฟล์ robo นำเข้า

นี่เป็นอีกตัวอย่างหนึ่ง ฉันได้ทำงานเกี่ยวกับปัญหา GitHub ที่เรากำลังพยายามแก้ไขปัญหาความเข้ากันได้ระหว่างปลั๊กอินของเรากับปลั๊กอิน WordPress ยอดนิยมตัวอื่น เมื่อฉันแก้ไขปัญหานั้น ฉันต้องติดตั้งปลั๊กอินนั้นและตั้งค่าคอนฟิกใน wp-config.php. ดังนั้นฉันจึงสร้างโปรไฟล์สำหรับมัน:

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

ตอนนี้ฉันสามารถเตรียมสภาพแวดล้อมของฉันให้พร้อมสำหรับการดำเนินการในขั้นตอนเดียว เพียงแค่ robo profile issue2530

เช่นเดียวกับขั้นตอน post-install ในคำสั่งรีเซ็ต แต่ละแถวในนิยามโปรไฟล์เป็นเพียงคำสั่งทุบตีที่แยกจากกัน คุณสามารถใช้มันเพื่อเปิดสคริปต์แยก ลบไฟล์ หรืออะไรก็ได้ที่คุณต้องการ นอกจากนี้ยังค่อนข้างเป็นไปได้ที่จะยิงตัวเองที่เท้า ดังนั้นเหยียบอย่างระมัดระวัง

ที่มา

หากข้อใดข้างต้นฟังดูน่าสนใจที่จะลองใช้ นี่คือ 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 ที่ฉันได้สรุปไว้ที่นี่ช่วยประหยัดเวลาให้ฉันได้ทุกวันในฐานะนักพัฒนาปลั๊กอิน ฉันไม่สามารถกลับไปทำสิ่งเหล่านี้ด้วยตนเองได้อีก

คุณใช้เครื่องมือใดในการทำให้ส่วนที่น่าเบื่อที่สุดของเวิร์กโฟลว์การพัฒนาเป็นแบบอัตโนมัติ แจ้งให้เราทราบในความคิดเห็น