想要盡快開始使用 Better WP-Config 嗎?
define()
WordPress 核心所需的所有常數.php
關聯數組、 .env
檔或JSON
檔進行設定。db
、 debug
、 error
、 salts
等。define()
與ini_set()
等。define()
常數private
目錄來儲存配置ABSPATH
(例如 WP core)設定為 Web 根目錄、 /wp
或任何其他子目錄WP_CONTENT_DIR
設定為/wp-content
、 /app
或任何其他子目錄local
、 test
、 stage
、 prod
等。HTTP_HOST
域secrets
除外)index.php
或wp-config.php
進行任何建置變更即可部署$_ENV
、 $_SERVER
或getenv()
加載private
目錄中wp_config()->print_config();
(注意:在我們完成此問題之前,以下內容不會成立。在此之前,請參閱我們的快速入門)
只需建立一個名為/wp-content/config/config.php
的文件,並使用此處的格式新增網站的配置:
<?php
return array(
'db[name]' => 'example_db',
'db[user]' => 'example_user',
'db[pass]' => '1234567890abcdef',
'db[charset]' => 'utf8mb4_unicode_ci',
'db[collate]' => 'utf8mb4',
'db[host]' => 'localhost',
'db[table_prefix]' => 'wp_',
'defines' => array(
'CONSTANT_REQUIRED_BY_A_PLUGIN' => 'it's value'
),
);
您還需要將網站的/index.php
和/wp-config.php
替換為非常簡單的替代方案,您可以分別在此處和此處找到。
然而,在做出錯誤的假設之前:
更好的 WP-Config 可以從../config
、 /private/config
或您喜歡的任何地方載入設定檔。
如果您喜歡將配置和程式碼分開,您可以將file_format
設定為'env'
。
它可能看起來很簡單——這是為了讓入門變得容易——但 Better WP-Config 的架構是為了處理高度複雜的配置要求。一旦您開始使用並遇到更複雜的用例(例如多環境和自動化部署),您將看到 Better WP-Config 的真正靈活性和強大性。
您可能會問 Better WP-Config 試圖解決什麼問題。您可能會問: “為什麼我們需要更好的 WordPress 配置解決方案?”好吧,我們需要一個,因為我們發現除了瑣碎的用例之外還有太多的用例需要更好的配置解決方案。繼續閱讀:
WordPress 是一個很棒的 CMS,但它忽略了 WordPress 開發人員想要使用更專業的工作流程(例如test
/ stage
/ live
環境)的需求。預設的 WordPress 配置旨在管理一個環境的配置;如果您想管理更多內容,則必須推出自己的多環境配置解決方案。
WordPress 允許您將設定儲存在 Web 根目錄或上一層目錄中的wp-config.php
中。雖然您可以將配置儲存在另一個檔案中,然後在wp-config.php
中require()
它(這就是Better WP-Config所做的),但將自訂解決方案組合在一起意味著您還需要記錄和維護它,假設您將來想依賴它。
如果您確實不厭其煩地開發和記錄諸如 Better WP-Config 這樣的解決方案,那麼您基本上會投入時間(和金錢?)來複製您剛剛使用的解決方案,而無需任何開發和記錄工作。
更糟的是,每個 WordPress 主機(例如 Pantheon 和 WPEngine)都推出了自己的任意不相容的設定解決方案來支援自己的託管 WordPress 產品。
以下是各種 WordPress 託管網站主機如何使用wp-config.php
處理和/或限制您。
如果您熟悉其他託管 WordPress 網站如何處理wp-config.php
請考慮提交拉取請求,其中包含有關他們如何處理wp-config.php
的文檔,以幫助我們和其他人。
使用過 WordPress 的任何人都知道如何透過 PHP 常數DB_HOST
、 DB_NAME
、 DB_USER
和DB_PASSWORD
配置 WordPress 的資料庫憑證。當您第一次開始使用 WordPress 時,這看起來很簡單,但隨著時間的推移,您會意識到它使配置非常不靈活,因為您無法將配置從WordPress 的預設值、專案的預設值、環境的具體情況以及最終的Web 主機的設定級聯。
更好的 WPConfig 並沒有消除不可變常數的使用,而是等到所有級聯配置都合併後再define()
這些常數。 (但這可能是從 WordPress 中消除 PHP 的define()
d 常數的使用的第一步。這是一個想法,因為 PHP 的不可變常數使得 WordPress 功能的自動化測試比實際需要的要困難得多。)
不幸的是,沒有簡單的方法可以找到 WordPress 核心可用的所有選項,因為它們隱含在 WordPress 的程式碼庫和各種線上文件位置中。更好的 WP-Config (大部分)透過"wp_config()->print_config()
解決了這個問題,類似於phpinfo()
許多配置選項沒有預設值,例如資料庫配置,這增加了本地開發所需的學習。 Better WP-Config為所有「已知」選項提供預設選項。
就其本身而言,您可以想出一組可行的約定,以便能夠對您的專案所需的所有不同環境的配置進行版本控制- 我們做到了- 但隨後您意識到每個網站主機以不同的方式處理它並儘可能地嘗試,您覺得不可能找到一致的解決方案供您的團隊使用,並且可以與您和您的客戶選擇的不同網絡主機配合使用。
為了更好地理解為什麼這很困難,請務必閱讀 Pantheon 和 WPEngine 如何分別處理它們的wp-config.php
檔案。
最後,由於wp-config.php
缺乏標準化,託管 WordPress Web 主機做出的不相容選擇加劇了與專業工作流程和版本控制用例相關的問題,這使得部署變得比需要的更加困難。無論您是使用 SFTP 上傳、Pantheon 等 Git 部署,還是透過 CircleCI 等持續整合提供者進行部署,這都適用。
好消息是 Better WP-Config 今天解決了(幾乎)所有這些問題!開始吧。
我們對Better WP-Config 的表現非常滿意。然而,事情可能是:
如果 ClassicPress 和 CalmPress 前叉採用 Better WP-Config 來配置,那就太好了,
如果 WordPress管理的網站主機能夠為其服務標準化“更好的 WP-Config”,那就更好了,或者
最重要的是,如果WordPress 本身能夠使用更好的 WP-Config進行新安裝,同時仍然保持對已經使用wp-config.php
的現有網站的持續支持,就像多年來一樣。
GPLv2