เปิดแบบสำรวจสำหรับผู้แต่งธีม WordPress บนไฟล์ JSON และบล็อกธีม

WordPress 5.8 เปิดตัวระบบการเลือกใช้ธีมเพื่อกำหนดการตั้งค่าบล็อก สไตล์ เทมเพลต และอื่นๆ มันทำผ่านไฟล์ theme.json ใหม่ที่ผู้เขียนสามารถวางไว้ที่รูทของโฟลเดอร์ธีมของพวกเขา Anne McCarthy หัวหน้าโครงการ FSE Outreach ได้ประกาศการสำรวจก่อนหน้านี้ในวันนี้เพื่อรับข้อเสนอแนะจากนักพัฒนาเกี่ยวกับคุณลักษณะนี้

“เนื่องจากกลไกใหม่นี้เป็นก้าวแรกสู่ระบบสไตล์ที่ครอบคลุมสำหรับอนาคตของ WordPress สิ่งสำคัญคือต้องรับฟังจากทุกคนที่กำลังใช้ theme.json เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับวิธีที่ผู้คนใช้เครื่องมือนี้และสิ่งที่อาจสมเหตุสมผลที่จะรวมไว้ ใน Core ในอนาคต” เธอเขียนไว้ในประกาศ

แบบสำรวจนี้เปิดให้ผู้เขียนธีมทุกคนที่เคยใช้ theme.json มาก่อน ทำให้พวกเขามีโอกาสแสดงความคิดเห็นก่อนใครและช่วยบังคับเรือให้ก้าวไปข้างหน้า

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

ต่อไปนี้คือคำตอบของฉันต่อคำถามของแบบสำรวจ นั่นคือเวอร์ชันที่จัดระเบียบแล้ว

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

ประสบการณ์

คำถามแรกของแบบสำรวจค่อนข้างสั้นและแห้ง โดยจะถามว่าประสบการณ์ของคุณเป็นอย่างไรกับธีมแบบเอกสารสำเร็จรูป หรือใช้ theme.json มีสี่ตัวเลือก (และตัวเลือก "อื่นๆ"):

• ฉันได้สร้างและเปิดตัวธีมบล็อกแล้ว
• ฉันได้ทดลองกับรูปแบบการสร้างบล็อค
• ฉันได้สำรวจโดยใช้ theme.json กับธีมแบบคลาสสิก
• ฉันใช้ธีมบล็อกแล้ว แต่ฉันยังไม่ได้สร้างธีม

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

มันเริ่มต้นอย่างไรและมันจะเป็นอย่างไร

คำถามที่สองถามว่าเราเริ่มต้นบล็อกธีมและ theme.json ได้อย่างไร ตัวเลือกต่างๆ อยู่ระหว่างการฟอร์กธีมที่มีอยู่ โดยใช้ธีมว่างเปล่า หรือเริ่มจากศูนย์

อีกครั้ง นี่เป็นหนึ่งในสิ่งที่ฉันได้ทดลองกับแต่ละทิศทาง แต่ฉันจำจุดเริ่มต้นที่แน่นอนไม่ได้ งานส่วนใหญ่ของฉันมาจากการสร้างธีมที่ฉันใช้ครั้งล่าสุดในปี 2019

ฉันวางแผนที่จะปล่อยสิ่งนี้เป็นธีมใหม่ฟรีในบางจุด ฉันส่วนใหญ่รอสิ่งต่อไปนี้:

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

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

เทมเพลตและชิ้นส่วนเทมเพลต

แบบสำรวจถามถึงเทมเพลตและส่วนต่างๆ ของเทมเพลตที่รวมไว้ในธีมแบบบล็อกเสมอ มีช่องแสดงความคิดเห็นอิสระ — ขั้นตอนบน soapbox...

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

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

ระบบเทมเพลตบล็อกไม่ทำงานเช่นนั้น โดยพื้นฐานแล้วจะบังคับให้นักพัฒนาฝ่าฝืนหลักการ Don't Repeat Yourself (DRY)

ตัวอย่างเช่น หากนักออกแบบต้องการแสดงส่วนเทมเพลตส่วนหัวอื่นสำหรับหน้าและโพสต์ พวกเขาจะต้องสร้างเทมเพลต header-page.php หรือ header-post.php ในรูปแบบดั้งเดิมเท่านั้น อย่างไรก็ตาม เนื่องจากระบบเทมเพลตบล็อกแตกต่างกัน พวกเขาจึงต้องสร้างเทมเพลตระดับบนสุดสองเทมเพลต single.html (โพสต์) และ page.html เพื่อทำสิ่งเดียวกันให้สำเร็จ

นี่เป็น "สิ่งที่ไม่ดี" เนื่องจากผู้สร้างธีมต้องทำซ้ำโค้ดอื่นๆ ทั้งหมดในแต่ละเทมเพลตระดับบนสุด ไม่มีวิธีโหลดส่วนเทมเพลตต่างๆ ตามบริบท

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

ฉันยังตอบคำถามส่วนที่สองและระบุส่วนเทมเพลตที่ใช้บ่อยที่สุดของฉัน (แยกตามลำดับชั้น):

• หัวข้อ
• เนื้อหา
  – ลูป
  – แถบด้านข้าง
• ส่วนท้าย

ส่วนเทมเพลต content-*.html และ loop-*.html เป็นส่วนที่มีรูปแบบต่างๆ มากที่สุด

การกำหนดสี

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

Morten Rand-Hendriksen เปิดตั๋วในปี 2018 เพื่อกำหนดมาตรฐานรูปแบบการตั้งชื่อสีของธีม มันไม่ใช่การสนทนาครั้งแรกและไม่ใช่ครั้งสุดท้าย ปัญหาที่ควรแก้ไขคือทากสำหรับสีในระบบ ซึ่งเป็นวิธีที่ธีมกำหนดจานสี เมื่อผู้ใช้ใช้สีที่ตั้งไว้ล่วงหน้า ทากจะถูกฮาร์ดโค้ดลงในเนื้อหาของตน เปลี่ยนไปใช้ธีมอื่นที่มีทากต่างกัน และสีเก่าจะหายไปและไม่เปลี่ยนเป็นสีของธีมใหม่โดยอัตโนมัติ

ฉันใช้ชื่อเชิงความหมายที่ตามหลังสิ่งที่คล้ายกับระบบการแรเงาของเฟรมเวิร์ก CSS ของ Tailwind แทนที่จะใช้ red-medium (อธิบาย) ฉันจะใช้ primary-500 (ความหมาย) เป็นต้น แนวทางเชิงความหมายจะช่วยให้ผู้สร้างธีมสามารถกำหนดชุดสีที่อัปเดตทุกครั้งที่ผู้ใช้เปลี่ยนธีม

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

การตั้งค่า JSON ธีมอื่นๆ

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

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

ฉันไม่แน่ใจว่าฉันต้องการพรีเซ็ตหรือไม่เพราะฉันไม่รู้ว่า WordPress จะใช้มันอย่างไร เป็นสิ่งที่คนอื่นๆ ถามหา และแทบจะใช้งานได้ทุกหนทุกแห่ง การกำหนดระบบทั้งหมดรอบๆ ตัวอาจทำให้ปวดหัวได้ แต่ฉันยังคงต้องการดูการอภิปรายเกี่ยวกับการนำการตั้งค่าระยะห่างมาตรฐานสากลมาใช้เป็นอย่างน้อย

การตั้งค่าและสไตล์ต่อบล็อก

ส่วนแบบสำรวจนี้เป็นคำถามที่ใช่/ไม่ใช่ เพียงถามว่าผู้เขียนธีมรวมการตั้งค่าหรือสไตล์ต่อบล็อกไว้ในไฟล์ theme.json หรือไม่ แน่นอน ฉันฝากความคิดเห็นเพิ่มเติมไว้ในส่วนความคิดเห็นเพิ่มเติมในภายหลัง

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

การเขียน CSS ใน JSON โดยพื้นฐานแล้วสิ่งที่เรากำลังพูดถึงนั้นรู้สึกผิดในหลายระดับ ปัจจุบัน จำกัดไว้เพียงรูปแบบที่กำหนดค่าได้เพียงไม่กี่รูปแบบ ดังนั้นสิ่งใดก็ตามที่เกินกว่านั้นจะต้องเจาะลึกเข้าไปในไฟล์ CSS จริงอยู่ดี นั่นเป็นปัญหาเนื่องจากโค้ด CSS ของธีมครึ่งหนึ่งถูกแบ่งระหว่าง theme.json และไฟล์ CSS แยกกัน จากมุมมองด้านการพัฒนา มันทำให้ codebase ดูแลรักษายากขึ้น

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

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

คำติชมอื่นๆ: A PHP Layer

ฉันเคยพูดไปแล้ว แต่มันซ้ำซากจำเจ เราจำเป็นต้องมีเลเยอร์ PHP สำหรับระบบกำหนดค่า theme.json นี้ ขณะนี้มีตั๋วเปิดสำหรับการจัดการเรื่องนี้

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

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