Jeffgeerling.com ย้ายมาใช้ Hugo

 (jeffgeerling.com)
2 คะแนน โดย GN⁺ 2026-01-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • JeffGeerling.com ซึ่งรันบน Drupal มาตั้งแต่ปี 2009 ได้เปลี่ยนมาใช้ Hugo static site generator (SSG) เพื่อเพิ่มประสิทธิภาพในการดูแลบล็อกส่วนตัว
  • ภาระจาก การอัปเกรดและบำรุงรักษา จำนวนมากตั้งแต่ Drupal 6 ถึง 10 เป็นแรงจูงใจสำคัญของการย้ายครั้งนี้
  • Hugo รองรับการเขียนแบบ Markdown ทำให้ขั้นตอนการเผยแพร่ที่เคยซับซ้อนง่ายขึ้น และสามารถจัดการขั้นตอนโพสต์และดีพลอยได้ด้วยคำสั่งเพียงบรรทัดเดียว
  • ระหว่างการย้ายระบบ อาจเกิดปัญหาบางส่วน เช่น ลิงก์รูปภาพผิดพลาด, URL สูญหาย และฟีเจอร์คอมเมนต์กับการค้นหาจะถูกนำกลับมาในภายหลัง
  • นี่เป็นตัวอย่างที่แสดงให้เห็นถึงข้อดีเชิงปฏิบัติของการย้ายไปใช้เว็บไซต์แบบสแตติก สำหรับนักพัฒนาเดี่ยวที่ต้องการ เวิร์กโฟลว์ที่กระชับและดูแลรักษาง่ายขึ้น

เบื้องหลังการย้ายจาก Drupal ไปสู่ Hugo

  • เว็บไซต์นี้เริ่มต้นบน Drupal 6 ตั้งแต่ปี 2009 และค่อย ๆ อัปเกรดผ่าน 7, 8, 9 และ 10
    • ผู้เขียนนำ CMS ที่ใช้ในงานอาชีพมากว่า 10 ปีมาใช้กับบล็อกส่วนตัวด้วย
  • หลังผ่าน กระบวนการอัปเกรดที่ซับซ้อน จาก Drupal 7 ไป 8 ความเหนื่อยล้าจากการต้องดูแล Digital Experience Platform (DXP) ระดับองค์กรบนบล็อกส่วนตัวก็สะสมมากขึ้น
  • บล็อกนี้ถูกใช้เป็น พื้นที่เสริมสำหรับโปรเจกต์ส่วนตัวและคอนเทนต์บน YouTube และจึงตัดสินใจย้ายเพื่อให้โฟกัสกับการเขียนมากกว่าการดูแล CMS

เหตุผลที่เลือก Hugo

  • ก่อนหน้านี้เคยมีประสบการณ์ย้ายเว็บไซต์งานอดิเรกไปยัง static hosting มาแล้ว และบางส่วนก็แปลงเป็น Jekyll หรือ Hugo
  • Jekyll เหมาะกับ GitHub Pages แต่ในฐานะที่ไม่ได้เชี่ยวชาญ Ruby ผู้เขียนจึงชอบ การตั้งค่าที่เรียบง่ายและความเร็วสูงของ Hugo มากกว่า
  • Hugo รองรับ Markdown เป็นพื้นฐาน และเชื่อมเข้ากับวิธีการเขียนเดิมได้อย่างเป็นธรรมชาติ

กระบวนการย้ายและปัญหาที่พบ

  • งานย้ายระบบกำลังดำเนินอยู่ใน GitHub issue #158
  • ด้วยจำนวน โพสต์มากกว่า 3,500 รายการ และข้อมูลสะสมตลอด 20 ปี จึงมีโอกาสเกิด รูปภาพเสีย, ลิงก์ผิดพลาด, รีไดเร็กต์ตกหล่น บางส่วน
  • ผู้เขียนกำลังพยายามรักษาโครงสร้าง URL เดิมให้ได้มากที่สุด หรือเพิ่มรีไดเร็กต์ในจุดที่จำเป็น

การปรับปรุงเวิร์กโฟลว์ด้วย Markdown

  • ตั้งแต่ปี 2020 เป็นต้นมา ทุกโพสต์ถูกเขียนด้วย Markdown
    • ก่อนหน้านี้จะเขียน Markdown ใน Sublime Text แล้วแปลงเป็น HTML ก่อนอัปโหลดเข้า Drupal แบบแมนนวล
  • บน Drupal การเขียนโพสต์ต้องผ่านหลายขั้นตอน
    • วางเนื้อหา, อัปโหลดและแทรกรูปทีละภาพ, แก้วันที่เผยแพร่, ล้างแคช ฯลฯ
    • รวมถึงการจัดการ Cloudflare cache เพื่อรับมือ DDoS ทำให้กระบวนการยิ่งซับซ้อน
  • บน Hugo สามารถเขียนไฟล์ Markdown แล้วเผยแพร่ได้ทันทีด้วยคำสั่ง hugo && git commit && git push
  • ภาระการดูแลเซิร์ฟเวอร์อย่าง Composer, Drush, PHP, MariaDB, Nginx ฯลฯ หายไป ทำให้การบำรุงรักษามีประสิทธิภาพขึ้น

แผนต่อไป (TODOs)

  • ฟีเจอร์ คอมเมนต์ จะถูกนำกลับมาในเฟส 2 ด้วยระบบคอมเมนต์แบบสแตติกที่โฮสต์เอง
    • งานที่เกี่ยวข้องกำลังดำเนินใน GitHub issue #167
  • ฟีเจอร์ ค้นหาในเว็บไซต์ เดิมใช้ Apache Solr แต่ตอนนี้ถูกปิดไว้ชั่วคราว
    • แนวทางทำระบบค้นหาใน Hugo กำลังถูกพิจารณาใน issue #168
  • ในช่วงแรกของการย้าย คอมเมนต์จะยังถูกปิดใช้งาน และ การย้ายงานเดิมจะใช้เวลาอีกระยะหนึ่ง

ความหมายของการย้ายครั้งนี้

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

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

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

 
GN⁺ 2026-01-06
ความคิดเห็นจาก Hacker News

  • เมื่อหลายปีก่อน ฉันย้ายเว็บไซต์ส่วนตัวไปใช้ ตัวสร้างเว็บไซต์แบบสแตติกที่พัฒนาด้วย Common Lisp ซึ่งฉันเขียนเอง
    ตอนแรกมีประมาณ 850 บรรทัด ตอนนี้โตเป็นราว 1500 บรรทัดแล้ว และเรนเดอร์เกือบทุกอย่างแบบสแตติก ไม่ว่าจะเป็นบล็อกโพสต์ สมุดเยี่ยม หน้าแสดงความคิดเห็น ฟีด RSS แยกตามแท็ก ฯลฯ
    ฉันเขียนโค้ดทั้งหมดรวมถึง HTML และ CSS เองด้วยมือ เพื่อรักษาการควบคุมด้านความงามของเว็บไว้ได้เต็มที่ และเพิ่มฟีเจอร์ใหม่ก็ทำได้เร็ว
    ตัวอย่างเช่น การเพิ่มหน้า “backlinks” ใช้โค้ด CL แค่ราว 40 บรรทัดกับเวลา 15 นาทีก็พอ
    ตอนนี้มันเสถียรมากจนแทบไม่ต้องแตะอะไรอีก และฉันโฟกัสกับการเขียนได้อย่างเดียว

    • สำหรับนิสัยแบบฉัน บล็อกที่ self-host กลับเป็นปัญหา
      ฉันใช้เวลาไปกับการจูนเอนจินบล็อกจนสุดท้ายไม่ได้เขียนอะไรเลย
      เลยตั้งใจกลับไปใช้โฮสติ้งโซลูชันที่ควบคุมได้น้อยกว่า ตอนนี้จึงโฟกัสกับการเขียนได้อย่างเดียว
    • ฉันเองก็ชอบ อิสระและความเสถียร ของ static site generator ที่ทำมาเพื่อจุดประสงค์เดียว
      เมื่อก่อนฉันดูแลโปรเจ็กต์โอเพนซอร์สชื่อ Tclssg และด้วยฟีดแบ็กจากผู้ใช้ก็ได้เพิ่มทั้งเอกสารและฟีเจอร์อีกมาก
      แต่พอเป็นโปรเจ็กต์สาธารณะ ก็ปรับโครงสร้างตามใจได้ยาก
      ตอนนี้ฉันใช้ตัวสร้างสำหรับเว็บตัวเองโดยเฉพาะที่ประกอบด้วย Python (900 บรรทัด) + Pandoc Lua (700 บรรทัด)
      ประวัติวิวัฒนาการทางเทคนิคสรุปไว้ที่ เว็บไซต์ของฉัน
    • ฉันก็ทำแบบเดียวกัน เคยพอร์ตเว็บ taoofmac.com ไปเป็น Hy แล้วก็เขียนใหม่กลับมาเป็น Python
      ตอนนี้กำลังทำใหม่อีกครั้งด้วย TypeScript/Bun และยังคงมี องค์ประกอบแบบ LISP อยู่
      ฉันกำลังมองหาภาษา LISP/Scheme dialect ขนาดเบาที่มี SQLite และ HTML parsing ในตัว และคอมไพล์เป็น native ได้
      รายละเอียดอยู่ ที่นี่
    • ฉันก็ทำแบบเดียวกัน โดย เขียนตัวสร้างเว็บไซต์ด้วย Go
      ผ่านมาหลายปีก็ยัง build ทั้งเว็บได้ภายในไม่ถึง 1 วินาที
      ฉันใส่ทั้งฟีเจอร์ RSS feed และ code highlighting เอง โดยใช้ Chroma กับ Blackfriday
      ฉันเคยลองใช้ Hugo แต่ซับซ้อนเกินไป เลยทำเองดีกว่า
    • สงสัยว่าบนบล็อกแบบสแตติกจัดการ คอมเมนต์ กันอย่างไร

  • เมื่อก่อนฉันย้ายจาก svbtle มา Hugo แต่พูดตรง ๆ ว่า เสียใจ
    ฉัน fork ธีมมาใช้ แต่ Hugo พังบ่อยจนเสียเวลากับการดูแลรักษามากเกินไป
    ตอนนี้เว็บถึงขั้น build ไม่ได้เลย
    ถ้าจะให้แนะนำ ควรเก็บ เวอร์ชันไบนารี ที่ใช้ build เว็บไว้ใน source control ด้วย

    • ฉันเพิ่งตระหนักว่าซอฟต์แวร์บางอย่างไม่จำเป็นต้องอัปเดตเสมอไป
      static site generator แทบไม่มีประเด็นด้านความปลอดภัย ดังนั้นถ้าไม่ได้ต้องการฟีเจอร์ใหม่ ก็ใช้ เวอร์ชันเก่าเดิม ต่อไปได้
      ตราบใดที่ระบบปฏิบัติการหรือ CPU ไม่เปลี่ยนไปมาก ก็มักไม่มีปัญหา
    • แค่ระบุเวอร์ชันไว้ใน CI config ก็พอ
      ฉันเองก็ pin เวอร์ชันโดยอ้างอิง การตั้งค่านี้
      ตอนหาว่าเวอร์ชันไหนใช้ได้ การใช้ binary search จะมีประสิทธิภาพที่สุด
    • ฉันแก้ปัญหาด้วย Docker image แบบคัสตอม
      พอทั้งบนเครื่อง local และใน CI ใช้ Hugo เวอร์ชันเดียวกัน ก็แทบไม่เจอปัญหา
    • ถ้าใช้ไบนารีแบบ off-the-shelf ก็แค่ใส่ไว้ที่ ${project}/bin/ แล้วใส่ใน .gitignore จากนั้นบันทึก checksum ลงในไฟล์ SHA256SUMS
      วิธีนี้คล้าย Git LFS เวอร์ชันเรียบง่าย
    • ฉันก็เจอปัญหาเดียวกันกับ Jekyll
      เวลาเปลี่ยนไปใช้คอมเครื่องใหม่จะกลัวเรื่องให้เวอร์ชันตรงกัน และสุดท้ายกำลังพอร์ตไป PHP แต่ยังทำไม่เสร็จ

  • ถ้าเป็นคนที่เขียนบทความด้วย Markdown อยู่แล้ว การย้ายไป Hugo ก็สมเหตุสมผล
    ฉันเองก็ย้ายโพสต์ Jekyll กว่า 500 โพสต์มา Hugo และสิ่งที่ยากที่สุดคือ syntax ของเทมเพลต
    แต่โดยรวมแล้วก็คุ้มค่า
    ฉันสรุปขั้นตอนย้ายและสคริปต์แปลงอัตโนมัติไว้ใน บล็อกโพสต์

    • อยากรู้ว่าทำไมถึงย้ายจาก Jekyll ไป Hugo เพราะฉันก็ยังพอใจกับ Jekyll มาก

  • SSG นั้นดีสำหรับ เว็บไซต์แบบสแตติก แต่ถ้าต้องมีปฏิสัมพันธ์ก็ต้องมีเซิร์ฟเวอร์อยู่ดี
    ในเมื่อยังไงก็ต้องรันเซิร์ฟเวอร์อยู่แล้ว การเรนเดอร์ Markdown แบบไดนามิกอาจจะง่ายกว่า
    สุดท้าย SSG ก็แค่เพิ่ม dependency และจุดที่พังได้
    ฉันคิดว่า Jeff น่าจะมานั่งเสียใจทีหลังตอนอยากเพิ่มฟีเจอร์อย่างคอมเมนต์
    สำหรับฉัน เซิร์ฟเวอร์เรียบง่ายที่ใช้ SSR คือทางออกที่สมจริงกว่า

    • แต่ถ้ามีผู้เข้าชมหรือบอตเยอะขึ้น เซิร์ฟเวอร์ก็อาจล่มได้
      หน้าแบบสแตติกไม่มีความเสี่ยงแบบนั้น และทราฟฟิกส่วนใหญ่ก็เป็นแบบอ่านอย่างเดียว
      ดูเหมือน Jeff เองก็กำลังจะทำฟีเจอร์คอมเมนต์ด้วยตัวเองตาม issue
    • ฉันเองก็รันทั้ง เครื่องมือวิเคราะห์แบบ self-host และระบบคอมเมนต์เองอยู่
      ขนาดโค้ดเล็กและเรียบง่ายกว่าตอนใช้ Drupal มาก
    • static site generator จริง ๆ แล้วเป็นการ ลด dependency มากกว่า
    • ฉันใช้ SSG สำหรับหน้าแบบสแตติก และใช้เซิร์ฟเวอร์ Common Lisp + Hunchentoot สำหรับคอมเมนต์
    • ฉันก็เปลี่ยนเว็บไปใช้ SSG และไม่เสียใจเลย กลับรู้สึกว่ายิ่งเรียบง่ายยิ่งดี

  • อยากรู้ กระบวนการตัดสินใจ ตอนเลือก SSG
    มีเครื่องมือหลักหลายตัวทั้ง Hugo, Eleventy, Jekyll ฯลฯ และโดยเฉพาะ Hugo ก็ดูจะมี การเปลี่ยนที่ทำให้เข้ากันไม่ได้ บ่อย
    ถ้าเป็นโปรเจ็กต์เก่า ฉันคิดว่าตอนนี้ควรให้เสถียรภาพได้แล้ว

    • ในความเป็นจริง Hugo เพิ่งยกเครื่องระบบเทมเพลตครั้งใหญ่ใน v0.146
      ซึ่งทำให้บล็อกของฉัน build พัง และเอกสาร ก็ยังอัปเดตไม่ครบ
      การเปลี่ยนแปลงตัวมันเองไม่ใช่ปัญหา แต่ปัญหาคือเอกสารตามไม่ทัน

  • ช่วงนี้สงสัยว่า Pelican เป็นอย่างไรบ้าง ในฝั่ง Python ดูเหมือน Hugo กับ Pelican จะเป็นสองตัวหลัก
    บางทีก็รู้สึกว่าการรวมกับ ActivityPub น่าสนใจกว่า RSS

    • ฉันใช้ Pelican และพอใจมาก
      ก่อนหน้านี้เคยใช้ Nikola แต่ dependency เยอะเกินไปและมีปัญหา incremental build ไม่สอดคล้องกัน
      Pelican ดีตรงที่ยังคงความเรียบง่ายไว้ได้
    • ฉันเองก็ใช้ Pelican มาหลายปีแล้ว
      ให้ความรู้สึกว่าเอกสารเสร็จไปประมาณ 90% จึงยังขาดรายละเอียดเล็ก ๆ น้อย ๆ แต่ถ้าใช้แค่ฟีเจอร์พื้นฐานก็ยอดเยี่ยมมาก
    • ฉันติด ปลั๊กอินที่เขียนเอง หลายตัวเข้ากับ Pelican แล้วใช้งานอยู่
      โปรเจ็กต์ยังมีคอมมิตทุกเดือน แปลว่ายังมีชีวิตอยู่
    • ถ้าคุณรู้ Python อยู่แล้ว Pelican ก็เป็นตัวเลือกที่เป็นธรรมชาติที่สุด

  • ตอนนี้ฉันกำลังจะย้ายจาก Hugo ไป Zola
    การตั้งค่าและเทมเพลตของ Zola ให้ความรู้สึกตรงไปตรงมามากกว่า

    • ฉันก็ย้ายจาก Jekyll ไป Zola และไม่เสียใจเลย
      ฉันใช้ GitHub Actions ทำให้การ build และ deploy เป็นอัตโนมัติ
    • ถ้า requirement ไม่เยอะ ชุด Zola + gist นั้นเรียบง่ายและลงตัวดี

  • ฉันใช้ Hugo มา 3 ปีแล้ว
    สิ่งที่เรียนรู้คือให้ fork ธีมมาดูแลเอง
    หลีกเลี่ยง submodule และค่อย ๆ อัปเดตจะดีกว่า
    ฟีเจอร์คอมเมนต์ยังดูยุ่งยากอยู่ดี

    • จริง ธีมสุดท้ายก็แตกต่างกันไปตามแต่ละเว็บ
      ฉันเองก็เคยพยายามย้ายธีม Drupal แต่สุดท้ายยอมแพ้
      ฉันคิดว่าการรวมโค้ดมาไว้ตรง ๆ แล้ว override เฉพาะส่วนที่ต้องใช้ ดีกว่าใช้ submodule

  • ปีที่แล้วฉันเริ่มบล็อกด้วย Hugo แต่จาก 18 โพสต์ มีถึง 3 ใน 4 ที่ต้องปวดหัวกับ ข้อผิดพลาดตอน build
    มันไม่เสถียรเกินไปจนทำให้ผิดหวัง

    • ฉันก็ย้ายจาก Hugo ไปใช้ Python SSG ที่เขียนเอง
      แทนที่จะเสียเวลาทำความคุ้นเคยกับวิธีของ Hugo ฉันกลับรู้สึกว่าสะดวกกว่ามากถ้าทำมันอย่างรวดเร็วด้วยภาษาที่ตัวเองรู้

  • เมื่อก่อนฉันเคยทำ SSG แบบง่าย ๆ เอง แต่ช่วงหลังอยากได้อะไรที่เป็นระบบมากขึ้นเลยลองใช้ 11ty
    แต่ เทมเพลต Liquid ใช้งานลำบากมาก
    ฉันอยากใช้เทมเพลตแบบ JSX แต่ 11ty กลับทำให้เรื่องนั้นยาก
    NextJS SSG มีฟีเจอร์เยอะก็จริง แต่ซับซ้อนเกินไปจนรู้สึกเกินความจำเป็น
    ตอนนี้กำลังคิดจะสร้าง SSG แบบคัสตอมบนเฟรมเวิร์กอย่าง Tempest

    • Eleventy รองรับ ภาษาเทมเพลตแบบคลาสสิก อย่าง Mustache ด้วย
      ฉันเองก็ย้ายเว็บที่ใช้ Punch ไป Eleventy และถ้าความเร็ว build พอรับได้ ก็รู้สึกว่ามันดีกว่า Hugo
      ตอนนี้ฉันทำเว็บใหม่ด้วย Astro แล้ว
    • เราเพิ่งย้ายเว็บไซต์การตลาดของสตาร์ตอัปจาก NextJS ไป Astro และพอใจมาก
      มันมีแนวคิดแบบ static-first แต่ก็ยังใช้แบ็กเอนด์ลอจิกได้เมื่อจำเป็น
      NextJS ซับซ้อนเกินไปสำหรับเว็บไซต์ที่เรียบง่าย