การบรรยายทางเทคนิค WP21
(ma.tt)- WordPress ครบรอบ 21 ปี นับตั้งแต่ Matt Mullenweg และ Mike Little ฟอร์ก b2/cafélog แล้วออกรุ่นแรก และในการพัฒนาต่อจากนี้ก็ควรกลับไปยึดเงื่อนไขที่ทำให้ประสบความสำเร็จในช่วงแรกอีกครั้ง
- ทิศทางของผลิตภัณฑ์ยึดตามหลักการว่า เรื่องที่ง่ายควรใช้งานได้อย่างเป็นธรรมชาติ, และเรื่องที่ซับซ้อนก็ควรทำได้เช่นกัน
- ความสามารถของเว็บแบบไดนามิก อย่างบล็อก คอมเมนต์ และ pingback ทำให้เว็บไซต์สนุกยิ่งขึ้น และให้คุณค่ากับเว็บไซต์แบบไดนามิกมากกว่าเว็บไซต์แบบสแตติก
- ระบบนิเวศของปลั๊กอินและธีมควรมี โครงสร้างพื้นฐานสำหรับการพัฒนา ในระดับเดียวกับ WordPress core และในปี 2024 ก็ไม่เหมาะที่จะยังพึ่งพาวิธี อัปโหลด ZIP
- วงจรฟีดแบ็ก ที่ใกล้ชิดกับผู้ใช้, ฟอรัมที่ยึดชุมชนเป็นศูนย์กลาง, การพรีวิวธีมที่ดี, และ Playground จะเป็นตัวกำหนดประสบการณ์ WordPress ในอนาคต
ครบรอบ 21 ปีของ WordPress และหลักการของผลิตภัณฑ์
- WordPress ครบรอบ 21 ปีนับตั้งแต่ Matt Mullenweg และ Mike Little ฟอร์กงาน b2/cafélog ของ Michel แล้วออกรุ่นแรก
- ในการพัฒนาต่อจากนี้ก็ควรคำนึงถึงองค์ประกอบที่มีส่วนทำให้ WordPress ประสบความสำเร็จในช่วงแรกต่อไป
- หลักการสำคัญของผลิตภัณฑ์คือ สิ่งที่เรียบง่ายต้องง่ายและเป็นธรรมชาติ และสิ่งที่ซับซ้อนก็ต้องทำได้เช่นกัน
บล็อก เอกสาร และฟีเจอร์ชุมชน
- บล็อก คอมเมนต์ และ pingback ควรใช้งานได้อย่างสนุก
- เว็บไซต์แบบสแตติกก็ไม่เป็นไร แต่มีจุดยืนว่าเว็บไซต์แบบไดนามิกดีกว่า
- แทบทุกเว็บไซต์สามารถดีขึ้นได้หากมีบล็อกที่ยอดเยี่ยม
- เอกสารควร แก้ไขได้ง่ายเหมือนวิกิ
- วิกิถูกมองว่าเป็นเครื่องมือที่ “น่าทึ่ง”
- ในชุมชน ฟอรัมควรเป็นศูนย์กลาง
- bbPress และ BuddyPress ต้องการความสนใจมากกว่านี้
ระบบนิเวศของปลั๊กอินและธีม
- ปลั๊กอินและธีมทั้งหมดควรมี โครงสร้างพื้นฐานสำหรับการพัฒนา ระดับเดียวกับที่ใช้สร้าง WordPress เอง
- การจัดการเวอร์ชัน
- ตัวติดตามบั๊ก
- ฟอรัม
- เอกสาร
- การทำให้รองรับหลายภาษา
- ห้องแชต
- P2
- เส้นทางที่ง่ายต่อการมีส่วนร่วมและเข้าสู่ชุมชน
- ในปี 2024 การจัดการปลั๊กอินและธีมด้วยวิธี อัปโหลด ZIP ไม่เหมาะสม
- การพรีวิวธีมควรยอดเยี่ยม
- คอลเลกชันของ ธีมที่ไม่ใช่เชิงพาณิชย์ ซึ่งมีสุนทรียะและฟังก์ชันที่หลากหลายเป็นสิ่งสำคัญ
วงจรฟีดแบ็กและความโปร่งใสสำคัญกว่ากฎ
- ไม่ควรเอนเอียงไปที่แนวทางและข้อกำหนดมากเกินไป
- การออกแบบกลไกของมาร์เก็ตเพลสที่ดี, วงจรฟีดแบ็ก แบบอัตโนมัติ, และความโปร่งใสต่อผู้ใช้นั้นดีกว่า
- ควรผลักขอบเขตระหว่างฟังก์ชันกับการออกแบบให้ไกลขึ้น
- ต้องมี การไม่ยอมรับโดยเด็ดขาด ต่อสแปมและพฤติกรรมแบบสแปม
- วงจรฟีดแบ็กควรขยายตามการใช้งานและชุมชนโดยรวม แทนที่จะพึ่งพา gatekeeper
ลักษณะของ core และจุดสัมผัสกับผู้ใช้
- WordPress core ควร มีความเห็นของตัวเองและมีเอกลักษณ์
- Easter egg
- ภาษาที่มีเอกลักษณ์แม้จะแปลยาก
- คาแรกเตอร์แบบแจ๊ส
- ทุกคนที่พัฒนาซอฟต์แวร์และตัดสินใจควรต้องใช้ซอฟต์แวร์นั้นด้วย
- นักพัฒนาและผู้ตัดสินใจควรอยู่ใกล้ชิดกับผู้ใช้ปลายทางทั่วไปผ่านกิจกรรมที่ทำได้ เช่น งานซัพพอร์ต มีตอัป และอีเวนต์
Playground และประสบการณ์เริ่มต้น
- Playground ถูกคาดหวังว่าจะเปลี่ยนทุกอย่าง
- วันที่ 27 พฤษภาคม 2003 ซึ่งเป็นวันที่ WordPress รุ่นแรกออก Matt Mullenweg ได้เขียนบล็อก 953 คำจากหน้าประตูบ้านพ่อแม่ โดยทิ้งประโยคไว้ว่า “ผมปล่อย WordPress แล้ว และรู้สึกดี”
- คืนนั้นเขาตั้งค่า WP ให้เพื่อนชื่อ Ramie Speight และให้การสนับสนุนทางโทรศัพท์แก่ Mike Tremoulet ที่พบกันในงานรวมตัวบล็อกเกอร์ท้องถิ่น
- เพื่อนสมัยมัธยมของเขาต่างก็ใช้ WordPress บนโดเมนของตัวเอง และ วงจรฟีดแบ็ก นั้นมีบทบาทอย่างมากในการหล่อหลอมซอฟต์แวร์
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
น่าเสียดายที่ WordPress ดูเหมือนไม่ใช่แค่ไม่รักษา มาตรฐานการพัฒนา แต่ยังพยายามทำลายมันอย่างแข็งขัน
ใช้ตัวแปรโกลบอลไปทั่วทุกที่และส่งเสริมสปาเกตตีโค้ดผ่านธีมแบบคลาสสิก แล้วในธีมแบบใหม่ก็ให้เอา JSON ไปใส่ในคอมเมนต์ HTML ทำให้ไม่มีการรองรับจากเอดิเตอร์ เกิดข้อผิดพลาดได้ง่าย และกลายเป็นการออกแบบที่ประหลาด
อดสงสัยไม่ได้ว่าวิศวกรระดับซีเนียร์ตัดสินใจกันจริงจังให้ใส่เทมเพลต JSON ในคอมเมนต์ HTML จริงหรือ และถ้ามองแบบทฤษฎีสมคบคิดก็ดูเหมือนพยายามฆ่าตลาดฟรีแลนซ์หรือดิจิทัลเอเจนซี แล้วดันคนไปใช้ตัวสร้างเว็บไซต์แบบ WYSIWYG ของ WP.com
มันเป็นลักษณะ PHP ข้างใน HTML ข้างใน JS ข้างใน CSS และพึ่งพาโครงสร้างโดยนัยว่าต้องอ่านไฟล์ไหนตามลำดับใดเพื่อประกอบหน้าเว็บทั้งหน้า
ตอนแรกอาจดูสะดวก แต่กลับทำให้ปิดแท็ก HTML ไม่ครบในไฟล์เดียวและไปจบในอีกไฟล์หนึ่ง จนใช้ซ้ำไม่ได้
มันดูเหมือนความผิดพลาดของมือใหม่ แต่มีธีมนับพันพึ่งพาวิธีนี้อยู่ เลยกลายเป็นแก้ยากไปแล้ว และยิ่งเห็นชัดเมื่อเทียบกับวิธีเรนเดอร์บล็อกและแมโครในเทมเพลต Jinja2
WordPress มีไว้สำหรับ ลูกค้าที่ไม่มีงบ และลูกค้าราคาถูกที่คิดว่าตัวเองแค่ต้องการเว็บไซต์ธรรมดาๆ และผมว่าความคิดเรื่องเว็บธรรมดาๆ แบบนั้นก็ตายไปนานแล้ว
https://timber.github.io/docs/v2/
พอย้ายไปเซิร์ฟเวอร์ใหม่ที่พาธติดตั้งต่างออกไปแค่นิดเดียวก็พังทันที
น่าเสียดายที่แบบนั้นอาจส่งผลเสียต่อสโลแกนการตลาดที่ว่า “แพลตฟอร์มของเราขับเคลื่อนเว็บไซต์ทั้งเว็บ 43.4% ”
น่าเสียดายที่การตัดสินแบบฉับไวและความเห็นที่แข็งกร้าวกลายเป็นส่วนหนึ่งของชุมชนไปแล้ว
ในช่วง 2-3 เดือนที่ผ่านมา ผมได้พัฒนา WordPress เยอะมาก และอยากบอกว่าการแยกโค้ดที่บล็อก (Gutenberg) มอบให้นั้นยอดเยี่ยม
ถ้าใช้เป็นปลั๊กอินแยกอิสระหรือใช้ร่วมกับ Advanced Custom Fields ก็สามารถสร้างเว็บไซต์แบบโมดูลาร์เต็มรูปแบบพร้อมกระบวนการพัฒนาและระบบดีไซน์ที่ควบคุม HTML เองได้ 100%
ผมแนะนำให้ทุกคนทำความเข้าใจและเรียนรู้ WordPress อย่างจริงจัง ผมไม่ได้มีความเกี่ยวข้องใดๆ กับ WordPress
อยู่ๆ วันนี้ Gutenberg กับ ACF Blocks ก็ไปชนกันที่ไหนสักแห่งเรื่องการพาร์สคอนเทนต์ของฟิลด์มีเดียแบบซ้อนกัน
สาเหตุอาจเป็นเพราะ “ผู้ใช้ใส่คำอธิบายภาพที่ไม่ควรใส่” หรืออาจเป็นเพราะ “ออบเจ็กต์โกลบอลของปลั๊กอินไปทำให้อีกออบเจ็กต์โกลบอลที่ส่งเข้า
acf_register_block_type()ปนเปื้อน”ผมอาจต้องโทรหาลูกค้าที่กำลังโมโหอยู่แล้ว แล้วบอกให้เขาอย่าเพิ่งตัดสินเร็วและมีความเห็นรุนแรงก็ได้
ตอนนี้อาจไม่เป็นแบบนั้นแล้ว แต่ความระแวงก็ถือว่าเข้าใจได้ ผมเห็น CVE เยอะพอสมควรในอัปเดตที่ตรวจทุกสัปดาห์ แม้ทั้งหมดอาจเป็นความเสี่ยงต่ำหรือเกี่ยวกับปลั๊กอินที่แทบไม่มีคนใช้ก็ตาม
index.phpของ WordPress แบบใสซื่อเพื่อพยายามทำความเข้าใจว่ามันทำงานอย่างไรจำได้ว่าผมไม่เข้าใจอะไรเลยนอกจากคอมเมนต์ด้านบนไฟล์ที่เขียนว่า “code is poetry”
แต่นั่นก็ทำให้วิธีคิดเรื่องโค้ดของผมเปลี่ยนไป และยิ่งทำให้ผมหลงใหลการเขียนโปรแกรมมากขึ้น
ถ้าต้องการเมตาดาต้าสำหรับโพสต์ก็ต้องติดตั้ง ACF และถ้าจะกรองด้วยเมตาดาต้านั้น พอมีฟิลเตอร์พร้อมกันไม่กี่ตัว SQL query ก็ timeout แล้ว แค่ดูสคีมาประหลาดของ WP ก็รู้เหตุผลได้
Gutenberg สัญญาว่าจะเป็น React component ที่แก้ไขได้แบบ WYSIWYG แต่กลับตัดสินใจประหลาดด้วยการเก็บแอตทริบิวต์ไว้ใน HTML เอา HTML ที่เรนเดอร์แล้วใส่ลงฐานข้อมูล และบังคับให้นักพัฒนาคอมโพเนนต์ต้องคอยรักษาอาร์เรย์ของการเปลี่ยนแปลง deprecated ทุกครั้งที่มีการแก้อะไรบางอย่าง
มีความพยายามจะรีแฟกเตอร์ WordPress แล้วต่อเข้ากับ Laravel เพื่อแก้ปัญหาเหล่านี้[1] แต่ทุกเลเยอร์ก็ดูเป็นฝันร้าย และแม้แต่คนเขียนแต่ละส่วนเองก็น่าจะตัดสินได้ยากว่าทำไมมันถึงพังแบบสุ่มๆ
ระบบนิเวศของปลั๊กอินอาจดูน่าสนใจ แต่การทำปลั๊กอินก็ไม่เป็นมาตรฐาน ทำให้มีโอกาสสูงที่จะยัดก้อน CSS และ JS ที่เทอะทะให้ผู้ใช้
ผมย้ายไปใช้ Directus กับ Astro แล้ว และถ้าต้องเป็นการดีพลอย PHP แบบทั่วไป ผมก็คงใช้ CMS บน Laravel อย่าง October หรือ Statamic
[1]: https://roots.io/
ช่วงปี 2009-2011 ผมเคยใช้งานมันเยอะพอสมควร รวมถึงเขียนและแก้ปลั๊กอินด้วย แต่ก็ไม่เคยรู้สึกว่าเข้าใจมันอย่างแท้จริง มีแค่ความเข้าใจคร่าวๆ หรือไม่ก็ยอมรับมันไปแบบนั้น
ชอบ WordPress เพราะคนชอบติดตั้งเอง ลงปลั๊กอินไร้ประโยชน์ ไม่ปลอดภัย และบั๊กเยอะเป็นสิบตัว แล้วพอเวลาผ่านไปเว็บพังก็สามารถคิดค่าบริการสำหรับโซลูชันที่ปลอดภัยและแข็งแรงกว่าทีหลังได้
ให้ความรู้สึกเหมือนโปรเจกต์ทำเล่นช่วงสุดสัปดาห์ที่ไม่เคยจบแต่ถูกปล่อยสู่สาธารณะหลังยืดเยื้อนานเกินไป และมีลูป
forยาว 5 หน้าจอที่วนอยู่บนตัวแปร global ขนาดมหึมาซ้ำไปซ้ำมาเพื่อทำอะไรบางอย่างWordPress เป็นตัวอย่างโปรดของคำว่า “ไม่จำเป็นต้องสมบูรณ์แบบ แค่ ใช้งานได้ก็พอ”
โปรเจกต์เจ๋ง ๆ จำนวนมากตายไปเพราะทำขั้นตอนแรกให้ซับซ้อนเกินไป ถ้ามีคนเริ่มใช้แล้ว จะปรับปรุงทีหลังก็ได้เสมอ แต่ต้องปล่อยออกมาก่อน
หนักถึงขั้นที่นักพัฒนาภาษา PHP เองก็ไม่สามารถทำฟีเจอร์หรือการแก้ไขบางอย่างได้ เพราะทีม WordPress ไม่อยากย้ายโค้ด และ WordPress ก็กินสัดส่วนการใช้งาน PHP ก้อนใหญ่มาก
WP เป็นเครื่องมือที่สมบูรณ์แบบสำหรับงาน 95% แต่การจูน 5% สุดท้ายนั้นน่าหงุดหงิดอย่างมาก
ผมใช้มันมามาก และคิดว่าการที่มันอยู่รอดมาได้นานขนาดนี้คือหลักฐานของความมีประโยชน์ หวังว่ามันจะอยู่ต่อไปอีก 21 ปี
เอาจริง ๆ ผมไม่เคยรู้สึกว่า WordPress ใช้งานง่ายเลย ทุกอย่างดูสวยงามอยู่ได้แค่ตราบใดที่ยังหา theme กับ plugin ดี ๆ ได้ แต่พอเริ่มต้องการ การปรับแต่งเฉพาะทาง เล็กน้อย ทุกอย่างก็เริ่มพันกันไปหมด
แต่พอเปิดดูตัวเว็บ โค้ดของปลั๊กอิน/ธีม และไฟล์ CSS จริง ๆ ก็ต้องนั่งงัดอยู่หลายชั่วโมงเพื่อให้ได้ผลลัพธ์ที่ต้องการ และถึงจะทำสำเร็จ ก็มักทำส่วนอื่นของเว็บพังไปด้วย
ไม่นับเรื่องเล่าเชิงดูถูกพวกนี้ Matt ทำได้ดี และเรื่องสุดท้ายก็ดีด้วย
การอัปเดตต้องมีการแทรกแซงด้วยมือ ธีมต้องแก้ ปลั๊กอินถูกทิ้งร้าง ผมไม่อยากแบกรับภาระแบบนี้อีกแล้ว เลยย้ายทุกเว็บไปใช้ Hugo/Jekyll/MkDocs เป็นต้น ตั้งแต่ราวปี 2017
ถ้าเป็นบล็อก ผมอยากใช้ Ghost มากกว่า WP และผมก็ชอบ JS มากกว่า PHP ด้วย
น่าสนใจที่หลายคนพูดว่า “ฉันเป็น WordPress developer” แต่ในความเป็นจริงกลับหมายถึงชุดประสบการณ์และทักษะที่ต่างกันโดยสิ้นเชิง
สำหรับบางคน มันหมายถึงการติดตั้งธีมและปลั๊กอินจากหน้าผู้ดูแล WordPress และเขียนเนื้อหาลงหน้าเว็บ
สำหรับอีกบางคน มันหมายถึงโค้ด PHP แบบเก่าที่เขียน HTML ด้วย PHP templates และปรับแต่งการทำงานของ WordPress หรือก็คือ classic theme
สำหรับอีกกลุ่ม มันหมายถึงการเขียน JS+React พร้อม Docker และ CI/CD สำหรับ block theme แบบใหม่
อยากให้มีบริษัทมากกว่านี้นำ นโยบายลาพักยาว ของ Automattic ไปใช้
https://automattic.com/benefits/sabbatical/
สิ่งที่ทำให้รู้สึกว่าแก่ขึ้นคือเวลาเห็น “WP” แล้วนึกถึง WordPerfect(https://en.wikipedia.org/wiki/WordPerfect) แทนที่จะเป็น WordPress
ตอนนี้ WordPress ก็มีอายุถึงระดับที่แม้แต่ประเทศที่เคร่งที่สุดก็นับว่าเป็นผู้ใหญ่แล้ว ส่วน WordPerfect ก็เข้าสู่วัยวิกฤตกลางคนเรียบร้อย
สิ่งที่น่าประทับใจใน WordPress คือพวกเว็บเนิร์ดมักคาดหวังว่ามันต้องง่ายโดยอัตโนมัติ แล้วถ้าไม่เป็นอย่างนั้นก็จะหงุดหงิด
เหมือนทุกอย่าง WordPress ก็ต้องเรียนรู้ และมันมีมุมมองของตัวเอง
มันมีประวัติศาสตร์ประหลาด ๆ ด้วย โดยเฉพาะวิธีจัดการรายการสื่อที่ผมไม่ชอบเอามาก ๆ แต่ถึงอย่างนั้นมันก็มีวิธีวิทยาของมัน
ถ้าผมบอกว่าตัวเองรู้ Go, JS, Perl, Java, Ruby, C แล้วโวยว่า Rust เรียนยาก แน่นอนว่าคนต้องโต้แย้งผม
WordPress ดูเหมือนจะทำเรื่องง่าย ๆ แต่จริง ๆ แล้วมันเป็น แพลตฟอร์ม ที่ค่อนข้างกว้าง คุณอาจต้องอ่านเอกสารสักหน่อย
ถ้าคุณได้รับช่วงต่อเว็บไซต์ที่ใช้ Elementor การถามคนที่สร้างมันว่าจะแก้อะไรง่าย ๆ ยังไงก็น่าจะช่วยได้
แต่ถ้าคุณได้รับช่วงต่อเว็บที่ใช้ Visual Composer หรือ Divi คุณอาจถึงขั้นอยากยิงคนที่สร้างมันขึ้นมา
ถ้าคุณคิดว่า Gutenberg แย่ ตอนนี้มันไม่แย่แบบนั้นแล้ว พอนึกถึงยุค Divi แล้ว ตอนนั้นหนักกว่ามากจริง ๆ
ถ้ามี timeout เกิดขึ้นแม้แต่นิดเดียวระหว่างรัน JavaScript UI สุดสยองที่ครอบอยู่บน WordPress แค่การบันทึกโพสต์บล็อกก็อาจทำให้ทั้งเว็บไซต์เสียหายจนกู้คืนไม่ได้
การแปลเป็นอิตาลีและฝรั่งเศสก็ห่วยระดับเกมญี่ปุ่นยุค 90 และตัวเลือก responsive ก็แทบไม่ทำงานเลย เว้นแต่คุณจะนับว่าการซ่อนหรือแสดงเนื้อหาที่ breakpoint บางจุดคือ responsive
ทุกอย่างเปราะบางอย่างรุนแรง เพราะ “ธีม” ฝั่งฟรอนต์เอนด์นั้นแทบเป็นแค่กอง JavaScript ยุค jQuery ที่อ่านไม่รู้เรื่อง
ผมมั่นใจ 100% ว่าถ้า Elegant Themes ไม่ทุ่มเงินมหาศาลกับโฆษณา ก็คงไม่มีใครใช้มัน