想要尽快开始使用 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