การเปรียบเทียบโดยละเอียดระหว่าง WordPress และ CMS ตุลาคม

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

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

ทำไมต้องตุลาคม CMS

ฉันพบว่าเมื่อเดือนตุลาคม CMS ได้รับรางวัล หลังจากนั้นฉันเข้าสู่โหมดการวิจัยและใช้เวลาอย่างมากในการขุดลึกลงไปใน CMS นี้ จากมุมมองของทั้งผู้ใช้และนักพัฒนา เมื่อฉันได้รับความรู้เกี่ยวกับ CMS นี้ ฉันรู้สึกมั่นใจว่าสามารถประเมินคุณสมบัติของมันได้อย่างตรงไปตรงมา ซึ่งแตกต่างจาก WordPress ฉันเลือก CMS นี้เพื่อเปรียบเทียบตัวเลือกอื่นๆ เช่น Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo และอื่นๆ ด้วยเหตุผลดังต่อไปนี้:

• ฉันรู้ว่า CMS นี้ทำงานอย่างไร (ต่างจาก Grav);
• เป็นโอเพ่นซอร์สฟรี (ต่างจาก Statamic และ ButterCMS);
• เมื่ออายุได้ 5 ปี ถือว่า "ค่อนข้าง" ใหม่ (ต่างจาก Joomla และ Drupal);
• มันเป็นตัวสร้างเนื้อหาแบบไดนามิก (ไม่คงที่) และอยู่ใน PHP (ต่างจาก Jekyll และ Hugo)
  

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

อะไรคือความแตกต่างระหว่างทั้งสอง?

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

นอกจากนี้ บทความนี้ไม่สามารถสรุปผลได้อย่างชัดเจนเนื่องจากเกี่ยวข้องกับชุดย่อยของความเป็นไปได้ทั้งหมดเท่านั้น ตัวอย่างเช่น เราสามารถหาการเปรียบเทียบทางออนไลน์ได้ เช่น “WordPress vs Drupal vs Joomla”, “WordPress vs Static Site Generators” และแม้แต่ “WordPress vs Medium” เนื่องจากไม่มีบทความใดที่เห็นภาพทั้งหมด การเปรียบเทียบเหล่านี้จึงไม่สามารถสรุปได้ และไม่ควรได้รับการปฏิบัติเช่นนั้น

เริ่มต้นด้วยการเปรียบเทียบ

ปรัชญาและกลุ่มเป้าหมาย

ไม่ใช่เรื่องบังเอิญที่ WordPress มีอำนาจเกือบ 1 ใน 3 เว็บไซต์ นับตั้งแต่เริ่มก่อตั้ง บริษัทได้พยายามอย่างยิ่งที่จะให้เป็นมิตรกับผู้ใช้เป็นอย่างยิ่งและประสบความสำเร็จในเรื่องนี้ โดยขจัดความขัดแย้งสำหรับผู้ใช้ด้านเทคนิคและผู้ใช้ที่ไม่ใช่ด้านเทคนิค เช่นเดียวกับผู้คนจากทุกพื้นเพ โดยไม่คำนึงถึงระดับการศึกษาและเศรษฐกิจของพวกเขา Matt Mullenweg ผู้ก่อตั้ง WordPress ได้กล่าวว่าคำขวัญของ WordPress ที่ว่า “Democratize Publishing” สำหรับยุคปัจจุบันมีความหมายดังต่อไปนี้:

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

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

ในทางตรงกันข้าม October CMS นั้นมุ่งเป้าไปที่นักพัฒนามากกว่า เนื่องจากมีการกำหนดไว้อย่างชัดเจนตั้งแต่เปิดตัวครั้งแรก:

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

ในคำพูดของผู้ก่อตั้ง ภารกิจของ CMS คือ "พิสูจน์ว่าการสร้างเว็บไซต์ไม่ใช่วิทยาศาสตร์จรวด" ตุลาคม CMS ที่อิงจาก Laravel สามารถอ้างว่ามีรากฐานที่แข็งแกร่งของโค้ดโมดูลาร์ที่นำกลับมาใช้ใหม่ได้ ซึ่งสามารถสร้างแอปพลิเคชันที่มีสถาปัตยกรรมอย่างเหมาะสม บำรุงรักษาได้ในระยะยาว และปรับแต่งได้อย่างเต็มที่โดยไม่ต้องมีการแฮ็ก ซึ่งเป็นประเภทที่ดึงดูดโปรแกรมเมอร์ที่จริงจัง ตุลาคม CMS สามารถมอบประสบการณ์การใช้งานที่ยอดเยี่ยมให้กับผู้ใช้ อย่างไรก็ตาม มันไม่ง่ายหรือราบรื่นเหมือนที่ WordPress มอบให้ ผู้ใช้อาจต้องอธิบายวิธีใช้ฟังก์ชันบางอย่างก่อนจึงจะสามารถใช้งานได้ ตัวอย่างเช่น การฝังแบบฟอร์มจากปลั๊กอินบางตัวมีคำอธิบายยาวๆ เกี่ยวกับวิธีการทำ ซึ่งยุ่งยากกว่าฟังก์ชันการลากและวางที่เห็นได้ชัดในตัวเองซึ่งมีให้โดยปลั๊กอินหลายรูปแบบใน WordPress

การติดตั้ง

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

การติดตั้ง CMS เดือนตุลาคมก็ราบรื่นเช่นกัน: การติดตั้งวิซาร์ดเองใช้เวลาน้อยกว่าห้านาที และหากคุณติดตั้งผ่านการติดตั้งคอนโซล การติดตั้งก็จะเร็วยิ่งขึ้นไปอีก คุณสามารถทำได้โดยไปที่ไดเร็กทอรีเป้าหมายแล้วดำเนินการ curl -s https://octobercms.com/api/installer | php curl -s https://octobercms.com/api/installer | php (หลังจากนั้นเราต้องป้อนการกำหนดค่าฐานข้อมูล มิฉะนั้นจะทำงานเป็นไฟล์ CMS แบบแฟลต) เมื่อการติดตั้งเสร็จสิ้น เราจะมีเว็บไซต์ที่ทำงานได้อย่างสมบูรณ์ แต่ยังค่อนข้างว่างเปล่า (หากคุณเพิ่มเวลาที่จำเป็นในการติดตั้งและกำหนดค่าปลั๊กอินที่จำเป็น คุณสามารถคาดหวังได้ว่าจะใช้เวลาอย่างน้อย 15 นาที)

ความปลอดภัย

WordPress ถูกกล่าวหาว่าไม่ปลอดภัยเนื่องจากมีช่องโหว่จำนวนมากที่พบอย่างต่อเนื่อง สิ่งนี้บังคับให้ผู้ใช้มีซอฟต์แวร์สำหรับ CMS และปลั๊กอินที่ติดตั้งทั้งหมดเป็นเวอร์ชันล่าสุดเสมอเพื่อหลีกเลี่ยงการหาช่องโหว่ด้านความปลอดภัย ปัญหาหลักคือการสนับสนุนของ WordPress สำหรับ PHP เวอร์ชันเก่าซึ่งไม่รองรับโดยชุมชนการพัฒนา PHP อีกต่อไป (ปัจจุบัน WordPress รองรับ PHP 5.2.4 ในขณะที่ PHP เวอร์ชันล่าสุดที่รองรับอย่างสมบูรณ์คือ 5.6) อย่างไรก็ตาม ปัญหานี้ควรได้รับการแก้ไขในเดือนเมษายน 2019 เมื่อ WordPress จะเริ่มรองรับ PHP เวอร์ชัน 5.6 ขึ้นไปอย่างเป็นทางการ

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

ในทางกลับกัน CMS ตุลาคมไม่ได้มีชื่อเสียงว่าไม่ปลอดภัย อย่างไรก็ตาม เนื่องจากมีไซต์สดประมาณ 27,000 ไซต์ที่ใช้เดือนตุลาคมเมื่อเทียบกับ WordPress หลายล้านไซต์ เราจึงไม่สามารถตัดสินทั้งสองไซต์ด้วยเงื่อนไขเดียวกันได้ อย่างไรก็ตาม ทีมงานที่อยู่เบื้องหลัง CMS ของเดือนตุลาคม ให้ความสำคัญกับความปลอดภัยเป็นอย่างมาก ดังที่เห็นได้จากข้อความแจ้งของการติดตั้ง Wizard ให้ป้อน URL แบ็กเอนด์ของ CMS โดยตั้งเป็น /backend โดยค่าเริ่มต้นแต่สามารถเปลี่ยนแปลงอย่างอื่นได้ เพื่อทำให้แฮกเกอร์กำหนดเป้าหมายไซต์ได้ยากขึ้น . ในทางตรงกันข้าม การเปลี่ยน URL ล็อกอินและแบ็กเอนด์ของ WordPress จาก /wp-login.php และ /wp-admin ตามลำดับเป็นอย่างอื่นจะต้องทำผ่านปลั๊กอิน นอกจากนี้ October CMS ยังสามารถทำหน้าที่เป็น CMS แบบไฟล์เรียบ (เช่น ไม่มีฐานข้อมูล) และหลีกเลี่ยงช่องโหว่ที่เกี่ยวข้องกับฐานข้อมูล เช่น การฉีด SQL

กองเทคโนโลยี

ทั้ง WordPress และ CMS ตุลาคมทำงานบน LAMP stack แบบเดิม: Linux, Apache, MySQL และ PHP (อย่างไรก็ตาม เฉพาะ PHP เท่านั้นที่ได้รับการแก้ไข: เรายังสามารถใช้ Windows, Nginx, MariaDB และอื่นๆ ได้) CMS ตุลาคมยังสามารถทำงานเป็น CMS ไฟล์เรียบ ซึ่งหมายความว่าสามารถทำได้โดยไม่ต้องใช้ฐานข้อมูล ฟังก์ชันมากมาย (เช่น บล็อกโพสต์และผู้ใช้) ฟังก์ชันเดียวที่รับประกันคือหน้า ซึ่งถือเป็นหน่วยพื้นฐานสำหรับการสร้างและเผยแพร่เนื้อหาและจัดส่งเป็นคุณลักษณะหลัก

เกี่ยวกับกลุ่มภาษา ไซต์ที่สร้างด้วยทั้ง WordPress และ CMS ตุลาคมนั้นใช้ HTML, CSS และ JavaScript (โปรดทราบว่ามีการใช้ PHP เพื่อสร้าง HTML) ตุลาคม CMS ยังทำให้ง่ายต่อการใช้ไฟล์ LESS และ SASS

กระบวนทัศน์การเขียนโปรแกรม

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

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

ตะขอ/เหตุการณ์

การเขียนโปรแกรมใน WordPress อาจมีลักษณะเป็น HDD ซึ่งย่อมาจาก “Hook-Driven Development” เบ็ดเป็นกลไกที่ช่วยให้เปลี่ยนพฤติกรรมหรือค่าดีฟอลต์และอนุญาตให้โค้ดอื่นดำเนินการฟังก์ชันที่เกี่ยวข้อง ตะขอถูกเรียกใช้ผ่าน "การกระทำ" ที่อนุญาตให้เรียกใช้ฟังก์ชันพิเศษ และ "ตัวกรอง" ที่อนุญาตให้แก้ไขค่า

Hooks ซึ่งแพร่หลายในฐานรหัส WordPress เป็นหนึ่งในแนวคิดที่ฉันชอบมากที่สุดจากการเขียนโค้ดใน WordPress พวกเขาอนุญาตให้ปลั๊กอินโต้ตอบกับปลั๊กอินอื่น ๆ (หรือกับแกนหรือธีม) ได้อย่างสะอาด โดยให้การสนับสนุนพื้นฐานบางอย่างของการเขียนโปรแกรมเชิงมุมมอง

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

การพึ่งพาไลบรารี JavaScript

เวอร์ชันล่าสุดของ WordPress รวมเอา Gutenberg ที่ขับเคลื่อนด้วย React สำหรับประสบการณ์การสร้างเนื้อหาเริ่มต้น ดังนั้นการพัฒนา WordPress จึงอาศัย JavaScript เป็นหลัก (ส่วนใหญ่ผ่าน React) แม้ว่าจะสามารถใช้เฟรมเวิร์กหรือไลบรารีอื่น ๆ ได้ (ตามหลักฐานจาก Elementor Blocks สำหรับ Gutenberg ซึ่งอิงกับ Marionette) นอกจากนี้ WordPress ยังคงใช้ Backbone.js (สำหรับ Media Manager) และ jQuery (รหัสเดิม) อย่างไรก็ตาม เราสามารถคาดหวังว่าการพึ่งพาไลบรารีเหล่านี้จะหมดไป เนื่องจาก Gutenberg ถูกรวมเป็นบรรทัดฐานใหม่

CMS เดือนตุลาคมขึ้นอยู่กับ jQuery ซึ่งใช้เพื่อติดตั้งเฟรมเวิร์ก AJAX เสริมเพื่อโหลดข้อมูลจากเซิร์ฟเวอร์โดยไม่ต้องรีเฟรชหน้าเบราว์เซอร์

หน้า ธีม และปลั๊กอิน

ทั้ง WordPress และ October CMS ถือว่าหน้าเป็นหน่วยพื้นฐานสำหรับการสร้างและเผยแพร่เนื้อหา (ในกรณี WordPress นอกเหนือจากโพสต์) รองรับการเปลี่ยนรูปลักษณ์ของเว็บไซต์ผ่านธีม และอนุญาตให้ติดตั้งและขยายฟังก์ชันการทำงานของเว็บไซต์ผ่านปลั๊กอิน . แม้ว่าแนวคิดจะเหมือนกันใน CMS ทั้งสอง แต่ก็มีความแตกต่างเล็กน้อยในการใช้งานซึ่งก่อให้เกิดพฤติกรรมที่แตกต่างกันบ้าง

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

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

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

ฟังก์ชันการทำงานหลักเทียบกับปลั๊กอิน

WordPress พยายามที่จะมอบฟังก์ชันการทำงานหลักที่น้อยที่สุดซึ่งได้รับการปรับปรุงผ่านปลั๊กอิน WordPress ใช้ "กฎ ⁸⁰ ⁄ ₂₀ " เพื่อตัดสินใจว่าจะรวมฟังก์ชันการทำงานบางอย่างไว้ในประสบการณ์หลักหรือไม่ ถ้ามันเป็นประโยชน์ต่อผู้ใช้ 80% ที่เข้าไป มิฉะนั้น มันจะเป็นของปลั๊กอิน-แลนด์ เมื่อเพิ่มปลั๊กอินลงในไซต์ ปลั๊กอินเหล่านี้อาจทำให้บวมได้หากมีการติดตั้งปลั๊กอินมากเกินไป ปลั๊กอินอาจทำงานร่วมกันได้ไม่ดี หรือรันโค้ดที่คล้ายกันหรือโหลดเนื้อหาที่คล้ายกัน ส่งผลให้ประสิทธิภาพต่ำ ดังนั้น ในขณะที่การเปิดตัวไซต์ WordPress นั้นค่อนข้างง่าย แต่ความท้าทายที่ใหญ่กว่าคือการบำรุงรักษาทั่วไป และสามารถรักษาสถานะที่เหมาะสมและมีประสิทธิภาพเมื่อเพิ่มคุณสมบัติใหม่

ในทำนองเดียวกัน October CMS ก็พยายามที่จะนำเสนอฟังก์ชันการทำงานหลักที่น้อยที่สุด แต่สำหรับสเตียรอยด์: ฟังก์ชันที่รับประกันเพียงอย่างเดียวคือการสร้างและเผยแพร่หน้าเว็บ และสำหรับทุกสิ่งทุกอย่าง เราจะต้องติดตั้งปลั๊กอินตัวใดตัวหนึ่งซึ่งแสดงเป็น:

“ทุกสิ่งที่คุณต้องการและไม่มีอะไรที่คุณไม่ต้องการ”

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

ตุลาคม CMS ยังมีคุณลักษณะบางอย่างในแกนกลางซึ่ง (แม้ว่าจะไม่จำเป็นเสมอไป) สามารถปรับปรุงแอปพลิเคชันได้อย่างมาก ตัวอย่างเช่น รองรับทันทีที่อัปโหลดไฟล์สื่อไปยัง Amazon S3 และเข้าถึงผ่าน Rackspace CDN นอกจากนี้ยังมี Media Manager ซึ่งส่วนใหญ่ใช้ผ่านปลั๊กอิน เช่น สำหรับการเพิ่มรูปภาพในบล็อกโพสต์ (เพจสามารถใช้ Media Manager เพื่อฝังไฟล์สื่อได้ อย่างไรก็ตาม CMS ยังมาพร้อมกับส่วนเนื้อหาเพื่ออัปโหลดไฟล์สื่อสำหรับไฟล์เหล่านี้ซึ่งดูเหมาะสมกว่า)

ฉันเชื่อว่าความเห็นชอบในเดือนตุลาคมจะช่วยให้เราผลิตแอปพลิเคชันที่ทำงานได้น้อยที่สุดเท่าที่จะเป็นไปได้ ส่วนใหญ่เกี่ยวข้องกับไซต์ทั่วไป อย่างไรก็ตาม มันยังสามารถย้อนกลับมาและกระตุ้นให้เกิดการบวม เพราะเส้นของสิ่งที่จำเป็นและสิ่งที่ไม่จำเป็นนั้นเป็นสิ่งที่ไม่แน่นอน และเป็นการยากที่จะกำหนดล่วงหน้าโดย CMS ความยากลำบากนี้สามารถชื่นชมได้เมื่อพิจารณาแนวคิดของ "ผู้ใช้": ใน WordPress ผู้ใช้เว็บไซต์และผู้ดูแลเว็บไซต์เป็นของเอนทิตีผู้ใช้เดียวกัน (และด้วยบทบาทและสิทธิพิเศษ เราสามารถทำให้ผู้ใช้กลายเป็นผู้ดูแลระบบได้) ในเดือนตุลาคม CMS ทั้งสองใช้งานแยกกัน จัดส่งหลักในการใช้งานสำหรับผู้ดูแลระบบเว็บไซต์ ซึ่งสามารถเข้าสู่ระบบในพื้นที่แบ็กเอนด์และแก้ไขการตั้งค่า และผ่านปลั๊กอินการใช้งานของผู้ใช้เว็บไซต์ ผู้ใช้ทั้งสองประเภทนี้มีกระบวนการเข้าสู่ระบบที่แตกต่างกันและตารางฐานข้อมูลที่แตกต่างกันสำหรับการจัดเก็บข้อมูล ดังนั้นจึงอาจละเมิดหลักการ DRY (อย่าทำซ้ำตัวเอง)

ปัญหานี้เกิดขึ้นไม่เฉพาะกับพฤติกรรมของเอนทิตีเท่านั้น แต่ยังรวมถึงฟิลด์ข้อมูลใดบ้างที่มันต้องมี ตัวอย่างเช่น ฟิลด์ข้อมูลผู้ใช้เว็บไซต์ควรกำหนดไว้ล่วงหน้าหรือไม่ ฟิลด์โทรศัพท์จำเป็นหรือไม่? แล้วฟิลด์ URL ของ Instagram เป็นอย่างไรเมื่อพิจารณาว่า Instagram ได้รับความนิยมเมื่อเร็ว ๆ นี้? แต่เมื่อสร้างเว็บไซต์ระดับมืออาชีพ เราไม่ควรใช้ฟิลด์ URL ของ LinkedIn แทนใช่หรือไม่ การตัดสินใจเหล่านี้ขึ้นอยู่กับแอปพลิเคชันอย่างชัดเจน และไม่สามารถตัดสินใจได้ด้วย CMS หรือปลั๊กอิน

ปลั๊กอิน CMS เดือนตุลาคมที่เรียกว่า User ใช้ผู้ใช้ แต่ไม่มีฟิลด์ผู้ใช้ใด ๆ นอกจากนี้ปลั๊กอิน User Plus ยังเพิ่มฟิลด์ผู้ใช้ตามอำเภอใจหลายฟิลด์ ซึ่งอาจไม่เพียงพอ ดังนั้นปลั๊กอิน User Plus+ จะเพิ่มฟิลด์ผู้ใช้อื่น ๆ เราจะหยุดกระบวนการนี้เมื่อใด ที่ไหน และอย่างไร

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

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

การสร้างเนื้อหา

Gutenberg มีส่วนสนับสนุนสำคัญสองประการใน WordPress: มันใช้ส่วนประกอบเป็นหน่วยสำหรับการสร้างไซต์ (ซึ่งมีข้อดีหลายประการเหนือการเข้ารหัส blobs ของ HTML) และแนะนำเอนทิตีที่เรียกว่า "บล็อก" ซึ่งเมื่อ Gutenberg ระยะที่ 2 เสร็จสิ้น (สันนิษฐานใน 2019) จะให้วิธีการรวมเนื้อหาเข้ากับไซต์แบบรวมเป็นหนึ่ง ซึ่งจะทำให้ประสบการณ์การใช้งานของผู้ใช้ง่ายขึ้น ตรงข้ามกับกระบวนการเพิ่มเนื้อหาผ่านรหัสย่อ ปุ่ม TinyMCE เมนู วิดเจ็ต และอื่นๆ ที่วุ่นวายมากขึ้น

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

หากส่วนประกอบ React เป็นหน่วยพื้นฐานสำหรับการสร้างเนื้อหาใน WordPress ตุลาคม CMS จะขึ้นอยู่กับสมมติฐานที่ว่าการรู้ HTML แบบเก่าที่ดีก็เพียงพอแล้วสำหรับการสร้างไซต์ อันที่จริง เมื่อสร้างเพจ เราจะแสดงตัวแก้ไข HTML (Markup) ง่ายๆ:

หากหน้านั้นเป็น HTML แบบคงที่เพียงอย่างเดียว ก็ไม่จำเป็นต้องมี CMS แทนที่ หน้า CMS ตุลาคมจะเขียนโดยใช้เทมเพลต Twig ซึ่งรวบรวมเป็นโค้ด PHP ที่ปรับให้เหมาะสมที่สุด พวกเขาสามารถเลือกเลย์เอาต์เพื่อรวมโครงของเพจ (เช่น องค์ประกอบที่ซ้ำกัน เช่น ส่วนหัว ส่วนท้าย และอื่นๆ) สามารถใช้ตัวยึดตำแหน่ง ซึ่งกำหนดไว้ในเลย์เอาต์เพื่อให้เพจปรับแต่งเนื้อหา และสามารถรวม Partials ซึ่งเป็นส่วนย่อยของโค้ดที่นำกลับมาใช้ใหม่ได้ นอกจากนี้ เพจยังสามารถรวมบล็อคเนื้อหา ซึ่งเป็นไฟล์ข้อความ HTML หรือ Markdown ที่สามารถแก้ไขได้ด้วยตัวเองและสามารถแนบส่วนประกอบที่เป็นฟังก์ชันการทำงานผ่านปลั๊กอินได้ และสุดท้าย เมื่อใดก็ตามที่ HTML ไม่เพียงพอและเราจำเป็นต้องสร้างโค้ดแบบไดนามิก เราก็สามารถเพิ่มฟังก์ชัน PHP ได้

ตัวแก้ไขเป็นข้อมูลเกี่ยวกับ HTML ไม่มีพื้นที่ textarea สำหรับการเพิ่มเนื้อหาในลักษณะภาพ — อย่างน้อยไม่ผ่านประสบการณ์เริ่มต้น (ฟังก์ชันนี้เป็นของปลั๊กอิน-land) ดังนั้นการมีความรู้เกี่ยวกับ HTML จึงเป็นสิ่งจำเป็นสำหรับการใช้ CMS ตุลาคม นอกจากนี้ อินพุตต่างๆ มากมายสำหรับการสร้างเนื้อหา (หน้า เลย์เอาต์ ตัวยึดตำแหน่ง บางส่วน บล็อกเนื้อหา ส่วนประกอบ และฟังก์ชัน PHP) อาจมีประสิทธิภาพมาก อย่างไรก็ตาม มันไม่ง่ายเหมือนผ่านอินเทอร์เฟซบล็อกรวมจาก WordPress อย่างแน่นอน แม้จะมีความซับซ้อนมากขึ้นก็ตาม เนื่องจากสามารถเพิ่มองค์ประกอบอื่นๆ ได้ (เช่น เพจและเมนูสแตติก และตัวอย่าง) และบางส่วน เช่น เพจและเพจสแตติก ดูเหมือนจะมีฟังก์ชันการทำงานเหมือนกัน ทำให้สับสนในการตัดสินใจว่าเมื่อใด ใช้อย่างใดอย่างหนึ่ง

ด้วยเหตุนี้ ฉันกล้าพูดได้เลยว่าในขณะที่แทบทุกคนสามารถใช้ไซต์ WordPress จากฝั่งผู้ดูแลระบบได้ แต่ October CMS นั้นเป็นมิตรกับนักพัฒนามากกว่าที่ไม่เป็นมิตรกับผู้ใช้ด้านเทคนิค ดังนั้นโปรแกรมเมอร์อาจพบว่าการใช้งานนั้นน่าสนุก แต่ก็มีอย่างอื่นบ้าง บทบาท (นักการตลาด พนักงานขาย และอื่นๆ) อาจพบว่าไม่ใช่เรื่องง่าย

ผู้จัดการสื่อ

ทั้ง WordPress และ October CMS มาพร้อมกับ Media Manager ซึ่งช่วยให้สามารถเพิ่มไฟล์มีเดียไปยังไซต์ได้อย่างง่ายดาย รองรับการเพิ่มไฟล์หลายไฟล์พร้อมกันผ่านอินเทอร์เฟซแบบลากและวาง และแสดงภาพภายในพื้นที่เนื้อหา พวกเขาดูและประพฤติตนคล้ายคลึงกัน ความแตกต่างที่โดดเด่นเพียงอย่างเดียวที่ฉันพบคือ Media Manager ของ WordPress อนุญาตให้ฝังแกลเลอรีรูปภาพ และ Media Manager ของเดือนตุลาคมอนุญาตให้สร้างโครงสร้างโฟลเดอร์ด้วยตนเองเพื่อวางไฟล์ที่อัปโหลด

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

การทำให้เป็นสากล

WordPress core ใช้ gettext เพื่อเปิดใช้งานการแปลธีมและปลั๊กอิน เริ่มต้นจากไฟล์ . .pot ที่มีสตริงทั้งหมดที่จะแปล เราจำเป็นต้องสร้างไฟล์ .po ที่มีการแปลเป็นภาษา/สถานที่ที่เกี่ยวข้อง จากนั้นไฟล์นี้จะถูกคอมไพล์เป็นไฟล์ . .mo ไบนารีที่เหมาะสมสำหรับการแยกการแปลอย่างรวดเร็ว เครื่องมือในการทำงานเหล่านี้ ได้แก่ GlotPress (ออนไลน์) และ Poedit (แอปพลิเคชันที่ดาวน์โหลดได้) กลไกนี้ยังใช้งานได้สะดวกสำหรับการแปลฝั่งไคลเอ็นต์สำหรับ Gutenberg

ปัจจุบัน WordPress ไม่ได้จัดส่งโซลูชันใดๆ ที่เป็นแกนหลักในการแปลเนื้อหา และจะไม่ดำเนินการดังกล่าวจนกว่าจะถึงระยะที่ 4 ของ Gutenberg (กำหนดเป้าหมายสำหรับปี 2020+) ก่อนหน้านั้น ฟังก์ชันนี้มีให้โดยปลั๊กอินซึ่งมีกลยุทธ์ต่างๆ สำหรับการจัดเก็บและจัดการเนื้อหาที่แปลแล้ว ตัวอย่างเช่น ในขณะที่ปลั๊กอินเช่น Polylang และ WPML จัดเก็บการแปลแต่ละรายการในแถวของตัวเองจากตารางฐานข้อมูลที่กำหนดเอง (ซึ่งสะอาดดีเพราะไม่ได้ผสมเนื้อหาเข้าด้วยกัน แต่ช้ากว่าเนื่องจากต้องใช้ INNER JOIN เพิ่มเติมจากสองตารางเมื่อทำการสอบถาม ฐานข้อมูล) ปลั๊กอิน qTranslate X เก็บการแปลทั้งหมดไว้ในฟิลด์เดียวกันจากตารางฐานข้อมูลดั้งเดิม (เร็วกว่าสำหรับการสืบค้นข้อมูล แต่เนื้อหาที่ผสมทั้งหมดเข้าด้วยกันสามารถสร้างซากปรักหักพังบนเว็บไซต์ได้หากปิดการใช้งานปลั๊กอิน) ดังนั้นเราจึงสามารถเลือกซื้อสินค้าและตัดสินใจเลือกกลยุทธ์ที่เหมาะสมกับความต้องการของเรามากที่สุด

ตุลาคม CMS ไม่ได้จัดส่งฟังก์ชันการทำงานหลายภาษาผ่านแกนหลัก แต่เป็นปลั๊กอินที่สร้างโดยทีม CMS ตุลาคมที่รับประกันการผสานรวมที่ผิดพลาดในระบบ จากมุมมองการใช้งาน ปลั๊กอินนี้มอบสิ่งที่สัญญาไว้ จากมุมมองของการพัฒนา ปลั๊กอินนี้ใช้งานได้จริงไม่สมบูรณ์แบบนัก ใน WordPress เพจเป็นเพียงโพสต์ที่มีประเภทโพสต์เป็น "หน้า" และมีกลไกการแปลแบบเดียวสำหรับพวกเขา แต่ในเดือนตุลาคม CMS มีเอนทิตี "หน้า" "หน้าคงที่" และ "โพสต์บล็อก" และแม้ว่า คล้ายกันมาก พวกเขาต้องการการใช้งานที่แตกต่างกันสามแบบสำหรับการแปล! จากนั้น เนื้อหาจาก "หน้า" สามารถรวมรหัสข้อความ (เช่น รหัสที่เรียกว่า nav.content , header.title และอื่นๆ) ซึ่งแต่ละส่วนมีการแปลสำหรับสถานที่ทั้งหมดเป็นวัตถุ JSON แบบอนุกรมในตารางฐานข้อมูล rainlab_translate_messages เนื้อหาจาก “หน้าสแตติก” ถูกสร้างเป็นไฟล์สแตติกใหม่ตามสถานที่ อย่างไรก็ตาม URL ที่แปลทั้งหมดสำหรับสถานที่ทั้งหมดไม่ได้จัดเก็บไว้ในไฟล์ที่เกี่ยวข้อง แต่จะเก็บไว้ในไฟล์ของภาษาเริ่มต้นแทน เนื้อหาสำหรับ "บล็อกโพสต์" ถูกจัดเก็บเป็นวัตถุ JSON แบบอนุกรมที่มีหนึ่งแถวต่อสถานที่ในตารางฐานข้อมูล rainlab_translate_attributes และ URL ที่แปลจะถูกเก็บไว้ด้วยหนึ่งแถวต่อสถานที่ในตารางฐานข้อมูล rainlab_translate_indexes ฉันไม่รู้ว่าความซับซ้อนนี้เกิดจากวิธีการใช้งานปลั๊กอินหรือเป็นเพราะสถาปัตยกรรมของ CMS เดือนตุลาคม ไม่ว่าในกรณีใด นี่เป็นอีกตัวอย่างหนึ่งของการขยายตัวที่ไม่ต้องการในด้านการพัฒนา

การจัดการปลั๊กอิน

ทั้ง WordPress และ October CMS มีตัวจัดการปลั๊กอินที่ซับซ้อนซึ่งช่วยให้ค้นหาปลั๊กอิน ติดตั้งปลั๊กอินใหม่ และอัปเดตปลั๊กอินที่ติดตั้งอยู่ในปัจจุบันเป็นเวอร์ชันล่าสุด - ทั้งหมดจากภายในแบ็กเอนด์

การจัดการการพึ่งพา

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

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

การโต้ตอบกับฐานข้อมูล

WordPress มีฟังก์ชันในการดึงข้อมูลฐานข้อมูล (เช่น get_posts ) และจัดเก็บไว้ (เช่น wp_insert_post และ wp_update_post ) เมื่อดึงข้อมูล เราสามารถส่งพารามิเตอร์เพื่อกรอง จำกัด และเรียงลำดับผลลัพธ์ เพื่อระบุว่าต้องส่งผลลัพธ์เป็นอินสแตนซ์ของคลาสหรือเป็นอาร์เรย์ของคุณสมบัติและอื่น ๆ เมื่อฟังก์ชันไม่ตรงตามข้อกำหนดของเราทั้งหมด (เช่น เมื่อเราต้องทำ INNER JOIN ด้วยตารางที่กำหนดเอง) เราก็สามารถสืบค้นฐานข้อมูลได้โดยตรงผ่านตัวแปรส่วนกลาง $wpdb เมื่อสร้างปลั๊กอินด้วยประเภทโพสต์ที่กำหนดเอง โค้ดมักจะดำเนินการค้นหา SQL ที่กำหนดเองเพื่อเรียกค้นและ/หรือบันทึกข้อมูลลงในตารางที่กำหนดเอง โดยสรุป WordPress พยายามให้การเข้าถึงฐานข้อมูลผ่านฟังก์ชันทั่วไปในระยะแรก และผ่านการเข้าถึงฐานข้อมูลในระดับต่ำในระยะที่สอง

ตุลาคม CMS ใช้แนวทางที่แตกต่าง: แทนที่จะเชื่อมต่อกับฐานข้อมูลทันที แอปพลิเคชันสามารถใช้ Eloquent ORM ของ Laravel เพื่อเข้าถึงและจัดการข้อมูลฐานข้อมูลผ่านอินสแตนซ์ของคลาสที่เรียกว่า Models ทำให้การโต้ตอบกับฐานข้อมูลนั้นขึ้นอยู่กับการเขียนโปรแกรมเชิงวัตถุ . เป็นการเข้าถึงระดับสูง เพียงแค่ทำตามกฎเกี่ยวกับวิธีการสร้างตารางและตั้งค่าความสัมพันธ์ระหว่างเอนทิตี ปลั๊กอินก็สามารถดึงและ/หรือบันทึกข้อมูลโดยไม่ต้องเขียนบรรทัดของ SQL ตัวอย่างเช่น โค้ดด้านล่างดึงวัตถุจากฐานข้อมูลผ่านโมเดล Flight แก้ไขคุณสมบัติ และจัดเก็บอีกครั้ง:

 $flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();

การอัพเกรดโมเดลข้อมูล

อีกเหตุผลหนึ่งสำหรับความสำเร็จของ WordPress (นอกเหนือจากการไม่ทำลายความเข้ากันได้แบบย้อนหลัง) คือสถาปัตยกรรมฐานข้อมูล ซึ่งได้รับการออกแบบมาเพื่อให้แอปพลิเคชันสามารถเติบโตได้เมื่อเวลาผ่านไป วัตถุประสงค์นี้สำเร็จได้ด้วยคุณสมบัติ "เมตา" นั่นคือคุณสมบัติที่สามารถเพิ่มลงในวัตถุฐานข้อมูลได้ตลอดเวลา คุณสมบัติเหล่านี้ไม่ได้เก็บไว้ในคอลัมน์จากตารางเอนทิตีที่เกี่ยวข้อง (ทั้ง wp_posts , wp_users , wp_comments หรือ wp_terms ) แต่เป็นแถวในตาราง "meta" ที่เกี่ยวข้อง ( wp_postmeta , wp_usermeta , wp_commentmeta หรือ wp_termmeta ) และดึงข้อมูลกลับมาทำ INNER JOIN ดังนั้น แม้ว่าการดึงค่าเมตาเหล่านี้จะช้ากว่า แต่ก็ให้ความยืดหยุ่นที่ไม่จำกัด และแบบจำลองข้อมูลของแอปพลิเคชันแทบไม่จำเป็นต้องมีการออกแบบใหม่ตั้งแต่ต้นเพื่อใช้งานฟังก์ชันใหม่บางอย่าง

ตุลาคม CMS ไม่ได้ใช้คุณสมบัติเมตา แต่สามารถเก็บค่าตามอำเภอใจได้หลายค่าแทน ซึ่งไม่ได้แมปโดยตรงเป็นคอลัมน์ในตารางฐานข้อมูล เป็นวัตถุ JSON แบบอนุกรม Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application's database schema, October CMS relies on Laravel's Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (eg when installing a plugin's new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, ie treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).

A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/... ; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.

Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in several projects in the wild.

On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn't offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (eg accessing a property from a column is faster than from a row in another table through an INNER JOIN , which is the case with WordPress' meta properties).

CLI Support

Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel's Artisan. In addition to Laravel's commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.

Managed Hosting

It is not a problem finding a managed hosting provider for a WordPress site: given WordPress' market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).

Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven't found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.

Marketplace, Ecosystem And Cost

WordPress' commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.

Being relatively new (only five years so far), OctoberCMS certainly doesn't enjoy anything near WordPress' marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.

Hence, even though 600+ plugins doesn't sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October's founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)

In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October's better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.

ชุมชน

Being a part of and having access, WordPress' community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.

Furthermore, the WordPress community is real and tangible: it doesn't exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it's also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.

October CMS' community is nothing near in size or diversity as WordPress', even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October's founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.

Maintainers And Governance

Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?

ขับเคลื่อนหนึ่งในสามของไซต์ทั้งหมดในโลก WordPress ไม่ได้ขาดแคลนผู้มีส่วนได้ส่วนเสียที่มีส่วนร่วมในซอฟต์แวร์ ดังนั้นเราจึงไม่ต้องกลัวว่าซอฟต์แวร์จะพัง อย่างไรก็ตาม WordPress กำลังดำเนินการพิจารณาภายในเกี่ยวกับรูปแบบการกำกับดูแล โดยสมาชิกจำนวนมากในชุมชนระบุว่าการตัดสินใจเกี่ยวกับทิศทางของ WordPress นั้นถูกดำเนินการเพียงฝ่ายเดียวโดย Automattic บริษัทที่ดูแล WordPress.com จุดศูนย์กลางของการรับรู้นี้คือการตัดสินใจเปิดตัว Gutenberg ซึ่งสมาชิกหลายคนไม่เห็นด้วย และขาดการสื่อสารที่เหมาะสมจากผู้นำโครงการในระหว่างการพัฒนาและการเปิดตัว ด้วยเหตุนี้ สมาชิกในชุมชนจำนวนมากจึงตั้งคำถามถึงบทบาทของ "เผด็จการที่ใจดี" ซึ่งเคยมอบให้กับ Matt Mullenweg ผู้ก่อตั้ง WordPress และ CEO ของ Automattic และค้นคว้ารูปแบบการกำกับดูแลที่แตกต่างกันเพื่อค้นหารูปแบบที่เหมาะสมกว่าสำหรับอนาคตของ WordPress ยังไม่เป็นที่ทราบแน่ชัดว่าภารกิจนี้จะให้ผลลัพธ์ใด ๆ หรือสภาพที่เป็นอยู่ยังคงดำเนินต่อไป

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

เอกสาร

เอกสารประกอบของ WordPress ในไซต์ของตัวเองไม่ครอบคลุมมากนัก แต่ทำงานได้ดีพอสมควร อย่างไรก็ตาม เมื่อพิจารณาเอกสารทั้งหมดเกี่ยวกับ WordPress จากแหล่งที่มาทั้งหมด เช่น ไซต์ทั่วไป (Smashing Magazine, CSS tricks และอื่น ๆ อีกมากมาย) ไซต์เฉพาะ (WPShout, WPBeginner และอื่น ๆ อีกมากมาย) บล็อกส่วนตัว หลักสูตรออนไลน์ เป็นต้น แทบไม่มีแง่มุมใดในการจัดการกับ WordPress ที่ยังไม่ครอบคลุม

ตุลาคม CMS ไม่ได้สนุกกับหลักสูตรของบุคคลที่สาม บทช่วยสอน หรือบล็อกโพสต์เกี่ยวกับมันมากเท่ากับ WordPress อย่างไรก็ตาม เอกสารบนเว็บไซต์มีความครอบคลุมพอสมควร และแน่นอนว่าเพียงพอที่จะเริ่มเขียนโค้ดได้ ผู้ก่อตั้งเดือนตุลาคมยังเพิ่มเอกสารใหม่ผ่านบทช่วยสอนเป็นประจำ แง่มุมหนึ่งที่ฉันชอบเป็นการส่วนตัวคือการทำซ้ำเอกสารของ Laravel ในเอกสารของเดือนตุลาคมสำหรับทุกอย่างที่เกี่ยวข้อง ดังนั้นผู้อ่านต้องไม่เติมช่องว่างด้วยตัวเองและต้องเดาว่าโดเมนของเดือนตุลาคมคืออะไรและของ Laravel คืออะไร อย่างไรก็ตาม นี่ยังไม่สมบูรณ์แบบ 100% เอกสารประกอบของเดือนตุลาคมใช้เงื่อนไขที่มาจาก Laravel เช่น มิดเดิลแวร์ ตู้คอนเทนเนอร์ ส่วนหน้า และสัญญา โดยไม่ได้อธิบายอย่างเพียงพอว่าสิ่งเหล่านี้คืออะไร จากนั้น การอ่านเอกสารของ Laravel ล่วงหน้าจะมีประโยชน์ (โชคดีที่เอกสารของ Laravel นั้นมีความครอบคลุมอย่างยิ่ง และ Laracasts ของ Laravel ก็เป็นแหล่งข้อมูลการเรียนรู้ที่ดีอีกแหล่งหนึ่ง ไม่ใช่แค่เกี่ยวกับ Laravel แต่ยังรวมถึงการพัฒนาเว็บโดยทั่วไป)

บทสรุป

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

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

ในบันทึกส่วนตัว ในฐานะนักพัฒนา สิ่งที่ฉันพบในเดือนตุลาคม CMS นั้นดึงดูดใจฉันจริงๆ ส่วนใหญ่แล้วความสามารถในการสร้างแอปพลิเคชันแบบแยกส่วนตามที่มีให้ผ่าน Laravel ฉันจะพิจารณา CMS นี้สำหรับเว็บไซต์ใหม่อย่างแน่นอน อย่างไรก็ตาม ในระหว่างการเขียนบทความนี้ ฉันยัง "ค้นพบ" WordPress อีกครั้ง เป็นที่นิยมอย่างมาก WordPress ได้รับมากกว่าส่วนแบ่งการวิพากษ์วิจารณ์โดยส่วนใหญ่เกี่ยวกับ codebase เก่าและตั้งแต่ไม่นานมานี้ก็มีการแนะนำ Gutenberg; อย่างไรก็ตาม WordPress ยังมีฟีเจอร์ที่ยอดเยี่ยมบางอย่าง (เช่น โมเดลฐานข้อมูลที่ปรับขนาดได้มาก) ซึ่งไม่ค่อยได้รับคำชมมากนัก แต่ก็ควรนำมาพิจารณาด้วย และที่สำคัญที่สุด ไม่ควรพิจารณา WordPress ในด้านทางเทคนิคเพียงอย่างเดียว โดยเฉพาะอย่างยิ่ง ขนาดของชุมชนและระบบนิเวศทำให้ WordPress อยู่เหนือทางเลือกอื่นหนึ่งหรือสองระดับ โดยสรุป บางโครงการอาจได้รับประโยชน์จากการยึดติดกับ WordPress ในขณะที่บางโครงการอาจใช้ CMS เดือนตุลาคมหรือแพลตฟอร์มอื่นได้ดีกว่า

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

• การแคชอย่างชาญฉลาดในยุคของ Gutenberg
• ปรับปรุงโค้ด WordPress ด้วย PHP สมัยใหม่
• บทเรียนที่ได้รับขณะพัฒนาปลั๊กอิน WordPress
• วิธีใช้ Heatmaps เพื่อติดตามการคลิกบนเว็บไซต์ WordPress ของคุณ
• ระวัง: ฟังก์ชัน PHP และ WordPress ที่ทำให้ไซต์ของคุณไม่ปลอดภัย