系統環境
| 項目 |
內容 |
| 系統平台 |
XOOPS 2.7.2 |
| 程式語言 |
PHP 8.3 |
| 資料庫 |
MariaDB |
| 前端框架 |
Bootstrap 5.3 |
| 網站類型 |
企業形象 + 內容中心 + 線上購物與訂單查詢 |
| 功能模組 |
14 個,其中 1 個為自行開發 |
一、系統核心零改動
整個網站的客製化全部發生在外觀層——系統核心與所有功能模組的原始碼一行未改,唯一的例外是一行安全性修補,且經業主同意。
實作方式
- 66 支外觀版型檔
- 3,244 行品牌樣式層
- 樣式一律針對模組既有的元素撰寫;真的需要新元素時,才在外觀層加最少量的容器
為什麼這樣做
| 情境 |
零核心改動的差別 |
| 功能模組升級 |
不會把客製化蓋掉 |
| 要退回原狀 |
換佈景即可完整還原 |
| 交接下一手 |
「哪些是我們改的」一目了然 |
這是許多內容管理系統客製案在交接時最痛的地方——改動散落在核心與模組中,接手者無從分辨,也不敢升級。
二、區段版型系統
17 種區段版型,組出 13 個內容頁、共 116 個區段實例。
新頁面經常不需要工程師介入:
- 隱私權政策頁 = 五種既有區段組合,零新增版型
- 退換貨與賠償辦法頁 = 多章條文自動套用同一種條文區段
- 六個跨境服務子頁 = 同一組配方
長期維護成本的差距可以量化:13 個頁面,只用了 17 種版型。
詳細做法見模組化網站設計案例:17 種區段版型如何組出整站內容頁。
三、購物流程改造,模組輸出零變動
購物車兩個步驟、訂單查詢兩種畫面、三顆側欄元件全部換上新設計,但模組送出的每一個位元組都沒有變。
難點
購物模組原本的程式是靠欄位位置取值的——第幾列、第幾格。表格結構只要動一格,金額就會算錯。
作法
表格的欄列一格不動,外觀完全用樣式重塑,只在最外層加三處容器。
驗證方式
每一支版型改完,都把改造前後的模組輸出逐位元組比對。
實測結果:訂單明細表、費用明細表、結帳表單、內嵌程式共四段、6,018 位元組完全相同。
訂單清單只有登入後才會輸出、無法用一般方式抓取,改以指令列直接算繪版型再逐行核對。
四、在外觀層補上狀態同步
購物流程中原有幾處狀態不會同步的情況:
- 切換付款方式後,金額沒有重新計算
- 按瀏覽器「上一頁」返回後,選項雖然還原了,但相關欄位沒有跟著重算
作法
不改動模組原始碼,而是利用瀏覽器處理使用者操作的階段順序——在所有既有程式跑完之後,於最外層做一次「最後裁決」。
這個作法的價值
它不需要事先知道模組處理了哪些選項。系統會自行判斷這一次有沒有人處理過,沒有才接手。
這代表業主日後在後台新增任何付款或物流方式,都會自動被涵蓋,不必回頭改程式。
五、自研跨案件模組
為本案(以及後續案件)自行開發的模組,包含同意管理、通知與轉換追蹤:
- 63 支程式,約 9,900 行
- 2,267 行規格書,含 7 條架構決策紀錄
幾個設計決策
- 追蹤碼惰性化——訪客同意之前,分析與廣告的追蹤碼根本不會被載入,而不是載入後再停用
- 模組隔離——程式與樣式由元件載入而非全站預載,沒有使用該元件的頁面完全不會下載這兩個檔案,避免「裝一個模組拖慢全站」
- 不做全螢幕插頁廣告——寫進規格書的硬性限制,因為搜尋引擎對行動版插頁廣告有明確的排名處理
- 上傳安全——上傳的圖片會先在記憶體中重新編碼,只寫出處理後的結果,原始檔案位元組從頭到尾不會落在網站目錄裡
- 個資最小化——同意紀錄設有保留期限與自動清除機制,並有四道防止資料量失控的設計
六、結構化資料的工程設計
主樣板定義一組共用的資料圖譜,包含組織與網站兩個節點。各頁輸出的文章、問答、分類、麵包屑資料,其作者與發布者欄位一律以識別碼指回同一個節點,不在每一頁重複公司資料。
改公司資訊只需要改一個地方。
兩個刻意的選擇
選用組織類型而非在地商家類型——後者會以實體店家的檢查表驗證,價格區間、座標、營業時間沒填就會產生一連串警告。日後要做地圖曝光再升級,各頁的引用不必改。
不從後台系統設定讀取公司資料——站台名稱是關鍵字短語而非公司名,作者欄位是逗號串接的自由文字,兩者拿來當發布者名稱都會直接顯示在搜尋結果上。
其他
- 單一頁面最多同時輸出四塊結構化資料,各自獨立且都必須是合法格式
- 因此內文一律禁止手寫結構化資料
- 網站地圖頁與 sitemap.xml 皆已建置
以上為工程作法的說明,不涉及任何搜尋成效數據。
七、以設計稿作為內容的正確來源
本案的工作流程是:先與業主談清楚要說什麼 → 產出設計稿 → 逐區塊對應填進系統 → 抓線上頁面驗證。
多數案子是「先做版型、後補文案」,結果版型撐不住真實內容——文字太長會爆版,太短會空洞。
這個流程反過來:版型是照著已經定稿的內容長出來的。
數字的一致性
專案中期曾針對文案中十餘項互相矛盾的數值逐一與業主確認,定案後一次更新了 21 筆段落,之後所有新頁面都照同一組定案數值撰寫。
全站的數字不會互相打架——這在有費率、時效、材積限制的物流網站上特別重要。
八、交接文件是交付物的一部分
- 外觀層交接文件 1,512 行
- 自研模組說明文件 413 行
- 自研模組規格書 2,267 行,含 7 條架構決策紀錄
文件不只寫「這裡有什麼」,而是寫「為什麼這樣做」與「這裡踩過什麼坑」。
下一位工程師接手時,不需要重新推理一遍。
數字彙整
| 項目 |
數量 |
| 頁面設計稿 |
31 份 |
| 字型與色票一致率 |
31/31 |
| 外觀版型檔 |
66 支 |
| 品牌樣式 |
3,244 行 |
| 後台可調整區塊 |
47 個 |
| 內容頁 / 區段版型 / 區段實例 |
13 / 17 / 116 |
| 功能模組(含自研) |
14(1) |
| 自研模組程式 |
63 支 / 約 9,900 行 |
| 模組輸出逐位元組比對 |
6,018 位元組相同 |
| 交接文件 |
1,512 行 |
| 系統核心與模組改動 |
1 行(安全性修補) |
延伸閱讀