WordPress Playground: WordPress ที่ทำงานได้ครบถ้วนภายในเบราว์เซอร์

 (developer.wordpress.org)
5 คะแนน โดย GN⁺ 2023-07-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • WordPress Playground เป็นเครื่องมือออนไลน์สำหรับทดลองและเรียนรู้ WordPress ได้โดยไม่ต้องติดตั้ง และหน้านี้ทำหน้าที่เป็น ศูนย์รวมเอกสารอย่างเป็นทางการ ไม่ใช่หน้าเว็บไซต์ผลิตภัณฑ์
  • เอกสารถูกแบ่งเป็น Documentation, Blueprints, Developers และ API Reference เพื่อแนะนำวิธีเริ่มต้น การตั้งค่าผ่าน JSON การเชื่อมต่อกับโค้ด และเอกสารอ้างอิง API ตามลำดับ
  • ผู้ใช้สามารถเปิดไซต์ WordPress ใหม่ได้ภายใน 5 นาที ทดลองบล็อก ธีม และปลั๊กอิน หรือทดสอบ WordPress/PHP เวอร์ชัน ที่ต้องการได้
  • นักพัฒนาสามารถเลือกใช้ Query API, Blueprints API, JavaScript API ให้เหมาะกับเป้าหมาย และใช้ Playground เป็นสภาพแวดล้อมพัฒนาแบบโลคัลที่ไม่ต้องตั้งค่า
  • ทำงานภายในแซนด์บ็อกซ์ของเบราว์เซอร์และพึ่งพาแบ็กเอนด์หรือการยืนยันตัวตนน้อย จึงเหมาะกับเดโมต้นแบบ การทำโปรโตไทป์อย่างรวดเร็ว และสภาพแวดล้อมทดลองที่สร้างโดย AI

ศูนย์เอกสาร WordPress Playground

  • เว็บไซต์ทางการของ Playground ย้ายไปที่ wordpress.org/playground/ แล้ว และหน้านี้ถูกใช้เป็น จุดเริ่มต้นของเอกสาร
  • WordPress Playground เป็นเครื่องมือออนไลน์สำหรับทดลองและเรียนรู้ WordPress
  • เอกสารถูกจัดเป็น 4 ฮับ
    • Documentation: แนะนำ WordPress Playground คู่มือเริ่มต้น และจุดเข้าสู่เอกสาร
    • Blueprints: เอกสารของ ไฟล์ JSON ที่ใช้ตั้งค่าอินสแตนซ์ Playground
    • Developers: วิธีใช้งาน Playground จากภายในโค้ด
    • API Reference: เอกสารอ้างอิง API ทั้งหมดที่ WordPress Playground เปิดให้ใช้งาน

การเริ่มต้นและโฟลว์การพัฒนา

  • ผู้ใช้ใหม่สามารถเริ่มได้อย่างรวดเร็วจาก Quick Start Guide เพื่อสร้างไซต์ WordPress ใหม่ ทดสอบบล็อก ธีม และปลั๊กอิน หรือทดสอบ WordPress/PHP เวอร์ชันที่ต้องการ
  • Playground web instance อธิบายอินสแตนซ์ Playground ที่ให้บริการที่ https://playground.wordpress.net/
  • ใน About Playground สามารถดูข้อมูลเกี่ยวกับความปลอดภัย วิธีนำไปใช้ และข้อจำกัดในปัจจุบันของ Playground ได้
    • ผ่านเอกสาร Build, Test, Launch สามารถดูโฟลว์การใช้ Playground สำหรับการพัฒนา ตรวจสอบ และเปิดตัวผลิตภัณฑ์ได้
  • Guides เป็นเอกสารที่รวบรวมคำแนะนำแบบเป็นขั้นตอนและวิธีใช้งาน ส่วน Links and resources เป็นชุดรวมแหล่งข้อมูลที่เกี่ยวข้อง

ขั้นตอนแรกและการเลือก API

  • ขั้นตอนแรกสามารถเริ่มได้ภายใน 5 นาทีผ่าน Start using WordPress Playground และดู demo site ได้
    • นักพัฒนาสามารถเริ่มสร้างแอปแรกได้ที่ Get started for developing
    • Playground ยังสามารถใช้เป็น local development environment แบบไม่ต้องตั้งค่าได้ด้วย
    • limitations ในปัจจุบันสามารถดูได้ในเอกสารแยก
  • หากต้องการลงลึกมากขึ้น แนะนำให้ดู Playground APIs และแนวคิดพื้นฐานก่อน
    • Query API: ทำงานพื้นฐานได้ด้วยพารามิเตอร์ในคิวรีเท่านั้น
    • Blueprints API: ให้การควบคุมระดับสูงผ่าน ไฟล์ JSON แบบง่าย
    • JavaScript API: ให้การควบคุมทั้งหมดผ่าน JavaScript client ของแพ็กเกจ npm
    • สามารถดูวิธีการทำงานเชิงลึกเพิ่มเติมได้ในเอกสาร architecture

การมีส่วนร่วมและการใช้งานกับ AI

  • WordPress Playground เป็นโครงการโอเพนซอร์ส และเปิดรับการมีส่วนร่วมด้านโค้ด ดีไซน์ เอกสาร และการ triage
    • ผู้มีส่วนร่วมสามารถอ้างอิง Contributors Handbook
    • สามารถเข้าร่วมช่อง #playground บน Slack ได้ โดยข้อมูลการสมัครอยู่ที่ WordPress Slack page
    • ผู้มีส่วนร่วมทุกคนต้องปฏิบัติตาม Code of Conduct
  • Playground ถูกออกแบบมาให้ใช้งานร่วมกับ AI coding agent และเครื่องมือที่ขับเคลื่อนด้วย AI
    • รันแบบฝั่งไคลเอนต์ทั้งหมดบน WebAssembly ไม่ต้องใช้การยืนยันตัวตนหรือแบ็กเอนด์ และไม่ทิ้งผลข้างเคียงถาวรนอกแซนด์บ็อกซ์ของเบราว์เซอร์
    • Using Playground with AI agents: ใน Claude Code, Cursor, Gemini CLI, GitHub Copilot ฯลฯ สามารถติดตั้งสกิล wp-playground เพื่อมอบหมายการรันคำสั่งได้
    • AI-readable site index: สรุปแบบอ่านได้โดยเครื่องของความสามารถ API และเอกสารของ Playground ใน llms.txt
    • AGENTS.md: แนวทางสำหรับ AI coding agent ที่ร่วมพัฒนาในโค้ดเบสนี้
  • WordPress Playground เป็น ซอฟต์แวร์เสรี ภายใต้เงื่อนไขของ GNU General Public License version 2 หรือใหม่กว่า และข้อความเต็มของไลเซนส์อยู่ที่ LICENSE.md

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-15
ความคิดเห็นจาก Hacker News

  • ลองใช้บน Firefox ของแท็บเล็ต Android ราคาถูกแล้ว แม้การตอบสนองจะไม่ถึงกับฉับไว แต่ก็ไม่ได้ต่างจากการรัน LAMP stack เต็มรูปแบบ บนคลาวด์อินสแตนซ์หรือ VPS ทั่วไปมากนัก จนน่าทึ่งทีเดียว
    ในนั้นมีทั้ง PHP interpreter แบบเต็ม, โค้ดเบสของ WordPress หลายพันบรรทัด, และแม้แต่ SQLite รวมอยู่ด้วย ถึงอย่างนั้นก็ยังใช้งานได้ดีพอ ซึ่งถือว่าสุดยอดมาก

    • รู้สึกมาตลอดว่าประสิทธิภาพของ WordPress แทบไม่ต่างกันมากระหว่างฮาร์ดแวร์สเปกต่ำกับสเปกสูง สุดท้ายดูเหมือนว่า WordPress เองคือคอขวด

  • วิธีที่ทำให้สิ่งนี้ทำงานได้ถือว่าทันสมัยมาก: PHP รันเป็น ไบนารี WebAssembly, MySQL ถูกแทนที่ด้วย SQLite ผ่านปลั๊กอิน WordPress, และเว็บเซิร์ฟเวอร์ถูกสร้างด้วย Service Worker ของ JavaScript

  • จากข้อความที่ว่า “Playground รองรับทั้งแอปจดโน้ตสำหรับอุปกรณ์พกพา, สภาพแวดล้อมสำหรับการทดสอบอัตโนมัติ, ไปจนถึงเดโม WooCommerce ที่รันอยู่บนเว็บไซต์” สองอย่างหลังฟังดูเข้าใจได้หมด แต่แนวคิดเรื่องการทำ แอปมือถือที่อิง WordPress และรัน PHP ด้วย WebAssembly ภายในเบราว์เซอร์นี่ทำเอามึนไปเลย

    • แอปจดโน้ตมีอยู่จริง: https://wptavern.com/blocknotes-app-runs-wordpress-natively-...
    • ก็สมเหตุสมผลดี เพราะ PHP web stack เบากว่า Python หรือ Node มาก จึงเป็นเรื่องธรรมชาติที่จะฝังมันไว้ในเบราว์เซอร์ได้

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

    • ถ้าพูดถึงเว็บไซต์ยูทิลิตี้เล็ก ๆ อย่างเว็บวงดนตรี ก็เห็นด้วยเต็มที่ แค่เอาขึ้นโฮสติ้งราคาถูกแบบลวก ๆ แล้วหวังว่าวงจะยุบก่อนที่การเชื่อม Google Calendar จะพังก็พอแล้ว
      แต่ในฐานะคนที่กำลังผัดวันประกันพรุ่งงานย้าย SSO ของบุคคลที่สามจากเว็บ WordPress เก่าและเละ ไปยังเว็บ WordPress ใหม่ที่ก็เละพอกัน ขอบ่นหน่อยว่า ยังมี กลุ่มที่สาม อยู่จริง คือคนที่คอยดูแลบำรุงรักษาเพื่อให้กลุ่มแรกไม่ต้องสนใจเลยว่าไส้กรอกถูกทำอย่างไร
      ฉันทำงานแบบนี้มาราว 14 ปี โฮสต์เว็บไซต์ WordPress ของมหาวิทยาลัยขนาดกลางประมาณ 300 แห่ง สร้างและดูแลเว็บ .gov และเพราะทิศทางของทีม Gutenberg ก็เลยทำบล็อกแบบ React มาหลายตัวใน 3 แพตเทิร์นที่ต่างกันมาก ตั้งแต่ดีพลอยเซิร์ฟเวอร์, แก้ CSS สำหรับ IE6, ขูดข้อมูลจาก CMS ที่แทบไม่มีอยู่จริงเพื่อย้ายหลายพันหน้าและรูปภาพหลายหมื่นรูปเข้า WordPress, เขียนคำสั่ง WP-CLI, ไปจนถึงเขียนโค้ดฝืน ๆ ให้กระจายอีเวนต์ปฏิทินข้าม multisite ทั้งหมด ฉันทำมาหมดแล้ว
      ต้องมีใครสักคนที่รู้ว่าไส้กรอกทำอย่างไร และฉันคือคนนั้น เพราะงั้นฉันก็รู้ด้วยว่า WordPress เป็นกองขยะที่พร้อมพังแค่ไหน ฉันเคยทำงานกับโค้ดเบสที่มีประโยชน์จริง ใช้เครื่องมือที่ดีกว่า และมีฐานข้อมูลที่พอจะเข้าใจได้มาแล้ว ฉันก็รู้ว่าแพลตฟอร์มอื่นก็มีปัญหาเหมือนกัน แต่ WordPress แย่มากจริง ๆ
      เพราะงั้นฉันเลยด่ามันได้อย่างไม่รู้สึกผิด ตอนนี้หมดไฟสุด ๆ ถึงขั้นคิดว่าเลิกทุกอย่างไปอยู่บนรถบรรทุกแล้วเล่นดนตรีดีกว่า มันเป็นแพลตฟอร์มที่ห่วย และคนก็ไม่ค่อยอยากจ่ายเงินให้กับการทำให้มันยังพอใช้งานได้ สุดท้ายก็ยังมีคนที่เพราะสถานการณ์บังคับ ต้องกลับไปหา WordPress ที่เหมือนตึกไฟไหม้อยู่เรื่อย ๆ และความเกลียดชังร่วมกันที่มีต่อแพลตฟอร์มนี้ก็มีเหตุผลรองรับเต็มที่
    • WordPress ยอดเยี่ยมมากสำหรับกลุ่มแรกที่พูดถึงก่อนหน้านี้ ฉันมองว่ามันคล้ายกับเครื่องมืออย่าง Excel, FileMaker, และ Visual Basic ที่ช่วย ทำให้ซอฟต์แวร์เป็นประชาธิปไตย และเข้าถึงได้สำหรับทุกคน
      แน่นอนว่าเครื่องมือแบบนี้มีข้อจำกัดและปัญหาเรื่องคุณภาพ และผู้ใช้บางคนก็ต้องเจอกับมันในที่สุด ซึ่งก็ไม่เป็นไร ปัญหาเกิดขึ้นตอนที่คาดหวังให้ผู้เชี่ยวชาญมารวมระบบหรือสร้างต่อยอดบนสิ่งนี้ คนที่มาหานักพัฒนาเว็บมักมีความคาดหวังด้านคุณภาพ ปัญหาเฉพาะตัว และข้อกำหนดของตนเอง แต่ภาระตกทอดจาก WordPress กลับวางกับดักและอุปสรรคไว้มากเกินไปต่อเป้าหมายเหล่านั้น จนบ่อยครั้งกลายเป็นการเอาตะปูสี่เหลี่ยมไปยัดใส่รูวงกลม เรื่องเดียวกันนี้พูดได้กับ CRM หรือแพลตฟอร์มอีคอมเมิร์ซยอดนิยมหลายตัวเช่นกัน
    • ฉันคิดว่าตัวเองเป็นวิศวกรซอฟต์แวร์ที่จริงจังนะ แต่ก็ใช้ WordPress กับเว็บไซต์บริษัท
    • แทนที่จะหนีไปหา “โค้ดที่จัดรูปแบบสมบูรณ์แบบและขยายได้สุด ๆ” มันอาจเป็นการหยุดทำงานกับโค้ดเบสที่ไม่สมบูรณ์ในปัจจุบัน แล้วไปเริ่มโปรเจกต์ใหม่ที่คิดว่าจะสมบูรณ์แบบมากกว่า
    • ความแบ่งขั้วนี้ดูจะใกล้เคียงกับความต่างระหว่าง นักพัฒนา JavaScript แบบฟูลสแตก รุ่นใหม่ กับคนที่เติบโตมากับ PHP + MySQL มากกว่า

  • ในคีย์โน้ต State of the Word เดือนธันวาคม 2022 ตั้งใจจะพูดถึงเรื่องนี้ค่อนข้างใหญ่เลย: https://wordpress.tv/2023/01/04/matt-mullenweg-state-of-the-...
    ในฐานะวิศวกร พอได้เห็นว่ามันทำงานได้จริง แล้วลองนึกถึงทุกเลเยอร์ที่ต้องทำงานประสานกันเพื่อให้สิ่งนี้เกิดขึ้น ก็รู้สึกทึ่งมาก พออีก 6 เดือนต่อมามันกลายเป็นประเด็นดังบน HN ก็ยิ่งน่าสนใจ

    • ผมสนใจมากกับการเอาสิ่งที่จนถึงตอนนี้ถูกมองว่าเป็นแอปพลิเคชัน “ฝั่งเซิร์ฟเวอร์” มารันในเบราว์เซอร์ โดยเฉพาะอย่างยิ่งมันดูเหมือนเป็น กรณีแรกที่ SQLite ถูกนำไปรันในโปรดักชันจริง เลยยิ่งน่าสนใจ ก่อนหน้านี้ผมเห็นแต่เดโมเล่น ๆ
      พอลองไปดูโค้ดนิดหน่อยก็พบว่าตัวเองแทบไม่รู้อะไรเกี่ยวกับ PHP เลย และมันก็ดูเหมือนว่าไม่ได้ใช้แนวทาง SQLite-over-OPFS แบบ “ดั้งเดิม” เพื่อทำ persistence ด้วย พออ่านต่อก็ยังไม่ชัดเจนว่าตอนนี้ persistence storage ผ่าน Emscripten ยังทำได้หรือเปล่า สุดท้ายผมไปเจอ https://github.com/WordPress/wordpress-playground/issues/19 ซึ่งดูเหมือนจะหมายความว่าในตอนนี้ WordPress ในเบราว์เซอร์ยัง ไม่สามารถทำ persistence ได้ ก็น่าเสียดาย
    • การนำเสนอดีมาก ใครสนใจ WordPress Playground เริ่มแนะนำตั้งแต่นาที 48:33

  • สงสัยล้วน ๆ เลยนะ ถ้ายังไม่คิดเรื่องฐานข้อมูล นี่หมายความว่าสามารถรัน WordPress บน Cloudflare Worker ได้ใช่ไหม? https://developers.cloudflare.com/workers/runtime-apis/webas...

    • ทีมนี้เคยพยายาม deploy ไปที่ Cloudflare แต่ติดที่ ข้อจำกัดหน่วยความจำ 128MB ของ Workers: https://github.com/WordPress/wordpress-playground/issues/69
      ถึงอย่างนั้นก็ดูเหมือนว่ายังมีช่องทางที่จะทำให้เป็นไปได้ และ Cloudflare เองก็อาจเพิ่มเพดานได้
    • ไม่แน่ใจ 100% แต่ก็ดูมีความเป็นไปได้ แล้วก็มีอันนี้ที่เกี่ยวข้องด้วย: https://ma.rkusa.st/store-sqlite-in-cloudflare-durable-objec... และ https://developers.cloudflare.com/d1/
      เพราะงั้นก็น่าจะพอทำให้มันใช้งานได้

  • ผมใช้ WordPress กับหลายเว็บที่เกือบเป็น static อยู่บ่อย ๆ มันเหมาะมากสำหรับให้คนที่ไม่ใช่สายเทคนิคเพิ่มคอนเทนต์ต่อเนื่อง และสำหรับจุดประสงค์นี้ก็แทบไม่มีทางเลือกไหนที่ใกล้เคียง WordPress
    แต่ก็ต้องเลือกปลั๊กอินที่ใช้ให้รอบคอบ ตั้งค่า Cloudflare frontend ให้เหมาะสม และกันไม่ให้ผู้ใช้ทำอะไรที่ดูเหมือนง่ายแต่จริง ๆ อันตราย ความเกลียด WordPress ส่วนใหญ่ที่เห็นกันให้ความรู้สึกว่ามาจากคนที่เคยใช้มันเมื่อนานมากแล้ว หรือมีความต้องการที่ WordPress ตอบไม่ได้ หรือ ต้องรับช่วงระบบ legacy มา

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

  • Playground ที่รัน PHP บน WASM นี้ ตอบสนองเร็ว กว่าเว็บไซต์ทั่วไป 95% เสียอีก

    • จุดที่เจ๋งที่สุดตรงนี้คือมันลดการไปกลับกับเซิร์ฟเวอร์ลงอย่างมหาศาล ทั้งการเรียกฐานข้อมูลและการขอ asset ทุกอย่างเกิดขึ้นบนไคลเอนต์ แน่นอนว่าต้องยอมรับเวลาโหลดระดับไม่กี่วินาที
      WordPress น่าจะเป็นโซลูชันแบบ multi-page application ที่ถูกใช้งานมากที่สุด แต่สิ่งนี้แทบจะเปลี่ยนมันให้กลายเป็น single-page application ไปเลย แถมยังทำงานได้ดีกว่า single-page application ส่วนใหญ่ด้วย เพราะไม่ต้องคอยส่ง API request ไปที่เซิร์ฟเวอร์ตลอดเวลา
      ส่วนที่เป็น single-page application อย่างตัวแก้ไขโพสต์/หน้า และตัวแก้ไขไซต์ เป็นแอป React ที่ซับซ้อน แต่ในเดโมนี้กลับรู้สึกว่าลื่นไหลกว่าสภาพแวดล้อมพัฒนาแบบโลคัลเสียอีก มันแสดงให้เห็นชัดเจนว่าพอเอาการไปกลับกับเซิร์ฟเวอร์ออกไปแล้ว single-page application จะดีขึ้นได้แค่ไหน อ้างอิงไว้ก่อนว่าผมทำงานที่ Automattic และการได้เฝ้าดูการทดลองนี้มันยอดเยี่ยมมาก

  • ไม่ได้จำเป็นต้องลดค่าความเป็น WordPress ลง แต่ก็มีประวัติยาวนานและมีปัญหามากพอสมควร ถ้ามีทางเลือกแบบ self-hosted สมัยใหม่ที่ใช้ได้โดยไม่ต้อง สร้างไซต์แบบสแตติก หรือไม่ต้องมีโฮสติ้งที่ซับซ้อนก็คงดี

    • ไม่ว่าคู่แข่งรายไหนก็ต้องข้ามปัญหาแบบ ไก่กับไข่ ที่หนักมากไปให้ได้ WordPress มีปลั๊กอินที่ทำได้แทบทุกอย่าง และโดยมากก็มีซัพพอร์ตแบบเสียเงินด้วย เลยหลีกเลี่ยงได้ยาก
      ตัวโค้ดเบสไม่ค่อยดี การพัฒนาบนมันก็ชวนทรมาน และทั้งแนวทางการออกแบบกับการดูแลสโตร์ทางการก็ไม่ได้ช่วยป้องกันความสับสนและความเสี่ยงฝั่งฐานข้อมูลได้ ถึงอย่างนั้น ข้อเสนอแบบ “ตั้งค่า 2 วันแล้วจ่ายค่าปลั๊กอิน/ธีมเดือนละ 80 ดอลลาร์” ก็ขายได้ง่ายกว่ามากเมื่อเทียบกับ “ได้ครับ แต่ก่อนอื่นต้องใช้เวลาพัฒนาอย่างน้อย 2 เดือน”
      ต่อให้ต้องมีงานพัฒนาเพิ่ม ก็หาคนที่มีประสบการณ์พัฒนา WordPress ได้ง่าย และถ้าไม่อยากจ้างเองก็มีเอเจนซีที่เชี่ยวชาญ WordPress อยู่มากมาย คู่แข่งหน้าใหม่ไม่มีข้อได้เปรียบด้านขนาดแบบนี้ การออกแบบระบบที่ขยายต่อได้พร้อมโครงสร้างปลั๊กอินและธีมให้ดีกว่า WordPress มาก ๆ ไม่ใช่งานเล็ก แต่ก็ไม่ถึงกับเป็นไปไม่ได้หรือจำเป็นต้องใช้ทีมอัจฉริยะ อย่างไรก็ตาม บนเส้นทางการแย่งตลาดจาก WordPress นั่นกลับเป็นขั้นที่ง่ายที่สุด
    • มีตัวแทนที่ทดแทนได้ครบฟังก์ชันอยู่มากมาย แต่คุณค่าที่แท้จริงของ WordPress คือ ระบบนิเวศปลั๊กอิน, กลุ่มนักพัฒนา, และฐานผู้ใช้ที่สนับสนุน
      ใคร ๆ ก็คงเคยเจอลูกค้าที่ต้องการแค่ WordPress และไม่เอาอย่างอื่น ต่อให้ปล่อยโซลูชันใหม่ที่ดูสะอาดกว่า ลูกค้าหลายรายก็ยังกลับไปใช้ WordPress อยู่ดี สำหรับแนวทางแบบไฮบริดที่ให้ข้อกำหนดซับซ้อนทำด้วย custom app บนเฟรมเวิร์กอื่น แล้วจัดการคอนเทนต์ผ่าน WordPress instance กับคอนเน็กเตอร์ ก็ถือว่าเห็นคุณค่าอยู่
    • เหตุผลที่ WordPress ประสบความสำเร็จจนถึงทุกวันนี้คือ ในช่วงหลายปีที่ CMS อื่น ๆ ทำ API พังซ้ำแล้วซ้ำเล่า WordPress กลับรักษาความเสถียรไว้ได้เป็นส่วนใหญ่ และนั่นทำให้ ระบบนิเวศปลั๊กอิน ขนาดใหญ่เติบโตขึ้นมา
      อีกอย่างคือ PHP API ของ WordPress แทบไม่ใช้แนวคิดเชิงวัตถุ และส่วนใหญ่เป็นฟังก์ชันกับอาร์เรย์ คนที่รู้แค่พื้นฐานการเขียนโปรแกรมมาก ๆ ก็ยังทำปลั๊กอินหรือธีมเองได้
    • CMS ที่นักพัฒนาอยากร่วมงานด้วย กับ CMS ที่บริษัทอยากใช้นั้นเป็นคนละแบบกัน ถ้าจะเข้าไปอยู่ในกลุ่มหลัง ก็ต้องยอมรับ การเลือกแบบปฏิบัตินิยม หลายอย่างที่ทำให้ห่างจากแบบแรก
      บริษัทชอบของที่อยู่รอดมานาน และตามนิยามแล้วของพวกนั้นก็มักจะล้าสมัย
    • อยู่ที่นี่: https://github.com/Qbix/Platform

  • เทคโนโลยีเบื้องหลังเดโมนี้เจ๋งมาก อยากให้ดู ล็อก error/warning ของ PHP แบบเรียลไทม์ ได้ และอยากลองเช็กด้วยว่า simulator นี้สมบูรณ์แค่ไหน โดยเฉพาะเมื่อรวมถึงการเขียนฐานข้อมูล SQLite ใหม่
    การทดสอบปลั๊กอินหรือธีมก็ง่ายมาก แค่เพิ่ม &plugin=plugin-slug-from-dir เข้าไปก็พอ และถ้า slug ตรงกับ plugin slug ใน URL ของ WordPress.org ระบบจะดาวน์โหลดอัตโนมัติแล้วเพิ่มเข้า sandbox ให้ เอกสารของ Query API ทั้งหมดสำหรับการกำหนดค่า sandbox อยู่ที่นี่: https://wordpress.github.io/wordpress-playground/query-api/
    มั่นใจว่าต้องมีวิธีเปิดหรือแสดง debug log แน่ ๆ ไม่งั้นก็คงพัฒนาสิ่งนี้ขึ้นมาไม่ได้