Wordpress

wp-config.php 常用設定:10 個開關一次看懂

多數人以為 WordPress 安裝好、後台能登入,wp-config.php 這份設定檔的任務就到此結束,從此不會再打開。安裝精靈確實會幫你把資料庫主機、帳號密碼、資料表前綴這幾項「不寫進去網站就打不開」的基本資訊填好,但除錯模式要不要開、記憶體上限夠不夠用、後台的檔案編輯器該不該留著、對外連線要不要鎖起來,這些平常感覺不出差別的實用開關,精靈一律不會主動幫你設定,得自己找到這個檔案、手動加進去。

真正的差別,會在網站出狀況的那一刻現形。同樣是遇到白畫面當機或外掛互相衝突,先設定好的人能馬上打開記錄檔,看到出錯的行數與原因;沒設定的人只能對著一片空白畫面猜。這篇就整理十個 wp-config.php 常用設定,把安裝精靈沒幫你打開的開關,一項一項講清楚是什麼、什麼時候該開,以及背後那個容易被忽略的細節。

10 個 wp-config.php 常用設定依用途分成除錯排查、效能、資安、資料庫瘦身、環境判斷五類,一張圖看懂各常數在管什麼
10 個 wp-config.php 常用設定按用途分成五類,先抓住每個常數在管什麼,再決定要不要加進去。

動手改 wp-config.php 前,這幾件事要先弄清楚

wp-config.php 這份設定檔,不是你下載 WordPress 主程式時就已經在裡面的檔案,而是安裝流程依你填寫的資料庫資訊,當場自動產生出來的。它放在網站程式的根目錄,跟 wp-admin、wp-content 這些資料夾同一層,平常打開網站看不到它,得透過 FTP 軟體或主機控制台內建的檔案管理員才能碰到。

找到之後,用一般的純文字編輯器打開就好,記事本、VS Code 都可以。WordPress 官方開發手冊也特別提醒,編輯這類檔案千萬別用 Word 這類文書處理軟體,存檔時夾帶的格式碼會讓整個檔案壞掉。接下來要加的每一個設定,語法都是同一種寫法:

define( '常數名稱', 值 );Code language: PHP (php)

後面十個設定會沿用這個語法示範,不會每一項都重講一次怎麼寫。真正容易出錯的地方在於放置的位置,新增的這幾行程式碼,一定要放在檔案裡 /* That's all, stop editing! Happy blogging. */ 這行註解之前,順序放錯,常數不會生效。

動手前還有一件事比語法本身更重要,那就是先把這個檔案備份一份,或是先在測試站試過一輪再上正式站。少打一個引號、多一個空格,都可能讓整個網站直接打不開,而 wp-config.php 是少數一改錯就會讓網站完全連不上、連後台都進不去的檔案。

動手改 wp-config.php 的安全流程:先備份,到根目錄找檔、用純文字編輯器打開、把 define 貼在 stop editing 註解前、一次只加一行存檔驗證
改 wp-config.php 的安全順序:先備份,新增常數一定貼在 stop editing 註解之前,而且一次只加一行、存檔就重整驗一次。

設定一:打開除錯模式,讓白畫面變成看得懂的錯誤訊息

WP_DEBUG 是十個設定裡最基本、也最常被提到的一個。它預設是 false,網站前台出錯時,訪客通常只會看到一片空白,或是一句簡短的「發生嚴重錯誤」。把這個常數設成 true,PHP 執行時的錯誤、警告,連「這個函式已經快被淘汰,以後版本會拿掉」這類提示,都會整段顯示出來,你才知道問題卡在哪一個外掛、哪一行程式碼。

define( 'WP_DEBUG', true );Code language: PHP (php)

不過正式站不建議只單獨開這一行。錯誤訊息裡常常帶有檔案路徑、外掛名稱這類系統細節,直接攤在畫面上給任何訪客看,等於幫可能的攻擊者省了一道偵查手續。WordPress 官方文件也明講,這些除錯工具是設計給本機測試與測試站用的,不建議直接用在正式站上。

實務上會搭配另外兩個常數一起用:WP_DEBUG_LOG 設成 true,錯誤會被寫進 wp-content/debug.log 這個檔案留存;WP_DEBUG_DISPLAY 設成 false,則是不讓這些錯誤顯示在畫面上。三個常數合起來,就是「錯誤照樣記下來,但訪客什麼都看不到」:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Code language: PHP (php)

多數入門教學講到這裡就停了,但 WP_DEBUG_LOG 其實不是只能設 true 或 false,也可以直接指定一個自訂路徑,把錯誤記錄存成你自己指定的檔名與位置,方便跟其他記錄檔分開管理。

設定二:拉高記憶體上限,外掛裝多了不再動不動就當機

「Allowed memory size of xxx bytes exhausted」這句錯誤訊息,多半在外掛裝到一定數量之後才會冒出來。WordPress 預設只會嘗試把 PHP 可用的記憶體拉到單一站台 40MB、多站台(multisite)環境 64MB,外掛裝得越多、功能越複雜,程式執行時要用的記憶體就越容易觸頂,一旦超過,頁面直接當機或顯示錯誤。

WP_MEMORY_LIMIT 負責拉高網站前台可以用的記憶體上限:

define( 'WP_MEMORY_LIMIT', '256M' );Code language: PHP (php)

WP_MAX_MEMORY_LIMIT 則是專門給後台管理畫面用,預設上限是 256MB。後台常常要做的批次操作,像是一次處理大量圖片、匯入大批資料,都比前台瀏覽吃記憶體,這個常數就是留給這類場合用的:

define( 'WP_MAX_MEMORY_LIMIT', '512M' );Code language: PHP (php)

這兩個常數各司其職,設對位置才有效果。不過這個設定能不能真的發揮效果,還要看主機本身允許的 PHP 記憶體上限有多高,設定值不能高過主機給的天花板。如果加了這幾行卻完全沒感覺,不是常數寫錯,多半是主機那邊的上限本來就卡在更低的地方,這時候要回頭問主機商能不能調高,而不是把數字改得更誇張。

設定三:關掉後台檔案編輯器,少一個被入侵後就地改代碼的路

WordPress 後台內建「佈景主題編輯器」與「外掛編輯器」,讓有權限的帳號能直接在瀏覽器裡改程式碼,不用碰 FTP 就能修改網站檔案。這個功能對一般網站幾乎用不到,卻是駭客一旦拿到管理員帳號後,最快用來植入惡意程式碼的路徑之一,不必再想辦法上傳檔案,直接在後台貼一段程式碼存檔就完成。

define( 'DISALLOW_FILE_EDIT', true );Code language: PHP (php)

DISALLOW_FILE_EDIT 設成 true 之後,這兩個編輯器的選單會直接從後台消失。如果想再往上加一階防護,DISALLOW_FILE_MODS 效果更完整,除了關閉編輯器,連「在後台直接安裝或更新外掛與佈景主題」的功能也會一併鎖住:

define( 'DISALLOW_FILE_MODS', true );Code language: PHP (php)

這種情況下就不必再另外設定 DISALLOW_FILE_EDIT,因為 DISALLOW_FILE_MODS 本身已經包含關閉編輯器的效果,兩個常數不必疊加。這個設定特別適合外掛與佈景主題的安裝、更新都是透過工程團隊或代管流程處理的網站,後台不需要手動點更新,鎖起來反而更安全。

設定四:後台登入強制走加密連線,密碼不再用明碼傳輸

後台登入時輸入的帳號密碼,如果網站沒有強制使用加密連線,理論上有機會在傳輸過程中被同一網路上的人攔截到。FORCE_SSL_ADMIN 這個常數,就是強制後台管理畫面與登入頁一律使用 HTTPS,確保密碼與登入後產生的 Cookie,都是加密傳輸,不會以明碼在網路上傳送:

define( 'FORCE_SSL_ADMIN', true );Code language: PHP (php)

比較舊的教學文章裡,有時候會看到另一個常數 FORCE_SSL_LOGIN,這其實已經在 WordPress 4.0 版就被淘汰,現在該用的是 FORCE_SSL_ADMIN,照抄舊教學設了一個已經沒作用的常數等於白設。

這個設定有一個前提要先確認,網站本身必須已經裝好 SSL 憑證。多數主機現在都會預設提供憑證,但如果你的網站還沒裝憑證就先開這個設定,後台反而會直接打不開,順序要先確認憑證裝好,再加這行常數。

設定五:限制修訂版本數量,資料庫不被草稿越塞越大

WordPress 每次編輯文章或頁面存檔,都會另外存一份「修訂版本」,方便之後想回復到舊版時可以叫回來。如果沒有另外設定,WordPress 預設 WP_POST_REVISIONS 為 true,代表修訂版本不限制數量,一篇常常被回頭修改、調整措辭的文章,累積下來可能存了幾十份修訂版本,全部堆在資料庫裡佔位置。

WP_POST_REVISIONS 可以設成一個整數,限制最多保留幾份,例如設成 3 就代表只留最近 3 份:

define( 'WP_POST_REVISIONS', 3 );Code language: PHP (php)

也可以直接設成 false,完全關閉這個功能,連一份都不存。這其實是一種取捨,保留比較多份修訂版本,回復舊版比較有彈性,但資料庫會跟著越養越肥;限制得太少或直接關閉,資料庫精簡,但真的想找回三次修改之前的內容時就找不到了。這沒有標準答案,看網站文章更新的頻繁程度自己抓一個數字。

設定六:資源回收桶多久清空,自己說了算

文章、頁面、附件、留言被刪除後,不會立刻消失,而是先進到資源回收桶,等一段時間才會被永久刪除。這個等待期由 EMPTY_TRASH_DAYS 控制,預設是 30 天:

define( 'EMPTY_TRASH_DAYS', 30 );Code language: PHP (php)

如果覺得 30 天的反悔空間不夠,可以把數字調大,留更久的緩衝;反過來也可以調小,讓資料庫不用留著一堆等著被清的舊資料。把這個常數設成 0,則是直接關掉資源回收桶功能,任何刪除動作都會立即永久生效。

設成 0 之後有一點要特別小心,點擊「永久刪除」不會再跳出確認視窗,等於刪了就真的沒了。如果後台有多人共同管理內容,這個設定反而要留意誤觸的風險,別為了圖方便關掉它,結果哪天手滑刪錯東西救不回來。

設定七:打開內建快取開關,省下重複運算的力氣

WP_CACHE 這個名字容易讓人誤會,以為設成 true 網站就自動有快取效果,其實它只是一個開關,本身不做任何快取運算:

define( 'WP_CACHE', true );Code language: PHP (php)

設成 true 之後,WordPress 執行時會去讀取 wp-content/advanced-cache.php 這支檔案,真正的快取邏輯就寫在這支檔案裡。多數時候不需要手動加這一行,因為安裝像頁面快取類的快取外掛時,外掛本身就會自動幫你把 WP_CACHE 設成 true、並產生 advanced-cache.php 這支檔案。

也因為這樣,這個常數更常被拿來當排查工具用。如果懷疑網站的快取沒有生效,回頭打開 wp-config.php 檢查有沒有這一行,以及 advanced-cache.php 這支檔案是不是真的存在,是一個很直接的起點,能快速判斷是快取外掛沒裝好,還是設定本身就沒開。

設定八:關掉假想的排程,改用主機真正的定時任務

WordPress 講的「排程」,像是設定某篇文章幾點自動發佈、外掛定期檢查更新這類任務,背後靠的是 wp-cron 這套機制,而它其實不是真的在背景一直運作,而是每次有訪客造訪網站時,順便檢查一次「現在有沒有該執行的排程任務」。流量夠大的網站幾乎感覺不出差異,但流量稀疏、甚至半夜完全沒人訪問的網站,排定好的任務就可能被拖延觸發,最常見的狀況就是設定好要準時發佈的文章,時間到了卻沒有準時發出去。

DISABLE_WP_CRON 可以先把這個依賴訪客觸發的「假排程」關掉:

define( 'DISABLE_WP_CRON', true );Code language: PHP (php)

關掉之後,改由主機真正的排程工具(例如主機控制台裡的 Cron Job)定時呼叫 wp-cron.php 這支檔案,讓排程任務準時執行,也不會拖慢訪客造訪當下的網頁載入速度。

除此之外還有兩個進階選項可以簡單認識一下:ALTERNATE_WP_CRON 用重新導向的方式觸發排程,通常在排定文章沒有準時發佈時被拿來當替代方案;WP_CRON_LOCK_TIMEOUT 則是限制排程不能在多久之內重複觸發,官方文件是以 60 秒當示範值。多數網站不必研究到這麼細,先把「關閉假排程,改設定主機真實 Cron」這個組合用起來就夠。

設定九:告訴 WordPress 這是正式站還是測試站

這是相對新、多數入門教學還沒提到的常數。根據 WordPress 官方開發手冊,WP_ENVIRONMENT_TYPE 讓 WordPress 知道目前執行的是哪一種環境:local(本機開發)、development(開發站)、staging(測試站),還是 production(正式站),四選一。

define( 'WP_ENVIRONMENT_TYPE', 'staging' );Code language: PHP (php)

如果沒有設定這個常數,或是填了不在這四個選項裡的值,WordPress 一律會當成 production 處理。這個常數真正的用途,是讓外掛與佈景主題可以依照環境自動調整行為,像是測試站自動關閉金流串接、正式站自動關閉除錯訊息,不用外掛作者自己在程式碼裡判斷網址來分辨這是正式站還是測試站,穩定度差很多。

有一個實務上容易忽略的細節值得記住,如果環境類型被判定為 development,而 wp-config.php 裡又沒有明確設定 WP_DEBUG,WordPress 會自動把 WP_DEBUG 視為開啟,這個連動關係如果不知道,可能會誤以為除錯模式是自己不小心開的。

WordPress 網站健康的 WordPress 常數區塊,列出 WP_ENVIRONMENT_TYPE、WP_DEBUG、WP_MEMORY_LIMIT 等常數目前生效的值
後台「工具 → 網站狀態 → 資訊」的 WordPress 常數區塊,能直接查到 WP_ENVIRONMENT_TYPE 這些常數目前生效的值。

設定十:鎖住對外連線,別讓網站被拿去打別人

WordPress 本身並不是一個完全封閉的系統,它會主動對外發出連線請求,像是檢查有沒有新版本可以更新、驗證付費外掛與佈景主題的授權,或是某些外掛需要串接第三方服務。這些對外連線平常不會被注意到,但如果網站不幸被植入惡意程式,這條對外連線的路徑反而可能被拿來當跳板,讓網站變成向外發動攻擊或聯繫惡意伺服器的工具。

WP_HTTP_BLOCK_EXTERNAL 設成 true 之後,預設只允許網站對自己(localhost)發出請求,其餘所有對外連線一律擋下:

define( 'WP_HTTP_BLOCK_EXTERNAL', true );Code language: PHP (php)

真正需要放行的網域,例如 WordPress.org 本身、或是網站串接的第三方服務網域,就透過 WP_ACCESSIBLE_HOSTS 用逗號分隔列出白名單,也支援萬用字元網域,像是 *.wordpress.org 就代表放行這個網域底下所有子網域:

define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );Code language: PHP (php)

這個設定偏進階,也最容易一開就把某些外掛正常運作需要的連線一起擋掉。開啟前最好先盤點一次網站實際會用到哪些外部服務,把它們一一加進白名單,而不是設完就丟著不管,之後某個外掛忽然失靈,才回頭發現是這個常數擋住了它需要的連線。

這十個 wp-config.php 常用設定不必一次全部加上去。如果只是想先解決眼前的問題,從除錯模式與記憶體上限這兩個排查問題最常用到的開始就夠;資安相關的幾項,像是關閉後台檔案編輯器、強制後台走加密連線、鎖住對外連線,留到網站正式上線前再一次加齊也不遲。

真正該養成的習慣,是每加一個常數就重新整理一次網站前台與後台,確認沒有因此打壞任何功能,再繼續加下一個,而不是把一長串設定整段複製貼上去,存檔之後就當作沒事。

資料來源
  1. wp-config.php – Common APIs Handbook — WordPress
  2. Debugging in WordPress – Advanced Administration Handbook — WordPress
  3. wp_get_environment_type() – Function Reference — WordPress