คำบรรยายเกี่ยวกับการใช้ผู้แต่งในปลั๊กอิน WordPress

งานชิ้นนี้สนับสนุนโดย Peter Suhm ผู้เขียนรับเชิญ ปีเตอร์เป็นนักพัฒนาเว็บจากดินแดนเดนส์ เขาเป็นผู้สร้าง WP Pusher และเป็นคนติดการเดินทางมาก โดยนำงานของเขาไปกับเขาด้วย

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

เรื่องเล่า

ลองนึกภาพกันซักพักว่าคุณกับฉันต่างก็เป็นผู้เขียนปลั๊กอินกัน เราทั้งคู่ต่างก็มีความคิดที่ดีเกี่ยวกับปลั๊กอินที่เราต้องการจะเผยแพร่ผ่าน WordPress.org เราต้องการรวมคุณลักษณะพิเศษบางอย่างไว้ในปลั๊กอินของเรา ซึ่งผู้ใช้เวอร์ชันฟรีสามารถปลดล็อกได้โดยการป้อนคีย์ใบอนุญาต

เราต้องการรหัสที่สามารถจัดการกับกระบวนการนี้ได้ เราทั้งคู่ตระหนักดีว่าปัญหานี้อาจได้รับการแก้ไขโดยคนอื่นแล้ว พวกเราไม่มีใครเป็นแฟนของการคิดค้นล้อใหม่ ดังนั้นเราจึงไปที่ Packagist และพิมพ์ "ตัวจัดการใบอนุญาต" ดูเหมือนว่าสมมติฐานของเรามีเหตุผล Yoast มีแพ็คเกจที่สามารถจัดการสิ่งนี้ได้แล้ว เราทั้งคู่ตัดสินใจที่จะทำ Quick composer require yoast/license-manager ง่าย สบาย. ตอนนี้ เราสามารถดำเนินการต่อไปในสิ่งที่สำคัญจริงๆ - คุณลักษณะหลักของปลั๊กอินที่เกี่ยวข้องของเรา

กรอไปข้างหน้า พร้อมที่จะปล่อยปลั๊กอินของคุณ คุณเข้าใจบางสิ่งบางอย่าง: ผู้ใช้ของคุณไม่จำเป็นต้องมี Composer ที่มีประโยชน์เมื่อติดตั้งปลั๊กอินจาก WordPress.org แล้วพวกเขาจะรับรหัสสำหรับตัวจัดการใบอนุญาตได้อย่างไร สถานการณ์นี้ค่อนข้างน่ารำคาญเพราะวิธีแก้ปัญหาเดียวที่คุณเห็นคือเพียงแค่คอมมิตไดเร็กทอรี vendor Composer ทั้งหมดไปยังปลั๊กอินของคุณแล้วส่งไปที่ WordPress.org คุณรู้ว่านี่ไม่ใช่วิธีที่ Composer ควรจะทำงาน แต่อะไรก็ตาม คุณไม่มีทางเลือกอื่นจริงๆ

ในขณะเดียวกัน ฉันได้ข้อสรุปเดียวกันกับปลั๊กอินของฉันแล้ว เพียงใส่รหัสตัวจัดการใบอนุญาตและดำเนินการให้เสร็จสิ้น

กรอไปข้างหน้าอีกครั้ง ตอนนี้ปลั๊กอินทั้งสองของเราอยู่ในที่เก็บ WordPress.org และในบางครั้ง มีคนตัดสินใจอัปเกรดเป็นเวอร์ชันพรีเมียมของเรา ดูเหมือนว่าทุกอย่างจะเรียบร้อย และเราทั้งคู่ต่างก็รู้สึกขอบคุณที่เราสามารถใช้โค้ดที่ Yoast ได้ใช้โอเพนซอร์สอย่างไม่เห็นแก่ตัว และไม่จำเป็นต้องสร้างวงล้อขึ้นใหม่

วันหนึ่ง คุณได้รับอีเมลแปลกๆ ลูกค้ากำลังประสบกับพฤติกรรมแปลกๆ บางอย่างเมื่อพยายามปลดล็อกคุณสมบัติพรีเมียมของคุณ มันไม่สมเหตุสมผลสำหรับคุณ เพราะไม่มีใครเคยรายงานเรื่องนี้ หลังจากการดีบักหลายชั่วโมง ในที่สุด คุณก็ขอให้ลูกค้าปิดการใช้งานอย่างอื่นทั้งหมด ยกเว้นปลั๊กอิน จากนั้น: ใช้งานได้! อืม. ดูเหมือนว่าปลั๊กอินของคุณจะเข้ากันไม่ได้กับปลั๊กอินอื่น ปลั๊กอินของฉัน

คุณเข้าใจสิ่งนี้หลังจากใช้เวลาหลายชั่วโมงในการดูซอร์สโค้ดของปลั๊กอินอื่นๆ ทั้งหมดที่ลูกค้าได้ติดตั้งไว้ เมื่อคุณรู้ว่าเราทั้งคู่ใช้ตัวจัดการใบอนุญาต เสียงกริ่งก็ดังขึ้น มันจะเป็นอย่างนั้นจริงๆเหรอ? ถ้าเป็นเช่นนั้น เหตุใดจึงไม่มี fatal errors: cannot redeclare class ที่เกิดจาก PHP ได้

หนึ่งสัปดาห์ก่อนหน้านั้น ฉันได้เพิ่มเวอร์ชันที่จำเป็นของตัวจัดการใบอนุญาตในปลั๊กอินของฉันเป็นเวอร์ชันล่าสุด ซึ่งรวมถึงการเปลี่ยนแปลงบางอย่าง (ในเชิงสมมุติ) ที่เสียหาย หลังจากการดีบักและ var_dump() 'ing มากขึ้น คุณจะรู้ว่าตัวจัดการใบอนุญาตเวอร์ชันของฉันเป็นเวอร์ชันที่โหลดโดย PHP ในปลั๊กอินของคุณ คุณพบว่ามันแปลกมากเพราะคุณต้องการตัวจัดการใบอนุญาตรุ่นอื่นกับ Composer โดยเฉพาะ คุณไม่รู้จริงๆ ว่าจะทำอย่างไรกับเรื่องนี้

เพราะคุณทำอะไรไม่ได้มาก

เกิดอะไรขึ้นที่นี่?

เมื่อเราทุกคนเห็นปัญหาแล้ว ให้ใช้เวลาสักครู่เพื่อทบทวนสิ่งที่เกิดขึ้นจริงในการเล่าเรื่อง ก่อนอื่น เหตุใด PHP จึงไม่ทำให้เกิดข้อผิดพลาดร้ายแรงเมื่อเห็นได้ชัดว่าคลาสสองคลาสมีชื่อเดียวกันกับที่เราทั้งคู่รวมตัวจัดการใบอนุญาตไว้ด้วย

เหตุผลก็คือเราใช้ตัวโหลดอัตโนมัติที่สร้างโดย Composer ตัวโหลดอัตโนมัตินี้จะสแกนโครงสร้างไดเร็กทอรีของการพึ่งพาของเราและเพิ่มทุกคลาสให้กับตัวโหลดอัตโนมัติ หากเพิ่มคลาสแล้ว ผู้แต่งจะไม่สนใจคลาสนั้น เงียบ. ฉันได้เขียนตัวอย่างโค้ดเล็กๆ ไว้ หากคุณต้องการดูเอง มันอยู่บน GitHub

เหตุใดจึงรวมตัวจัดการใบอนุญาตเวอร์ชันของฉันก่อนเวอร์ชันของคุณ

สิ่งนี้เกิดขึ้นเนื่องจากปลั๊กอินของฉันมีชื่อที่ทำให้โหลดก่อนหน้าคุณ บางที ในอนาคต เราทุกคนจะตั้งชื่อปลั๊กอินของเราว่า "Aaaaaa My Plugin" เพื่อให้โหลดได้ก่อน!

โดยสรุปแล้ว ประเด็นหลักในที่นี้คือ เราจะไม่ทราบว่าการอ้างอิงเวอร์ชันใดที่พร้อมให้บริการในเวลาดังกล่าว มันขึ้นอยู่กับปัจจัยที่เราไม่สามารถควบคุมได้อย่างเต็มที่ในฐานะนักพัฒนาปลั๊กอิน

นี่เป็นปัญหาเฉพาะของนักแต่งเพลงหรือไม่

ไม่ มันไม่ใช่อย่างนั้นจริงๆ WordPress ไม่มีวิธีจัดการกับโค้ดของบุคคลที่สามในปลั๊กอินหรือธีม ปัญหาอยู่ในนั้น เหตุผลที่ฉันพูดถึง Composer ก็คือตอนนี้กำลังได้รับความสนใจอย่างมาก หากนักพัฒนา WordPress ต้องการใช้ Composer ในปลั๊กอินที่เผยแพร่ผ่าน WordPress.org สิ่งนี้จะต้องได้รับการแก้ไข มิฉะนั้น เราจะเห็นความโกลาหลที่แท้จริงเมื่อปลั๊กอินทั้งหมดเริ่มเข้ากันไม่ได้เพราะใช้เวอร์ชันต่างกัน ยินดีต้อนรับสู่การดีบักนรก

เราจะทำอะไรได้บ้างเกี่ยวกับเรื่องนี้?

คนที่มีความกังวลเกี่ยวกับเรื่องนี้จริงๆ และทำงานอย่างหนักเพื่อค้นหาวิธีแก้ปัญหาที่เป็นไปได้คือ Coen Jacobs ฉันตัดสินใจติดต่อ Coen และถามเขาว่าเขาคิดว่ามีอะไรที่เราสามารถทำได้เกี่ยวกับเรื่องนี้หรือไม่

นักพัฒนาหลายคนได้รวมโค้ดของบุคคลที่สามไว้ในปลั๊กอินแล้ว นี่เป็นปัญหาจริงๆเหรอ?

ใช่ นี่เป็นปัญหาในระบบนิเวศของปลั๊กอินอยู่แล้ว จะยิ่งแย่ลงไปอีกเมื่อมีผู้คนจำนวนมากขึ้นคิดว่าควรนำฟังก์ชันการทำงานทั่วไปมาไว้ในแพ็คเกจที่แยกจากกัน แพ็คเกจเหล่านี้สามารถรวมเข้ากับปลั๊กอินได้หลายตัว และปัญหาก็จะปรากฏขึ้นมากขึ้นเรื่อยๆ ฉันได้พูดคุยกับนักพัฒนาสองสามรายที่เคยผ่านการดีบักมาแล้วและพยายามค้นหาสาเหตุของปัญหานี้

ก้าวไปข้างหน้า คุณจะแนะนำให้นักพัฒนาหยุดใส่โค้ดของบุคคลที่สามในปลั๊กอินหรือไม่

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

ณ จุดนี้ ฉันต้องการผลักดันการพัฒนาที่เกี่ยวข้องกับ WordPress ไปข้างหน้า ฉันต้องการแบ่งปันห้องสมุดและใช้ห้องสมุดที่ผู้อื่นแบ่งปัน ไม่มีใครควรคิดค้นล้อใหม่ซ้ำแล้วซ้ำอีก ดังนั้น ฉันจะเสี่ยงที่จะเจอปัญหาแบบนี้ แก้ปัญหาตามที่ปรากฏ

นี่ก็หมายความว่าฉันจะทำให้ดีที่สุดเพื่อค้นหาวิธีแก้ปัญหาระยะยาวสำหรับปัญหานี้ ผู้คนจำนวนมากขึ้นจะเริ่มใช้ Composer ผู้คนจำนวนมากขึ้นจะรวมกลุ่มไลบรารีกับปลั๊กอินของพวกเขา ปัญหานี้จะปรากฏขึ้นบ่อยขึ้น ถึงเวลาแก้ไขแล้ว

นักพัฒนาปลั๊กอินสามารถทำอะไรได้บ้างเพื่อป้องกันปัญหานี้

มีวิธีแก้ปัญหาที่ฉันได้เห็นบางคนใช้แล้ว โดยพื้นฐานแล้วจะเป็นการย้ายการพึ่งพาของคุณไปยังเนมสเปซของปลั๊กอิน Danny van Kooten ทำสิ่งนี้กับหนึ่งในปลั๊กอินของเขา นี้ไม่เหมาะอย่างไรก็ตาม ทุกครั้งที่เขาอัปเดตการขึ้นต่อกัน เขาต้องดูไฟล์ทั้งหมดและเปลี่ยนเนมสเปซอีกครั้ง นี่ไม่ใช่งานใหญ่สำหรับห้องสมุดขนาดเล็กอย่าง Pimple แต่เป็นงานใหญ่สำหรับห้องสมุดขนาดใหญ่

สิ่งนี้สามารถทำได้ด้วยเนมสเปซเท่านั้น ดังนั้นคุณจะต้องทำให้ปลั๊กอินของคุณต้องใช้ PHP 5.3+ เช่นกัน ฉันจะไม่โกหก ฉันคิดว่าทุกปลั๊กอินควรเริ่มทำอย่างนั้นไม่ช้าก็เร็ว แต่เป็นสิ่งที่คุณต้องพิจารณาอย่างแน่นอนเมื่อคุณตัดสินใจที่จะทำเช่นนี้

ทางออกที่ดีที่สุดจะเป็นอย่างไรถ้ามี?

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

WordPress ควรทำให้ผู้ใช้ปลายทางง่ายขึ้นในขณะที่ยังช่วยให้นักพัฒนาสามารถใช้แพ็คเกจใดก็ได้ที่ต้องการ ในความคิดนี้ ฉันได้เริ่มรวบรวมปลั๊กอิน WordPress Composer Installer ซึ่ง Composer ทำงานหนักทั้งหมดในขณะที่ผู้คนติดตั้งปลั๊กอินเหมือนที่เคยเป็นมา ทันทีที่ฉันสามารถดำเนินการนี้ให้เสร็จสิ้นได้ ฉันจะผสานรวมเข้ากับโฟลว์ตัวติดตั้งปลั๊กอินทั้งหมดอย่างเหมาะสม

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

บทสรุป

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

สุดท้ายนี้ ฉันต้องการพูดอีกครั้งว่านี่ไม่ใช่ปัญหาของ Composer มันเป็นปัญหาของ WordPress