WordPress 安装中最重要文件之一是 wp-config.php 文件。该文件位于 WordPress 文件目录的根目录下，包含网站的基本配置信息，例如数据库连接信息。
配置数据库设置
重要： 切勿使用 Microsoft Word 等文字处理器编辑 WordPress 文件！
在 WordPress 目录的基础目录中找到 wp-config-sample.php 文件，并使用 文本编辑器 打开它。
默认 wp-config-sample.php
注意：这是来自 wp-config-sample.php 的默认示例。其中的值仅为示例，用于说明您应该做什么。
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );
/** MySQL database username */
define( 'DB_USER', 'username_here' );
/** MySQL database password */
define( 'DB_PASSWORD', 'password_here' );
/** MySQL hostname */
define( 'DB_HOST', 'localhost' );注意： /* */ 内的文本是 注释，仅供参考。
设置数据库名称
将 '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 socket 文件路径。
define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database host注意： 您很可能 无需更改此值。如果您不确定，请尝试使用默认值 'localhost' 进行安装并查看是否有效。如果安装失败，请联系您的网络托管提供商。
MySQL 备用端口
如果您的主机为数据库使用备用端口号，则需要在 wp-config.php 文件中更改 DB_HOST 的值以反映主机提供的备用端口。
对于 localhost：
define( 'DB_HOST', '127.0.0.1:3307' );
or
define( 'DB_HOST', 'localhost:3307' );对于指定服务器：
define( 'DB_HOST', 'mysql.example.com:3307' );将上述任一代码示例中的数字 3307 替换为您主机提供的端口号信息。
MySQL Sockets or Pipes
如果您的主机使用 Unix sockets 或 pipes，则需要在 wp-config.php 文件中更改 DB_HOST 的值以反映主机提供的 socket 或 pipe 信息。
define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'example.tld:/var/run/mysqld/mysqld.sock' );
将上面的文本字符串 /var/run/mysqld/mysqld.sock 替换为您主机提供的 socket 或 pipe 信息。
数据库字符集
DB_CHARSET 的引入是为了允许指定创建 MySQL 数据库表时使用的数据库 字符集（例如 TIS620 泰语使用 tis620）。
utf8（Unicode UTF-8）的默认值几乎总是最佳选择。UTF-8 支持任何语言，因此通常建议将 DB_CHARSET 保留为 utf8，而针对您的语言使用 DB_COLLATE 值。
此示例展示了被视为 WordPress 默认值的 utf8：
define( 'DB_CHARSET', 'utf8' );通常没有理由更改 DB_CHARSET 的默认值。如果您的博客需要不同的字符集，请阅读 Character Sets and Collations MySQL Supports 以获取有效的 DB_CHARSET 值。警告： 正在进行升级的用户。
如果您的 wp-config.php 文件中不存在 DB_CHARSET 和 DB_COLLATE，除非您已阅读并理解 Converting Database Character Sets，否则 请勿将这两个定义添加到您的 wp-config.php 文件中。对于现有博客，向 wp-config.php 文件添加 DB_CHARSET 和 DB_COLLATE 可能会导致严重问题。
数据库排序规则
DB_COLLATE 的引入是为了允许指定数据库 排序规则（即字符集的排序顺序）。在大多数情况下，此值应留空（null），以便根据 DB_CHARSET 指定的数据库字符集由 MySQL 自动分配数据库排序规则。当输入字符与显示字符不一致时，您可能需要将 'DB_COLLATE' 设置为 UTF-8 character sets 中定义的 UTF-8 值之一（适用于大多数西欧语言）。另请参阅 SQL 手册中的 Unicode Character Sets）。
WordPress 默认的 DB_COLLATE 值：
define( 'DB_COLLATE', '' );UTF-8 Unicode General 排序规则
define( 'DB_COLLATE', 'utf8_general_ci' );UTF-8 Unicode Turkish 排序规则
define( 'DB_COLLATE', 'utf8_turkish_ci' );通常没有理由更改 DB_COLLATE 的默认值。将值留空（null）可确保在创建数据库表时由 MySQL 自动分配排序规则。警告： 正在进行升级的用户。
如果您的 wp-config.php 文件中不存在 DB_COLLATE 和 DB_CHARSET，除非您已阅读并理解 Converting Database Character Sets，否则 请勿将这两个定义添加到您的 wp-config.php 文件中。您可能需要进行 WordPress 升级。
安全密钥
您不需要记住这些密钥，只需让它们足够长、随机且复杂即可——或者更好的是使用 在线生成器。您可以随时更改这些密钥以使所有现有 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"，暴力破解者可能需要数百万小时才能破解。'盐（salt）' 用于进一步增强生成结果的安全性。
这四个密钥是实现增强安全性所必需的。四个盐是推荐的，但不是必需的，因为如果没有提供，WordPress 会为您自动生成盐。为了包容性，它们默认包含在 wp-config.php 中。
有关密钥和安全密码的技术背景和详细分解的更多信息，请参阅：
- 维基百科关于密码破解的解释
- Lorelle VanFossen – 用强密码保护你的博客
- Instructables – 安全密码技巧
- Huffington Post – 今天就可以做的 17 个保护在线密码的技巧
高级选项
以下部分可能包含高级信息，某些更改可能会导致不可预见的问题。请在修改这些设置之前确保你已执行定期备份并知道如何恢复它们。
table_prefix
$table_prefix是置于数据库表名称前的值。如果你想使用wp_以外的前缀作为数据库前缀，请更改此值。通常在同一个数据库中安装多个 WordPress 博客时（例如在使用多站点功能时）会更改此值。
如果你为每个安装指定唯一的前缀，则可以在一个数据库中进行多个安装。如果选择这样做，请务必注意安全性。
$table_prefix = 'r235_'; // 仅允许数字、字母和下划线！WP_SITEURL
WP_SITEURL 用于定义 WordPress 地址（URL）。定义的值是你的 WordPress 核心文件所在的地址。它也应包含 http:// 部分。不要在末尾添加斜杠“/"。在 wp-config.php 中设置此值将覆盖 wp_options 表 中siteurl的值。添加此项可以减少加载网站时的数据库调用次数。注意：这不会更改数据库中存储的值。如果从 wp-config 中删除了此行，URL 将恢复为旧的数据库值。请使用 RELOCATE 常量来更改数据库中的siteurl值。
如果 WordPress 安装在名为"wordpress"的目录中（针对域 example.com），请按以下方式定义 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 覆盖 wp_options 表 中 home 的值，但不会更改数据库中的值。home是你希望用户在浏览器中输入以访问你的 WordPress 博客的地址。它应包含 http:// 部分，且末尾不应有斜杠“/"。添加此项可以减少加载网站时的数据库调用次数。
define( 'WP_HOME', 'http://example.com/wordpress' );如果你正在使用给 WordPress 分配独立目录中描述的技术，请遵循以下示例。请记住，如果使用此类设置，你还将在 Web 根目录中放置一个 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' );移动主题文件夹
你不能移动主题文件夹，因为其路径相对于 wp-content 文件夹是硬编码的：
$theme_root = WP_CONTENT_DIR . '/themes';
不过，你可以使用 register_theme_directory 注册额外的主题目录。
请参阅如何移动 wp-content文件夹。有关如何确定主题文件夹的更多详细信息，请参阅 wp-includes/theme.php。
移动上传文件夹
将 UPLOADS 设置为：
define( 'UPLOADS', 'blog/wp-content/uploads' );此路径不能是绝对路径。它始终相对于 ABSPATH，因此不需要前导斜杠。
修改自动保存间隔
在编辑帖子时，WordPress 会使用 Ajax 在你编辑时自动保存帖子的修订版本。你可能希望增加此设置以延长自动保存之间的延迟时间，或者减少设置以确保永远不会丢失更改。默认值为 60 秒。
define( 'AUTOSAVE_INTERVAL', 160 ); // 秒文章修订版本
WordPress 默认会保存对帖子或页面进行的每次编辑的副本，从而允许恢复到该帖子或页面的先前版本。可以禁用修订版本的保存，也可以指定每篇帖子或页面的最大修订版本数量。
禁用文章修订版本
如果你不设置此值，WordPress 会将 WP_POST_REVISIONS 默认为 true（启用文章修订版本）。如果你想禁用这个强大的修订版本功能，请使用此设置：
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 选项控制站点的环境类型。
WordPress 支持四种环境类型：
production（默认）：连接到互联网并可被互联网访问的实时站点，staging：连接到互联网并可被互联网访问的非生产预发布环境development：连接到互联网并可被互联网访问的非生产开发环境local：可以访问互联网但不可被互联网访问的非生产开发环境
对于设置为 development 或 local 环境类型的站点，WP_DEBUG 会自动启用。
对于可通过互联网访问的环境，应用程序密码功能要求站点通过安全的 HTTPS 连接提供。对于 local 环境，应用程序密码功能可在不安全的 HTTP 连接上工作。
环境类型的值按以下顺序处理，每个顺序方法都会覆盖之前的任何值：WP_ENVIRONMENT_TYPE PHP 环境变量 和 WP_ENVIRONMENT_TYPE 常量。
对于这两种方法，如果提供的任何环境类型值不在允许的环境类型列表中，将返回默认的 production 值。
设置该值的最简单方法可能是定义常量：
define( 'WP_ENVIRONMENT_TYPE', 'staging' );SCRIPT_DEBUG
SCRIPT_DEBUG 是一个相关常量，它将强制 WordPress 使用 wp-includes/js、wp-includes/css、wp-admin/js 和 wp-admin/css 中的“dev”版本的脚本和样式表，而不是加载 .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（等于 4339 的二进制数）的含义，请参阅 PHP 错误常量。最左边的 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 );因为 wp-config.php 会在每次查看页面时加载（除非是从缓存文件加载），所以它是设置控制 PHP 安装的 php.ini 设置的绝佳位置。如果您无法访问 php.ini 文件，或者只想即时更改某些设置，这将非常有用。一个例外是 'error_reporting'。当 WP_DEBUG 定义为 true 时，无论您在 wp-config.php 中尝试设置什么，WordPress 都会将 'error_reporting' 设置为 E_ALL。如果您确实需要将 'error_reporting' 设置为其他值，则必须在 wp-settings.php 加载之后进行，例如在插件文件中。
如果您开启了错误日志记录，请记住事后删除该文件，因为它通常位于公开可访问的位置，任何人都可能访问您的日志。
以下示例开启 PHP 错误日志记录并将其记录到特定文件。如果 WP_DEBUG 定义为 true，错误也将保存到该文件中。只需将此代码放在任何 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 );Mike Little 在 Manchester WordPress User Group 上的改进版本：
/**
* 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 为 false，它和另外两个 WordPress DEBUG 常量都不会起作用。PHP 指令（无论是什么）将占主导地位。除了 'error_reporting'，WordPress 会将此设置为 4983（如果 WP_DEBUG 被定义为 false）。其次，即使 WP_DEBUG 为 true，其他常量也只有在它们也被设置为 true 时才会起作用。如果它们被设置为 false，则 PHP 指令保持不变。例如，如果您的 php.ini 文件包含指令 ('display_errors' = 'On')；但您在 wp-config.php 文件中写入了 define( 'WP_DEBUG_DISPLAY', false ); 语句，错误仍将在屏幕上显示，尽管您尝试通过将 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，并在 WordPress 安装根目录的 .htaccess 文件中添加以下条目：
<Files debug.log>
Order allow,deny
Deny from all
</Files>这将防止任何人通过 HTTP 访问该文件。您可以通过 FTP 从服务器检索日志文件进行查看。
增加分配给 PHP 的内存
WP_MEMORY_LIMIT 选项允许您指定 PHP 可以消耗的最大内存量。如果在收到类似“Allowed memory size of xxxxxx bytes exhausted"的消息时，可能需要此设置。
此设置仅增加 WordPress 的 PHP 内存，不增加其他应用程序的内存。默认情况下，WordPress 将尝试将分配给 PHP 的内存增加到单站 40MB（代码位于 /wp-includes/default-constants.php 开头），多站点为 64MB，因此 wp-config.php 中的设置应根据您的设置反映高于 40MB 或 64MB 的值。
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 的内存。其默认值为 256MB。
define( 'WP_MAX_MEMORY_LIMIT', '512M' );注意：这必须在包含 wp-settings.php 之前放置。
缓存
WP_CACHE 设置，如果为 true，则在执行 wp-settings.php 时包含 wp-content/advanced-cache.php 脚本。
define( 'WP_CACHE', true );自定义用户和用户元数据表
CUSTOM_USER_TABLE 和 CUSTOM_USER_META_TABLE 用于指定 WordPress 通常使用的用户和用户元数据表不被使用，而是使用这些值/表来存储您的用户信息。
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>";
}
?>
或者，考虑使用 Query Monitor
覆盖默认文件权限
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 访问，以及
- （第四选）"ftpsockets"利用 PHP Sockets 类进行 FTP 访问。
- FTP_BASE是 WordPress 安装目录"base"(ABSPATH)文件夹的完整路径。
- FTP_CONTENT_DIR是 WordPress 安装目录中 wp-content 文件夹的完整路径。
- FTP_PLUGIN_DIR是 WordPress 安装目录中 plugins 文件夹的完整路径。
- FTP_PUBKEY是您的 SSH 公钥的完整路径。
- FTP_PRIKEY是您的 SSH 私钥的完整路径。
- FTP_USER可以是 FTP 用户或 SSH 用户名。这些很可能相同，但请根据您希望进行的更新类型使用相应的一个。
- FTP_PASS是为 FTP_USER输入的用户名的密码。如果您使用 SSH 公钥认证，可以省略此项。
- FTP_HOST是您 SSH/FTP 服务器的hostname:port组合。默认 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 设置为 localhost，以避免在尝试更新插件或 WP 本身时出现 503 问题。
启用 SSH 升级访问
有两种方式可以使用 SSH2 进行升级。
第一种是使用SSH SFTP Updater Support 插件。第二种是使用内置的 SSH2 upgrader，这需要安装 pecl SSH2 扩展。
要安装 pecl SSH2 扩展，您需要发出类似以下的命令，或与您的 Web 托管提供商联系以获取安装：
pecl install ssh2安装 pecl ssh2 扩展后，您需要修改 PHP 配置以自动加载此扩展。
pecl 在大多数 Linux 发行版中由 pear 包提供。要在 Redhat/Fedora/CentOS 上安装 pecl：
yum -y install php-pear要在 Debian/Ubuntu 上安装 pecl：
apt-get install php-pear建议使用未受密码短语保护的私钥。已有大量报告指出受密码短语保护的私钥无法正常工作。如果您决定尝试使用受密码短语保护的私钥，则需要将私钥的密码短语作为 FTP_PASS 输入，或在安装更新时出现在凭证字段中的“Password”字段中输入。
备用 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 来启用它。
注意：这应在需要时启用，并在问题解决后禁用。启用后，用户无需登录即可访问该功能，因为其主要意图是修复损坏的数据库，而当数据库损坏时，用户通常无法登录。
define( 'WP_ALLOW_REPAIR', true );脚本位于{$your_site}/wp-admin/maint/repair.php。
DO_NOT_UPGRADE_GLOBAL_TABLES
DO_NOT_UPGRADE_GLOBAL_TABLES定义可防止dbDelta()和升级函数对全局表执行昂贵的查询。
拥有大型全局表（特别是 users 和 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 Version 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 请求，这将仅允许 localhost 和您的博客发起请求。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' );参考：Disabling Auto Updates in WordPress 3.7
清理图像编辑
默认情况下，WordPress 每次编辑图像时都会创建一组新图像，当您恢复原始图像时，它会在服务器上保留所有编辑。将 IMAGE_EDIT_OVERWRITE 定义为 true 会改变此行为。始终只创建一组图像编辑，当您恢复原始图像时，编辑将从服务器中删除。
define( 'IMAGE_EDIT_OVERWRITE', true );保存前再次检查
请务必检查您输入的任何上述值周围是否有前导和/或尾部空格，并且不要删除单引号！
在保存文件之前，请务必再次检查是否意外删除了参数值周围的任何单引号。
要保存文件，请选择文件 > 另存为 > wp-config.php，并将文件保存在您的 WordPress 安装根目录下。将文件上传到您的 Web 服务器，即可准备安装 WordPress！