配置 wp-config.php

WordPress 安装中最重要的文件之一是文件wp-config.php。该文件位于 WordPress 文件目录的根目录中，包含您网站的基本配置详细信息，例如数据库连接信息。

在开始之前，您需要打开文本编辑器（如Notepad或Sublime Text），并以wp-config.php为名称创建一个新文件。
打开wordpress的安装目录，找到wp-config-sample.php文件并将其复制到您的文本编辑器中的新文件中。
现在可以开始编辑wp-config.php文件了。文件中有多个定义常量的代码段，其中每个常量的名称和值都是以键值对的形式出现。
首先，您需要定义数据库连接的详细信息。找到以下代码：

/** MySQL数据库的名称 */
define('DB_NAME', 'database_name_here');

/** MySQL数据库用户名 */
define('DB_USER', 'username_here');

/** MySQL数据库密码 */
define('DB_PASSWORD', 'password_here');

/** MySQL主机 */
define('DB_HOST', 'localhost');

将其中的"database_name_here"替换为您的实际数据库名称，"username_here"替换为您的实际MySQL用户名，"password_here"替换为您的实际MySQL密码，"localhost"替换为您的实际MySQL主机名。

接下来，设置安全密钥。找到以下代码：

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

将每个密钥的值替换为随机字符串，以增加安全性。

最后，设置表前缀。找到以下代码：

$table_prefix  = 'wp_';

将"wp_"替换为您想要使用的表前缀。

将所做的更改保存到wp-config.php文件中。

恭喜您！您已经成功配置了WordPress的wp-config.php文件。

详细配置

重要提示： _切勿_使用 Microsoft Word 等文字处理器来编辑 WordPress 文件！

wp-config-sample.php 在 WordPress 目录的基本目录中找到该文件，并在文本编辑器中打开。

注意： /* */ 中的文本是_注释_，仅供参考。

设置数据库名称

将“database_name_here”替换为您的数据库名称，例如_MyDatabaseName_。

define( 'DB_NAME', 'MyDatabaseName' ); // Example MySQL database name

设置数据库用户

将“username_here”替换为您的用户名，例如_MyUserName_。

define( 'DB_USER', 'MyUserName' ); // Example MySQL username

设置数据库密码

将“password_here”替换为您的密码，例如_MyPassWord_。

define( 'DB_PASSWORD', 'MyPassWord' ); // Example MySQL password

设置数据库主机

将“localhost”替换为您的数据库主机的名称，例如_MyDatabaseHost_。可能还需要端口号或 Unix 套接字文件路径。

define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database host

注意：很有可能您不必更改它。如果您不确定，请尝试使用默认值“localhost”进行安装，看看它是否有效。如果安装失败，请联系您的网络托管服务提供商。

MySQL备用端口

如果您的主机为您的数据库使用备用端口号，您需要更改文件中的DB_HOSTwp-config.php值以反映您的主机提供的备用端口。

对于本地主机：

define( 'DB_HOST', '127.0.0.1:<strong>3307' );
or
define( 'DB_HOST', 'localhost:<strong>3307' );

对于指定的服务器：

define( 'DB_HOST', 'mysql.example.com:<strong>3307' );

将3307替换为您的主机提供给您的任何端口号。

MySQL 套接字或管道

如果您的主机使用 Unix 套接字或管道，请相应地调整文件中的DB_HOSTwp-config.php值。

define( 'DB_HOST', '127.0.0.1:<strong>/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'localhost:<strong>/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'example.tld:<strong>/var/run/mysqld/mysqld.sock' );

替换为主机提供的套接字或管道信息。 _/var/run/mysqld/mysqld.sock_

数据库字符集

DB_CHARSET可用以允许在定义 MySQL 数据库表时指定要使用的数据库字符集（例如，tis620 代表 TIS620 泰语）。

utf8 ( Unicode UTF-8 )的默认值几乎总是最佳选择。UTF-8 支持任何语言，因此您通常希望将 DB_CHARSET 保留为utf8并使用您的语言的DB_COLLATE值。

此示例显示 utf8，它被视为 WordPress 默认值：

define( 'DB_CHARSET', 'utf8' );

通常不需要更改 DB_CHARSET 的默认值。如果您的博客需要不同的字符集，请阅读字符集和排序规则 MySQL 支持以获取有效的 DB_CHARSET 值。**警告：**执行升级的人员。

如果您的文件中不存在 DB_CHARSET 和 DB_COLLATE wp-config.php，请不要将任何一个定义添加到您的wp-config.php文件中，除非您阅读并理解了Converting Database Character Sets。wp-config.php对于现有博客，将 DB_CHARSET 和 DB_COLLATE 添加到文件中可能会导致重大问题。

数据库整理

DB_COLLATE可用于指定数据库排序规则（即字符集的排序顺序）。在大多数情况下，此值应留空 (null)，以便 MySQL 根据 DB_CHARSET 指定的数据库字符集自动分配数据库排序规则。您可能需要将“'DB_COLLATE”'设置为大多数西欧语言的 UTF-8字符集中定义的 UTF-8值之一的示例是，当您输入的字符不是与显示的内容相同。（另请参阅SQL 手册中的Unicode 字符集）

WordPress 默认的 DB_COLLATE 值：

define( 'DB_COLLATE', '' );

UTF-8 Unicode 通用排序规则

define( 'DB_COLLATE', 'utf8_general_ci' );

UTF-8 Unicode 土耳其语整理

define( 'DB_COLLATE', 'utf8_turkish_ci' );

通常没有理由更改 DB_COLLATE 的默认值。将该值留空 (null) 将确保在创建数据库表时由 MySQL 自动分配排序规则。**警告：**执行升级的人员

如果您的文件中不存在 DB_COLLATE 和 DB_CHARSET wp-config.php，除非您阅读并理解了Converting Database Character Sets ，否则不要将任何一个定义添加到您的文件中。您可能需要升级 WordPress。wp-config.php

安全密钥

您不必记住密钥，只需让它们变长、随机且复杂——或者更好的是，使用在线生成器。您可以随时更改这些内容以使所有现有 cookie 失效。这确实意味着所有用户都必须重新登录。

示例（不要使用这些！）：

define( 'AUTH_KEY',         't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|' );
define( 'SECURE_AUTH_KEY',  'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj' );
define( 'LOGGED_IN_KEY',    'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^' );
define( 'NONCE_KEY',        'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe' );
define( 'AUTH_SALT',        '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G' );
define( 'SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #' );
define( 'LOGGED_IN_SALT',   'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+V.o<$|#_}qG(GaVDEsn,~*4i' );
define( 'NONCE_SALT',       'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%' );

通过向密码中添加随机元素，密钥使您的站点更难成功攻击。

简而言之，密钥是一种密码，其中包含一些元素，这些元素使生成足够多的选项来突破安全屏障变得更加困难。像“password”或“test”这样的密码很简单，也很容易被破解。一个不使用字典单词的随机长密码，例如“88a7da62429ba6ad3cb3c76a09641fc”，需要蛮力攻击者花费数百万小时才能破解。A ' _salt_用于进一步增强生成结果的安全性。

增强的安全性需要这四个密钥。这四种盐是推荐的，但不是必需的，因为如果没有提供，WordPress 会为您生成盐。它们wp-config.php默认包含在包容性中。

有关密钥和安全密码的技术背景和细分的更多信息，请参阅：

Ryan Boren——WordPress 2.6 中的 SSL 和 Cookie
维基百科对密码破解的解释
Lorelle VanFossen——用可靠的密码保护你的博客
Instructables - 安全密码提示
赫芬顿邮报 – 您今天可以采取的 17 条保护在线密码的技巧

高级选项

以下部分可能包含高级信息，某些更改可能会导致无法预料的问题。在修改这些设置之前，请确保您练习定期备份并知道如何恢复它们。

表前缀

$ table_prefix是放在数据库表前面的值。如果您想使用**wp_**以外的内容作为您的数据库前缀，请更改该值。通常，如果您在同一个数据库中安装多个 WordPress 博客，这会发生变化，就像使用多站点功能一样。

如果您给每个安装一个唯一的前缀，则可以在一个数据库中进行多个安装。如果您选择这样做，请牢记安全性。

$table_prefix = 'r235_'; // Only numbers, letters, and underscores please!

WP_SITEURL

WP_SITEURL 允许定义 WordPress 地址（URL）。定义的值是您的 WordPress 核心文件所在的地址。它也应该包括该http://部分。不要在末尾加上斜杠“ / ”。设置此值将wp-config.php覆盖siteurl的wp_options 表值。添加这个可以减少加载站点时数据库调用的次数。注意：这不会改变数据库存储的值。如果此行从中删除，则 URL 将恢复为旧数据库值。使用RELOCATE常量更改数据库中的siteurl值。wp-config

如果 WordPress 安装到域example.com 的名为“wordpress”的目录中，请像这样定义 WP_SITEURL：

define( 'WP_SITEURL', 'http://example.com/wordpress' );

基于 $_SERVER['HTTP_HOST'] 动态设置 WP_SITEURL

define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );

注意： HTTP_HOST 是由 PHP 根据请求中的 HTTP HOST 标头的值动态创建的，因此可能存在文件包含漏洞。SERVER_NAME 也可以动态创建。但是，当 Apache 配置为 UseCanonicalName “on”时，SERVER_NAME 由服务器配置设置，而不是动态设置。在这种情况下，使用 SERVER_NAME 比使用 HTTP_HOST 更安全。

基于 $_SERVER['SERVER_NAME'] 动态设置 WP_SITEURL

define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' );

博客地址（URL）

与 WP_SITEURL 类似，WP_HOME_会覆盖_ home的_wp_options 表__值__，但不会在数据库中更改它。_ home是您希望人们在浏览器中输入以访问您的 WordPress 博客的地址。它应该包括该部分，并且末尾http://不应有斜线“ **/ ”。**添加这个可以减少加载站点时数据库调用的次数。

define( 'WP_HOME', 'http://example.com/wordpress' );

如果您正在使用Giving WordPress Its Own Directory中描述的技术，请遵循以下示例。index.php请记住，如果您使用这样的设置，您还将在您的网络根目录中放置一个。

define( 'WP_HOME', 'http://example.com' );

基于 $_SERVER['HTTP_HOST'] 动态设置 WP_HOME

define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );

移动 wp-content 文件夹

您可以将wp-content包含主题、插件和上传内容的目录移到 WordPress 应用程序目录之外。

将 WP_CONTENT_DIR 设置为此目录的完整本地路径（无尾部斜杠），例如

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content' );

将 WP_CONTENT_URL 设置为此目录的完整URL （无尾部斜杠），例如

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content' );

移动插件文件夹

将 WP_PLUGIN_DIR 设置为此目录的完整本地路径（无尾部斜杠），例如

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

将 WP_PLUGIN_URL 设置为该目录的完整URI （无尾部斜杠），例如

define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins' );

如果您对插件有兼容性问题，请将 PLUGINDIR 设置为该目录的完整本地路径（无尾部斜杠），例如

define( 'PLUGINDIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

移动主题文件夹

您不能移动 themes 文件夹，因为它的路径是相对于wp-content文件夹的硬编码：

$theme_root = WP_CONTENT_DIR 。'/主题';

但是，您可以使用register_theme_directory注册额外的主题目录。

查看如何移动 wp-content文件夹。有关如何确定主题文件夹的更多详细信息，请参阅wp-includes/theme.php。

移动上传文件夹

将上传设置为：

define( 'UPLOADS', 'blog/wp-content/uploads' );

这个路径不可能是绝对的。它总是相对于 ABSPATH，因此不需要前导斜杠。

修改自动保存间隔

编辑帖子时，WordPress 使用 Ajax 在您编辑时自动保存对帖子的修订。您可能希望增加此设置以延长自动保存之间的延迟时间，或减少此设置以确保您永远不会丢失更改。默认值为 60 秒。

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

发布修订

默认情况下，WordPress 将保存对帖子或页面所做的每次编辑的副本，从而可以恢复到该帖子或页面的先前版本。可以禁用修订的保存，或者可以指定每个帖子或页面的最大修订数。

禁用发布修订

如果您不设置此值，WordPress 默认 WP_POST_REVISIONS 为_true_（启用后期修订）。如果您想禁用 awesome revisions 功能，请使用此设置：

define( 'WP_POST_REVISIONS', false );

注意：一些用户在将命令移动到中初始块注释下的第一行之前无法使它起作用wp-config.php。

指定后期修订的数量

如果您想指定 WordPress 存储的最大修订数，请将_false_更改为整数/数字（例如，3 或 12）。

define( 'WP_POST_REVISIONS', 3 );

注意：一些用户在将命令移动到中初始块注释下的第一行之前无法使它起作用wp-config.php。

设置 Cookie 域

可以为那些具有异常域设置的人指定 WordPress cookie 中设置的域。例如，如果子域用于提供静态内容，您可以将 cookie 域设置为仅您的非静态域，以防止 WordPress cookie 随每次请求发送到您子域上的静态内容。

define( 'COOKIE_DOMAIN', 'www.example.com' );

启用多站点/网络能力

WP_ALLOW_MULTISITE 是启用多站点功能的功能。如果此设置不存在，wp-config.php则默认为 false。

define( 'WP_ALLOW_MULTISITE', true );

重定向不存在的博客

如果访问者试图访问不存在的子域或子文件夹，NOBLOGREDIRECT 可用于重定向浏览器。

define( 'NOBLOGREDIRECT', 'http://example.com' );

致命错误处理程序

WordPress 5.2 引入了恢复模式，当插件导致致命错误时显示错误消息而不是白屏。

该站点遇到技术困难。请检查您的站点管理员电子邮件收件箱以获取说明。

不再向用户显示白屏和 PHP 错误消息。但是在开发环境中，如果要启用 WP_DEBUG_DISPLAY，则必须通过将 WP_DISABLE_FATAL_ERROR_HANDLER 设置为 true 来禁用恢复模式。

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );

WP_DEBUG

WP_DEBUG选项控制一些错误和警告的报告，并允许使用 WP_DEBUG_DISPLAY 和 WP_DEBUG_LOG 设置。默认布尔值为 false。

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later
define( 'WP_DEBUG', true );

仅当 WP_DEBUG 设置为 true 时才会打印数据库错误。数据库错误由wpdb类处理，不受PHP 错误设置的影响。

将 WP_DEBUG 设置为 true 也会将错误报告级别提高到 E_ALL 并在使用过时的函数或文件时激活警告；否则，WordPress 将错误报告级别设置为 E_ALL ^ E_NOTICE ^ E_USER_NOTICE。

WP_ENVIRONMENT_TYPE

WP_ENVIRONMENT_TYPE 选项控制站点的环境类型：local、development、staging和production。

环境类型的值按以下顺序处理，每个顺序方法覆盖任何以前的值：WP_ENVIRONMENT_TYPE PHP 环境变量和 WP_ENVIRONMENT_TYPE 常量。

对于这两种方法，如果提供的环境类型的值不在允许的环境类型列表中，production则将返回默认值。

设置值的最简单方法可能是通过定义常量：

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

注意：何时development返回wp_get_environment_type() , WP_DEBUG 将被设置为true如果它没有在wp-config.php站点文件中定义。

脚本调试

SCRIPT_DEBUG是一个相关常量，它将强制 WordPress 使用 , , , 中的脚本和样式表的“开发”版本，wp-includes/js并将wp-includes/css加载wp-admin/js而wp-admin/css不是.min.css和.min.js版本。如果您计划修改某些 WordPress 的内置 JavaScript 或级联样式表，您应该将以下代码添加到您的配置文件中：

define( 'SCRIPT_DEBUG', true );

禁用 Javascript 串联

为了获得更快的管理屏幕，所有 JavaScript 文件都连接到一个 URL 中。如果 JavaScript 在管理屏幕中无法运行，您可以尝试禁用此功能：

define( 'CONCATENATE_SCRIPTS', false );

配置错误记录

配置错误日志记录可能有点棘手。首先，默认的 PHP 错误日志和显示设置是在 php.ini 文件中设置的，您可能有也可能没有访问权限。如果这样做，则应将它们设置为向公众提供的实时 PHP 页面所需的设置。强烈建议不要向公众显示错误消息，而是将其路由到错误日志。此外，错误日志不应位于服务器的可公开访问部分。示例推荐的 php.ini 错误设置：

error_reporting = 4339
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /home/example.com/logs/php_error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
html_errors = Off

关于错误报告 4339 这是一个自定义值，它只记录影响站点运行的问题，而忽略通知之类的事情，甚至可能不是错误。1000011110011的二进制位的含义见PHP错误常量，二进制数等于4339，最左边的1表示报任何E_RECOVERABLE_ERROR。接下来的0表示不报告E_STRICT，（草率但使用功能编码时抛出）等等。随意确定您自己的自定义错误报告编号以代替 4339。

显然，您需要为您的开发环境设置不同的设置。如果您的暂存副本位于同一台服务器上，或者您无权访问php.ini，则需要在运行时覆盖默认设置。您是希望将错误转到日志文件，还是希望在出现任何错误时立即收到通知，或者两者兼而有之，这完全取决于个人偏好。下面是一个示例，它会立即报告您可以插入到wp-config.php文件中的所有错误：

@ini_set( 'log_errors', 'Off' );
@ini_set( 'display_errors', 'On' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', true );

因为不是从缓存文件加载的每个页面视图都加载，所以它是设置控制 PHP 安装的设置wp-config.php的绝佳位置。php.ini如果您无权访问文件php.ini，或者只是想即时更改某些设置，这将很有用。一个例外是“error_reporting”。当 WP_DEBUG 被定义为 true 时，'error_reporting' 将被 WordPress 设置为 E_ALL，无论您尝试在 wp-config.php 中设置什么。如果您确实需要将“error_reporting”设置为其他内容，则必须在wp-settings.php加载后完成，例如在插件文件中。

如果您打开错误记录，请记住之后删除该文件，因为它通常位于可公开访问的位置，任何人都可以访问您的日志。

下面是一个打开 PHP error_logging 并将它们记录到特定文件的示例。如果 WP_DEBUG 被定义为真，错误也将被保存到这个文件中。只需将它放在任何_require_once_或_include_命令之上。

@ini_set( 'log_errors', 'On' );
@ini_set( 'display_errors', 'Off' );
@ini_set( 'error_log', '/home/example.com/logs/php_error.log' );
/* That's all, stop editing! Happy blogging. */

另一个记录错误的例子，正如 Mike Little 在wp-hackers 电子邮件列表中所建议的：

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content (if Apache does not have write permission, you may need to create
 * the file first and set the appropriate permissions (i.e. use 666) )
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

来自曼彻斯特 WordPress 用户组的 Mike Little 的精炼版本：

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content only when WP_DEBUG is true. if Apache does not have write permission,
 * you may need to create the file first and set the appropriate permissions (i.e. use 666).
 */
define( 'WP_DEBUG', true ); // Or false
if ( WP_DEBUG ) {
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );
    @ini_set( 'display_errors', 0 );
}

令人困惑的是 WordPress 有三 (3) 个常量，看起来它们可以做同样的事情。首先，请记住，如果 WP_DEBUG 为假，它和其他两个 WordPress DEBUG 常量不会执行任何操作。PHP 指令，无论它们是什么，都将占上风。除了 'error_reporting'，如果 WP_DEBUG 定义为 false，WordPress 会将其设置为 4983。其次，即使 WP_DEBUG 为真，其他常量也只有在它们也设置为真时才会执行某些操作。如果将它们设置为 false，则 PHP 指令保持不变。例如，如果您的php.ini文件有指令 ('display_errors' = 'On'); 但是你有语句 define( 'WP_DEBUG_DISPLAY', false ); 在你的wp-config.php文件，即使您试图通过将 WP_DEBUG_DISPLAY 设置为 false 来阻止它，错误仍将显示在屏幕上，因为这是 PHP 配置的行为。这就是为什么将 PHP 指令设置为您需要的非常重要的原因，以防任何相关的 WP 常量设置为 false。为了安全起见，明确设置/定义这两种类型。有关 WP 常量的更多详细说明，请参阅在 WordPress 中调试。

对于您的公共、生产 WordPress 安装，您可以考虑将以下内容放入您的wp-config.php文件中，即使它可能部分多余：

@ini_set( 'log_errors', 'On' );
@ini_set( 'display_errors', 'Off' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false );   // 5.2 and later
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

默认的调试日志文件是 /wp-content/debug.log. 将错误日志放在可公开访问的位置存在安全风险。理想情况下，您的日志文件应该放在您站点的公共根目录之上。如果您不能这样做，至少，将日志文件权限设置为 600，并将此条目添加到.htaccessWordPress 安装根目录中的文件中：

<Files debug.log>
    Order allow,deny
    Deny from all
</Files>

这可以防止任何人通过 HTTP 访问该文件。您始终可以通过 FTP 从服务器检索日志文件来查看日志文件。

增加分配给 PHP 的内存

WP_MEMORY_LIMIT选项允许您指定 PHP 可以消耗的最大内存量。如果您收到诸如“允许的 xxxxxx 字节的内存大小已耗尽”之类的消息，则可能需要此设置。

此设置仅增加 WordPress 的 PHP 内存，不增加其他应用程序。默认情况下，WordPress 会尝试将分配给 PHP的内存增加到/wp-includes/default-constants.php单站点的 40MB （代码位于wp-config.php

在使用此功能之前，WordPress 会自动检查 PHP 分配的内存是否少于输入的值。例如，如果 PHP 已分配 64MB，则无需将此值设置为 64M，因为 WordPress 会在需要时自动使用所有 64MB。

注意：有些主机不允许自动增加 PHP 内存限制。在这种情况下，请联系您的主机以增加 PHP 内存限制。此外，许多主机将 PHP 限制设置为 8MB。

调整 WordPress 内存限制也可能会产生问题。您可能最终隐藏了问题的根源，因为它会在您添加更多插件或功能时发生。

如果您遇到内存不足的问题，即使内存限制提高了，您也应该正确调试您的安装。您可能有太多与特定操作相关的内存密集型功能，应该将这些功能移至 cronjob。

将 PHP 内存增加到 64MB

define( 'WP_MEMORY_LIMIT', '64M' );

将 PHP 内存增加到 96MB

define( 'WP_MEMORY_LIMIT', '96M' );

管理任务所需的内存可能比通常的操作需要的多。在管理区域中，可以通过定义 WP_MAX_MEMORY_LIMIT 从 WP_MEMORY_LIMIT 增加或减少内存。

define( 'WP_MAX_MEMORY_LIMIT', '128M' );

注意：这必须放在 wp-settings.php 包含之前。

缓存

WP_CACHE设置，如果为真，则在执行时包含脚本。wp-content/advanced-cache.php``wp-settings.php

define( 'WP_CACHE', true );

自定义用户和用户元数据表

CUSTOM_USER_TABLE和CUSTOM_USER_META_TABLE用于指定不使用 WordPress 通常使用的用户和 usermeta 表，而是使用这些值/表来存储您的用户信息。

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

注意：即使手动设置了'CUSTOM_USER_META_TABLE'，仍然会为每个数据库创建一个用户元数据表，并为每个实例提供相应的权限。默认情况下，WordPress 安装程序将为第一个用户（ID #1）添加权限。您还需要通过插件或自定义功能管理对每个站点的权限。如果未设置，您将遇到权限错误和登录问题。

CUSTOM_USER_TABLE 在您的第一个 WordPress 实例的初始设置期间最容易采用。第一个实例的定义语句wp-config.php指向wp_users默认存储数据的位置。在第一个站点设置之后，将工作复制wp-config.php到下一个实例只需要更改变量$table_prefix。不要使用原始安装已使用的电子邮件地址。完成设置过程后，使用自动生成的管理员帐户和密码登录。接下来，将您的普通帐户提升为管理员级别并注销管理员。以您自己的身份重新登录，删除管理员帐户并根据需要升级其他用户帐户。

语言和语言目录

WordPress 4.0 版允许您更改 WordPress管理屏幕中的语言。更改管理设置屏幕中的语言。前往“设置” > “通用”，然后选择“网站语言”。

WordPress v3.9.6 及以下版本

WPLANG定义语言翻译 (.mo) 文件的名称。WP_LANG_DIR定义 WPLANG .mo 文件所在的目录。如果未定义 WP_LANG_DIR，WordPress 首先查找 wp-content/languages，然后wp-includes/languages查找由 WPLANG 文件定义的 .mo。

define( 'WPLANG', 'de_DE' );
define( 'WP_LANG_DIR', dirname(__FILE__) . 'wordpress/languages' );

要找出 WPLANG 语言代码，请参阅此处。WP Local 列中的代码是您需要的。

保存查询以供分析

SAVEQUERIES定义将数据库查询保存到一个数组中，并且可以显示该数组以帮助分析这些查询**。**这些信息保存了每个查询、调用它的函数以及执行该查询所花费的时间。**注意：**这会对您的站点产生性能影响，因此请务必在不调试时将其关闭。

首先，将其添加到wp-config.php文件中：

define( 'SAVEQUERIES', true );

然后在主题的页脚中放置以下内容：

if ( current_user_can( 'administrator' ) ) {
    global $wpdb;
    echo "<pre>";
    print_r( $wpdb->queries );
    echo "</pre>";
}
?>

或者，考虑使用查询监视器

覆盖默认文件权限

FS_CHMOD_DIR和FS_CHMOD_FILE定义语句允许覆盖默认文件权限**。**这两个变量是为了应对主机在suexec下运行时核心更新功能失败的问题而开发的。如果主机对所有用户文件使用限制性文件权限（例如 400），并拒绝访问设置了组或世界权限的文件，这些定义可以解决问题。

define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

提供 setgid 的示例：

define( 'FS_CHMOD_DIR', ( 02755 & ~umask() ) );

注意：' **0755'**和' 02755 '是八进制值。八进制值必须以 0 为前缀，并且不使用单引号 (') 分隔。另请参阅：更改文件权限

WordPress 升级常量

注意：根据需要定义尽可能少的以下常量以更正您的更新问题。

需要定义这些的最常见原因是：

使用涉及符号链接的特殊安装设置运行的主机。您可能需要定义与路径相关的常量（FTP_BASE、FTP_CONTENT_DIR 和 FTP_PLUGIN_DIR）。通常简单地定义基数就足够了。

某些 PHP 安装附带了与某些 FTP 服务器不兼容的 PHP FTP 扩展。在这些罕见的情况下，您可能需要将 FS_METHOD 定义为“ftpsockets”。

以下是 WordPress 更新的有效常量：

FS_METHOD强制文件系统方法。它只能是“direct”、“ssh2”、“ftpext”或“ftpsockets”。通常，只有在遇到更新问题时才应更改此项。如果您更改它但没有帮助，请将其改回/删除。在大多数情况下，如果自动选择的方法不起作用，则将其设置为“ftpsockets”即可。
- **（主要偏好）“direct”**强制它使用来自 PHP 内部的直接文件 I/O 请求，这充满了在配置不当的主机上打开安全问题，这是在适当的时候自动选择的。
- **（次要偏好）“ssh2”**是强制使用 SSH PHP 扩展（如果已安装）
- **（第三个偏好）“ftpext”**是强制使用 FTP PHP 扩展进行 FTP 访问，最后
- **（第 4 个偏好）“ftpsockets”**利用 PHP 套接字类进行 FTP 访问。
FTP_BASE是 WordPress 安装的“基础”(ABSPATH) 文件夹的完整路径。
FTP_CONTENT_DIR是 WordPress 安装的 wp-content 文件夹的完整路径。
FTP_PLUGIN_DIR是 WordPress 安装插件文件夹的完整路径。
FTP_PUBKEY是 SSH 公钥的完整路径。
FTP_PRIKEY是 SSH 私钥的完整路径。
FTP_USER是用户 FTP 或 SSH 用户名。这些很可能是相同的，但使用适合您希望执行的更新类型的那个。
FTP_PASS是为****FTP_USER输入的用户名的密码。如果您使用 SSH 公钥身份验证，则可以省略。
FTP_HOST是您的 SSH/FTP 服务器的主机名：端口组合。默认的FTP端口是21，默认的SSH端口是22，这些就不用说了。
FTP_SSL如果底层传输支持（并非在所有服务器上都可用），则 SSL 连接为 TRUE 。这适用于“安全 FTP”，不适用于 SSH SFTP。

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_BASE', '/path/to/wordpress/' );
define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' );
define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' );
define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' );
define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' );
define( 'FTP_USER', 'username' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'ftp.example.org' );
define( 'FTP_SSL', false );

某些配置应将 FTP_HOST 设置为本地主机，以避免在尝试更新插件或 WP 本身时出现 503 问题。

启用 SSH 升级访问

使用 SSH2 升级有两种方法。

第一种是使用SSH SFTP Updater Support 插件。第二种是使用内置的 SSH2 升级程序，这需要安装 pecl SSH2 扩展。

要安装 pecl SSH2 扩展，您需要发出类似于以下的命令或与您的网络托管服务提供商联系以安装此扩展：

pecl install ssh2

安装 pecl ssh2 扩展后，您需要修改 PHP 配置以自动加载此扩展。

大多数 Linux 发行版中的 pear 包都提供了 pecl。在 Redhat/Fedora/CentOS 中安装 pecl：

yum -y install php-pear

在 Debian/Ubuntu 中安装 pecl：

apt-get install php-pear

建议使用不受密码保护的私钥。有大量报告称受密码短语保护的私钥无法正常工作。如果您决定尝试使用密码短语保护的私钥，您将需要输入私钥的密码短语 FTP_PASS，或者在安装更新时在提供的凭据字段的“密码”字段中输入它。

替代 Cron

可能有理由使用 WP 的替代 Cron。如果预定的帖子没有按预期发布，最常见的是这样做。这种替代方法使用重定向方法。当 cron 需要运行时，用户的浏览器会获得重定向，以便他们立即返回站点，同时 cron 继续在他们刚刚断开的连接中运行。这种方法有一定的风险，因为它依赖于非本地 WordPress 服务。

define( 'ALTERNATE_WP_CRON', true );

禁用 Cron 和 Cron 超时

通过将 DISABLE_WP_CRON 设置为 true 来完全禁用 cron。

define( 'DISABLE_WP_CRON', true );

确保 cron 进程不能每 WP_CRON_LOCK_TIMEOUT 秒运行一次以上。

define( 'WP_CRON_LOCK_TIMEOUT', 60 );

附加定义常量

以下是可以定义的附加常量。这些可能不应该设置，除非首先尝试了其他方法。如果您的域设置不寻常，Cookie 定义会特别有用。

define( 'COOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'home' ) . '/' ) );
define( 'SITECOOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'siteurl' ) . '/' ) );
define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' );
define( 'PLUGINS_COOKIE_PATH', preg_replace( '|https?://[^/]+|i', '', WP_PLUGIN_URL ) );
define( 'TEMPLATEPATH', get_template_directory() );
define( 'STYLESHEETPATH', get_stylesheet_directory() );

清空垃圾桶

此常量控制 WordPress 从垃圾箱中永久删除帖子、页面、附件和评论之前的天数。默认值为 30 天：

define( 'EMPTY_TRASH_DAYS', 30 ); // 30 days

要禁用垃圾，请将天数设置为零。

define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days

**注意：**当有人使用此设置点击“永久删除”时，WordPress 不会要求确认。

自动数据库优化

有自动数据库修复支持，您可以通过将以下定义添加到您的wp-config.php文件来启用它。

注意：这应该只在需要时启用，并在问题解决后禁用。启用后，用户无需登录即可访问该功能，因为其主要目的是修复损坏的数据库，而当数据库损坏时用户通常无法登录。

 define( 'WP_ALLOW_REPAIR', true );

该脚本可以在找到{$your_site}/wp-admin/maint/repair.php。

DO_NOT_UPGRADE_GLOBAL_TABLES

DO_NOT_UPGRADE_GLOBAL_TABLES定义可防止dbDelta() 和升级函数对全局表进行昂贵的查询**。**

具有大型全局表（特别是用户和 usermeta）的站点，以及与 bbPress 和其他 WordPress 安装共享用户表的站点，可以通过将 DO_NOT_UPGRADE_GLOBAL_TABLES 定义为 true 来防止升级在升级期间更改这些表。由于 ALTER、无限制的 DELETE 或 UPDATE 可能需要很长时间才能完成，因此大型站点通常希望避免将这些作为升级的一部分运行，以便他们自己处理。此外，如果安装在多个 bbPress 和 WordPress 安装之间共享用户表，您可能希望一个站点成为升级主机。

define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );

查看所有定义的常量

PHP 有一个函数返回所有当前定义的常量及其值的数组。

 print_r( @get_defined_constants() );

禁用插件和主题文件编辑器

有时您可能希望禁用插件或主题文件编辑器，以防止过度热心的用户能够编辑敏感文件并可能导致站点崩溃。如果黑客获得对特权用户帐户的访问权限，则禁用这些还可以提供额外的安全层。

define( 'DISALLOW_FILE_EDIT', true );

注意：某些插件的功能可能会受到在其代码中使用的影响current_user_can('edit_plugins')。插件作者应该避免检查此功能，或者至少检查是否设置了此常量并显示适当的错误消息。请注意，如果插件无法正常工作，这可能就是原因。

禁用插件和主题更新和安装

这将阻止用户从 WordPress 管理区域使用插件和主题安装/更新功能。设置这个常量也会禁用插件和主题文件编辑器（即您不需要设置 DISALLOW_FILE_MODS 和 DISALLOW_FILE_EDIT，因为它自己的 DISALLOW_FILE_MODS 将具有相同的效果）。

define( 'DISALLOW_FILE_MODS', true );

管理员和登录需要 SSL

注意： WordPress 4.0 版弃用了 FORCE_SSL_LOGIN。请使用 FORCE_SSL_ADMIN。

FORCE_SSL_ADMIN 适用于您想要保护登录和管理区域的安全，以便永远不会以明文形式发送密码和 cookie。有关详细信息，另请参阅Administration_Over_SSL 。

define( 'FORCE_SSL_ADMIN', true );

阻止外部 URL 请求

通过将 WP_HTTP_BLOCK_EXTERNAL 定义为 true 来阻止外部 URL 请求，这将只允许本地主机和您的博客发出请求。常量 WP_ACCESSIBLE_HOSTS 将允许其他主机通过请求。WP_ACCESSIBLE_HOSTS 常量的格式是逗号分隔的主机名列表，支持通配符域，例如 *.wordpress.org 将允许联系 wordpress.org 的所有子域。

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

禁用 WordPress 自动更新

站点可能有不自动更新的原因，例如自定义或主机提供的更新。它也可以在主要版本之前完成，以便在允许在生产站点上进行更新之前留出时间在开发或暂存环境中进行测试。

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

禁用 WordPress 核心更新

操作核心更新的最简单方法是使用 WP_AUTO_UPDATE_CORE 常量：

 # 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' );

参考：在 WordPress 3.7 中禁用自动更新

清理图像编辑

默认情况下，WordPress 会在您每次编辑图像时创建一组新图像，而当您恢复原始图像时，它会将所有编辑内容留在服务器上。将 IMAGE_EDIT_OVERWRITE 定义为 true 会改变这种行为。只会创建一组图像编辑，当您恢复原始图像时，这些编辑将从服务器中删除。

 define( 'IMAGE_EDIT_OVERWRITE', true );

保存前仔细检查

请务必检查您输入的上述任何值周围的前导和/或尾随空格，并且不要删除单引号！

在保存文件之前，请务必仔细检查您没有意外删除参数值周围的任何单引号。确保文件中的结束 PHP 标记后没有任何内容。文件中的最后一件事应该是**?>**而不是别的。没有空间。

要保存文件，请选择文件 > 另存为 > wp-config.php并将文件保存在 WordPress 安装的根目录中。将文件上传到您的网络服务器，您就可以安装 WordPress 了！