วิธีเข้าถึงการพัฒนา WordPress สมัยใหม่ (ตอนที่ 1)

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

เหตุใดเราจึงสนใจคุณภาพของโค้ดใน WordPress core? มันใช้งานได้ใช่ไหม

ใช่ มันใช้ได้ผล และ codebase อายุ 15 ปีไม่น่าจะได้รับการปรับโครงสร้างใหม่ทั้งหมดโดยผู้ดูแลอาสาสมัคร น่าเสียดาย นี่หมายความว่ามันยังทำงานเป็นตัวอย่างของการเข้ารหัส “วิถีของ WordPress” ซึ่งทำให้นักพัฒนาจำนวนมากไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดและเทคนิคการพัฒนาที่ทันสมัย ปลั๊กอินและธีมของ WordPress จำนวนมากมีโค้ดที่ไม่ดี และการปฏิบัติตามแนวทางดั้งเดิมอย่างสุ่มสี่สุ่มห้ายังคงมีแนวโน้มต่อไป

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

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

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

แน่นอนว่าสิ่งนี้ใช้ไม่ได้กับงานง่ายๆ อย่างแท้จริง เช่น การเพิ่ม CSS สองสามบรรทัดหรือโพสต์และเขียนใหม่สองสามรายการ แต่การรวมปลั๊กอินสองสามตัวเข้าด้วยกัน (หรือมากกว่าปกติหลายสิบปลั๊กอิน) หรือการสร้างไซต์ที่ขับเคลื่อนด้วย Visual Composer นั้นไม่ใช่วิศวกรรมซอฟต์แวร์

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

เวิร์กโฟลว์การพัฒนา WordPress สมัยใหม่

โดยทั่วไป รหัสคุณภาพคือ:

• อ่านได้ เข้าใจได้ง่ายว่าโค้ดใช้ทำอะไรและเพราะเหตุใด
• โมดูลาร์ โค้ดกลุ่มเล็กๆ ที่มีจุดประสงค์ที่ชัดเจนนั้นง่ายต่อการเข้าใจ พัฒนา และทดสอบ
• นำกลับมาใช้ใหม่ได้ การนำโมดูลที่พัฒนาแล้วกลับมาใช้ใหม่เพื่อแก้ปัญหาที่คล้ายคลึงกันจะช่วยเร่งการพัฒนาได้อย่างมาก
• บำรุงรักษาได้ การปรับเปลี่ยนฟังก์ชันการทำงานเก่าหรือการแนะนำคุณลักษณะใหม่เป็นเรื่องง่าย

ผลลัพธ์หลัก—ต้นทุนการพัฒนาและการเป็นเจ้าของที่ต่ำกว่า—มีประโยชน์มากมายที่ฉันจะไม่พูดถึงที่นี่

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

ใช้การควบคุมเวอร์ชัน

นี่หมายถึงการใช้ Git น่าเศร้าที่ “การเข้ารหัสคาวบอย” ในการผลิตผ่าน FTP นั้นยังคงเป็นเรื่องที่น่าสนใจ เมื่อเร็ว ๆ นี้ฉันทำงานให้กับเอเจนซี่ในสหราชอาณาจักรและพวกเขามีไฟล์ที่มีชื่อเช่นนี้ทั่ว codebase:

• functions copy.php
• functions copy 2.php
• functions test.php
• functions2.php
• functions test2.php

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

ทำผิดพลาดในรหัสของคุณและทั้งเว็บไซต์ก็ล่ม? การ git reset ทำให้ทุกอย่างกลับมาเหมือนเดิม การอัปเดตเวอร์ชันใหม่ทำลายทุกอย่าง? git reset ทำงานเหมือนไทม์แมชชีน รหัสที่เป็นอันตรายบางตัวปรากฏขึ้นจากที่ไหนเลย? git status แสดงไฟล์ใหม่ ไฟล์ที่ถูกลบ หรือการเปลี่ยนแปลงในไฟล์ที่ติดตาม จากนั้นคุณเพียงแค่ git checkout กู้คืนต้นฉบับ

ระวังการเปิดเผย .git Folder

ตกลง การใช้ Git เป็นสิ่งสำคัญอย่างชัดเจน แต่เมื่อคุณทำเช่นนั้น สิ่งสำคัญคือต้องหลีกเลี่ยงการเปิดเผยที่เก็บ Git ของคุณให้ถูกแฮ็ก ปัญหาจะเกิดขึ้นเมื่อคุณมีโฟลเดอร์ .git ถูกเปิดเผยและจัดเก็บข้อมูลรับรองของคุณไว้ในโฟลเดอร์นั้น

การติดตั้ง WordPress มาตรฐานใช้งานได้เต็มรูปแบบในโฟลเดอร์เว็บสาธารณะ และโฟลเดอร์ .git ก็มักจะอยู่ที่นั่นเช่นกัน เห็นได้ชัดว่าไม่ควรจัดเก็บข้อมูลรับรองการเข้าสู่ระบบไว้ในที่เก็บ Git แต่เกิดขึ้นที่ที่เก็บข้อมูลส่วนใหญ่มีข้อมูลที่ละเอียดอ่อนซึ่งไม่ควรรั่วไหลออกไปภายนอก

ดังนั้นการเข้าถึงโฟลเดอร์ .git แบบสาธารณะจึงควรถูกบล็อก หากคุณใช้ Apache การเพิ่มข้อมูลโค้ดด้านล่างที่ด้านบนของไฟล์ . .htaccess จะบล็อกการเข้าถึงโฟลเดอร์ .git และไฟล์บันทึกด้วยเช่นกัน ไฟล์บันทึกมักจะมีข้อมูลที่ละเอียดอ่อน ดังนั้นจึงควรทำให้ไม่พร้อมใช้งานเช่นกัน สำหรับการตั้งค่าเว็บเซิร์ฟเวอร์ต่างๆ โปรดขอความช่วยเหลือจากผู้เชี่ยวชาญ DevOps

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

ใช้สภาพแวดล้อมที่แยกจากกัน

อย่าทำการพัฒนาบนไซต์สด - นี่เป็นสูตรสำหรับการหยุดทำงานและลูกค้าที่ไม่มีความสุข ตกลง แต่คุณควรตั้งค่าอย่างไร

ตามหลักการแล้ว ควรมีสภาพแวดล้อมการพัฒนาสามแบบ โดยที่โค้ดจะไปในทิศทางเดียวเสมอ: local → staging → production นี่เป็นวิธีที่พิสูจน์แล้วเพื่อหลีกเลี่ยงการชน การอัปเดตหลัก ปลั๊กอิน และธีมทั้งหมดจะทำในเครื่องก่อน จากนั้นจึงทดสอบในการแสดงขั้นตอน และในที่สุดก็ปรับใช้กับเวอร์ชันที่ใช้งานจริงได้

ตัวอย่างเช่น การกำหนดค่าเฉพาะเซิร์ฟเวอร์สามารถเก็บไว้ในไฟล์แยกต่างหากได้ คุณสามารถสร้าง wp-config-local.php สำหรับแต่ละสภาพแวดล้อมภายในเครื่องและสภาวะแวดล้อม (อย่าลืมเพิ่มลงในไฟล์ .gitignore ของคุณ!) จากนั้นเพิ่มข้อมูลโค้ดต่อไปนี้ใน wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

บ่อยครั้งวิธีที่ดีที่สุดในการตั้งค่าสภาพแวดล้อมที่แตกต่างกันคือการใช้ตัวแปรสภาพแวดล้อม หากคุณไม่คุ้นเคยกับแนวคิดนี้ ฉันขอแนะนำให้ใช้โซลูชันที่ทันสมัยอย่างสมบูรณ์ เช่น Roots

ใช้ WP-CLI

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

อีกตัวอย่างหนึ่งคือการปรับใช้ครั้งแรกทำได้ง่ายด้วย WP-CLI สิ่งเหล่านี้สามารถทำได้ด้วยคำสั่งไม่กี่คำสั่ง:

• กำลังดาวน์โหลดแกน ธีม และปลั๊กอิน
• การค้นหาและแทนที่ในฐานข้อมูล
• การเพิ่มผู้ดูแลระบบผู้ใช้

นอกจากนี้ การกระทำเหล่านี้สามารถเขียนสคริปต์และทำงานอัตโนมัติได้

ใช้ตัวเลือกการปรับใช้ขั้นสูง

เมื่อพูดถึงระบบอัตโนมัติ การเรียนรู้เทคโนโลยีและกระบวนการปรับใช้บางอย่างก็คุ้มค่า เช่น:

• การรวมอย่างต่อเนื่อง/การปรับใช้/การส่งมอบอย่างต่อเนื่อง (CI/CD)
• นักเทียบท่า
• การทดสอบอัตโนมัติ (รวมถึงการทดสอบการถดถอยส่วนหน้า)

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

ใช้ผ้าสำลี

สำหรับโปรเจ็กต์ทุกขนาด ผ้าปูที่นอนเป็นประโยชน์สำหรับนักพัฒนาส่วนใหญ่ Linting หมายถึงการตรวจสอบรหัสของคุณโดยอัตโนมัติเพื่อหาข้อผิดพลาด IDE ที่มีคุณลักษณะครบถ้วนเช่น PHPStorm นั้นทำเสร็จแล้ว อย่างไรก็ตาม โปรแกรมแก้ไขที่ง่ายกว่า เช่น VSCode หรือ Sublime Text ต้องการโปรแกรมเฉพาะที่เรียกว่า linter วิธีหนึ่งในการตั้งค่านี้คือการกำหนดค่าตัวแก้ไขของคุณให้เรียกใช้ linter ทุกครั้งที่คุณบันทึกไฟล์

PHP_CodeSniffer เป็นข้อมูลพื้นฐานสำหรับ PHP นอกจากการตรวจสอบข้อผิดพลาดทางไวยากรณ์แล้ว ยังตรวจสอบได้ว่าโค้ดของคุณเป็นไปตามหลักเกณฑ์ด้านรูปแบบ เช่น PSR-2 หรือไม่ สิ่งนี้ทำให้มาตรฐานการเข้ารหัสต่อไปนี้ง่ายขึ้นอย่างมาก

สำหรับ JavaScript ESLint เป็น linter ยอดนิยม มีชุดกฎที่กว้างขวางและรองรับการกำหนดค่าแบบกำหนดเองสำหรับรสชาติและกรอบงานทั้งหมดของ JavaScript

กรณีการใช้งานที่มีประสิทธิภาพในที่นี้คือการรวม linting เข้ากับไปป์ไลน์ CI/CD เพื่อให้โค้ดทั้งหมดได้รับการตรวจสอบโดยอัตโนมัติก่อนที่จะนำไปใช้งาน

เทคนิคการพัฒนา Front-end WordPress ที่ทันสมัย

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

ใช้เครื่องมือที่ทันสมัย: Sass และ ES6+

โลกของการพัฒนาส่วนหน้านั้นเปลี่ยนแปลงตลอดเวลาและเคลื่อนไหวอยู่ตลอดเวลา เมื่อเราคิดว่า Sass เป็นเครื่องมือที่ดีที่สุดสำหรับการเขียน CSS—และสำหรับการพัฒนาก่อน Gutenberg WordPress มันยังคงเป็น—แต่ทุกคนก็เริ่มพูดถึง CSS-in-JS และส่วนประกอบที่มีสไตล์

แม้แต่ WordPress ก็ไม่สามารถต้านทานและหยิบเอาเทคโนโลยีใหม่ๆ เหล่านี้ขึ้นมาบางส่วนได้ Gutenberg ตัวแก้ไขบล็อกใหม่ สร้างขึ้นบน React และ REST API

คุณควรได้รับความเร็วอย่างแน่นอนด้วยเทคโนโลยีส่วนหน้าหลักเหล่านี้:

• ES6+ เอกสารของ WordPress เรียกว่า ESNext และยังสนับสนุนให้ใช้
• แซส ใช้โดย WooCommerce และวิธีที่ดีที่สุดในการเขียน CSS หากคุณยังไม่คุ้นเคยกับ CSS-in-JS
• เว็บแพ็ค แม้แต่แกนหลักของ WordPress ก็ใช้ Webpack และ Babel ในตอนนี้

ES6 และ Sass เป็น JavaScript และ CSS สมัยใหม่ ตามลำดับ และ Webpack เป็นเครื่องมือที่ช่วยให้สามารถใช้คุณลักษณะที่ทันสมัยเหล่านี้ได้โดยไม่ต้องกังวลเกี่ยวกับความเข้ากันได้แบบย้อนหลัง Webpack สามารถเรียกได้ว่าเป็นคอมไพเลอร์แอพส่วนหน้าที่สร้างไฟล์สำหรับการใช้งานในเบราว์เซอร์

การเปลี่ยนจาก jQuery เป็น Vue.js หรือ React

แกนหลักของ WordPress และปลั๊กอิน WordPress เกือบทั้งหมดขึ้นอยู่กับ jQuery ดังนั้นคุณจึงหยุดใช้งานไม่ได้ ที่จริงแล้ว มันไม่สมเหตุสมผลเลยที่จะหยุดใช้มันสำหรับงานง่ายๆ เช่น ซ่อน <div> สองสามตัวหรือทำคำขอ AJAX แบบครั้งเดียวเมื่อคุณคุ้นเคยกับการทำแบบนั้น กำลังโหลด jQuery อยู่และใช้งานง่ายและสะดวก

แอปที่ซับซ้อนเป็นที่ที่ jQuery ต้องดิ้นรน: ตรรกะที่ติดตามยาก, นรกโทรกลับ, ตัวแปรทั่วโลก และไม่มีเทมเพลต HTML สิ่งนี้เรียกร้องให้มีวิธีการจัดระเบียบแอพส่วนหน้าอย่างชัดเจน

ไลบรารีฟรอนต์เอนด์สมัยใหม่ เช่น React ใช้หลักการการเขียนโปรแกรมเชิงวัตถุ (OOP) และจัดระเบียบสถาปัตยกรรมแอปส่วนหน้าให้เป็นส่วนประกอบแบบแยกส่วนและนำกลับมาใช้ใหม่ได้ ส่วนประกอบประกอบด้วยโค้ด มาร์กอัป และ "สถานะส่วนประกอบ" (ตัวแปร) ทั้งหมดสำหรับองค์ประกอบเฉพาะ องค์ประกอบสามารถเป็นได้เกือบทุกอย่าง: ปุ่ม ช่องป้อนข้อมูล แบบฟอร์มผู้ใช้ หรือวิดเจ็ตที่แสดงโพสต์ล่าสุดจากส่วนหลังของ WordPress REST API ส่วนประกอบสามารถมีส่วนประกอบอื่นๆ ได้ ทำให้เกิดความสัมพันธ์แบบลำดับชั้น

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

มีไลบรารี่แบบอิงส่วนประกอบสองแห่งที่กำลังมาแรงในขณะนี้: Vue.js และ React ปฏิกิริยาจะเป็นตัวเลือกที่ชัดเจนเพราะ Gutenberg ใช้อยู่แล้ว อย่างไรก็ตาม สำหรับผู้ที่เพิ่งเริ่มใช้ JavaScript สมัยใหม่ Vue.js อาจเริ่มต้นได้ดีกว่า

React นำคุณเข้าสู่ส่วนลึกโดยใช้ฟีเจอร์ ES6, คลาส, ไวยากรณ์ JSX ที่เป็นกรรมสิทธิ์ และไปป์ไลน์การสร้าง Webpack ทันที เส้นโค้งการเรียนรู้ค่อนข้างสูงชัน

ในทางกลับกัน Vue.js นั้นเป็นมิตรกับผู้เริ่มใช้งานมากกว่ามาก และสามารถใช้ได้โดยเพียงแค่วางแท็ก <script> Vue.js ใช้ JavaScript ธรรมดา (ES5), HTML และ CSS การแนะนำแนวคิดใหม่จะค่อยเป็นค่อยไปมากขึ้น

หลังจากทำงานผ่านโปรเจ็กต์ Vue.js สองสามโปรเจ็กต์แล้ว คุณก็พร้อมแล้วที่จะเจาะลึกลงไปใน React ไม่ใช่ว่ามันจำเป็นเสมอไป แต่การพัฒนาของ Gutenberg นั้นต้องการมัน

ใช้ WordPress REST API

REST API ของ WordPress เป็นเพียงอินเทอร์เฟซมาตรฐานสำหรับการขอและแก้ไขข้อมูลจาก WordPress จากระยะไกล เป็นสถาปัตยกรรมซอฟต์แวร์มากกว่าวิธีการเข้ารหัสที่ต่างไปจากเดิมอย่างสิ้นเชิง สามารถใช้ตัวอย่าง jQuery AJAX แบบเก่ากับพารามิเตอร์ที่แตกต่างกันเล็กน้อย

ประโยชน์ที่สำคัญที่สุด? เนื่องจาก WordPress REST API กำหนดมาตรฐานการสื่อสารระหว่างส่วนหลังและส่วนหน้า จึงเป็นขั้นตอนสำคัญที่นำไปสู่ความเป็นโมดูล ความสามารถในการใช้ซ้ำ และความสามารถในการอ่านโค้ดของคุณ เทมเพลตที่น่ากลัวเหล่านั้นที่มี HTML และ PHP ผสมกันและ SQL บางตัวที่รวมอยู่ในส่วนผสมนั้นต้องไป เมื่อเทมเพลตเป็นเพียง HTML ที่มีตัวยึดตำแหน่งสำหรับข้อมูลที่ส่งผ่านเป็นพารามิเตอร์ ไม่มีความแตกต่างที่สำคัญระหว่างการส่งข้อมูลนั้นใน PHP หรือผ่าน REST API ไปยังแอปส่วนหน้า

คุณอาจต้องการดู WPraphQL มันอาจจะใช่หรือไม่ใช่ในที่สุดแทนที่ WordPress REST API แต่ได้รับแรงฉุดอย่างรวดเร็ว

เรียนรู้ Gutenberg (ลูกค้าจะต้องการในไม่ช้า)

เป้าหมายสูงสุดของ Gutenberg คือการปรับแต่งเว็บไซต์แบบเต็ม ท่ามกลางแผนอื่นๆ

ซึ่งเป็นการวางรากฐานสำหรับรูปแบบใหม่สำหรับ WordPress Core ซึ่งจะส่งผลต่อประสบการณ์การเผยแพร่ทั้งหมดของแพลตฟอร์มในที่สุด

หน้าโครงการ WordPress Gutenberg บน GitHub

Gutenberg ได้รับการตอบกลับครั้งใหญ่จากนักพัฒนา WordPress ข้อโต้แย้งบางประการที่ต่อต้านการรวมเข้ากับแกนหลักของ WordPress คือ:

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

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

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

ถึงเวลาต้องเร่งความเร็ว: แม้แต่ “วิธีเวิร์ดเพรส” ก็พัฒนาขึ้น

ข้อโต้แย้งที่พบบ่อยที่สุดในการใช้เครื่องมือและเทคนิคทั้งหมดที่อธิบายไว้ข้างต้นในการพัฒนา WordPress คือ: “วิธี WordPress” ในการทำสิ่งต่าง ๆ ยังคงใช้งานได้ และวิธีนี้น่าจะดีกว่าสิ่งใหม่ ๆ เหล่านี้ทั้งหมด

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

บางครั้ง WordPress และ WooCommerce ได้ปฏิบัติตามแนวทางการพัฒนา "ปลั๊กอินคุณลักษณะ" ที่ใช้และใช้เทคโนโลยีใหม่ เมื่อถึงเวลา ปลั๊กอินเหล่านี้จะรวมเข้ากับแกนหลัก เช่นเดียวกับ Gutenberg WooCommerce ยังมีโครงการ React ของตัวเองอีกด้วย WordPress REST API ยังเริ่มต้นเป็นปลั๊กอินแยกต่างหากและตอนนี้เป็นส่วนหนึ่งของแกนหลักของ WordPress

คำถามไม่ใช่ ว่า เราควรเรียนรู้สิ่งใหม่ ๆ และใช้มันในการทำงานประจำวันของฉันหรือไม่ แต่ อย่างไร . คำตอบคือ "ค่อยๆ" ทีละขั้น ไม่ว่าจะเรียนรู้สิ่งใหม่หรือทำสิ่งที่คุณรู้ดีในรูปแบบใหม่และแตกต่างออกไป

ตัวอย่างเช่น เรียนรู้วิธีใช้ Webpack กับสคริปต์เก่าทั้งหมดของคุณ Webpack สามารถแปลงรหัส ES6+ ใหม่ของคุณเป็น JavaScript "ธรรมดา" ที่เข้ากันได้กับเบราว์เซอร์รุ่นเก่า นอกจากนี้ยังสามารถย่อขนาดสคริปต์และรวมเข้าด้วยกัน นั่นเป็นสิ่งใหม่อย่างหนึ่ง เสร็จแล้ว? จากนั้นเขียน JavaScript ของคุณใหม่โดยใช้ประโยชน์จากคุณสมบัติ ES6 เป็นวิธีการใหม่ในการทำสิ่งที่คุณรู้ดี

ผลลัพธ์: คุณจะได้เรียนรู้ Webpack และ ES6 ในฐานะมืออาชีพ เราควรก้าวขึ้นและไม่ถอยกลับ ให้เรียนรู้อยู่เสมอ และแบ่งปันเมื่อคุณทำ: Toptal รักษารายการแนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนา WordPress และยินดีรับการสนับสนุนจากชุมชน

ในส่วนที่ 2 ของซีรีส์ เราจะเจาะลึกในส่วนของ PHP ของการพัฒนาแบ็คเอนด์ WordPress ที่ทันสมัย