wp-config.php 文件的開發人員高級指南

已發表: 2022-09-28

你對wp-config了解多少？ 在這幾行 PHP 中有驚人的力量！ 本文介紹了一些您可能不知道但確實應該知道的wp-config 。

您知道關於wp-config.php文件的所有信息嗎？ 您是否閱讀了有關它的整個WordPress 文檔頁面？ 一直到最後？

如果您已經熟悉wp-config的基礎知識，那麼閱讀官方 WordPress 文檔可能會是一個適當的打盹節。

如果您想要真正的開發人員款待，按主題很好地分組，並以只能稱為“對幾個 PHP 常量完全不必要的熱情”的方式交付，那麼請堅持：我即將讓wp-config.php再次變得酷。

來自辛普森一家的米爾豪斯，臉上寫著“wp-config”，標題是“我媽媽說我很酷”。

目錄

  1. 誰應該讀這個？
  2. 你為什麼要讀這個？
  3. 基礎知識
  4. 查看 wp-config 常量
  5. 分解wp-config.php加載過程
    1. wp-config 可以上移
    2. 如果沒有 wp-config.php 文件，則會加載設置屏幕
    3. wp-config.php 很早就加載
    4. 不要亂用 wp-config.php！
  6. 檢查/檢查您的 wp-config.php 文件
  7. 使用 wp-config.php 保護 WordPress
    1. 從網站訪問者保護 wp-config.php
    2. 旋轉鍵/鹽
    3. 移動和隱藏東西
    4. 禁用文件編輯器
    5. 禁用自動更新
    6. 防止外部 HTTP 請求
  8. 移動東西
    1. 移動用戶和用戶元表
    2. 移動內容、上傳和插件目錄
  9. 內容相關設置
    1. 更改站點和儀表板 URL
    2. 帖子設置
    3. 發布修訂
    4. 更改自動保存間隔
  10. 包起來

誰應該讀這個？

本文面向已經知道如何編輯wp-config.php文件並了解可以放入其中的一些配置設置的開發人員和高級用戶。

我不會告訴你如何使用 FTP 或 cPanel 編輯文件，或者為什麼你不應該使用 MS Word 來編輯它。

我不會告訴你如何配置你的數據庫或回顧你在 2013 年使用的舊設置，但實際上應該不再需要了。 無論如何，大多數主機都會為您處理基礎知識。

如果您是wp-config.php的新手，那麼不乏可以為您提供基礎知識的指南，或者您可以隨時深入研究官方文檔。

你為什麼要讀這個？

是的，是的，我聽到了。 如果您可以在本文中添加的基本細節都在其他地方介紹過，並且如果您的主機無論如何都處理了大部分基礎知識，那麼您為什麼要閱讀這篇文章？ 而且，確實，我為什麼要花時間寫它？

好吧，如果您對編輯wp-config.php感到滿意，並且知道它的基本功能，那麼您可能至少是一名中級 WordPress 開發人員。

您可能至少部分負責託管大型網站，可能是客戶。 所以你需要知道如何在緊急情況下使用這個文件。 為了對這個文件有足夠的了解，如果你編輯它，你就不會做錯什麼。

此外，您幾乎肯定會希望鎖定 WordPress 的某些功能，超出您的主機允許您自動配置的功能。

很可能有些事情你甚至不知道你可以用wp-config.php做！ 一些“啊哈！” 值得擁有的時刻。

本文是配置一些 WordPress 內部的有用參考點。 因此，請繼續閱讀、添加書籤並與您的朋友和同事分享。

基礎知識

我說這不是初學者的文章，但我們應該建立基本事實以確保我們處於同一起點。

wp-config.php文件位於 WordPress 安裝的根目錄中（它可以位於其他位置，但我們會談到這一點），作為 WordPress 初始化的一部分加載，並允許您配置 WordPress 核心。

它對 WordPress 的運行至關重要。 它存儲一組常量，讓您指定：

  • WordPress 使用的數據庫連接和表前綴。
  • 安全信息，如鹽和身份驗證密鑰。
  • WordPress 核心的其他功能的設置，例如WP_CACHE和WP_DEBUG 。
  • 可以將自己的選項添加到文件的插件的設置。
  • 您自己的配置選項。

至關重要的是， wp-config.php是一個特定於環境的文件。 它的內容可以（並且應該！）對於不同的站點是不同的。 即使是同一站點的本地副本、暫存副本和實時副本，文件中的值也會不同。

WordPress 附帶一個wp-config-sample.php文件，其中包含 WordPress 工作所需的最少細節。 作為安裝的一部分，您可以將其複製到您自己的wp-config.php中，但這些天通常會為您完成。

最後，請注意，當您從現有站點打開wp-config.php文件時，您可能會看到一些舊的 PHP 常量用於舊功能，例如默認文件權限和用於運行升級的 FTP 憑據。 我們不會在這裡介紹這些內容，因為您不太可能需要使用它們。

查看 wp-config 常量

有幾種方法可以快速檢查 WordPress 常量的值，而無需通過 SSH 連接到遠程服務器並打開文件。

WordPress 核心的站點健康功能允許您通過導航到工具 -> 站點健康 -> 信息 -> WordPress 常量來查看一些基本值。 數據庫常量也可以在同一頁面的“數據庫”部分中看到。

數據庫常量，顯示在 WordPress 站點健康頁面的數據庫部分。

查詢監視器插件有一個“環境”面板，您可以在其中看到一些常用的wp-config常量。

查詢監視器插件的“環境”面板，顯示了一些常用的 wp-config 常量。

WordPress 命令行界面 WP-CLI 有一個wp config命令，可用於獲取和設置wp-config.php中的常量。 這通常需要您首先使用 SSH，但如果您在 WP-CLI 配置中設置別名，則可以創建快速快捷方式來查看和修改遠程wp-config文件中的常量。

分解wp-config.php加載過程

知道wp-config.php文件何時加載很有用，因為這決定了您可以用它做的一些事情和不能做的事情。 跟踪加載過程是一個很好的練習：

  • WordPress 開始加載index.php文件。 這需要wp-blog-header.php文件。

  • wp-blog-header.php做的第一件事就是加載wp-load.php 。

  • 接下來， wp-load.php設置 ABSPATH 常量（基礎 WordPress 核心目錄）並在加載wp-config.php之前初始化error_reporting() 。

這個加載過程，尤其是wp-load.php中的代碼，可以教給我們一些有趣的東西。 這是該代碼：

 /* * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit * of avoiding cases where the current directory is a nested installation, eg / is WordPress(a) * and /blog/ is WordPress(b). * * If neither set of conditions is true, initiate loading the setup process. */ if ( file_exists( ABSPATH . 'wp-config.php' ) ) { /** The config file resides in ABSPATH */ require_once ABSPATH . 'wp-config.php'; } elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) { /** The config file resides one level above ABSPATH but is not part of another installation */ require_once dirname( ABSPATH ) . '/wp-config.php'; } else { // A config file doesn't exist. // [Code here to load the setup screen for in-browser configuration] }

我們在這裡看到了什麼？

wp-config.php 可以上移

首先，註釋告訴我們可以將wp-config.php放在“WordPress 根目錄”中。 它沒有提到的是“根”實際上可以是wp-load.php ABSPATH的 ABSPATH之上的目錄。

我們可以在尋找dirname( ABSPATH ) . '/wp-config.php'的elseif中看到這個額外的檢查。 dirname( ABSPATH ) . '/wp-config.php' 。 註釋中解釋了elseif中的附加條件。

如果沒有 wp-config.php 文件，則會加載設置屏幕

其次，我們可以看到，如果配置文件不存在，它將加載設置屏幕。

您完全有可能以前從未見過這個屏幕。 它允許您在基於 Web 的用戶界面中輸入初始配置信息，例如數據庫憑據：

很少見的 WordPress 設置屏幕。如果 WordPress 找不到配置文件，它會加載它，允許您手動設置配置選項。

這是WordPress值得了解的一個功能。 如果您曾經將 WordPress 核心文件放在公開可用的 Web 服務器上，但沒有創建wp-config.php文件，那麼其他人（或者更有可能是機器人）可以出現並以他們的方式設置 WordPress並可能損害您的託管。

wp-config.php 很早就加載

第三點要注意的是wp-config.php在 WordPress 的啟動序列中很早就被加載了。 這意味著：

  1. 在wp-config.php中有很多我們不能做的事情。 例如，我們不能在此處添加鉤子（操作或過濾器），因為用於執行此操作的函數和數據結構尚未加載。 而且我們無權訪問 WordPress 的任何內部函數、對象和 API。

  2. 我們對接下來發生的事情有很大的控制權。 因為文件加載得這麼早，所以對 WordPress 有很大的影響。 這既好又壞。 我們可以很容易地讓 WordPress 徹底死掉。 但我們也可以從 WordPress 的幾乎任何其他地方訪問wp-config.php中定義的任何內容。

不要亂用 wp-config.php！

我們從這個過程中學到的最後一件事是，這種強大的力量伴隨著巨大的責任。

wp-config.php文件的底部是這些行：

 /* Add any custom values between this line and the "stop editing" line. */ /* That's all, stop editing! Happy publishing. */ /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';

這裡有一些說明，但“停止編輯”這一行很重要。 此行之後是 WordPress 初始化序列的延續。 在錯誤的地方添加新代碼可能只會導致新代碼沒有任何效果。 但為了安全起見，我建議遵循這些說明。 他們在那裡是有充分理由的。

檢查/檢查您的 wp-config.php 文件

如果您在生產環境中工作，您真的不想在wp-config.php文件中添加任何錯誤。 此處的錯誤可能會破壞您的網站，並且您可能不會收到有用的錯誤消息。

您可以使用-l （“lint”）選項在命令行上運行php ，以檢查wp-config.php文件中是否存在致命的 PHP 語法錯誤。

$ php -l wp-config.php

解析錯誤：語法錯誤，第 9 行 wp-config.php 中的意外標記“require_once”

解析 wp-config.php 時出錯

你甚至可以編寫一個 shell 腳本來...

  1. 將wp-config.php複製到臨時文件中，
  2. 編輯臨時文件，
  3. 對臨時文件進行 Lint，然後
  4. 僅當它沒有語法錯誤時才將其複制回來。

如果您對命令行感到滿意，那麼使用諸如wp config set <name> <value>之類的 WP-CLI 命令來安全地設置值比手動操作更安全。

你也可以使用 WP-CLI 列出你的配置值（這是一個刪除了一些條目的示例——你明白了！）：

$ wp 配置列表
+---------------------+-------------------------- --------------------+----------+
| 姓名 | 價值 | 類型 |
+---------------------+-------------------------- --------------------+----------+
| 根目錄 | /用戶/smithers/站點/snpp | 變量 |
| webroot_dir | /Users/smithers/sites/snpp/public | 變量 |
| 表前綴 | wp_ | 變量 |
| WP_HOME | https://snpp.test | 常數 |
| WP_SITEURL | https://snpp.test/ | 常數 |
| 數據庫名 | snpp | 常數 |
| 數據庫用戶 | 根 | 常數 |
| DB_PASSWORD | 蒙哥馬利 | 常數 |
| 數據庫主機 | 127.0.0.1 | 常數 |
| DB_CHARSET | utf8mb4 | 常數 |
| DB_COLLATE | | 常數 |
| DB_PREFIX | wp_ | 常數 |
| WP_DEBUG | 1 | 常數 |
| WP_DEBUG_LOG | 1 | 常數 |
| WP_DEBUG_DISPLAY | | 常數 |
| WP_ENVIRONMENT_TYPE | 發展| 常數 |
| DISABLE_WP_CRON | | 常數 |
| DISALLOW_FILE_EDIT | 1 | 常數 |
+---------------------+-------------------------- --------------------+----------+

這兩種技術確實可以為您省去一些麻煩，並且不會讓您擔心在如此重要的文件中不小心將分號放在錯誤的位置。

使用 wp-config.php 保護 WordPress

安全性是 WordPress 中一個永遠熱門的話題。 我們可以在wp-config文件中更改的一些設置將更多工具放入我們的安全工具箱中。

wp-config文件的這些部分絕對不是您應該使用的唯一東西來實現良好的 WordPress 安全性。 除了以下部分中的信息外，請確保您徹底了解網站安全性。

從網站訪問者保護 wp-config.php

默認情況下，您的wp-config文件位於您網站的根目錄中，它恰好包含關鍵信息，例如您的數據庫登錄詳細信息和密碼鹽。 您不希望這些信息公開可用，因此您應該確保您的wp-config文件受到網站訪問者的保護。

您的託管公司通常會為您執行此操作。 您可以通過在您的域之後添加/wp-config.php來嘗試從瀏覽器訪問文件來進行檢查。 如果您移動了文件，此 URL 可能會有所不同。

如果您已將wp-config文件放在網站根目錄上方的目錄中，那麼您應該看不到它。 在大多數其他情況下，無論如何嘗試訪問該文件時，您只會收到一條 PHP 錯誤消息，因此這里通常無事可做。 但是，如果您想正確保護它，那麼您可以通過修改您的 Web 服務器（Apache 或 nginx）配置來阻止對它的訪問。

最後，如果您將網站文件存儲在 Git 中，重要的是不要將wp-config文件存儲在 Git 存儲庫中。 這樣做可能會洩漏有關您站點的關鍵信息，但此外，您可能希望在每個環境中都使用此文件的不同版本。 所以最好將它添加到你的.gitignore並手動管理每個環境中的文件。

旋轉鍵/鹽

什麼是鍵/鹽？

鍵和鹽部分是wp-config中更神秘的部分之一。 這組看起來很奇怪的常量有助於加密 cookie 和 nonce 之類的東西。 無需深入細節——正如 WP Engine 所擁有的——它們添加了一層額外的隨機性，如果你不知道鹽和密鑰，這會使事情更難解密。

為什麼要“旋轉”鍵/鹽？

首先，“旋轉”只是“改變”的一個花哨的詞。 我不知道為什麼我們使用“旋轉”。 這不像我們曾經回到同一組鑰匙！

如果網站被黑客入侵，您可能應該更改您的密鑰和鹽，因為您不能保證密鑰和鹽仍然是秘密的。 但是無論如何，您可能希望定期輪換它們，例如使用密碼，以確保沒有人知道它們是什麼。

旋轉鍵/鹽的問題

更改鍵和鹽並非沒有痛苦。 任何擁有 cookie 集的人都會丟失它。 因此，任何登錄的人都會被踢出，任何擁有 WooCommerce 購物車的人都會被清空。

如何旋轉鍵/鹽

我的意思是，您可以編輯wp-config文件並在舊字符上鍵入一些新的隨機字符。 但這會很乏味，而且人類不太擅長隨機性。

因此，讓我告訴您一些在wp-config中設置新鍵/鹽的方法。

  1. 從生成器手動添加密鑰：您可以使用 wordpress.org 生成器來獲取您需要的代碼。 只需將其複制並粘貼到wp-config文件中即可代替舊值。
  2. 使用插件：許多安全插件，如 Sucuri Security、iThemes Security 和 Malcare 都具有此功能。 Salt Shaker 是一個專用插件，可以按計劃為您自動執行此過程。
  3. 使用 WP-CLI。 我們說過 WP-CLI 有多棒了嗎？ 我們做到了？ 好的。 好吧，我們再說一遍！ 您可以使用wp config shuffle-salts命令在幾秒鐘內完成這項工作。

移動和隱藏東西

安全人員會告訴你，“默默無聞的安全”根本不是安全，但有些人仍然喜歡隱藏他們的 WordPress 內容，以便為黑客設置一些額外的障礙。

wp-config文件為您提供了許多用於執行此操作的選項，我們將在後面的有關移動內容和關閉文件編輯的部分中介紹這些選項。

禁用文件編輯器

WordPress 有一個方便的功能，允許您從管理儀表板內部編輯主題和插件中的文件。 編輯wp-config.php可以讓您關閉這些文件編輯器！ 有些人為了安心而喜歡禁用它們。

現在我知道有一個安全論點，即如果有人對您的站點具有管理員訪問權限——這是使用這些編輯器所必需的——那麼他們可以上傳插件並做任何他們喜歡的事情。 啟用這些編輯器並沒有為黑客提供比他們已經擁有的更多的權力。

但是，儘管關閉這些功能實際上可能不會提高安全性，但這樣做的真正原因是阻止實際被授權為管理員的人使用它們。 如果您是代理商，您可能不希望您的客戶發現他們可以編輯所有主題文件，對嗎？

默認情況下，許多主機只會禁用此功能。 但是如果你想讓它們消失，就像添加一樣簡單：

 define( 'DISALLOW_FILE_EDIT', true );

或者，如果您真的想鎖定您的文件系統，可以使用DISALLOW_FILE_MODS ，我們將在下一節中介紹。

禁用自動更新

無論您喜歡還是討厭它們，WordPress 的自動更新都對 WordPress 生態系統產生了積極的影響，並且難以忽視。 但並不是每個人都希望他們的軟件能夠自理！

因此wp-config讓您可以通過一組簡單的、您可以設置的不言自明的常量來控制自動更新過程：

 # Disable all core updates: define( 'WP_AUTO_UPDATE_CORE', false ); # Enable all core updates, including minor and major: define( 'WP_AUTO_UPDATE_CORE', true ); # Enable core updates for minor releases (default): define( 'WP_AUTO_UPDATE_CORE', 'minor' );

如果你想要更極端的東西，你可以DISALLOW_FILE_MODS ：

 define( 'DISALLOW_FILE_MODS', true );

但這會阻止 WordPress 將任何與核心、主題、插件或翻譯相關的內容寫入磁盤，並且會禁用有關小更新的電子郵件通知。 一位核心貢獻者將其描述為“除非你確切地知道自己在做什麼，否則使用起來非常愚蠢”。

稍微不那麼極端的是AUTOMATIC_UPDATER_DISABLED 。 這使您可以安裝插件和主題，但不會更新它們或核心軟件。 不過，它也會禁用翻譯更新。

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

wordpress.org 上有關於這一切的詳細指南，包括其他一些選項，例如使用過濾器進行更細粒度的控制。

最後，我注意到如果你的網站是版本控制的，那麼很可能 WordPress 已經為你禁用了更新。 例如，站點根目錄（或不同位置的各種其他文件）中存在.git目錄將禁用自動更新，而無需向wp-config添加任何內容。

配置 HTTPS

配置 HTTPS 通常具有挑戰性。 隨著來自 LetsEncrypt 和 Cloudflare 等地方的免費、受信任的安全證書的出現，許多主機只需單擊幾下即可為您設置。 這個設置可能應該被認為是遺留的，但也許你仍然需要它來做一些事情。

FORCE_SSL_ADMIN常量告訴 WordPress始終將 SSL 用於登錄頁面和 WordPress 儀表板。 這確保了安全憑證和 cookie 不能在未加密的情況下發送。

但是，就像我說的那樣，一家好的託管公司無論如何都會讓在您的網站上設置 HTTPS 變得簡單，所以就去做吧。

防止外部 HTTP 請求

最後，在安全方面，您可以阻止外部 HTTP 請求。 這意味著 WordPress 無法聯繫互聯網上的其他地方來執行 API 調用或下載更新等操作。

允許 WordPress 通過 HTTP 聯繫外部服務通常是一個好主意，因為它可以讓您獲取更新、安裝插件和主題，如果您關閉 HTTP 請求，許多插件將會中斷。

但是 WordPress 核心和許多插件和主題將“遙測”或“使用數據”發送回中央服務器。 這可能很好——它可以幫助插件和主題開發人員了解誰在使用他們的軟件以及如何使用。 但是，如果您的網站上有特別敏感的數據，您可能需要禁用此功能。 你可以這樣做：

 define( 'WP_HTTP_BLOCK_EXTERNAL', true );

如果您想要一個可以聯繫的主機的允許列表，那麼您也可以這樣做：

 define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );

請注意，可訪問主機列表是逗號分隔的列表，並且允許使用通配符子域。 您可以使用 Log HTTP Requests 插件監控正在聯繫的主機。

移動東西

並非每個 WordPress 安裝都是相同的。 出於安全原因，某些主機或框架喜歡移動目錄或將特定於站點的代碼和資產與 WordPress 核心分開。 我關於使用 Git 和 Composer 管理 WordPress 的文章介紹了這種方法的一些好處。

那麼 WordPress 為您提供了哪些選項——因為需要一個更好的術語——“移動東西”？

更改數據庫前綴

WordPress 默認使用數據庫表名前綴wp_ 。 這個前綴被添加到所有數據庫表名中，並且也在其他一些地方使用，例如選項表中的<prefix>user_roles選項和<prefix>capabilities用戶元條目。

黑客或攻擊者可能會在攻擊中使用默認前綴，試圖發現或修改您的數據庫表。 因此，有些人建議將其從默認值更改。

wp_config選項$table_prefix允許您執行此操作，您可能應該將其設置為一些簡短但隨機的字符串，並以下劃線為後綴：

 $table_prefix = 'b4F8az_';

這將告訴 WordPress 使用諸如b4F8az_posts之類的表名而不是wp_posts 。

您不必更新任何代碼來適應這種變化（除非代碼寫得非常糟糕），但是如果您在現有站點上更改它，您將不得不對您的數據庫進行一些更新——而不僅僅是重命名桌子！

一些安全插件會為您執行此操作，並且有一個插件也可以執行此操作。 我們強烈建議在執行此操作之前備份您的數據庫，並註意最好在安裝 WordPress 時選擇非默認表前綴，而不是在站點運行時更改它。

一個奇怪的註釋是$table_prefix是一個變量，而不是一個常量。 它是 WordPress 為您提供的示例配置文件中定義的唯一變量！ 如果您仍然好奇：是的，WP-CLI 的wp config命令會為您解決這個問題，您甚至不必知道！

移動用戶和用戶元表

我從來沒有見過這樣做的，我在寫這篇文章時才知道可以這樣做，但是你也可以完全改變用戶和用戶元表的名稱。

我想這有助於防止嘗試“SELECT * FROM wp_usermeta;”的 SQL 注入攻擊，但我很高興聽到其他原因。

在任何情況下，您都需要CUSTOM_USER_TABLE和CUSTOM_USER_META_TABLE常量：

 define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' ); define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );

在使用這些常量之前，有一些注意事項值得了解。 使用此功能前請查看官方文檔。 就像使用自定義表前綴一樣，這絕對是安裝新站點時最好的做法，而不是以後修改它。

移動內容、上傳和插件目錄

也可以移動整個wp-content目錄、 uploads目錄以及themes和plugins目錄。 注意事項：

  • 在某些情況下，您需要設置 URL 以及目錄。
  • 您需要小心使用完整路徑或適當的相對路徑。
  • 這些設置都不應該有斜杠。

有關詳細信息，請參閱官方文檔——我不會在這裡重複所有這些。

最後，請注意，如果您更改這些，編碼錯誤的插件或主題可能會搞砸。 這絕不應該發生，但值得了解。

如果您是插件或主題開發人員，請務必記住這些路徑可以更改。 因此，請確保不要對目錄或 URL 的路徑進行硬編碼。 這裡對您有用的功能是：

wp_upload_dir
plugins_url
plugin_dir_url
plugin_dir_path
get_stylesheet_directory
get_stylesheet_directory_uri
get_template_directory – 請注意，對於子主題，這將返回父主題的位置
get_template_directory_uri

在 WordPress 開發人員手冊中有更詳盡的功能列表。

最後，除了在 WordPress 安裝中移動文件外，您可能還想移動 wp-admin 位置，或更改站點的位置。 wp-config.php也可以提供幫助。

內容相關設置

畢竟，WordPress 是一個內容管理系統。 因此，您會期望可以在wp-config.php中使用一些常量來控制內容選項。 讓我們看看，看看我們能做些什麼。

更改站點和儀表板 URL

這些一直讓我困惑。

要設置站點的 URL，您需要使用WP_HOME常量，而不是WP_SITEURL常量。

WP_SITEURL常量不會更改您網站的 URL。

使困惑？

WP_SITEURL的官方描述是“你的 WordPress 核心文件所在的地址”。 這也令人困惑，因為它是 URL，而不是目錄。

不要怪我，我只是你當天的導遊！

設置WP_HOME和WP_SITEURL會覆蓋wp_options數據庫表中的home和siteurl條目。 所以，至少，這是有道理的。

 // NOTE: These must not have trailing slashes define( 'WP_HOME', 'https://helfish.media' ); define( 'WP_SITEURL', 'https://hellfish.media/wordpress` );

您可以在將站點移動到新 URL 後使用這些常量，以便在正確修復數據庫的同時啟動並運行站點。 您甚至可以選擇在之後將它們留在原處。

當您將核心 WordPress 文件移動到不同的目錄時，也可以使用WP_SITEURL設置。

使用這些還可以防止運行一兩個數據庫查詢以從選項表中獲取值，因此它可能會獲得邊際性能增益。 雖然如果你正在做對象緩存，那麼增益可能可以忽略不計。

官方文檔中有更多詳細信息，甚至還有關於更改站點 URL 的完整支持文章。 此外，該文章還包括wp-config.php的晦澀RELOCATE常量，我在研究本文之前從未聽說過。

最後，在移動站點時，請注意這不是您唯一需要更改的內容。 建議對 URL 字符串進行完整的數據庫搜索和替換。

帖子設置

當涉及到帖子時，您可以修改一些不同的設置。 其中大多數與後期修訂或自動保存功能有關。

發布修訂

WordPress 的默認行為是保存對帖子和頁面所做的所有修訂。 這樣做的好處是很容易恢復到以前的版本。 缺點是所有這些修訂都會佔用數據庫中的空間，並且會通過減慢數據庫查詢來影響站點性能。

可以通過修改wp-config.php文件中的WP_POST_REVISIONS值來完全禁用後期修訂。 它默認為真。 要關閉修訂，您可以將其設置為 false：

 define( 'WP_POST_REVISIONS', false );:

某些主機，包括 WP Engine，默認禁用後期修訂。 我建議在進行任何更改之前諮詢您的託管服務提供商。 這因主機而異，但如果您使用 WP Engine，則無法通過wp-config啟用修訂，因為它將在服務器級別被覆蓋。

如果您的主機控制它並且您嘗試更改它，您不一定會破壞某些東西，但您可能會浪費您的時間。

如果您擔心後期修訂會減慢數據庫查詢速度，更好的選擇可能是限制 WordPress 存儲的修訂數量。 這由WP_POST_REVISIONS常量控制，您可以將其設置為要保留的最大修訂數：

 define( 'WP_POST_REVISIONS', 5 );

更改自動保存間隔

您還可以減少自動保存觸發的頻率。 這默認為每 60 秒一次，但您可以將其更改為您喜歡的任何內容。 如果您偏執，您可能希望將其設置為 20 或 30 秒。

重要的是要記住自動保存需要多長時間。 您不希望它們因過於頻繁地發生而重疊，因此不要將此值設置為例如一秒。 自動保存時間不太可能超過默認的 60 秒，但如果您希望保存請求，可以增加間隔：

 define( 'AUTOSAVE_INTERVAL', 120 ); // Seconds

包起來

wp-config中有很多潛力等待解鎖。 我希望這次旅行有助於突出一些可能的事情。 在以後的文章中，我將研究wp-config中固有的更多高級功能，包括多站點安裝和調試。 我還將研究性能，包括如何調整內存限制、CRON 問題和環境類型。

毫無疑問，官方文檔中還潛藏著其他寶藏，等待被發現。 您發現了哪些使用wp-config的技巧？ 在評論中告訴我。