ถามบาร์เทนเดอร์: จะเกิดอะไรขึ้นเมื่อบล็อกมาร์กอัปเปลี่ยนแปลง

ฉันเป็นนักพัฒนาที่เพิ่งเริ่มพัฒนากับ Gutenberg เมื่อเร็วๆ นี้ มีประโยชน์และฟีเจอร์ที่น่าทึ่งมากมาย แต่ก็มีข้อเสียมากมาย ความไม่สอดคล้องกัน รวมถึงเอกสารที่แย่มากและล้าสมัย

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

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

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

ไม่ควรมีวิธีใดที่นักพัฒนาบล็อกจะเลือกไม่เข้าร่วมกระบวนการตรวจสอบความถูกต้องหรือวิธีการกู้คืนบล็อกทั่วโลก

PJ

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

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

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

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

ในฐานะนักพัฒนา ฉันพยายามคิดเสมอถึงผลลัพธ์ที่เกิดขึ้นจริงจากการเปลี่ยนแปลงเหล่านี้จากมุมมองของผู้ใช้ ที่ควรเกิดขึ้นตั้งแต่วันที่ #1 ไม่ใช่หลังจากที่คุณได้เผยแพร่โครงการของคุณ

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

"สำหรับเวอร์ชัน/การอัปเดตบล็อก แน่นอนว่าเป็นหนึ่งในส่วนต่างๆ ของ Gutenberg API ที่เราจำเป็นต้องทำการแลกเปลี่ยนทางสถาปัตยกรรม และเราตัดสินใจที่จะให้ความสำคัญกับประสบการณ์ของผู้ใช้มากกว่านักพัฒนา" Benguella กล่าว

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

“เพื่อให้เข้าใจปัญหาอย่างถูกต้อง เราต้องเข้าใจว่าบล็อกทำงานอย่างไรและแก้ไข” เบงเกลลากล่าว “บล็อกอินสแตนซ์เป็นวัตถุ JSON และ UI ของตัวแก้ไขจัดการ JSON นั้น แต่เพื่อให้เข้ากันได้แบบย้อนหลัง เพื่อให้แน่ใจว่าจะรักษาเนื้อหาของผู้ใช้ในรูปแบบที่อ่านง่ายที่สุด และเพื่อให้สอดคล้องกับมาตรฐานเว็บมากที่สุด ตัวแก้ไขบล็อก ไม่เก็บวัตถุ JSON แต่เป็นการทำให้เป็นอันดับ HTML ของวัตถุใน post_content ”

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

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

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

การทำให้เป็นโมฆะประเภทเดียวกันนี้สามารถเกิดขึ้นได้เมื่อนักพัฒนาปลั๊กอินอัปเดตบล็อกของตน อย่างไรก็ตาม แทนที่จะเปลี่ยน HTML ที่บันทึกไว้ นักพัฒนาได้เปลี่ยน "ความคาดหวัง" ของบล็อก โดยเปลี่ยนวิธีการบันทึกและแยกวิเคราะห์

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

WordPress มีเอกสารการเลิกบล็อก อย่างไรก็ตามมันไม่ทั่วถึง แหล่งที่มาที่ดีที่สุดในการดูการเลิกใช้งานในโลกแห่งความเป็นจริงคือการดูไลบรารีบล็อกของ Gutenberg บล็อกที่เลิกใช้แล้วมีไฟล์ deprecated.js

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

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

ทีมงานได้ปรับปรุงระบบการตรวจสอบเมื่อเวลาผ่านไป ทำให้มีการเปลี่ยนแปลงเล็กน้อยที่ไม่ทำลายสถานะการบล็อก นอกจากนี้ยังมีตั๋วเปิดสำหรับการปรับปรุงในอนาคต