我為什麼把網站分成普通文章和圖集？完整改造過程

為什麼我要增加普通文章模式？

我的網站原本以圖集內容為主。每一張圖片搭配一段文字，讀者需要使用「上一頁」和「下一頁」按鈕切換內容。

這種設計適合新聞圖片、事件照片和需要逐張檢視的圖集，但我開始撰寫自己的實際經驗後，發現它並不適合普通文章。

例如，我寫下網站專案轉移、Docker 建置失敗和程式依賴修復的完整經過。這些內容包含多個段落、步驟、圖片和錯誤訊息。如果仍然使用圖集模式，文章就會被拆成數頁。

讀者看完一部分後需要點選下一頁，才能繼續閱讀。手機使用者也需要反覆切換頁面，閱讀體驗不夠連貫。

我最初考慮直接刪除圖集分頁，把所有內容都改成普通文章。但是網站已經存在許多舊圖集，而且手機版的圖集排版可以正常使用。如果直接修改原本的顯示方式，很可能影響已經發布的內容。

所以我最後決定保留原來的圖集模式，再另外增加一種普通文章模式。

兩種模式的用途分別是：

1. 圖集模式：適合圖片新聞、事件照片和逐張說明。
2. 普通文章模式：適合原創經驗、教學、問題排查和長篇內容。

這樣不需要破壞舊內容，也能讓之後發布的原創文章使用更適合閱讀的版面。

後臺如何區分兩種內容？

為了避免每次發布文章時修改程式，我在後臺編輯頁面增加了「內容型別」選項。

建立或編輯內容時，可以選擇：

• 圖集
• 普通文章

如果選擇圖集，網站繼續使用原來的圖片計數、上一頁和下一頁按鈕。舊圖集的電腦版與手機版排版保持不變。

如果選擇普通文章，系統會把所有圖片和文字放在同一個頁面中，依照後臺排列順序連續顯示。文章中不再出現頁數、重點編號以及上一頁或下一頁按鈕。

這次修改不只是前端隱藏按鈕，資料庫也新增了用來記錄內容型別的欄位。這樣網站每次讀取內容時，都能先確認它屬於圖集還是普通文章，再使用正確的版面。

我也為文章增加了固定英文網址。例如原本的數字網址可能是：

/article/01

修改後使用固定網址：

/article/onedrive-project-storage-transfer

舊網址仍然可以開啟，並會自動跳轉到新的固定網址。這樣以前分享出去的連結不會立即失效，搜尋引擎也能找到正確的新頁面。

部署這項修改時，我先備份網站程式和 MySQL 資料庫，再執行資料庫升級及重新建立 Docker 容器。

建置過程中曾經因為缺少 opencc-js 依賴而失敗。修復依賴後，新的網站映像才成功建立。這也讓我確認：涉及資料庫和內容結構的改動，不能只檢查畫面，還必須驗證依賴、容器、舊網址和新網址。

改造後的普通文章頁面

完成修改後，普通文章可以在同一個頁面中依序顯示摘要、圖片、段落、小標題、列表和程式內容。

讀者只需要向下捲動，不必反覆點選下一頁。推薦內容也移到完整文章的末尾，不會在正文尚未讀完時提前出現。

我分別使用電腦和手機測試頁面，主要檢查以下專案：

1. 普通文章是否完整顯示所有圖片和文字。
2. 頁面是否仍然出現上一頁、下一頁或頁數。
3. 圖片在手機上是否超出畫面寬度。
4. 文字大小和行距是否適合閱讀。
5. 推薦內容是否只出現在正文結束後。
6. 舊圖集能否繼續使用原本的分頁功能。
7. 舊數字網址能否正確跳轉到固定網址。

第一次測試時，我發現資料庫中的文章雖然已經改成普通文章，但瀏覽器仍然顯示舊圖集頁面。後來檢查才發現，我開啟的是舊的動態網址，而不是新的固定網址。

重新確認資料庫中的內容型別和網址後，普通文章頁面才正確顯示。這讓我瞭解到，畫面看起來沒有改變，不一定代表新功能失效，也可能是網址、舊資料或快取仍然指向舊內容。

兩種模式並存的好處

這次改造完成後，我不需要把所有舊圖集重新編輯，也不需要放棄原本適合圖片新聞的功能。

舊內容繼續使用圖集模式，新撰寫的實際經驗則使用普通文章模式。兩種內容可以共用同一個網站、分類和推薦系統，但閱讀方式各自獨立。

對我來說，最大的改變不是移除幾個按鈕，而是讓網站開始具備真正適合原創內容的文章結構。

普通文章能夠完整呈現問題、操作過程、錯誤、解決方法和最後結果。讀者不必為了增加頁面瀏覽次數而一直點選下一頁，也更容易理解整件事情的前因後果。

這次改造讓我學到的事情

經過這次實際修改，我整理出幾個之後會繼續遵守的做法：

1. 不直接破壞已經正常運作的舊功能。
2. 新功能使用獨立欄位和顯示條件。
3. 修改資料庫前先備份程式和資料。
4. 新文章使用固定、容易理解的英文網址。
5. 舊網址保留跳轉，避免分享連結失效。
6. 電腦版和手機版都需要實際檢查。
7. 部署完成後，同時驗證新文章和舊圖集。

我原本只是想讓文章不再顯示上一頁和下一頁，最後卻完成了內容型別、網址、後臺編輯和前端版面的整體調整。

這次經驗也讓我明白，網站功能不一定只能全部使用同一種顯示方式。先確認不同內容的實際用途，再為它們設計適合的閱讀形式，通常比強行統一所有頁面更合理。