最根本原因就是，我已經沒有太多心力在維護系統上，加上Wordpress功能太強也相對容易被攻擊。其實我後來每次登入都是累積20+未更新的plugin……，你可以想想我的主機洞有多大… 再加上我的主機太久沒維護，都不知道累積多少未處理的CVE了……

我現在的考量是，舊部落格內容會全部保留繼續上線。但是要做靜態化處理拔掉後端。 至於舊留言就在做靜態化的時候就一起包進主文裡不再更動，然後外嵌新的留言系統，讓舊文還能繼續保有留言的功能。 靜態化完成之後，後端主機就關閉停用，然後就是整個舊站上線封存不再更動了。

靜態化前的處理：處理現有會綁後端的舊功能

停用所有會用到後端有關的功能、Widget小工具。所以我直接把右側sidebar那邊會用到後端的全部都拿掉了。

站內搜尋

直接放棄，反正現在的舊文全部都是過時內容，大概也用不到了。真的有需要，借助Google搜尋就好了，反正我會繼續讓舊網址繼續生效。

規劃靜態化後的留言功能要何去何從？以及難度如何？

這個對部落格來說算是極其重要的功能，所以針對這需求，我有想過三種情況

保留所有舊留言，不再開放新留言

這是最簡單也是最不需要額外做處理的解法。

關閉留言功能以後，讓靜態化plugin自然的跟著文章頁面一起打包就行。

保留所有舊留言，外嵌新的留言系統混合使用

其實這本來是我打算要採用的方式，已經確定在Wordpress後台的「外觀」→「佈景主題檔案編輯器」，可以直接修改comments.php區塊，把comment_form這段註解停用掉就可以關閉新留言輸入框，也可以用這段來插入外嵌留言服務用的區域。

變成舊留言是隨著主文內容一起打包，新留言則是以新留言系統外加上去的。

將所有舊留言全部轉移到新留言系統

這算是最漂亮的解法，舊留言搬到新留言系統以後，全面改用新留言系統（前提是新的留言系統有支援匯入功能）。

這個方案是我決定用Disqus這家，並且是以Wordpress Plugin形式安裝之後，才發現有匯入舊留言的功能。

留言系統的選擇考量

Disqus

老牌，雖然這家聽說已經是賣給廣告公司，但是目前看到穩定運行的留言系統除了Github類型以外，就只有這家了（其他的我不太敢用，不知道會不會突然倒閉然後留言資料來不及搬）。 

然後讓我比較意外的是Disqus有匯入舊留言的功能（Wordpress Plugin），所以也不用考慮新舊留言混合方案了，全部移到新的留言系統就好了。

Github類相關（utterances giscus gitalk）

其實這三個我有比較過，不過這三家各自的優缺點會再另外寫文詳述，今天這邊只大略說，如果選Github類型的，基本上真的要留言的訪客也需要註冊Github才能留言。因為考量到舊站舊內容不一定全是技術類的，所以在舊站就不挑這類型的。（但是新站確定要用gitcus，理由有空會在新站說）

其他家的留言系統

基本上因為不夠老牌，我不太敢用，因為留言資料基本上就是交給最後選定的這家，所以要是突然倒閉來不及把資料搬走就…。

也不考慮自架，因為這邊舊站都要封存了，我不會有心力再維護後端了。

更換留言系統成 Discus

基本上安裝官方的Wordpress Plugin就可以了，安裝之後會全面把Wordpress整個留言系統都被替換成Discus，會看不到原先在Wordpress內建留言系統的留言。而且在Wordpress後台也會直接把Wordpress內建留言系統的相關選單直接隱藏。

但是Discus WordPress Plugin有做舊留匯入功能，基本上可以把所有的舊留言全部搬過去。

將本站靜態化 – 使用 Staatic Plugin

目前找到最能用的Wordpress Plugin 就是Staatic這家了，主要是這家的免費版就足夠使用，會把完整頁面包含舊留言都會一起打包進來。

• Staatic https://wordpress.org/plugins/staatic

這家Plugin的原理其實就是一整個爬蟲，會正常瀏覽你的全站所有頁面，把所有頁面都打包進來。所以前提就是要確定你的網站是公開上線的，而且URL Rewrite是正常運作的。

先前也有考慮過其他家的plugin

• Simply Static: 免費版好像不能把Wordpress系統的舊留言一起靜態化打包進來，所以我當初為了這需求而不用這家。不過後來才發現我最後選用的Disqus留言系統可以直接匯入所有舊留言，所以其實就沒有不能包含Wordpress留言系統舊留言問題了。
• WP2Static: 很多教學文主推，不過這個已經死掉了，我嘗試下載zip庫存版本硬裝，Wordpress系統還不給裝。

設定404頁面

對應到設定選項：Staatic Settings→Advanced→Page Not Found Path

這邊我有手動修改404輸出檔案要輸出成 404.html 來用，這樣就可以和Github Pages自訂404頁面的方法對應上了。

Deploy to files

對應到設定選項：Staatic Settings→Deployment

他雖然有Deploy to Github Pages的功能，不過要另外申請API Key看起來很麻煩。我只想簡單了事。所以選擇「Deploy static site to Local Directory」到檔案資料夾之後，我再手動ssh進主機，手動git push上去。反正我這個舊站現在的目的就是封存，之後不會再頻繁更動了，所以想說這部份簡單做就好。

不過如果你的目的只是為了靜態化加速，沒有要封存的話，還是建議設Deploy to Github，之後在編修文章時能自動處理會方便很多。

略過特定檔案

對應到設定選項：Staatic Settings→Deployment→Retain Files/Directories

他預設Deploy時會自動清空該資料夾的所有檔案，但是因為我要搭配git和Github設定的Domain Name，所以要把這兩份檔案資料夾略過

• git
• CNAME

靜態化後的踩坑：Discus + WordPress 整個靜態化之後功能失效

因為靜態化後的網址會不同，原先我用Wordpress plugin形式安裝的Discus好像還是會和後端的東西有關連到，一旦轉到靜態站之後，外嵌留言就會壞掉。會在網頁實際出現「我們無法載入 Disqus。如果您是管理者請見我們的除錯指南。」

我是開檢查元素之後才發現Wordpress後端站與靜態站送給Discus的Request是不一樣的，這樣比對之後才知道需要手動額外設定。

所以我直接去Wordpress後台：「外觀」→「佈景主題檔案編輯器」，直接對 single.php 單篇文章模板直接插入控制disqus_config參數的JS，具體步驟如下：

建立assets/js/disqus-config.js 檔案

function loadDisqusConfig(pageUrl, pageId) {
  window.disqus_config = function () {
    this.page.url = pageUrl;
    this.page.identifier = pageId;
  };
}

設定inc/assets.php

    // Disqus
    wp_register_script( 'disqus', get_template_directory_uri() . '/assets/js/disqus-config.js', array(), '1.0.0', true ); // 加入此行

    // Register theme scripts.
    wp_register_script( 'vs-scripts', get_template_directory_uri() . '/assets/js/theme.js', array(
      'jquery',
      'object-fit-images',
	  'disqus', // 加入此行
    ), $version, true );

在single.php單篇文章那邊加入

<script src="/wp-content/themes/showme/assets/js/disqus-config.js"></script>
<script>
  // 避免靜態化工具對 this.page.url 產生破壞，改為 JS 拼接
  const protocol = "https:";
  const slashes = "//";
  const domain = "blog-legacy.yuaner.tw";
  const path = "<?php echo esc_js(parse_url(get_permalink(), PHP_URL_PATH)); ?>";
  const pageUrl = protocol + slashes + domain + path;
  const pageIdentifier = "<?php echo get_the_ID(); ?> <?php echo esc_js( $post->guid ); ?>";

  loadDisqusConfig(pageUrl, pageIdentifier);
</script>

你可能會問為什麼single.php呼叫的這段要故意拆字給JS處理呢～？因為實測發現，即使是直接把網址寫死，但Staatic在render產生靜態頁檔案的時候，還是會主動強行把我寫死的網址改掉，導致Discus留言功能還是壞掉的。所以我後來對策是拆字，然後由JS前端來拼湊組合出完整的網址字串，來避開後端產出靜態內容後被Staatic強改的困擾。

靜態化後的Duscus文章留言初始化

五年內的留言可以用同步的方式讓Discus對該篇文章初始化

過久的就只能手動在Wordpress站一個個正常開啟文章，讓Discus對該篇文章初始化後，才能開始留言。（本來想說要寫自動點開文章的爬蟲腳本，不過後來我還是人肉手動一個個點也比寫腳本省事，就這樣處理完了）

Staatic成功產生出靜態化網站資料夾後

簡單開個測試用小站（以apache2為例）

/etc/apache2/ports.conf

Listen 81 # 新增一個要啟用的Port

/etc/apache2/sites-available/wordpress-static.conf

<VirtualHost *:81>
        DocumentRoot /var/www/html/wordpress-static
</VirtualHost>

然後做 a2ensite wordpress-static 和記得重啟 systemctl reload apache2

上傳到Github Pages上架

打包完成之後，我是直接 cd 到已產出靜態包資料夾，然後手動當場做 git init 、git add –all 、 git commit -m ‘init’ 。後續有更新的話，就是靜態產完之後，在add和commit和push處理。

網址規劃調整

• blog.yuaner.tw （常駐開放）
  • 目前暫時設301導轉，以網址右邊字串結構原封不動，暫時一律導轉到blog-legacy.yuaner.tw
  • 之後新部落格正式上架，就會改掛這個網址了
  • 有在考慮透過CDN層設定舊網址導向到舊站用網址，不過之後有心力再弄吧～
• blog-legacy.yuaner.tw （常駐開放）
  • 現在這個舊部落格就轉移到這個網址封存了。
  • 一開始是先把整個這個Wordpress系統掛上這網址。現在做完靜態化處理之後，已經將這個網址改掛靜態化後的主機（其實就是Github Pages），之後這個就當作我以前的歷史回憶吧～
• xxxadmin.yuaner.tw （我自己內部用）
  • 舊站靜態化之後搬去靜態網頁空間主機，把blog-legacy.yuaner.tw網址取代掉了。而原始的Wordpress系統站就另外開設這個網址掛上來。後續就只有這邊能登入Wordpress管理後台。
  • 靜態化完成之後，Wordpress這個主機就會關閉停掉。如果偶爾要回來處理舊站的話，就會把這個主機開回來，然後處理完重新產生出新的靜態化版本上架之後就會關閉這台主機。
• xxxadmin.yuaner.tw:81 （我自己內部用）
  • 同Wordpress主機，只是產完靜態化網站包之後，在上傳Github Pages=之前，還有地方可以測適用。
• blog-stage.yuaner.tw （測試中）
  • 新站測試中，敬請期待！之後會移除這個網址，然後正式掛到blog.yuaner.tw主站去！！

其實我本來還有考慮把這個舊站搬遷至wordpress.com

想說反正主要目的是為了封存不再維護更動了，然後wordpress.com 線上版架構本來就一樣，而且wordpress.com線上版本來就是會專人維持維護營運就不用我再親自管了。不過後來有發現幾個大問題：

• 需接受被內容審查
  • 雖然這點所有線上版都一樣，不過我的情況更慘，才剛剛匯入就被平台當垃圾內容自動Ban掉整個帳號。而且免費帳號還不能用即時客服，後來是找到申訴連結以後，寫信申訴才處理好。
• theme必須更換成wordpress.com提供的：這點我也還能接受，利用他提供的theme盡量調到接近先前的樣子就行。
• 網址域名必須用他準備的xxx.wordpress.com
  • 這點我也還能接受，因為我的目的主要就是封存舊站，我只要把舊網址做301導轉就行。
• 致命傷：網址結構必須用 /2025/06/sample-post/ 這串
  • 這會直接導致和我現在的網址結構：/%category%/%postname%/ 不合，完全無法以轉址規則的方式讓舊網址

我這邊的主機線路是：
對外網 — Cloudflare — Reverse Proxy — WordPress

Cloudflare設定的地方在

Dashboard→「SSL/TLS」→「概觀」→「自訂SSL/TLS」那邊

一個解法：Cloudflare走flexable模式

好處：簡單方便 缺點：是強制主機送https超連結，主機自身自己不知道有https，容易造成線路混亂。

我的網路線路就是：

WordPress主機視角: 全程都是http，不知道自己是https

從Cloudflare到Worepress這段走80純http，但是對外到Cloudflare這邊走https。
因為Wordpress自己不知道是走https，所以由Wordpress輸出的所有連結都會是http，必須手動改設定強制都送https超連結。

改wp-config.php 強制開 HTTPS：

$_SERVER['HTTPS'] = 'on';

另一個解法：Cloudflare走full模式（我最後採用的方案 ）

缺點：設定麻煩一些 好處：可以讓目標主機知道

我的網路線路就是：

WordPress主機視角: 雖然傳輸是http，但可以從封包header知道現在是https

然後Reverse Proxy這層要加入以下內容，讓可以識別是不是https的header能正確傳給Wordpress那邊：

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;

wp-config.php

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

本來想說這篇寫在新站，不過想想是和Wordpress有關，所以還是先當作這裡Wordpress舊站的倒數兩篇吧～

參考資料

• https://medium.com/@tyh409700530/nginx-reverse-proxy-wordpress-in-https-mode-a21658f23978