用了 7 年自架 WordPress，最後還是決定自架部落格，網站營運不花錢

前情提要:在 N 年前(2017)提到 從 Logdown 搬出來啦，這個部落格一開始是在一個免費的寫作平台 Logdown，後來因為平台的開發者跑去對岸搞其他更賺錢的事業，疏於維護他的平台，於是我跳船到自己架 WordPress 的行列，主機也換了幾間，看看是不是真的有那些商人吹得這麼美好?

有人稱讚 WordPress 優點，對他而言可能是優點，也有可能是在賺分潤，像有一間無限流量的 WordPress 每個月只要台幣 100 多塊，還不用自己管伺服器......好險，差一點又開始推銷了，只講亮點、不講代價。無忌你要記得，越說自己毫無問題的生意，越會在你最累的時候爆最難修的雷。

結果在 2023 年，我決定讓這個部落格脫離 WordPress 的魔爪，還是自己寫程式最自由。
1.除了域名之外，其他都不花錢。
2.自由修改。
3.打開 VS Code 就可以寫文章，不需要打開瀏覽器，也不需要登入後台。
4.WordPress 又有可怕的新漏洞? 干我屁事。

本來是分享一些心得，結果一直拖到 2025 年快過完了還沒寫完，決定拆成幾篇。

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

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

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

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

我就是不需要複雜的技術架構，不需要仰賴什麼所見即所得編輯器、版面設定、主題切換，直接就能寫文章，改版面。我也不需要複雜的權限管理、檔案管理、外掛管理、資料庫管理等功能。

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

1.刺激的網站資安問題

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

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

用 WordPress 做網站可以過得很快樂，前提是從來不去看 access log，也不安裝登入失敗的鎖定套件。一旦看了，就會發現自己其實一直站在攻擊清單裡。

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

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

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

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

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

文章有時候會放一些程式碼，例如一些工具教學提到的內容或指令，有時候是可以跟訪客讀者互動的 JS 小程式。

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

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

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

當然不能說主機商的保護機制，或是他跟上游廠商買的工具有錯。反正我不玩了，選擇其他方式，能保有更多控制權和自由度。

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

有裝一些資安通報類的擴充套件，功能概述是會自動比對 WordPress 網站內安裝的套件與其版本，有沒有出現在全球資安漏洞通報庫中，有的就會用各種方式通知網站管理員，要嘛寄各種 New Vulnerability Detected、Your site may be in danger 的通知信，要嘛顯示在 WordPress 網站後台各處。

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

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

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

既然有些工具的機制只是檢查已知套件，那就有很多方法可以繞過去，或是達成同樣的功能，但不要用套件。

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

2.佈景主題停止更新

2017 年前搬來 WordPress 時，隨便選了一個看似順眼的免費佈景主題，灰色+白色+Tiffany Blue 的配色，改一些樣式就繼續用。

經過時間的洗禮，我深刻了解到 WordPress 佈景主題不是只有表面上看到的視覺樣式，還包含對每個程式頁面 archive/category/single post/tag/search 等一堆頁面的頁面元素的樣式和設定，還有牽涉後台能直接視覺化調整的：header/footer 的排版、選單位置、側邊欄配置、文章列表的呈現方式、文章內容的版型、特色圖片的尺寸和位置、字型和顏色系統。這些設定都是佈景主題的重要組成部分。

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

不理想狀態就是經過時間的洗禮，讓人深刻了解到 WordPress 佈景主題不是只有表面上看到的視覺樣式。因為我用到一個已經停止更新的佈景主題，佈景主題的前端檔案裡面，一堆有的沒的 JS 和一些 IE 時代的 CSS 寫法，想把 jQuery 拔掉也會有問題。

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

理想的處置是另開個測試站，一支一支檢查檔案，把佈景主題的過時程式全部重寫；翻閱 WordPress 那些主程式的開發文件，把佈景主題的檔案大改一番，改完再移回來。

或是挑一個新的佈景主題，調整樣式到自己喜歡的樣子，改完再移回來。

但想到就懶。

如果時間重來

如果時間重來，我可能會選一些付費的佈景主題大廠，他們也會出一些基本功能的免費佈景主題。

雖然這種基本版功能被閹割過，要騙人去買他們的完整版付費佈景主題，日後還有可能被綁死在他們的生態中，但至少在資本市場這個公司&員工有錢賺的概念下，多半會持續更新維護，或是享有他們自家的生態系的優點。每套佈景主題也是有各自的地雷，但這種事就是不經一事不長一智。

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

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

當然這些網站活得稍微久一點就會浮現的各種雜務，對於覺得 vibe coding 跟 AI 講幾句話就能做網頁的人，可能是認知範圍外的事，基層工作人員在講一些天方夜譚。反正只要網站沒出事，就沒人在意。

3.媒體庫之亂

WordPress 的系統架構並不是只要把圖片檔丟到一個資料夾，然後所有程式就能直接使用這些檔案。而是資料庫還有一堆紀錄，然後修改某些站台設定，就會生成各種尺寸的圖片和目錄結構。

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

當然也可以尋找更多外掛，把圖片用自己喜歡的方式儲存好，但這些外掛又各自的地雷，編輯器或其他外掛也不一定完全相容這些非 WP 系統原生的儲存邏輯。要是再撞上使用者的特殊需求，蹦~又能促進慘業經濟發展。

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

聽起來好像沒什麼? 但就遇到一個情況，要更改網站的某處圖片，操作步驟就是不能直接打圖片網址，然後從上傳、選擇圖片，那個程式做成一定會到圖片裁切的步驟，圖片裁切完，就會發現圖片背景透明不見了。後來還是另外想辦法繞過去。

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

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

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

本來部落格已經盡量不安裝多餘的 WordPress 擴充套件，但還是免不了每次更新系統環境、主程式、擴充套件，或是調整一些程式碼後，喜迎「這個網站發生重大問題」，下一步就是熟練地打開 Debug 錯誤訊息設定，或是上主機看 log，看是哪一支檔案的哪一行出錯，然後把出錯的套件資料夾註解掉、刪掉，或是改寫程式。

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

後來體會到那類工具存在的理由，例如可以在面板上直接切換是否顯示錯誤訊息、調閱錯誤訊息、把某套件更新或停用、把 WordPress 專門的謎之系統參數包裝成一個個開關，簡單來說就是 WordPress 有一套開放原始碼的主程式架構，然後專門為了因應這堆破事而設計的。

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

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

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

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

5.快取玄學

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

有些是伺服器端的快取機制，例如用 redis 服務、或是在主機檔案目錄產生一堆謎之檔案、或是改一些程式的 http header、或是改一些伺服器環境設定參數。

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

有些是會壓縮靜態檔案、壓縮頁面 HTML，但有時候反而把 CSS&JS 壓到前端程式碼出錯，真是令人匪夷所思。

有的是會把動態頁面做靜態化處理，但是 WP 的套件背後實作方式百百種，靜態化之後反而造成一些奇怪的故障，要是碰到有會員機制或電商網站，情況更為複雜。

搞得有時候修改佈景主題或某些操作時，要一直清除伺服器端快取。不然效果沒出來時，不知道是自己寫錯/沒設定好，還是看到的又是快取舊資料?

有些快取套件可以設定管理員自己登入網站時，不會看到快取內容，減少修改網站時的靈異現象。
但反過來說，在管理員登入後台只是為了純粹編輯文章的情況下，管理員自己反而無福享受快取帶來的加速效果，或是覺得使用者是不是平常開網站也這麼慢。衍生各種問題。

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

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

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

6.表面是摘要問題，本質是控制權問題

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

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

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

其他諸如此類的問題還不少，畢竟 WordPress 部落格程式不是一行一行自己寫的，也不是跟別人討論出來的，而是幾個步驟安裝後，平白無故就有個幾十萬行的程式碼的程式讓我使用。除了之前踩過的坑，對整體程式結構與執行流程，幾乎沒有完整的心智模型可言。

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

7.一個 Markdown 各自表述

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

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

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

• 相關的生態系沒跟上，功能遠比市場上那些第三方編輯器陽春(簡約?)
• 操作概念對有些人來說難以入手，Word 之類的文書軟體用習慣了，無法理解為什麼要用這種區塊的方式來排版?
• 如果要用新的編輯器修改網站舊頁面、舊文章，更是一場災難。

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

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

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

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

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

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

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

問題在於......在 WordPress 上使用 Markdown。

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

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

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

如果別的地方編輯好的內容直接貼過來 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 原始碼...。

或是發生這種，將導致內文莫明其妙多一堆空行

<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，類似這樣:

[caption id="attachment_8538" align="alignnone" width="1000"]<img src="/wp-content/uploads/2024/05/img.jpg" alt="圖片替代說明" width="1000" height="656" class="size-full wp-image-8538" /> 圖片替代說明[/caption]

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

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

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

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

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

我盡量把 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 時期

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

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

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

缺點是:

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

因應這種洋蔥 API 問題，後來做成先預處理，把一些內容存成靜態 json 檔案。

WordPress 後台那邊多寫幾組 hook，當文章有新增修改或某些操作時，會觸發預處理程式，更新靜態 json 檔案。

完全拋棄 WordPress 時期

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

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

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

小結

後來之後做的部落格又用了什麼特殊功能，每個功能又有什麼坑，就以後再寫吧，這種事情是永遠沒有做完的一天的。

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

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

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

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

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

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

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

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