自架 WordPress 用了 7 年，最後又回到自己寫程式

WordPress 號稱「世界上 43% 的網站都在用」，聽起來很厲害對吧？

但他們不會告訴你的是：這 43% 的網站管理員，有多少人每天早上醒來第一件事，是祈禱今天不要收到套件資安警告通知信；還有多少人看到「這個網站發生重大問題」時，已經能熟練地打開系統偵錯模式和查閱系統紀錄；維護部落格花的時間，可能遠超過寫文章。

前情提要:這個部落格一開始是在一個免費的寫作平台 Logdown，後來因為平台的開發者跑去對岸搞其他更賺錢的事業，疏於維護他的平台，於是我在 2017 年跳船(從 Logdown 搬出來啦)，搬到自己架 WordPress 的行列。

這幾年也把這部落格放在不同的虛擬共享主機上面跑，看看使用上是不是真的有商人吹得這麼輕鬆、美好?

結果在 2023 年，我決定讓這個部落格脫離 WordPress 的魔爪，還是自己寫程式最自由。

1. 除了域名之外，其他都可以不花錢。
2. 自由，想怎麼改就怎麼改。而且只要環境對，還是可以任意建子目錄放自己的前端+後端程式。
3. 打開 VS Code 就可以寫文章，不需要打開瀏覽器，也不需要 2FA 登入後台。
4. 什麼 AI 產文，什麼預覽、翻譯，VS Code Extension Marketplace 的套件任人使用，一言不合還可以自己開發套件，不用看平台或開源團隊的臉色。
5. WordPress 又有可怕的新漏洞? 主程式或套件大改版? 干我屁事。

像最近痞客邦平台系統大改版，使用者怨聲載道，聽說好幾天沒辦法正常發文，舊文章還被系統改內文，符號或影片被刪掉什麼的。

確實，對平台的使用者而言，使用部落格平台，資料就只有「線上的那一份」。

相比之下，我們自己寫程式自己架站的人絕對不是在自找麻煩，而是從此脫離這種平台維修、帳號被鎖、文章突然不見、平台系統大改版的情況。真正需要擔心的，反而只剩各種雲端基礎設施本身是否正常運作，程式語言是否沒落。

以目前本部落格的架構來說，電腦本機有一份，GitHub repo 有一份，網站伺服器有一份，伺服器的 snapshot 裡還有一份，其他還有什麼自己電腦在 NAS 的備份之類的就不提了...

本來是分享一些心得，結果一直拖到 2025 年快過完了還沒寫完，決定先發一部分。

部落格改版這件事做起來非常自由，沒有什麼心理負擔，不像工作一樣，需要對別人的期待和幻想給出什麼保證和交代...

拋棄 WordPress 的理由: 我不需要這種編輯模式

有人稱讚 WordPress 優點，對他而言可能是優點，也有可能是在賺分潤，像有一間無限流量的 WordPress 每個月只要台幣 100 多塊，還不用自己管伺服器......好險，差一點又開始推銷了，只講亮點、不講代價，這是網路上九成推廣 WordPress 的文章的常見現象。

無忌你要記得，越說自己毫無問題的生意，越會在難以想像的地方爆最難處理的雷。

只談亮點、不談代價的銷售手法

關於 WordPress 架站的幾種業者形式，在之前的當 Elementor 賣起雲端架站平台一文已經提過，就不再贅述。有些人享受到的「美好服務」也只是規模經濟下的產物，而不是基層人員的個人能力問題。

然後要是 WordPress 這套軟體也搞得跟「一般的」商業軟體一樣:

• 拿到安裝程式碼、伺服器安裝那個軟體，每年就要付多少授權費。
• 每年還要多付多少錢，才能獲得更新維護。
• 想要修改程式碼或任何需求，都得透過「國外原廠」「官方合作夥伴」提交工單，或是留聯絡資訊乖乖等回覆。
• 必須透過授權代理商購買，普通個人使用者幾乎無法直接取得正式授權。
• 原廠經常進行各種稽核，使用端有永遠做不完的文書作業，還要擔心哪天被原廠終止使用權。

那些業者偉大的商業模式就會瞬間崩塌。不過這一天還沒來臨，以後應該也不會，討論起來沒啥意思，先在此打住。

當內容只是文章時，這些功能全都是多餘的

本文提到的情況，主要是以我自己的使用情況而衍生的，與其他使用 WordPress 的網站不一定有關。

別人用 WordPress 用得好好的，什麼問題都沒有? 那很棒。

我就是不需要複雜的技術架構，我直接就能寫文章，改版面，不需要仰賴什麼所見即所得編輯器? 版面設定? 佈景主題切換? widget? 在管理後台調整功能參數和開關，然後後台的預覽畫面是一個樣子，前台的實際畫面又是另一個樣子?

選單項目管理? 分類管理? 調整順序? 這不是做幾個文字檔，把兩行對調、插入一行就好了嗎。

我不需要登入後台、人機驗證、點進好幾層選單、點擊後等待編輯介面載入、每改一個儲存一次...

我也不需要複雜的權限管理、檔案管理、外掛管理、資料庫管理等功能。

這個部落格就只有文章，沒有編排什麼精美的頁面。那種版面編輯器的大戰已經看到膩了，那種討論往往都是這樣:
A說哪個編輯器很好用；
B可以說它用 Figma 做好的設計稿很難用那隔編輯器排到 pixel-perfect；
C可以說範本區塊不夠多，遇到那種不給內容要先設計的場合不適合；
D可以說介面沒有中文，很難教別人操作；
E說功能太複雜；
F說有些東西太精簡，某某效果還是做不出來......

現實中有無數種設計情況跟需求，這種東西永遠沒辦法讓每個人都滿意。

用文字檔與原始碼寫網站，早就不是少數派

拋棄視覺化編極器，擁抱文字檔跟網頁原始碼，這也不是什麼癡心妄想。讓 AI 隨便找幾篇案例，這些網站本來使用某種複雜的 CMS，後來改用 Markdown+Git 的形式，這還是公司，要是個人網站&部落格就更多了。

• Cursor - Coding Agents & Complexity Budgets
• Highlight.io - Using Github as a Headless CMS

只要有一段文案，就有機會讓 AI 做出某些風格的一頁式網頁，或是互動式小遊戲活動網頁，有時候何必執著於使用 1px 1px 調整細節的工具呢?

隨便拍一張照片，就有機會用 AI 直接將照片美化重新構圖，有時候何必執著於使用將圖片去背、修改細節的影像處理工具呢?

下面分享一些過去用 WordPress 讓人覺得非常疲憊的地方。

1.刺激的網站資安問題

不是真的網站被駭、被打到打不開，或是被掛馬之類的，而是為了網站資安防護引發的一連串效應。

WordPress 成為預設攻擊目標的現實

用 WordPress 做網站可以很快樂，
前提是從來不去看各種伺服器和防護機制的 log，
不安裝後台嘗試登入失敗就會鎖定的套件，
後台登入失敗的通知信不要設定到自己信箱，
不安裝任何安全檢查通知工具，
不去檢查有沒有遇到垃圾關鍵字攻擊。

一旦看了就回不去了，會發現歲月靜好只是一層輕薄的假象。

每次在檢查 access log 或一些系統紀錄時，就會看到一堆不知名 ip 嘗試存取各種 WordPress 的程式檔案路徑、API endpoint，塞各種離奇的 payload 想要執行。

通常是鎖得好好的，不會有任何影響，但不知道會不會哪一天不小心開放，總是毛毛的。

我也從這些紀錄中學到不少「檢查」別人 WordPress 網站的技巧。

這也不是單獨有人想 try 我這部落格的問題，基本上只要有個 IP、有個網域名稱，不管你是 WordPress 網站，還是在外面可以用手機連上的 NAS、監視器主機，也都會碰到......哪一天剛好成功被人打進來，就會發生有趣的事，這是現代網路環境的現實。

通用型防護開始干擾創作流程

文章有時候會放一些程式碼，例如一些工具文會提到某些伺服器用的指令，有時候是內文放一段跟訪客讀者互動的 JS 小程式。

問題來了，有時候會文章存檔送出後，內文會被虛擬主機商的某些資安機制攔截，導致剛剛打了老半天的東西不見。

要嘛再改內文，嘗試看看怎樣不會被擋；
或是把東西放在別的地方，用 iframe 內嵌；
甚至有時候做實驗做到自己的 IP 被主機商封鎖。還要到去主機商提供的面板找設定解開。

這種每次儲存文章時的不安心感，有幾次寫老半天，然後送出時又觸發 WAF 的阻擋畫面，回上一頁時剛剛寫的內容都不見了，實在非常火大。

當然不能說主機商不該做任何保護機制，或要求人家特別為我改設定，或是指責它跟上游廠商採購的工具有 bug，這又是另一個可以無限展開的大議題。

反正我不玩了，選擇其他方式，追求更高的控制權和更多自由度。

部落格變成資安待辦事項產生器

曾經有裝一些資安通報類的擴充外掛，會自動比對 WordPress 網站內安裝的套件與其版本，有沒有出現在全球資安漏洞通報庫中，

要是幸運中獎(網站內有套件版本出現資安漏洞)，就會用各種方式通知網站管理員，要嘛寄各種 New Vulnerability Detected、Your site may be in danger 的通知信，要嘛顯示在 WordPress 網站後台各處。

(雖然網站已經不是用 WordPress，但系統還是根據以前的套件清單紀錄，持續通知...)

有時候漏洞的觸發情況可能很刁鑽，CVSS 判為低風險，如果網站根本沒有開放訪客註冊，沒有馬上更新也不會怎樣。

但沒人會知道會不會下一分鐘來一個 CVSS 10 分的超大漏洞? 然後人還在外面，沒辦法做任何處置，天有不測風雲，網站有旦夕禍福。

還有一種情況就是，有些套件或佈景主題，最後更新已經是數個月或數年前。然後因為這個套件有漏洞，就一直收到通知信，看到就煩，除非吃飽沒事自已去修...。

這種工具只是通知用途，真的有壞人來也完全沒用。機制基本上只是檢查安裝的已知套件名稱，完全不牽涉原始碼掃描/靜態檢測/動態檢測，那就有很多方法可以繞過去。

有些版面調整需求，像文章頁尾要固定多加一個贊助連結，調整文章換頁的 UI 之類的，其實不一定要裝套件，可以改佈景主題檔案，也可以用 function code 或 code snippet 達成差不多的功能。

這還是我自己的部落格，不用準備什麼對人交代的報告，但三不五時就冒出待辦事項，還是令人心煩。

2.佈景主題停止更新

2017 年搬來自架 WordPress 時，從後台的佈景主題清單隨便選了一個看似順眼的，預設是灰色+白色+Tiffany Blue 配色的免費佈景主題。結果我選到一個已經停止更新的佈景主題。

佈景主題不只是樣式，而是一整座冰山

因為是外國人做的佈景主題，字體跟一些樣式不太適合中文網站，中文的斜體明體小字實在很難閱讀。然後一堆按鈕文字還是寫死的外文，沒有多國語系檔案，我就直接改佈景主題的 PHP、CSS、JS 檔案，改一改就繼續用，我那時真是聰明過分，直接改佈景主題程式碼好像很厲害，實際上菜味都飄出來。

改天想說試一下別的佈景主題，按一下套用，看起來不太滿意，就又換回原本那個佈景主題。結果佈景主題變回一開始未修改的樣子??!! 喔~原來 WordPress 的系統設計還有 child-theme 這種概念，還好之前改過的程式碼有備份，於是又再處理過。

經過時間的洗禮，我深刻了解到 WordPress 佈景主題不是只有表面上看到的視覺樣式，實際上是冰山下半部關於對 archive/category/single post/tag/search 等一堆程式功能頁面的頁面元素樣式和設定，牽涉後台能直接視覺化調整的：header/footer 的排版、選單位置、側邊欄配置、文章列表的呈現方式、文章內容的版型、特色圖片的尺寸和位置、不同尺寸下 RWD 的選單功能，字型和顏色系統。

這些設定都是佈景主題的重要組成部分。

理想狀態下，能讓網站管理者在盡量不碰程式碼，甚至不具備任何專業知識的情況下，舒服地調整網站的呈現方式。

不理想狀態就是經過時間的洗禮，讓人深刻了解到 WordPress 系統、網頁前後端程式、各種網路和計算機的底層邏輯。

新功能輪不到我，壞處卻一直冒出來

因為我用到一個已經停止更新的佈景主題，佈景主題的前端檔案裡面，有一堆有的沒的 JS 和一些 IE 時代的 CSS 寫法，隨著每年網頁前端技術發展，都有不少改進空間(然後用新的技術去做，短時間看似 best practice，但隔一陣子又會有更好的)，不過那時候 IE 瀏覽器還沒死光，所以沒有特別大的動力去改掉它們。

我每隔一段時間就會把 WordPress 主程式更新到最新版，但各種新功能都與我無關，因為佈景主題不支援。

好處輪不到我，壞事倒是一堆，例如記得有一次更新 WP 主程式，馬上發現網頁上的主選單收合效果按了沒反應，記得那次好像是 WP 官方把 jQuery 版本大更新；還是 jQuery Migrate 預設停用怎樣的，太久了記不清，反正佈景主題的原始作者用了一堆 jQuery 的寫法，就受到影響。

這還不是一次到位，官方依據群眾反應，在幾個小版本中連續調整。最後的結果是碰到這種相容性問題的 WP 站長，要再幫網站額外安裝官方出的套件 jQuery Migrate。

諸如次類的事就埋下不少陰影，平常沒在跟隨「國外原廠」的社群討論或 roadmap，沒人知道下一個官方的版本又會採取什麼激進的行動。

要是沒把主程式和套件的自動更新關掉，要是開太多權限給普通人用，讓每個後台操作人員看到更新通知就去按，下場常常就是有機會讓網站的佈景主題、外掛、程式碼出問題，幫人管網站每年收的費用沒有變多，但是待辦事項一直平白無故增加。

理想的處置是另開個測試站，一支一支檢查檔案，把佈景主題的過時程式全部重寫；翻閱 WordPress 那些主程式的開發文件，把佈景主題的檔案大改一番，改完再移回來。或是重新挑一個新的佈景主題，調整到自己喜歡的樣子，改完再移到正式上線的環境。

但想到就懶。

如果時間重來

如果時間重來，我可能會選擇一些付費的佈景主題大廠，他們也會出一些基本功能的免費佈景主題。而不是光看到封面圖覺得很喜歡。

講是這樣講，但這個原則根本無法成立。

如果坐時光機回到 2017 年，選擇當年熱門的 OceanWP、GenerateBlocks，還是當年度的 Twenty Seventeen(封面圖是植物的那個)? 放到現在來看，也不見得是好選擇。

剛剛選錯了，那我們再坐一次時光機回去 2017 年，用時空旅人的視角，挑選如今 2025 年知名好用的佈景主題，像 Kadence、Blocksy、Astra、Greenshift 之類的?

好笑的是他們在當時要嘛根本還沒開始做佈景主題，要嘛公司都還沒成立哩。Elementor 的 Hello Elementor 佈景主題也是在 2020 年才出哩。那時候 WP 官方還沒有區塊編輯器這種玩意。

因為產品策略是要拐人去買付費佈景主題，所以推出功能被閹割過的免費版，一旦買下去，日後還有可能被綁死在他們的生態中(只能選相容他們佈景主題的套件)，但至少在資本市場這個公司&員工有錢賺的概念下，多半會持續更新維護，或是享有他們自家的生態系的優點。

就算每套有各自的地雷，例如可能網頁改到一半，會想到這個在某某佈景主題可以直接視覺化調整，在這個佈景主題卻要自己寫程式碼?

但這種事就是不經一事不長一智。也不可能直接換佈景主題，換佈景主題意味著網站會有一陣子顯示佈景主題的初始預設樣式，要重新慢慢調整成想要的樣子。

佈景主題的 PHP 版本相容性問題

雖然當初那個佈景主題雖然已經不更新，但至少在 PHP 7.X 跟 8.X 環境上沒有出現難以修復的錯誤。

這輕描淡寫的一句話是很多 WordPress 老網站的通病，一些從 PHP 5.x 時期建置的網站，碰上近年一些因為資安政策，強制將環境 PHP 和 MySQL 升級到非 EOL 版本的主機商，蹦~網站根本打不開，主程式、佈景主題、套件的錯誤修都修不完，又能促進慘業經濟發展。

當然這些網站跟程式碼活得稍微久一點，就會浮現的各種問題和雜務，這才是真正的網站和系統管理實務，而不是 vibe coding 跟 AI 講幾句話就能做出一個 XXX。

也許大多數時候，業主/長官和我們卑微的工程師的立場是不同的，業主只想要網站打得開，其他的事可能是認知範圍外的事，又或者明明知道，但就是不想去管，把煩惱外包化，反正市場上一定有更低的價格。

3.媒體庫之亂

WordPress 的系統架構並不是只要把圖片檔丟到一個資料夾，然後所有程式就能直接使用這些檔案。而是SQL資料庫還要幫每個媒體檔案建立一堆 meta 紀錄，然後當使用者在網頁介面修改某些 WP 站台設定，就會生成各種尺寸的圖片和檔案目錄結構。

在各種外掛操作上傳圖片或插入圖片的時候，有些外掛存的是媒體 ID，有些是存圖片 URL，兩種設計方式各有各的地雷，但這是使用 WordPress 不可承受之痛。

當然也可以尋找更多外掛，把圖片和媒體用自己喜歡的方式儲存好，例如幫媒體檔案建立資料夾的，把媒體檔案放在外部服務或CDN的，各種自動壓縮轉檔的。

但這些外掛又各自的地雷，編輯器或其他外掛也不一定完全相容這些非 WP 原生的儲存邏輯。要是再撞上使用者的特殊需求，蹦~又能促進慘業經濟發展。

流程越簡單表示操作空間越少

媒體庫工具曾經有一個功能，使用網站媒體庫上傳並編輯圖片，再用線上的裁切功能，透明圖片會變不透明，或是GIF動態效果會消失。

聽起來好像沒什麼? 但就遇到一個情況，要更改網站的某處圖片，操作步驟就是不能直接選圖片或打圖片網址。

那個程式做成從上傳、選擇圖片，接著一定會到圖片裁切的步驟，圖片裁切完，就會發現圖片背景透明不見了。後來還是得另外想辦法繞過去。

WebP 等新型圖檔格式的時代來臨

另外，用了幾年後，2021 年的 WordPress 5.8 終於開始支援 WebP，但是要輕鬆替換之前網站內的 jpg&png 圖? 這又是另一個好問題，都可以另外寫一篇 WordPress 奇遇記了。

這當然不只是安裝一個套件就能解決的事，「輕鬆升級」後會看到某些編輯工具選擇圖片的地方出現一堆叉燒包，前台一些動態載入圖片地方變成叉燒包，或是圖片轉檔到一半，然後跳出升級付費版的通知。

一些普通網頁程式的工作流程，到了 WordPress 生態系又有不同的玩法。

4.這個網站發生重大問題/這個網站發生嚴重錯誤

本來部落格已經盡量不安裝多餘的 WordPress 擴充套件，但還是免不了每次更新系統環境、主程式、擴充套件，或是調整一些程式碼後，喜迎「這個網站發生重大問題」正能量循環:熟練地打開 Debug 錯誤訊息設定，或是上主機看 log，看是什麼地方出錯。
⭣
把出錯的套件資料夾註解掉、刪掉，找舊版本來安裝。或是改寫程式碼。
⭣
然後下次碰到官方出了更新時，又要擔心自己補的會被覆蓋掉，或是跟官方的衝突。
⭣
更新時懶得檢查，直接按更新。
⭣
「這個網站發生重大問題」
⭣
熟練地打開 Debug 錯誤訊息設定，或是上主機看 log，看是什麼地方出錯。

其他各種語言或架構的線上系統或網站，Python 亂升級版本、PostgreSQL 改一些參數，某個 npm 套件直接升級一個大版本號，程式當然也有可能會故障無法使用，但多半背後都有專門的帕魯在維護，一旦出事至少有人能讀懂錯誤訊息、查相依性、修掉不相容的程式。沒事也不會三天兩頭有人在更新。

而 WordPress 的使用者客群、主程式&套件&佈景主題的產品更新迭代狀況可能完全不同，所以有時候不能用傳統軟體工程的思維來管理 WordPress 網站，就像我們不會討論吃泡麵要怎麼才能吃得健康，煮泡麵那個水要用什麼高級水，精密測量研究泡麵要如何在煮好後還能放7天。

為什麼有專門管理 WordPress 網站的工具

我以前其實不理解為什麼有「專門為 WordPress 網站管理特別設計」的系統管理工具，底層邏輯不都是調整伺服器設定、管一個 PHP+MySQL 的網站嗎?

後來體會到那類工具存在的理由，例如這類工具多半可以:

• 在面板上直接切換是否顯示錯誤訊息
• 快速調閱錯誤訊息
• 網站後台進不去的情況下，把某套件更新或停用
• 把 WordPress 專門的謎之系統參數包裝成一個個開關
• 異地備份和快速還原
• 使用這類工具和外部廠商合作的產品，例如電子郵件、安全掃描等等

(這邊應該有個產品分潤連結)

總之簡單來說就是 WordPress 有一套開放原始碼的主程式架構，然後專門為了因應這堆破事而設計的。

「這個網站發生重大問題」這種整個網站打不開的明顯錯誤還算好的，最怕的是在某些特定操作才會出現的錯誤，或是 js 錯誤、ajax 錯誤，使用者只能看到點了沒反應，又要開始排查問題，想辦法重現問題。

有時候定期監控程式收到 Status 200 OK，首頁跟最新幾篇文章打得開，還以為網站好好的，但其實錯誤訊息被伺服器快取蒙蔽，某些功能已經掛了，比較舊的文章和管理後台都進不去，剛好進到下一點快取玄學。

5.快取玄學

講到這就不得不提各種 WordPress 的快取玄學，由於 WP 主程式非常肥大功能很多，為了笑能，市面上有各種 WordPress 的加速產品，每套產品背後都有不同的設計機制跟設定:

伺服器環境調整型

有些是伺服器端的調整，例如啟用 redis 服務、或是在主機檔案目錄產生一堆謎之檔案、或是改一些程式的 http header、或是改一些伺服器環境設定參數，把預設值很小的參數調整到適合肥大的 WordPress 網站。

但萬一設定得不好，或是伺服器某些規格太低/功能不支援，反而會跑得更慢/造成錯誤，至於什麼叫設定得不好? 除非真的去看原始碼，不然誰知道每個開關背後實做了什麼機制。

前端壓縮型

有些是會壓縮靜態檔案、壓縮頁面 HTML，降低頁面載入的大小。或是將某些前端檔案延遲載入、額外增加各種複雜的載入條件。

但有時候反而把 CSS&JS 壓到前端程式碼出錯，或是讓前端噴出一堆 JavaScript error，真是令人匪夷所思，我也不可能去看人家套件的程式碼都寫了啥，吃飽太閒嗎?

靜態化處理

有的是會把動態頁面做靜態化處理，造成有時候只是在網站修改一些內容，就要等待系統產生整個網站的靜態檔案。

還有 WP 的套件背後實作方式百百種，靜態化之後反而造成一些奇怪的故障。

CDN

有一些產品則是兼具以上的其中幾項功能，再順便賣 CDN，一旦方案額度用完，就沒有加速了，然後費用也是說漲就漲。

而且因為廠商設計成要賺 WordPress 使用者的錢，一般工程師在用的服務反而很難進到那個圈子，WP 使用者寧願每年花好幾百美元用套裝服務，而不是用量多少付多少，可能一年用不到 100 美元的服務。

總之一旦導入之後，可能舊問題沒解決，又產生了新問題。搞得有時候修改佈景主題或某些操作時，要一直清除伺服器端快取。不然效果沒出來時，不知道是自己寫錯/沒設定好，還是看到的又是快取舊資料?

有些快取暫存套件可以設定管理員自己登入網站時，不會看到快取內容，減少修改網站時的靈異現象。

但反過來說，在管理員登入後台只是為了純粹編輯文章的情況下，管理員自己反而無福享受快取帶來的加速效果，或是覺得使用者是不是平常開網站也這麼慢? 再衍生各種問題。

編輯器載入舊內容

WordPress 本身有自動儲存、版本紀錄之類的功能，但碰上瀏覽器開了多分頁+快取玄學+Markdown 編輯器+有些程式 rewrite 到其他路徑......等種種因素疊加，當碰到文章編輯介面打開時顯示「這個貼文有比下面版本還新的自動儲存版本」，又要花時間比對，讓人覺得很累。

最可怕的就是文章覆蓋問題，例如有A跟B段落要改，先改好A段落存檔，檢查前台，看到前台文章A段落有更新，接著再改B段落。但是有可能後台文章編輯區載入的卻整篇都是舊內容，要是用這個舊內容繼續改下去，就會把之前改的A文章段落覆蓋掉...。

幸好部落格只有我一個人在經營，不然在一般慘業情況下有時候又變成廠商的鍋，說網站內容被回溯，內容被偷改，有時候變成同事或員工的鍋，說別人會偷改文章，要工程師幫忙調紀錄云云。

6.表面是功能問題，本質是控制權問題

一旦有需求冒出，常常陷入這個循環:
WordPress 有這功能嗎? 大家都吹捧成這樣，不可能沒有吧。
⭣
怎麼不能用/跟想像中不一樣
⭣
找第三方套件
⭣
怎麼不能用/跟想像中不一樣/好貴
⭣
研究技術、想著自幹一套

文章摘要字數

文章列表會顯示標題、文章摘要、封面圖之類的東西，一開始好奇，為什麼文章摘要都只有一行短短幾個字?(我一開始都沒用繼續閱讀標記另外寫)，看起來不太順眼。

在文章底下顯示相關文章列表，裝了一些套件，套件本身有獨立的文章摘要字數、顯示方式的設定，但也是怎麼改都沒用，就是顯示短短幾行字。

後來仔細檢查佈景主題的程式碼，發現在 functions.php 裡面，作者有另外寫一套 excerpt_length 的 custom filter，這又接到前面那段佈景主題的鍋。感謝這個佈景主題讓人多學到一個觀念? 裝一堆套件調老半天，還不如先看佈景主題的 PHP 原始碼...

文章相關推薦

我想在文章底下顯示相關文章，「相關推薦」是一個非常大的學術性題目跟商業題目。試了幾個 WordPress 的套件，設定一個比一個複雜，全站設定有一些東西，單篇文章又有很多參數，有時候覺得我自己手動挑文章可能還更快，但設定了老半天，最後常常出來的相關文章是毫不相關的，該推薦的不推薦。

檢查程式後，發現多半是靠著分類、tag 跟文章標題在瞎推薦，效果不怎樣。

後來在其他網站使用，其實網站文章分類單純、網站都有統一主題時，勉強過得去，但就不適合我這種標題亂下，分類跟 tag 很不嚴謹的部落格，那些機制簡單的套件很難通過真正的考驗。

文章分類計數

有一次想幫側欄的文章分類清單，增加顯示該分類的文章總計數量，例如:網頁設計(20)、文書小幫手(15)這樣，那時候 WordPress 後台還是叫做小工具(widget)的時代，WP 有內建文章分類的小工具，預設還有一個顯示文章數量的開關。

把選項打開，存檔之後，不出意外的時候又要出意外了...什麼東西都沒顯示，而且不是被 CSS 隱藏，而是數字就沒被後端程式產生出來。我的文章分類沒在用特殊的第三方套件，就是用原生功能，又要開始 Debug 大賽，當然首要步驟不是先去翻程式碼，例如可以嘗試先換個佈景主題，看看是不是佈景主題有另外覆寫，或是打開顯示錯誤訊息的系統參數...

也許這就是自架 WordPress 的日常體驗，碰到需求，可能一個小開關打開，裝個套件就解決了。但也有可能又要檢查別人寫的程式，或是自己寫程式。

這跟平常有沒有多扶老太太過馬路沒關係，可能更像蝴蝶效應，例如外送員平常出門前看的一個星座運勢網站，在工程師調整 WordPress 功能的時候壞掉了，外送員看不到今日運勢，也忘了帶雨衣出門。結果下午突然下起暴雨，他全身濕透，心情煩躁地趕著送完最後一單。外送員到了工程師的鄰居家門口時，他猛力連按三次門鈴並大聲敲門，工程師寫到一半被這突如其來的巨響嚇了一跳，手一抖打翻了咖啡，趕緊清理鍵盤，擦乾淨後重新坐下，卻忘記剛才寫到哪裡，還少放了一個參數。然後工程師把星座運勢網站修好了，還將這個可能有問題的程式碼另外分享到開放原始碼專案中。然後有人用到了這段程式，想說為什麼東西顯示不出來?

迷因圖出自 Chappelle’s Show

當年的很多問題跟需求，現在看起來可能很青澀，在今天又有新做法就是了。

其他諸如此類的問題還不少，不管是自己的網站還是幫別人管網站，這種踩坑經驗不會有人討論，畢竟大部分的使用者可能連文章、頁面以外的的後台功能區都沒點過。講這些是要講給誰聽?

賣 WordPress 服務的廠商當然也不會拆自己台，一方面說系統有很多地雷、外行人難以駕馭，一方面又說系統便宜好上手? 不如與世推移，發一些「2026 年 WordPress 必裝的 10 個套件」、「這 5 個 WordPress 免費套件，讓網站流量暴增 300% 的神器 」之類的標題黨文章，成效才會好看。

畢竟這就是一個開放原始碼的套裝軟體，WordPress 部落格程式不是一行一行自己寫的，功能也不是跟別人討論出來的。而是幾個步驟安裝完成後，平白無故就有個幾十萬行的程式碼的程式讓我使用。除了以前踩過的坑之外，對整體程式結構與執行流程，幾乎沒有完整的心智模型可言。

使用 WordPress，教我最多的不是寫作和經營，而是逆向工程思維，還有文獻考證能力。

7.一個 Markdown 各自表述

從本文開頭的年份可以知道，當年這個部落格入坑 WordPress 的時候，還是傳統編輯器(Classic Editor)的時代，當年市場上還有一些 Elementor、Visual Composer、Beaver Builder 這種第三方的頁面編輯器。

等到隔年(2018)年底的 WordPress 正式版本，才開始有區塊編輯器(Block Editor，開發代號:Gutenberg)這玩意。

一開始大家都不看好 Block Editor 這玩意:

• 相關的生態系沒跟上，想要做 XXX 效果或功能? 沒有、不相容、要等更新、還在開發中。
• 看起來是對新手友善，功能遠比市場上那些第三方編輯器陽春(簡約?) 不像 webflow 或 framer 隨便點一個物件，側邊跑出幾十種的物件屬性。
• 操作概念對有些人來說難以入手，Word 之類的文書軟體用習慣了，無法理解為什麼要用這種區塊的方式來排版?
• 如果要用新的編輯器修改網站舊頁面、舊文章，更是一場災難。

只要有任何一行字跑版，任何一點小問題，這些 WordPress 老玩家就會發到網路上昭告天下，好像用了之後就會整個網站爆炸，十年心血付之一炬，你說誰會對這產品有信心?

持續再過幾年，Block Editor 的周邊生態逐漸發展，國外的廠商開始跟上投入區塊編輯器、區塊版面配置、全站編輯那些新功能。以前那種第三方的頁面編輯器也是持續肥大，佔有各自的山頭。

但這些編輯器我都沒在用，而是走在孤獨的路上，另外在 WordPress 安裝了使用 Markdown 撰文的編輯器。

每個編輯器對 Markdown 的支援性都有差異

有人可能聽過 Markdown 這東西，在一些筆記軟體、個人知識庫軟體、比較不注重視覺排版樣式的學術文件用途，或是 ChatGPT 這種 AI 工具的輸入輸出，都會用到 Markdown 這種標記語法。

這東西很好很方便，例如:

• 我可以一覽無遺內文所有連結網址、圖片替代文字有沒有放對，而不用一個一個點開檢查。
• 內文有什麼一覽無遺，而不是檢視原始碼時，複製貼上參雜一堆亂七八糟的東西進來。
• 加幾個符號就能完成各種文字編排，而不用打字打到一半用滑鼠選文字、到工具列上選樣式。
• 編輯書寫介面非常乾淨。
• AI 寫文、審稿、翻譯? 在 VS Code 隨便裝個 LLM 相關的套件，輕鬆達成。

最大的問題在於......在 WordPress 上使用 Markdown 寫文章。

先講其他的，某些天生預設使用 Markdown 當編輯格式的 CMS，還會另外設計只有他們在系統上能用的變種 Markdown 標記語法，例如:

• ![圖片替代文字](/assets/post-img/office.jpg){:class="customClass"}
• 換行不用特地加 \ (換段一樣是中間留一個空行)

但是...別的 CMS/筆記軟體/生產力工具，有特別優化 Markdown 的書寫和顯示方式，那是他們家的事，這些都跟 WordPress 沒什麼關係，不要把別的地方對 Markdown 的美好經驗帶過來。

如果別的地方編輯好的內容直接貼過來 WordPress，明明大家都是 Markdown，也絕對不要幻想最終的顯示結果會長得一樣。

WordPress 的第三方 Markdown 擴充套件也同樣有此情形，用其中一款 Markdown 編輯器編好文章，這完全沒問題。

改天看到別款 Markdown 編輯器有不錯功能，想換過去?

恭喜，有機會又來到前台排版修正檢查校對大賽。

然後因為還有一批最早的文章是從別的平台轉過來的，各種格式轉換問題還是相當可怕。

Markdown 編輯器語法多重轉換問題

WordPress 本身有自己的資料儲存邏輯，導致各種第三方的 Markdown 編輯器套件，基本上都需要在存檔，和每次和讀檔時進行某些處理，這中間過程非常容易出問題。

不管是要自己開發一個 WP 套件，還是做某種 WP 發文後自動同步到其他地方的程式，有幾種常見的方式把 WordPress 的貼文資料撈出來:

• 直接寫程式去撈 posts 資料表的 post_content 或 post_content_filtered 之類的欄位資料
• 透過某些 WP functions 撈下來
• 透過 WP REST API 撈下來

有些可以得到的已經被轉換好的 HTML，有些則是 WP 專用的標記語法，例如 <!-- wp:heading --> <!-- wp:heading --> <!-- wp:paragraph --> <!-- wp:page-list /-->，而不是一開始編輯文章時的 Markdown 語法。

如此一來就造成:

多編輯幾次後 Markdown 格式變回 HTML

有些文章可能一開始用 Markdown 寫得好好的，在不定時回去修改更新幾次之後，發現有些 h2, h3, 圖片，超連結，段落...不知道為什麼在編輯時變成 html 原始碼，或是上面那種<!-- wp:heading --> <!-- wp:heading -->標記...。

或是發生這種，讓內文莫名其妙多一堆空行

<ul>

<li>第一項</li><br>

<li>第二項</li><br>

<ul>

改掉之後，存檔，等下次要編輯時，資料再載入編輯器，又有機會變成不知道什麼鬼樣子。

網頁編輯器套件不適合拿來輸入和展示程式碼

部落格有些文章主題是網頁程式相關，WP 的 Markdown 編輯器套件用來顯示程式語法? 幾乎沒有 syntax highlight，在編輯介面很難閱讀的。

需要在文章裡面輸入成對的 HTML 標籤或一些程式語法，或是習慣用 emmet 之類各種簡寫展開工具的，這種 Markdown 編輯器套件實在是太難用了，

畢竟這些編輯器不是為了這種用途設計，就像在 Word, PowerPoint 裡面要輸入/展示程式碼也很痛苦。

但這些需求在 Visual Studio Code 輕鬆就能做到，內建 Markdown Preview，可以直接看原始碼也可以看預覽。

所以新的部落格的編輯形式，就是在本機 VS Code 撰文，然後用某些方式轉成 html 發佈到線上。

Markdown 一國兩制

其他關於 Markdown 編輯輯與顯示的問題，大概就是每一套 WordPress 套件對於 Markdown 的支援度有微妙的差異。

• 有的元素中間要空一格，例如## 標題 hash跟文字中間要空一格，有的竟然不用。
• 有的元素中間要空一行，例如## 標題 跟下一段內文上下黏在一起，就無法正常顯示，一定要多空一行，但有的又可以。
• 有的甚至無法在前台正常顯示無序項目清單/有序項目清單、表格等等。
• 還有巢狀大魔王，例如表格包項目清單，項目清單子層又有另一組項目清單......等等。

還好我不需要輸入什麼公式，Markdown 顯示不出來，那就直接打 HTML 吧? 那就又回到上一點的問題，這種編輯器顯示程式碼非常難閱讀、難輸入。

雖然在 2023 年後，有時候可以直接把那種無法正常顯示的 Markdown 丟給 LLM 轉成 HTML，但就是又多一道工。

還得小心檢查 LLM 有沒有在處理資料時偷改內文...

更換編輯器可能導致舊文章亂掉

這種編輯、存檔、實際顯示的轉換問題，也導致其他效應。

如果想換回 WP 原生的區塊編輯器，當修改舊文章，編輯器載入的是常常亂七八糟的東西，沒有顯示成正常的樣式，也沒有使用正確的區塊元件。

為了換編輯器，還要幾百篇文章，一篇一篇回去檢查跟修改嗎? 我才不要。

HEX 色碼自動變成 hashtag

文章內文有時候會有 HEX 色碼(例如 #0066CC)，有些 Markdown 編輯器不知道為啥會把 hex 色碼自動變成 WP 的文章標籤，還要手動去刪，非常困擾。

WP 原生的區塊編輯器是沒有這種怪毛病，交叉測試下，只要用特定一些 Markdown 編輯器就會有這問題，這可是世界上最好用、最適合所有人的 WordPress，怎麼需要我去翻閱套件的原始碼呢?

編輯器對特殊符號的判斷

這些 WordPress 的 Markdown 編輯器有幾種常見的形式，各種一些干擾寫作的問題:

• 所見即所得模式，輸入一些 Markdown 特有的符號之後，後面的文字會改變樣式。
• 原始編輯模式，編輯器只會有一些簡單的顏色標示，按下預覽按鈕，才會顯示出 Markdown 解析後的結果，但是又跟實際網站前台套上 CSS 樣式的情況差很大。
• 有一個專門區塊讓人輸入 Markdown 語法，然後按下按鈕，把 Markdown 解析之後，轉成正常的顯示方式。

當文章中要輸入一些特殊符號，例如我要說「這張圖是 800*600px」「某某的範圍是100~200ms」之類的，前述的有些 WordPress Markdown 編輯器就會把 * 和 ~ 當成 Markdown 語法，把符號刪掉、把後續文字變成其他樣式，或是整大段的文字顏色都不對勁了。

要嘛加一堆跳脫符號，例如 800\*600px，要嘛嘗試改變輸入方式，例如 800x600px。那今天要是想輸入顏文字呢? 真是一場惡夢。

然後還是那件事，改天再回來編輯，內容從資料庫儲存的字串，經過層層轉譯，顯示在編輯器，這些編輯內容又有機會顯示得亂七八糟，或是存檔後變得亂七八糟。

文字游標位置

例如在內文行內輸入 emoji，接下來後面的文字游標位置就會亂跑。要插入文字、刪除文字時，文字游標都卡在奇怪的位置，十分影響編輯體驗。

Caret Position Issues 算是一種經典工程問題，這些 WordPress 編輯器套件到底有啥問題，我也不想去查了，毀滅吧，趕緊的，累了。

插入圖片

有些 WordPress 的 Markdown 編輯器，插入圖片時產生的不是 Markdown 原生的圖片語法，而是產生一段 HTML。

幸好不太影響使用，因為我不是旅遊美食部落格，文章不需要插入一大串檔名叫什麼 IMG_5566 的照片，我的圖都有語意化命名，WordPress 的優點是圖片上傳之後不會強制變成 uuid 之類格式的名稱，所以光看每張圖的圖片檔名，大概知道是哪張圖。

但 WP 主程式更新 5.6 之後，插入圖片預設都會帶入一大串 Markdown 跟 HTML 混雜的 code，類似這樣:

要嘛手動刪掉，或是自己再加幾段 function filter 把多出來的東西清掉，但只要WP主程式保持更新，這種小地方不時冒出來整人，影響編輯體驗。

有些需求則是天生不適合 Markdown

這邊要講的，不管是 WordPress 上各種第三方的 Markdown 編輯器套件，還是其他網頁開發框架+CMS 是用 Markdown 編輯內容，或其他 Markdown 當預設編輯格式的文書產品，都會碰到。例如:

• 想要內文 AWD，有些文章圖片，在電腦上看剛剛好，在手機上縮太小很難看，正常在網頁設計會做好幾張圖，電腦大螢幕跟手機小螢幕上顯示不同的圖片，這種需求在 Markdown 不好達成。
• 想要幫文字加顏色，或是在 blockquote 中幫文字加顏色(blockquote 在 Markdown 又有另外的標記方式)，在 Markdown 也是又麻煩了起來。
• 想要 Markdown 與 HTML 混排，例如用 HTML 做一些 <detail>&<summary>，裡面再包 Markdown 的東西，通常會爛掉。

Markdown

很難排出這種文字樣式

諸如此類的需求還有很多，部落格文章在瀏覽器顯示，說穿了也就是網頁，WordPress 網頁上最終顯示的也是 HTML 和 CSS，這種在網頁設計上稀鬆平常的需求，但想要在 WordPress 編輯文章時輕鬆一點? 不要有太多期待。

還有一種江湖流派，為了解決 WordPress 上各種 Markdown 編輯器套件很難用的問題，發展出在 Notion 或某些筆記軟體寫文章，然後寫個轉檔程式或 n8n workflow，把文章丟到 WordPress 來發。

這種做法是挺有趣，有些商業軟體的 Markdown 線上編輯器也漂亮又好用。但我不想再增加一個外部服務，每引入一個商業化營運的平台，就等同於在工作流程裡多增加一個潛在的故障點。

我盡量把 Markdown 的問題在這點寫完，沒在用的可以可以忽略。

沒有人是局外人

其他人也不要想說...又沒另外安裝 Markdown 套件來編輯頁面和文章，與他何干?

只要用其他第三方編輯器來編內容的，整個編輯介面都被替換掉，而不是只是區塊編輯器中的小模組，或是內文插入一堆 WordPress 短碼的。

都有機會在更換編輯器、套件停用後，讓網頁前台顯示一些充滿錯誤的內容殘渣，又可以舉辦前台排版修正檢查校對大賽。

逃離 WordPress

問題忍了這麼多年，真正想逃離的契機，是剛好碰到主機到期。

接著開始講我為逃離 WordPress 做了什麼準備，這邊又不得不提 WordPress 有很多搬家備份玄學:

WordPress 備份搬家工具的坑

• 有些備份功能只是匯出一個文字檔，不包含媒體檔(圖片)或其他站台設定。
• 有些套件看似非常完美，可以把整個網站打包成一個套件自己的專門格式，輕鬆匯入匯出到別的網站，但是檔案超過一定大小就要購買付費版，每年繳錢。
• 有備份還原是一回事，內文內頁的圖片路徑、內文互連網址要取代又是另一回事，每個步驟要分開操作，不是一鍵無腦匯入匯出。
• 有的備份是免費的，還原要付費，或是還原的某些特殊功能要付費。
• 有些備份方案是以單一主機、單一服務為前提設計的；當用 Docker 架構架 WordPress，依照服務拆分成多個 container 後，這些搬家工具還是正常執行，但跑完之後發現要嘛檔案沒搬到，要嘛資料庫沒搬到，而且還要自己補一堆額外設定。
• 有些備份只會備那幾個 wp-xxx 的東西

例如我有開一個 demo 資料夾放一堆測試用的東西，或是開其他資料夾放小程式、在 htaccess 寫一堆額外的規則、網站根目錄下有一堆額外的檔案，這些額外客製的東西，很多備份套件是不會去處理的。

這也是網路上一堆 WordPress 備份教學都不提到的事情，就是要讓大家踩坑，然後吸引顧客上門。這也是「WordPress 搬家」這類服務最常起糾紛的事情，後來接手的人沒有權限看到那些檔案內容，當然也就無法完整的搬家。

如果沒有要繼續用 WordPress

上述是把一個 WP 網站資料轉移到另一個 WP 網站，但既然我以後沒有要用 WordPress，那思路就打開了，有非常多方式可以把網站內文都撈下來。

例如只是要把 WordPress 文章備份成每篇一個 md 檔案，可以隨便上網找個 https://github.com/lonekorean/wordpress-export-to-markdown，在本機跑一個 Node.js 程式，跑完之後文章就會通通變成 Markdown 檔案躺在自己電腦裡。

我當年用的時候還要記得把文章都設成公開，程式才抓得到，現在好像沒這問題。但難免又會有 HTML 轉換成 Markdown 的一些排版跑掉的問題，要自己檢查。

幸好文章評論用的是外部系統，只要搬家前後每篇文章的 URL 都保持一致，所以不用特別煩惱任何會員系統、留言系統的遷移事項。

想說先把網站移到別的地方。版面用了這麼多年，順便改改吧?

WordPress Headless 時期

先用 Headless CMS 的方式，WordPress 網站擺在另外的域名底下，需要編輯文章，就從另外的網址登入後台操作，

本來的公開網址則是重新寫一套前台程式，去呼叫另一個網站的 WordPress REST API。

好處是公開的前台站台幾乎沒東西，再也不用擔心那些常常被 try 的 URL，哪一天真的被 try 出什麼東西。

缺點是:

• 在主機管理上，這樣要維護兩個網站，有各自的 SSL、子域名、各種伺服器設定等等。
• 內文總會放圖片，那個圖片網址還是會暴露那個「真正的 WordPress 網站」，又要想辦法藏。
• 到處都有絕對路徑連結，例如內文的連結，文章清單等等，還是會暴露那個「真正的 WordPress 網站」，前台顯示時還要想辦法處理。
• 如果只是單純用一些前端框架直接呼叫 WP REST API，基本上會看的人只要打開瀏覽器 DevTool，也能看到「真正的 WordPress 網站」的網址。
• WordPress 本身修改佈景主題和其他視覺化修改版面的功能，直接武功全廢，不過反正本來就不想用了。
• 要再自己呼叫 WP REST API 把這堆頁面功能做出來：文章單頁/文章列表頁/日期彙整頁/分類文章列表/標籤文章列表/頁面/首頁/404。其餘像是 RSS Feed、sitemap 之類的東西都要另外再寫，但是自由度也更高，那時候還沒有像現在的 AI 寫程式碼的玩意。
• 有些 WP REST API 的設計方式，得要打好幾次才能得到組出完整資料。例如文章列表要顯示每篇文章的封面圖，要先呼叫 posts 拿到 featured_media 的媒體庫檔案 ID，再用 ID 和一些參數(例如圖片尺寸)去呼叫媒體庫的檔案 URL，容易讓首頁、文章清單等頁面的載入時間大幅拉長。

因應藏網址問題，前端站台就不是真的純靜態網頁了，又要搞些特殊設計。

因應洋蔥 API 問題，後來做成先預處理，把一些內容存成靜態 json 檔案。結果不小心越做多，幾乎整個站台會用到的檔案都處理了。

前台程式的技術選型，那時候選的路線是 Vanilla JS+TailwindCSS+PHP，盡量使用瀏覽器的原生物件和API，減少使用第三方套件。

如果當年有導入以下這些，現在來看又是一場悲劇:

• 2016 年出的 Vue2 (2023 年 EOL，然後 Vue3 大改版)
• AngularJS (2021 年 EOL)
• Gatsby，曾經紅極一時的 SSG，後來被收購後，產品就...
• 把 Bower、Gulp、Compass 這些整合進專案內，現在根本不能用

每次當文章有新增修改或某些操作時，就要更新預處理靜態 json 檔案，這用 WordPress 的 hook 寫幾行程式碼，自動觸發就完事了。

完全拋棄 WordPress 時期

既然網站內容都已經逐步變成一堆靜態 json 檔，那 WordPress 網站就可以關掉了。

接著重新規畫了一套 Markdown 寫作流程。

圖片的部分暫時先保留 WP 原本的網址結構 /wp-content/uploads/2024/10/img.jpg，實際背後會去呼叫放在雲端物件儲存服務上面的檔案，網站伺服器內壓根兒不放文章圖片。

小結

曾有計畫改成更像網頁設計師&工程師的個人網站，但計畫無限拖延。總之部落格在拋棄 WordPress 之後又營運兩年了，後悔當初沒有早點走，在 WordPress 身上浪費生命。

至於後來之後做的部落格又導入了什麼第三方的玩具，每種決策又帶來什麼地雷，以後有機會再寫吧，這種事情是永遠沒有做完的一天的。

手上還是有其他 WordPress 網站，而且有些程式客製化到從會員系統到後台都形存實異，如果說 WordPress 是一個屎坑，自己寫程式也有一些屎坑，那客製化 WordPress 程式就是雙重屎坑，有些功能用 WordPress 可以輕鬆達成，但也同時擁有兩者的缺點。

我推薦 WordPress 嗎?

每個人都有自己的用法，對於不想管 IT 的人而言，WordPress.org (WordPress 自架站)肯定是現代要線上寫作、發佈線上內容，值得推薦的工具之一。其他還有一堆商業平台，例如 Medium、方格子、Substack、WordPress.com(官方代管) 等等。

但「值得推薦」這回事，就像如果有人要換平板電腦，我會說 Apple、Samsung 或某些品牌有什麼特色，可能符合對方的預期，但不代表 iPad 是完美無缺的，Samsung 的平板是完美無缺的。實際上還是要根據每個人的需求而定。

所以說做事都要從需求出發嗎? 是也不是，更多時候是商業問題。

對於一般使用者要找廠商來伺候他的角度而定，常常變成...

• 廠商有賣什麼，就會狂推自家有賣的產品；
• 廠商不賣什麼東西，就要講一堆其他產品的壞話，把其他產品批評得一文不值。

使用者當然多半沒有分辨的能力，廠商就像 ChatGPT 會順著使用者的意講好話，外行人無法輕易分辨哪邊有問題。

覺得自己的需求好像跟廠商的產品吻合? 之後故事的發展只有上帝才知道了，可能每年都在搬網站，每年都在熟悉新系統，還邊用邊嫌，每個禮拜找外面的廠商來談理想和抱負。但其實某些需求，可能就找個工程師，好好寫個程式就能解決。

但談錢傷感情，最近剛好看到 Pixnet 系統大更新不太順利，引發諸多抱怨。系統商營運肯定有很多成本，但使用者願意付出嗎? 消費者心態我也了解，有些人會說經營網站或部落格沒有賺錢，所以廠商也不應該收錢。本來想說點什麼但還是算了。

ps.本文封面圖靈感來源:They don't know 迷因