ໃຊ້ຫນ້າອັນບໍລິສຸດເພື່ອສ້າງ blog "dynamic + article" ຫຼາຍພາສາ

ຂ້ອຍເຮັດໃຫ້ເວັບໄຊທ໌ຂອງຂ້ອຍເປັນ "dynamic + article" blog ຫຼາຍພາສາ: ເນື້ອຫາຖືກຈັດການດ້ວຍ Markdown, ການແປພາສາແມ່ນສໍາເລັດເມື່ອການປະກາດ, ຫນ້າຄົງທີ່ຖືກສ້າງຂຶ້ນໃນລະຫວ່າງການກໍ່ສ້າງ, ແລະຕົວທ່ອງເວັບແມ່ນຮັບຜິດຊອບສໍາລັບການອ່ານແລະປ່ຽນພາສາ. ບົດຄວາມນີ້ຈະທໍາລາຍຮູບແບບເນື້ອຫາ, ທໍ່ຮ່ວມກັນ, ການຄ້າລະຫວ່າງການໂຫຼດຕາມຄວາມຕ້ອງການແລະ SEO, ແລະສິ່ງທີ່ແນ່ນອນດ້ານຫນ້າທີ່ບໍລິສຸດຈະຊ່ວຍປະຢັດ.

2026/10/04 · ອ່ານ 1 ນາທີ

ຫນັງສືໃບລານຖືກແບ່ງອອກເປັນການປັບປຸງສັ້ນແລະບົດຄວາມຍາວ, ແລະຫຼັງຈາກນັ້ນເຊື່ອມຕໍ່ກັບຫນ້າຕົວທ່ອງເວັບໃນຫລາຍພາສາ.

ຂ້າພະເຈົ້າຫວັງວ່າເວັບໄຊທ໌ຂອງຂ້ອຍສາມາດຖືກນໍາໃຊ້ເພື່ອຂຽນຫຍໍ້ຫນ້າຂອງຄວາມຄິດ, ຫຼືຂຽນບັນຫາດ້ານວິຊາການຢ່າງສົມບູນຢ່າງຈະແຈ້ງ. ເອົາ "dynamics" ໃນສັ້ນຫນຶ່ງແລະ "ບົດຄວາມ" ໃນຫນຶ່ງຍາວ. ທັງສອງສາມາດເຊື່ອມຕໍ່ກັນໄດ້, ແລະເມື່ອຜູ້ເຂົ້າຊົມປ່ຽນພາສາ, ເນື້ອຫາຕ້ອງຖືກສະຫຼັບກັນ.

ຄວາມຕ້ອງການນີ້ເບິ່ງຄືວ່າເປັນເລື່ອງທໍາມະດາຫຼາຍ, ແຕ່ຖ້າທ່ານເພີ່ມຖານຂໍ້ມູນ, backend ແລະ API ເນື້ອຫາໃນຕອນເລີ່ມຕົ້ນ, ແລະຫຼັງຈາກນັ້ນຈັດການສະບັບຂອງແຕ່ລະພາສາ, ມັນຈະກາຍເປັນອີກຜະລິດຕະພັນຫນຶ່ງທີ່ຕ້ອງການການບໍາລຸງຮັກສາໄລຍະຍາວ.

ຂ້າພະເຈົ້າໄດ້ເລືອກທໍາອິດຈໍາກັດຄວາມຕ້ອງການກັບສິ່ງທີ່ຂ້ອຍສາມາດນໍາໃຊ້ໄດ້ຢ່າງແທ້ຈິງ: ** ຜູ້ຂຽນຫນຶ່ງ, ເຂົ້າໄປໃນ Git, ແລະສ້າງເວັບໄຊທ໌ໃຫມ່ຫຼັງຈາກການເຜີຍແຜ່. ຜູ້ອ່ານພຽງແຕ່ຕ້ອງການໄຟລ໌ຄົງທີ່ແລະຕົວທ່ອງເວັບ. ** ນີ້ແມ່ນໂຄງສ້າງ "dynamic + article" ໃນປະຈຸບັນຂອງ stephen.taipei.

pure front-end ຫມາຍເຖິງການອ່ານທ້າຍ

ໃຫ້ພວກເຮົາສ້າງຂອບເຂດທີ່ຈະແຈ້ງກ່ອນ. ໂຄງການນີ້ໃຊ້ React, Vite ແລະ Tailwind. Node.js ຍັງຕ້ອງການສໍາລັບການປຸງແຕ່ງເນື້ອຫາ, ການແປງຮູບພາບແລະການສ້າງສະຄິບ; ການແປຍັງຈະໂທຫາບໍລິການພາຍນອກໃນລະຫວ່າງຂັ້ນຕອນການພິມເຜີຍແຜ່. ຫຼັງຈາກການນໍາໃຊ້, ໄຟລ໌ຄົງທີ່ແມ່ນສະຫນອງໃຫ້ໂດຍ Nginx.

ດັ່ງນັ້ນສິ່ງທີ່ຂ້ອຍຫມາຍເຖິງໂດຍຫນ້າອັນບໍລິສຸດແມ່ນວ່າເມື່ອຜູ້ອ່ານເປີດເວັບໄຊທ໌, ພວກເຂົາບໍ່ຕ້ອງການ Blog back-end ພິເສດເພື່ອຄົ້ນຫາຂໍ້ມູນ, ຫນ້າກຸ່ມຫຼືແປໃນເວລາທີ່ແທ້ຈິງ. ມັນມີຂະບວນການສ້າງແລະໂຮດ, ແຕ່ບໍ່ມີຄໍາຮ້ອງສະຫມັກ API ຫຼືຖານຂໍ້ມູນທີ່ຍັງຄົງຄ້າງສໍາລັບການອ່ານບົດຄວາມ.

ຖ້າວຽກງານຖືກເຮັດລ່ວງຫນ້າ, ສິ້ນສຸດການອ່ານຈະງ່າຍຂຶ້ນຫຼາຍ.

ຂ່າວແລະບົດຄວາມແບ່ງປັນແຫຼ່ງດຽວກັນ, ແຕ່ລະຄົນມີຮູບແບບຂອງຕົນເອງ

ເນື້ອໃນແມ່ນສຸມໃສ່ content/, ແລະຂໍ້ຄວາມຕົ້ນສະບັບແມ່ນ Markdown ທັງໝົດ. ທັງສອງເນື້ອໃນແມ່ນບໍ່ໄດ້ shoehorned ເປັນຮູບແບບດຽວກັນ:

content/
  tags.yaml
  tags.locales.yaml
  notes/2026/20261004-0944.md
  notes/2026/20261004-0944.locales.yaml
  articles/frontend-only-multilingual-blog/
    index.md
    locales.yaml
    cover.webp

Dynamics ແມ່ນບັດສັ້ນ. ຊື່ໄຟລ໌ໃຊ້ນາທີຂອງເວລາ Taipei ເປັນ ID. ມັນສາມາດຖືກຫມາຍດ້ວຍຄວາມຄິດ, ການຮຽນຮູ້, ອອນໄລນ໌, ການໂກງຫຼືການອ່ານ. ມັນສາມາດຖືກສ້າງຕັ້ງຂຶ້ນໂດຍພຽງແຕ່ຂຽນວັກໂດຍບໍ່ຈໍາເປັນຕ້ອງຄິດເຖິງຫົວຂໍ້ທຸກຄັ້ງ. ການແຈ້ງເຕືອນຈະປາກົດຖ້າມັນເກີນ 500 ຄໍາ, ແລະມັນຄວນຈະຖືກປ່ຽນເປັນບົດຄວາມຖ້າມັນເກີນ 1,000 ຄໍາ.

ບົດຄວາມມີ slug ຄົງ, ຫົວຂໍ້, abstract, ວັນທີ, ແລະຍັງສາມາດມີເວລາປົກຫຸ້ມຂອງແລະການປັບປຸງ. URL ຈະບໍ່ຖືກປ່ຽນແປງຫຼັງຈາກທີ່ມັນຖືກເປີດເຜີຍຕໍ່ສາທາລະນະເພື່ອປ້ອງກັນບໍ່ໃຫ້ລິ້ງທີ່ແບ່ງປັນຕົ້ນສະບັບບໍ່ຖືກຕ້ອງ.

ສອງແມ່ນກ່ຽວຂ້ອງກັນໂດຍໃຊ້ article:. ສໍາລັບການປັບປຸງ, ທ່ານສາມາດຂຽນຄໍາຖາມທໍາອິດແລະຫຼັງຈາກນັ້ນເຊື່ອມຕໍ່ກັບບົດຄວາມທີ່ສົມບູນ; ຫນ້າບົດຄວາມຈະລາຍຊື່ການປັບປຸງທີ່ອ້າງອີງມັນໃນທາງກັບກັນ. ເນື້ອໃນສັ້ນຮັກສາຈຸດເລີ່ມຕົ້ນໃນປະຈຸບັນ, ແລະເນື້ອໃນຍາວແມ່ນຮັບຜິດຊອບສໍາລັບການສໍາເລັດການມາຈາກ. ບໍ່ຈໍາເປັນຕ້ອງຂຽນຂໍ້ຄວາມເຕັມດຽວກັນທັງສອງດ້ານ.

ໃຫ້ກົດລະບຽບເນື້ອຫາຂັດຂວາງຄວາມຜິດພາດກ່ອນທີ່ຈະສ້າງ

ຖ້າ Markdown ໄດ້ຖືກຖິ້ມເຂົ້າໄປໃນຮູບ, ບັນຫາຈໍານວນຫຼາຍຈະບໍ່ເຫັນໄດ້ຈົນກ່ວາຫຼັງຈາກມັນມີຊີວິດຢູ່: ວັນທີທີ່ບໍ່ຖືກຕ້ອງ, ບົດຄວາມທີ່ບໍ່ມີການເຊື່ອມຕໍ່, ຮູບພາບທີ່ບໍ່ມີ alt, ຫຼືຫົວຂໍ້ດຽວກັນຖືກຂຽນດ້ວຍສາມແທັກທີ່ຄ້າຍຄືກັນ.

ຂ້ອຍເອົາກົດລະບຽບເຫຼົ່ານີ້ເຂົ້າໄປໃນທໍ່ເນື້ອຫາທີ່ແບ່ງປັນ. loadContent ອ່ານໄຟລ໌, ກວດເບິ່ງຊ່ອງທີ່ມີ Zod, ແລະຫຼັງຈາກນັ້ນປະມວນຜົນ Markdown, ຮູບພາບ, ພາສາແລະຄວາມສໍາພັນຂອງເນື້ອຫາ. ທັງການກວດກາ CLI ແລະການກໍ່ສ້າງ Vite ໃຊ້ທໍ່ນີ້ເພື່ອຫຼຸດຜ່ອນຊ່ອງຫວ່າງລະຫວ່າງ "ເຄື່ອງຈັກທ້ອງຖິ່ນບອກວ່າມັນເຮັດວຽກ, ແຕ່ສະພາບແວດລ້ອມທີ່ເປັນທາງການບໍ່ໄດ້."

ແທັກພຽງແຕ່ຍອມຮັບລະຫັດລົງທະບຽນ tags.yaml; ບົດຄວາມທີ່ອ້າງອີງແບບເຄື່ອນໄຫວແລະການເຄື່ອນໄຫວອື່ນໆຕ້ອງມີ; ຕົວຢ່າງທ້ອງຖິ່ນສາມາດອ່ານສະບັບຮ່າງໄດ້, ແລະການກໍ່ສ້າງຢ່າງເປັນທາງການຈະບໍ່ລວມເອົາສະບັບຮ່າງ. ກົດລະບຽບເຫຼົ່ານີ້ບໍ່ໄດ້ອີງໃສ່ການຈື່ຈໍາພວກເຂົາໃນເວລາປະກາດ, ແຕ່ພວກເຂົາຂັດຂວາງການກວດສອບຢ່າງແທ້ຈິງ.

Markdown ກໍມີຂອບເຂດຜົນລັບທີ່ຊັດເຈນເຊັ່ນກັນ: raw HTML ຈະບໍ່ຖືກສົ່ງອອກໂດຍກົງ, HTML ທີ່ສ້າງຂຶ້ນຈະຖືກກວດລ້າງ, ແລະ code block ຈະຖືກເນັ້ນສີໃນຂັ້ນ build. ຮູບພາບເນື້ອຫາທີ່ອ້າງອີງດ້ວຍ relative path ໃນເຄື່ອງຈະຖືກແປງເປັນ WebP ທີ່ມີຄວາມກວ້າງສູງສຸດ 1600px ແລະລຶບ EXIF metadata ລວມທັງຂໍ້ມູນ GPS. ບົດຄວາມ, ບັດ ແລະຕົວຢ່າງສຳລັບແບ່ງປັນໃຊ້ຮູບທີ່ປະມວນຜົນແລ້ວຮ່ວມກັນ. ຮູບຈາກທາງໄກ ແລະຮູບທີ່ອ້າງອີງດ້ວຍ absolute path ຈາກ root ຈະບໍ່ຜ່ານຂັ້ນຕອນແປງພາຍໃນເຄື່ອງນີ້.

ຄ່າໃຊ້ຈ່າຍຂອງລະບົບຫຼາຍພາສາຈະຖືກຈ່າຍໃນເວລາທີ່ເຜີຍແຜ່ບົດຄວາມ.

ປະຈຸບັນ, ເວັບໄຊດັ່ງກ່າວຮອງຮັບ 22 ພາສາ. ຂໍ້ຄວາມຕົ້ນສະບັບຂອງຈີນແບບດັ້ງເດີມແມ່ນຂຽນຄັ້ງດຽວ, ແລະຫົວຂໍ້, ບົດຄັດຫຍໍ້, ຂໍ້ຄວາມແລະຮູບພາບຂອງ 21 ພາສາອື່ນໆຖືກເກັບໄວ້ໃນ locales.yaml ຕໍ່ໄປ.

ນີ້ແມ່ນການຕັດສິນໃຈທີ່ຂ້ອຍສົນໃຈ: ** ຜູ້ອ່ານບໍ່ຈໍາເປັນຕ້ອງລໍຖ້າການແປພາສາ. ** content:localize ສ້າງການແປເມື່ອໂພສ. ການກໍ່ສ້າງຢ່າງເປັນທາງການພຽງແຕ່ອ່ານໄຟລ໌ທີ່ມີຢູ່ແລະບໍ່ໄດ້ໂທຫາບໍລິການແປພາສາອີກເທື່ອຫນຶ່ງທຸກຄັ້ງທີ່ມັນຖືກປະຕິບັດ.

ໃຊ້ແຫຼ່ງອ້າງອີງເພື່ອປຽບທຽບຂໍ້ຄວາມຕົ້ນສະບັບ ແລະຂໍ້ຄວາມທີ່ແປແລ້ວ. ຖ້າຂໍ້ຄວາມຕົ້ນສະບັບຖືກປ່ຽນແປງ, ການແປພາສາເກົ່າບໍ່ສາມາດຖືກຖືວ່າເປັນສະບັບຫລ້າສຸດ; ຖ້າຄອບຄົວພາສາຫນຶ່ງຂາດຫາຍໄປຫຼືການແປພາສາລ້າສະໄຫມ, content:checkຈະລົ້ມເຫລວ. ຂະບວນການແປພາສາປົກປ້ອງລະຫັດ, ລະຫັດໃນແຖວ, ແລະເປົ້າຫມາຍການເຊື່ອມໂຍງຈາກການແປຕົວກໍານົດດ້ານວິຊາການຫຼື URLs.

ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າການແປພາສາອັດຕະໂນມັດມີຄຸນນະພາບຂອງການດັດແກ້ຂອງມະນຸດ. ມັນແກ້ໄຂຄວາມສົມບູນແລະຄວາມສອດຄ່ອງຂອງການປັບປຸງ, ແລະພາສາມືອາຊີບແລະສຽງຍັງຮຽກຮ້ອງໃຫ້ມີການອ່ານຫຼັກຖານສະແດງ. ຂໍ້ຄວາມຕົ້ນສະບັບທີ່ບໍ່ໄດ້ປ່ຽນແປງຈະຮັກສາການແປທີ່ມີຢູ່ແລ້ວ, ແລະຂໍ້ຄວາມທີ່ດັດແກ້ດ້ວຍຕົນເອງຈະບໍ່ຖືກຂຽນທັບໂດຍການດໍາເນີນການໃຫມ່.

ອ່ານບົດຄັດຫຍໍ້ໃນລາຍການ, ຄລິກເພື່ອໂຫລດບົດຄວາມ

ຫຼັງຈາກເນື້ອຫາເພີ່ມຂຶ້ນ, ຖ້າຫນ້າເວັບໂຫລດຂໍ້ຄວາມເຕັມຂອງແຕ່ລະບົດຄວາມແລະແຕ່ລະຄອບຄົວພາສາ, ຫນ້າທີ່ບໍລິສຸດຈະຊ້າຫຼາຍ.

Vite plugin ແບ່ງເນື້ອຫາອອກເປັນສາມ entry point: virtual:content/latest ສຳລັບໜ້າຫຼັກ, virtual:content/index ສຳລັບໜ້າເນື້ອຫາ ແລະ virtual:content/article/<slug> ແຍກຕ່າງຫາກສຳລັບແຕ່ລະບົດຄວາມ. ໜ້າຫຼັກສະແດງບັນທຶກສາມອັນຫຼ້າສຸດ ແລະບັດບົດຄວາມສາມອັນ. ຂໍ້ມູນບັນທຶກຍັງມີຂໍ້ຄວາມເຕັມແລະຄຳແປ; ບັດພຽງແຕ່ຕັດຂໍ້ຄວາມທີ່ສະແດງໃຫ້ສັ້ນລົງ. ບັດບົດຄວາມຍາວມີພຽງສະຫຼຸບ ແລະຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ; ເນື້ອຫາເຕັມຈະໂຫຼດແຍກຕາມແຕ່ລະບົດຄວາມຜ່ານ dynamic import.

React's Suspense ແມ່ນຮັບຜິດຊອບສໍາລັບການລໍຖ້າຂໍ້ຄວາມ, ແລະຂອບເຂດຄວາມຜິດພາດທາງນອກແມ່ນຮັບຜິດຊອບສໍາລັບການສະແດງຂໍ້ຄວາມຄວາມລົ້ມເຫຼວຂອງການໂຫຼດ. ເມື່ອຄໍາຮ້ອງຂໍຂໍ້ຄວາມລົ້ມເຫລວ, ຫົວຂໍ້, ບົດຄັດຫຍໍ້, ແລະການນໍາທາງຫນ້າຍັງຄົງຢູ່.

ຍັງມີການແລກປ່ຽນການຄ້າຢູ່ທີ່ນີ້: ປະຈຸບັນ, ມີບົດເລື່ອງຫນຶ່ງຕໍ່ບົດຄວາມ, ເຊິ່ງປະກອບດ້ວຍຄໍາແປຂອງແຕ່ລະຄອບຄົວພາສາ, ແລະມັນຍັງບໍ່ທັນໄດ້ແບ່ງອອກເປັນຫນຶ່ງ chunk ຕໍ່ຄອບຄົວພາສາ. ຂໍ້ຄວາມເຕັມແບບໄດນາມິກແລະການແປຖືກໃສ່ເຂົ້າໃນດັດຊະນີເນື້ອຫາ. ໃນຂະນະທີ່ປະລິມານເນື້ອຫາຍັງສືບຕໍ່ເພີ່ມຂຶ້ນ, ຂະຫນາດດັດສະນີແລະຈໍານວນການດາວໂຫຼດຂໍ້ຄວາມຫຼາຍພາສາແມ່ນຂັ້ນຕອນຕໍ່ໄປທີ່ຈະໄດ້ຮັບການວັດແທກ.

ຕ້ອງມີການສະຫຼັບດ້ານໜ້າ ແລະທາງເຂົ້າສຳລັບການອ່ານແບບຄົງທີ່.

ພວກເຮົາພຽງແຕ່ເຮັດ SPA, ແລະໃນເວລາທີ່ພວກເຮົາແບ່ງປັນມັນ, ພວກເຮົາມັກຈະເຫັນພຽງແຕ່ຫົວຂໍ້ແລະຮູບພາບຢູ່ໃນຫນ້າທໍາອິດ. ນີ້ບໍ່ພຽງພໍສໍາລັບບົດຄວາມ.

ດັ່ງນັ້ນ, ເມື່ອຕັ້ງຄ່າ, ແຕ່ລະແບບເຄື່ອນໄຫວ, ບົດຄວາມແລະ tag URL ມີແກະ HTML ຂອງຕົນເອງ, ເຊິ່ງປະກອບດ້ວຍຫົວຂໍ້, ຄໍາອະທິບາຍ, canonical, Open Graph ແລະ JSON-LD, ແລະຂໍ້ຄວາມຕົ້ນສະບັບທີ່ສາມາດອ່ານໄດ້ແມ່ນຖືກຈັດໃສ່ໃນ noscript. ທ່ານສາມາດໄດ້ຮັບເນື້ອໃນແລະການປົກຫຸ້ມຂອງສະເພາະຂອງບົດຄວາມນີ້ໂດຍບໍ່ມີການປະຕິບັດ JavaScript.

ເນື້ອໃນດຽວກັນຍັງຈະຜະລິດ feed.xml, sitemap-content.xml, ສະບັບ Markdown ຂອງບົດຄວາມ, ແລະດັດຊະນີບົດຄວາມສໍາລັບ llms.txt. ເຫຼົ່ານີ້ແມ່ນຜະລິດຕະພັນທີ່ສ້າງຂຶ້ນ, ບໍ່ແມ່ນຊຸດຂອງເນື້ອຫາອື່ນທີ່ຕ້ອງການ synchronization ຄູ່ມື.

ຢ່າງໃດກໍ່ຕາມ, ຂອບເຂດຂອງ SEO ຫຼາຍພາສາຍັງຕ້ອງມີຄວາມຊັດເຈນ: ** ປະຈຸບັນ, ການປັບປຸງແລະບົດຄວາມແບ່ງປັນ URL ດຽວກັນໃນແຕ່ລະພາສາ, ແລະພາສາຖືກປ່ຽນໂດຍດ້ານຫນ້າ; ຫນ້າເນື້ອໃນຄົງທີ່, ຟີດ, ແລະສະບັບ Markdown ຮັກສາຂໍ້ຄວາມຕົ້ນສະບັບ. ** ຫນ້າທໍາອິດຍັງມີການສະແດງກ່ອນສໍາລັບພາສາແລະໂຫມດແສງສະຫວ່າງແລະຊ້ໍາ. ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າແຕ່ລະບົດຄວາມຍັງມີ 22 ຫນ້າພາສາທີ່ສາມາດດັດສະນີເປັນເອກະລາດ.

ຖ້າທ່ານຕ້ອງການອະນຸຍາດໃຫ້ແຕ່ລະຄອບຄົວຂອງພາສາຖືກລວມເຂົ້າໂດຍເຄື່ອງຈັກຊອກຫາໃນອະນາຄົດ, ທ່ານຈະຕ້ອງເພີ່ມເສັ້ນທາງຄອບຄົວຂອງພາສາ, ຫນ້າສະຖິດທີ່ສອດຄ້ອງກັນແລະ hreflang. ນັ້ນແມ່ນຄວາມຕ້ອງການອີກອັນຫນຶ່ງທີ່ຊຸດນີ້ຍັງບໍ່ທັນບັນລຸໄດ້.

ການໂພດຍັງເປັນຂະບວນການຈັດສົ່ງ

ຂະບວນການພິມເຜີຍແຜ່ຂອງຂ້ອຍຄື: ຂຽນຂໍ້ຄວາມຕົ້ນສະບັບ, ສ້າງການແປ, ກວດສອບເນື້ອຫາ, ສົ່ງໄປທີ່ Git, ແລະຫຼັງຈາກນັ້ນລວມມັນເຂົ້າໄປໃນ main. ການປະຕິບັດ GitHub ທີ່ມີຢູ່ແລ້ວຈະສ້າງເວັບໄຊທ໌ຄືນໃຫມ່ແລະນໍາໃຊ້ມັນ.

npm run content:localize
npm run content:check
npm run test:content
npm run build

ຖ້າການແປຍັງບໍ່ຄົບທຸກພາສາ ຂ້ອຍຈະເພີ່ມສ່ວນທີ່ຂາດກ່ອນ. ບົດຄວາມທີ່ຍັງເປັນຮ່າງຈະຢູ່ໃນຕົວຢ່າງເບິ່ງພາຍໃນເຄື່ອງ. ຜົນຜະລິດ production ຍັງກວດວ່າບໍ່ມີໜ້າຮ່າງ ແລະຄົ້ນຫາເຄື່ອງໝາຍຮ່າງໃນໄຟລ໌ສາທາລະນະຫຼັກໆ ເຊັ່ນ feed, sitemap, ໜ້າຫຼັກ ແລະ JavaScript bundle. ເນື້ອຫາກໍມີ diff ແລະປະຫວັດເວີຊັນເໝືອນກັບໂຄດ ແລະສາມາດກູ້ຄືນພ້ອມກັນໄດ້.

ວິທີການນີ້ເສຍສະລະການອັບເດດໃນເວລາຈິງ: ຖ້າທ່ານປ່ຽນຂໍ້ຄວາມ, ທ່ານຕ້ອງລໍຖ້າການຈັດຕັ້ງປະຕິບັດ. ແຕ່ສໍາລັບເວັບໄຊທ໌ດ້ານວິຊາການຂອງຂ້ອຍ, ຂ້ອຍເຕັມໃຈທີ່ຈະຊື້ຂາຍການລໍຖ້ານີ້ເພື່ອແລກປ່ຽນກັບ backend ຫນ້ອຍຫນຶ່ງ, ໄລຍະເວລາການປະຕິບັດຫນ້ອຍຫນຶ່ງ, ແລະບັນທຶກການປ່ຽນແປງທີ່ງ່າຍຕໍ່ການຕິດຕາມ.

ເມື່ອໃດທີ່ມັນເຫມາະສົມທີ່ຈະເຮັດສິ່ງນີ້?

ຖ້າທ່ານເປັນຜູ້ຂຽນ, ຄວາມຖີ່ຂອງການໂພດສາມາດສ້າງໃຫມ່ໄດ້, ເນື້ອຫາແມ່ນຂໍ້ຄວາມຕົ້ນຕໍ, ແລະທ່ານຖືກນໍາໃຊ້ກັບ Git, ສະຖາປັດຕະຍະກໍານີ້ແມ່ນເຫມາະສົມຫຼາຍ. ການປັບປຸງສັ້ນເຮັດໃຫ້ລະດັບການຂຽນຕ່ໍາລົງ, ບົດຄວາມຮັກສາການສືບພັນທີ່ສົມບູນ, ແລະຫຼາຍພາສາຊ່ວຍໃຫ້ຄົນອ່ານເນື້ອຫາດຽວກັນຫຼາຍຂຶ້ນ.

ຖ້າຄວາມຕ້ອງການກາຍເປັນການຮ່ວມມືແບບສົດໆລະຫວ່າງຫຼາຍໆຄົນ, ການຄຸ້ມຄອງການອະນຸຍາດ, ຄວາມຄິດເຫັນຂອງຜູ້ອ່ານ, ເຂົ້າສູ່ລະບົບຫຼືການສະຫມັກ, ຫຼັງຈາກນັ້ນ CMS ແລະ backend ຕ້ອງໄດ້ຮັບການປະເມີນຄືນໃຫມ່. Pure-end ຈະບໍ່ເຮັດໃຫ້ຄວາມຕ້ອງການເຫຼົ່ານີ້ຫາຍໄປໂດຍອັດຕະໂນມັດ, ແຕ່ຂ້ອຍບໍ່ໄດ້ເອົາພວກມັນເຂົ້າໄປໃນຂອບເຂດຂອງ blog ນີ້ໃນເວລານີ້.

ຫຼັກການການອອກແບບເວລານີ້ແມ່ນໃກ້ຊິດກັບສິ່ງທີ່ຂ້ອຍຂຽນໃນ ຮູບແບບອອກແບບສະຖາປັດຕະຍະກຳສຳລັບຫຼາຍ layout ແລະຫຼາຍ theme: ທໍາອິດຄວາມຮັບຜິດຊອບແຍກຕ່າງຫາກຢ່າງຊັດເຈນ, ແລະຫຼັງຈາກນັ້ນໃຫ້ກົດລະບຽບຮ່ວມກັນຮັກສາຄວາມສອດຄ່ອງ.

ສໍາລັບເວັບໄຊທ໌ນີ້, ຈຸດສໍາຄັນແມ່ນເພື່ອໃຫ້ຂ້ອຍສາມາດສືບຕໍ່ຂຽນແລະຮູ້ວ່າເນື້ອຫາໃດຖືກສົ່ງກັບທຸກໆຄັ້ງທີ່ຂ້ອຍເຜີຍແຜ່.