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

首次下载 WordPress 时，并不包含 wp-config.php 文件。WordPress 安装过程会根据您在 安装 过程中提供的信息为您创建 wp-config.php 文件。

非开发人员通常不需要编辑 wp-config.php 文件。如果您正在根据技术人员或您的主机提供商提供的故障排除步骤进行操作，本 页面 将提供帮助。

wp-config.php

临时提示：此处链接可能指向简单部分，即：
* https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
* https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/

高级选项

以下章节可能包含高级信息，某些更改可能会导致不可预见的问题。请在修改这些设置之前确保已执行 定期备份 并了解如何恢复它们。

table_prefix

$table_prefix 是您数据库表前缀的值。如果您希望使用除 wp_ 以外的值作为数据库前缀，请更改此值。通常在同一个数据库中 安装多个 WordPress 博客（多站点功能）时会进行此项更改。

如果为每个安装指定唯一的前缀，则可以在一个数据库中拥有多个安装实例。但请注意，这样做需要考虑安全性问题。

$table_prefix = 'example123_'; // 仅允许数字、字母和下划线！

WP_SITEURL

WP_SITEURL 允许定义 WordPress 地址（URL）。定义的值是您的 WordPress 核心文件所在的地址。它应包含 https:// 部分。末尾不要加斜杠“/"。在 wp-config.php 中设置此值会覆盖 wp_options 表 中 siteurl 的值。定义这些常量会硬编码您网站的 URL 配置，从而提高可移植性并有助于防止因仪表板中的拼写错误或配置错误导致的问题。注意：这不会更改数据库中存储的值。如果从 wp-config 中删除此行，URL 将恢复为旧的数据库值。使用 RELOCATE 常量 来更改数据库中的 siteurl 值。

如果 WordPress 安装在名为"wordpress"的目录中（针对 域名 example.com），请按如下方式定义 WP_SITEURL：

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

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

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

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

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

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

博客地址 (URL)

与 WP_SITEURL 类似，WP_HOME 覆盖 wp_options 表 中 home 的值，但不会更改数据库中的值。home 是您希望用户在浏览器中输入以访问 WordPress 博客的地址。它应包含 https:// 部分，且末尾不应有斜杠“/"。定义这些常量会硬编码您网站的 URL 配置，从而提高可移植性并有助于防止因仪表板中的拼写错误或配置错误导致的问题。

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

如果您使用了 让 WordPress 拥有独立目录 中描述的技术，请遵循以下示例。请记住，如果使用此类设置，您还需要在 Web 根目录中放置一个 index.php 文件。

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

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

define( 'WP_HOME', 'https://' . $_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', 'https://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', 'https://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', 180 ); // 秒

文章修订版

默认情况下，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', 'https://example.com' );

致命错误处理器

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

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

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

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 及更高版本
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 及更高版本
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' );

注意：当 wp_get_environment_type() 返回 development 时，如果站点 wp-config.php 文件中未定义 WP_DEBUG，则将其设置为 true。

SCRIPT_DEBUG

SCRIPT_DEBUG 是一个相关常量，它将强制 WordPress 在 wp-includes/js、wp-includes/css、wp-admin/js 和 wp-admin/css 中使用脚本和样式表的"dev"版本，而不是加载 .min.css 和 .min.js 版本。如果您计划修改 WordPress 内置的 JavaScript 或级联样式表（CSS），应将以下代码添加到配置文件中：

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。

显然，您的开发环境需要不同的设置。如果您的 staging 副本在同一台服务器上，或者您无法访问 php.ini，则需要在运行时覆盖默认设置。至于偏好将错误发送到日志文件，还是立即收到任何错误通知，或者两者兼有，这纯属个人喜好。以下是一个示例，报告所有错误并立即显示，您可以将其插入到 wp-config.php 文件中：

@ini_set( 'log_errors', 'Off' );
@ini_set( 'display_errors', 'On' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 及更高版本
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 常量的更详细描述，请访问 Debugging in 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 内存少于输入的值。例如，如果已分配 64MB 给 PHP，则无需将此值设置为 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 之前放置。

缓存

WordPress 支持几种不同的缓存机制。这些系统是独立的，并非都由同一个常量或子系统控制。

WP_CACHE

define( 'WP_CACHE', true );

WP_CACHE 本身不会启用缓存。

当设置为 true 时，WordPress 会在引导期间早期尝试加载 wp-content/advanced-cache.php drop-in。这通常由页面缓存插件和一些托管平台使用。

如果不存在 advanced-cache.php 文件，定义 WP_CACHE 几乎没有或没有任何效果。

许多缓存插件会自动添加或管理此常量。

持久对象缓存

持久对象缓存使用 object-cache.php drop-in，与 advanced-cache.php 分开。

示例包括 Redis 和 Memcached 集成。

即使未定义 WP_CACHE，持久对象缓存也可能正常运行。

Transients 和持久对象缓存

Transients API 存储带有过期时间的临时数据，但数据存储位置取决于站点的缓存配置。

当激活 Redis 或 Memcached 等持久对象缓存 drop-in 时，transients 可以存储在外部对象缓存中。如果没有持久对象缓存，WordPress 将 transient 值存储在数据库中，通常在 wp_options 表中。

这意味着不能假设所有站点上的 transients 都基于内存。在没有持久对象缓存的站点上大量使用 transients 会增加数据库读写并导致 options 表增长。

设置有过期时间的 transients 默认不自动加载；未设置过期时间的 transients 会自动加载。这意味着大量使用过期的 transients 会在 wp_options 中添加行，而不会增加每次请求加载的 autoload 占用空间。

缓存层

不同的缓存层服务于不同的目的：

缓存类型典型实现用途
页面缓存advanced-cache.php提供完整的渲染页面
对象缓存object-cache.php缓存数据库/查询/应用程序对象
Opcode 缓存PHP OPcache缓存编译后的 PHP 字节码
浏览器缓存HTTP headers/CDN缓存浏览器中的资源

常见误解

  • WP_CACHE 不会自动启用 Redis 或 Memcached。
  • WP_CACHE 不会启用浏览器缓存。
  • 除非安装了缓存 drop-in，否则仅靠 WP_CACHE 不会提高性能。
  • 持久对象缓存和页面缓存是独立的系统。
  • Transients 并不总是存储在内存中；如果没有持久对象缓存，它们存储在数据库中。
  • wp_options 中的 transient 选项行不一定都会自动加载；只有未设置过期时间的 transients 才会自动加载。

相关资源

有关实现细节，请参阅：

  • advanced-cache.php
  • object-cache.php
  • wp_start_object_cache()
  • Drop-ins

遗留和专用性能常量

以下常量控制专用的脚本和样式加载、连接和压缩行为：

  • CONCATENATE_SCRIPTS
  • COMPRESS_SCRIPTS
  • COMPRESS_CSS
  • ENFORCE_GZIP

除非专门针对性能或资源加载问题进行故障排除，否则大多数站点不应手动定义这些常量。

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

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'，每个数据库仍会为每个实例创建相应的 usermeta 表及权限。默认情况下，WordPress 安装程序将为第一个用户（ID #1）添加权限。您还需要通过插件或自定义函数管理每个站点的权限。如果未正确设置，您将遇到权限错误和登录问题。

CUSTOM_USER_TABLE 是在首次设置 WordPress 实例时最容易采用的方式。第一个实例的 wp-config.php 中的 define 语句指向默认存储 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 define 语句允许覆盖默认文件权限。这两个变量是为了解决核心更新功能在运行 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 安装根目录（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 如果底层传输支持（并非所有服务器都可用），则设为 TRUE 以建立 SSL 连接。这是用于"Secure 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 升级器，这需要安装 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 天

若要禁用回收站，请将天数设置为零。

define( 'EMPTY_TRASH_DAYS', 0 ); // 零天

注意：使用此设置时，当有人点击“永久删除”时，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 版本 4.0 已弃用 FORCE_SSL_LOGIN。请使用 FORCE_SSL_ADMIN。

FORCE_SSL_ADMIN 用于当您想要保护登录和管理区域，确保密码和 Cookie 从不以明文形式发送时。有关更多详细信息，请参阅 HTTPS。

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 常量：

禁用所有核心更新：

define( 'WP_AUTO_UPDATE_CORE', false );

启用所有核心更新，包括次要和主要更新：

define( 'WP_AUTO_UPDATE_CORE', true );

启用次要版本的核心更新（默认值）：

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

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

清理图像编辑

默认情况下，WordPress 每次编辑图像时都会创建一组新图像，当您还原原始图像时，它会保留服务器上的所有编辑。将 IMAGE_EDIT_OVERWRITE 定义为 true 会改变此行为。只会创建一组图像编辑，当您还原原始图像时，编辑将从服务器中移除。

define( 'IMAGE_EDIT_OVERWRITE', true );

保存前再次检查

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

在保存文件之前，请务必仔细检查您是否意外删除了参数值周围的任何单引号。确保文件末尾的 PHP 标签之后没有任何内容。文件的最后一项应该是?>且不能有其他内容。不要有空格。

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