```
使用模板标签 [the_ID()](https://developer.wordpress.org/reference/functions/the_ID/) 可以显示文章的 ID 号。这个唯一标识符可以用于内部页面链接以及样式。例如，单篇文章可以拥有针对 `post-1` 以及 `post-2` 的样式。虽然为每篇文章都设置一个样式有点过度，但可能有一两篇文章你需要它们看起来有点不同。一些插件也可能使用这个标识符来自动改变不同文章的外观。
默认主题的内容容器具有**多文章视图**（例如，用于首页、分类、归档和搜索）以及用于单篇文章的**单文章视图**。多文章视图如下所示：
```
```
**多篇文章视图**的内容容器使用名为 `narrowcolumn` 的类，而**单篇文章视图**则使用名为 `widecolumn` 的类。单篇文章视图页面不会生成侧边栏，这使得文章能够占据整个内容区域的宽度。
```
```
与经典主题类似，这个分区设置了文章的样式和 `post-X` 的标识符，其中 `X` 代表文章的唯一 ID 号。这允许用户自定义特定文章的外观。
```
文章标题
```
这部分包含文章的标题代码，由 `
` 标签定义样式。
```
日期
```
日期代码由 `small` 标签包裹并定义样式。
```
```
文章内容由 `entry` CSS 选择器内的样式和段落标签组合定义样式。
```
文章元数据部分
```
[文章元数据部分](https://codex.wordpress.org/Post_Meta_Data_Section)包含关于文章的详细数据，例如日期、时间以及文章所属的分类。
```
```
[上一篇和下一篇链接](https://codex.wordpress.org/Next_and_Previous_Links)在 `navigation` div 中定义样式。它们还包含 `alignleft`（用于上一篇）和 `alignright`（用于按时间顺序的下一篇）类。
在**单篇文章视图**的内容结构中，这些元素的排列发生了变化：
```
```
由于没有侧边栏，`widecolumn` 类被设置为让内容横跨整个页面。`navigation` div 被移到了顶部。文章元数据现在被整合到 `entrytext` 父容器中，并且使用了不同的样式，添加了 `alt` 类选择器。
默认主题中的这两个示例，仅仅让您窥见了 WordPress 站点可以进行自定义的无数种方式。
#### 评论
评论可以显示在单篇文章视图中（使用 comments.php 模板文件），也可以显示在弹出窗口中（使用 comments-popup.php 模板文件）。这两种评论的整体样式基本相同。
##### Classic Theme Comments
```
RSS feed for comments on this post.
TrackBack URI
```
While individual sections of the comments feature styling reference, the Classic Theme has no general comment division or group style reference, one could be easily added.
**#comments h2**
Styles the title at the top of the comments list which says "Comments 4 Leave a Comment", with the latter part of the sentence in a link that jumps to ``.
**#comment-n**
Comments are given a unique ID number, signified here by the letter n. This allows them to be styled individually.
**#comments ol**
This begins the **ordered list** of the comments, counting down from one, and sets the overall style of the comments list.
**#comments li**
Style reference for each comment on the list.
**#comments p**
This paragraph tag styles the actual comments on the comment list.
**#comment cite**
This use of the cite controls the look of the commenter's name. It usually states "Name says:" in the comments list.
**#comments h2** or **#postcomment**
The h2 heading can be styled two ways, as #comments h2 or #postcomment. The latter is used by the "Leave a Comment" link from the top of the comments section, too.
**#commentform**
Style reference for the overall "form" for inputting comments. Each input area has it's own ID.
**#author**
ID reference for the comment author's input area.
**#comments small**
`
` 标签在经典主题中的多个位置被使用。这种用法环绕着**评论提交表单**中的文本以及评论中可用的**标签列表**文本。
**#email**
评论作者电子邮件的 ID 引用。
**#url**
评论作者网址的 ID 引用。
**#comment**
评论输入文本区域的 ID 引用。它并不样式化最终生成的评论，仅样式化输入框。
**#comment #submit**
经典主题中有两个提交按钮，分别用于搜索和评论提交。这是提交评论的按钮。
##### 默认主题评论
默认主题的评论功能在 comments.php 和 comments-popup.php 中使用循环查询，根据评论是否开放、关闭以及是否存在来改变部分信息。如果评论开放或关闭且尚未有任何评论，此信息将显示在 `
` 标签设置样式。
**#commentlist ol**
为评论列表的"有序列表"设置样式。
**.alt li** 和 **#comment-n**
评论列表项有两个样式引用。第一个是类 `alt`，第二个是评论 ID 号，此处用字母 n 表示。这允许对它们进行单独样式设置。
**cite**
`cite` 标签包裹"姓名说："以及指向评论作者 URL 的链接。
**.commentmetadata small**
`` 标签具有 `commentmetadata` 类，允许设置文章日期和时间的样式。
**ol #commentlist p**
为评论有序列表内的段落设置样式。
**#respond h3**
为"发表回复"标题设置样式。
**#commentform**
用于输入评论的整体"表单"的样式引用。每个输入区域都有自己的 ID。
**#author**
评论作者输入区域的 ID 引用。
**#comments small**
`` 标签在经典主题中的多个位置被使用。这种用法包裹了**评论提交表单中的文本 _以及_** _标签列表的文本_，这些标签可在评论中使用。
**#email**
评论作者电子邮件的 ID 引用。
**#url**
评论作者网址的 ID 引用。
**#comment**
评论输入文本区域的 ID 引用。它并不样式化最终生成的评论，仅样式化输入框。
**#comment #submit**
经典主题中有两个提交按钮，分别用于搜索和评论提交。这是提交评论的按钮。
##### 弹窗评论
经典主题和默认主题的 `comments-popup.php` 模板文件基本相同。它们都采用[经典主题评论结构](#Default_Theme_Comments)的布局。虽然经典主题使用 `` 标题，而默认主题在其评论中使用 `` 标题作为标题，但在 comments-popup.php 模板文件中，两者都使用 `` 标题标签。
```
....经典主题评论部分.....
...经典主题页脚....
```
body 标签通过 `#commentspopup` 设置整个页面的样式。`` 标题开启了评论部分。
如果您对整体主题的页眉和页脚内的标签结构进行了修改，请确保这些结构更改也应用于评论弹窗模板，特别是如果您打算[向公众发布该主题](https://codex.wordpress.org/Designing_Themes_for_Public_Release)。
### 侧边栏
正如您在默认主题中所见，侧边栏是否可见取决于正在使用的模板文件。一般来说，侧边栏可以简单也可以复杂。WordPress 主题通常在侧边栏中以**嵌套列表**的形式展示信息。关于侧边栏的定制，有一份逐步指南：[自定义您的侧边栏](https://codex.wordpress.org/Customizing_Your_Sidebar)，还有更多关于[使用 CSS 样式化列表](https://codex.wordpress.org/Styling_Lists_with_CSS)的信息。
通常，WordPress 侧边栏在一个列表中展示各个部分的标题，而该部分的项目则以嵌套列表的形式显示在标题下方。
经典主题的侧边栏看起来像下面这样（为简化起见，链接已移除）：
```
```
这些内容大多不言自明。每组链接都有其自己的 CSS 选择器：[页面](https://wordpress.org/documentation/article/create-pages/)、分类、归档、搜索和元信息。
#### 页面与链接分类
标记为"博客链接"的[页面](https://wordpress.org/documentation/article/create-pages/)与[链接](https://codex.wordpress.org/Links_Manager)分类，使用[](https://developer.wordpress.org/reference/functions/get_links_list/)和[](https://developer.wordpress.org/reference/functions/wp_list_pages/)模板标签自动生成标题。
对于**链接**分类，它会为该组链接生成h2标题。这意味着您可以将菜单h2标题的样式设置为与其他标题不同，或者，如果您希望它们看起来一致，请确保菜单h2样式与未自动生成的其他分类样式*匹配*。
**页面**模板标签生成pagenav作为标题，并以新方式标识页面。在多文章和单文章视图中，页面列表项具有class="page_item"来设置这些链接的样式。查看单个页面时，该页面的链接将变为class="current_page_item"，从而可以将其样式设置为与其余页面链接不同。
#### 分类、归档与元数据
其他侧边栏区块的标题，如 _categories_、_archives_、_meta_ 等，并未使用会自行生成标题的模板标签。这些标题是通过 PHP 语句在页面中“打印”出来的。虽然它们可以放入[标题标签](https://codex.wordpress.org/Designing_Headings)内，但 WordPress 使用 `_e()` 函数来显示或 `echo` 这些文本标题，同时标记这些文本为可能的翻译目标。如果你打算[开发主题](https://codex.wordpress.org/Theme_Development)并[公开发布](https://codex.wordpress.org/Designing_Themes_for_Public_Release)，强烈建议使用 echo 函数。
你可以单独或统一为这些标题设置样式。一些主题，如默认主题，将所有这类标题放在 `` 标签中，使列表标题看起来一致。因此，它们可能为每个区块使用样式引用，也可能不使用。如果你需要改变每个链接区块的外观，可以自行添加样式。
#### Search Form
The search form is found within the searchform.php. It may be found in different locations within the sidebar. To style the overall search form, use the search ID. Here is a list of the individual areas of the search form which may be styled by default. You may add style classes to gain more control over the look of your search form.
```
```
**#search**
The overall style for the search form.
**#search label**
Used to style the label tag, if necessary.
**#searchform**
Used to style the form itself.
**#search div**
This unlabeled div is a child container of the parent container search and maybe styled from within that selector.
**#searchform input**
To style the input area for the search, this selector combination will work.
**#searchsubmit**
_Used by the Default Theme_, this selector may be used to style the **search** or **submit** button.
The search form area, input, and button can be styled in many ways, or left with the default input and "button" look.
#### 元信息源链接
元链接可以显示为文本或代表各类链接的图标。XHTML 和 CSS 验证链接可使用 W3 图标。各类信息源也可用图标表示，或保留为文本形式。具体选择由您决定。侧边栏中使用文本或图标形式的信息源，相关说明详见文章 [WordPress 信息源](https://wordpress.org/documentation/article/wordpress-feeds/)。
### 页脚
页脚位于 footer.php 模板文件中。在默认主题和经典主题中，页脚包含的信息都很少。
**经典主题**
```
Powered by WordPress
```
页脚内容通过 `credit` 类以及 `
` 和 `` 标签进行样式设置。
该标签以 HTML 注释代码的形式显示页面使用的 MySQL 查询次数和页面加载时间。这是为了方便管理员使用，仅在页面源代码中可见。如果您希望将其显示在页面上，请移除[注释](https://codex.wordpress.org/Commenting_Code)。其外观将受到 `` 标签的 `credit` 类样式影响。在模板文件中，它看起来像这样：
```
```
**默认主题**
```
```
默认主题的页脚通过 `footer` ID 和 `` 标签进行样式设置。虽然页脚区域本身可能由 `footer` 设置样式，但 `
` 标签控制其中的文本。要为页脚内的 `
` 标签设置与页面其他部分不同的样式：
**#footer p {styles}**
## 资源
* [CSS](https://developer.wordpress.org/advanced-administration/wordpress/css/)
* [查找您的 CSS 样式](https://codex.wordpress.org/Finding_Your_CSS_Styles)
* [CSS 故障排除](https://codex.wordpress.org/CSS_Troubleshooting)
* [使用主题](https://wordpress.org/documentation/article/worik-with-themes/)
* [主题开发](https://codex.wordpress.org/Theme_Development)
* [为公开发布设计主题](https://codex.wordpress.org/Designing_Themes_for_Public_Release)
* [WordPress 课程](https://learn.wordpress.org/)
* [博客设计与布局](https://codex.wordpress.org/Blog_Design_and_Layout)
* [深入了解模板标签](https://codex.wordpress.org/Stepping_Into_Template_Tags)
# Update Services
Update Services are tools you can use to let other people know you've updated your blog. WordPress automatically notifies popular Update Services that you've updated your blog by sending a [XML-RPC](https://xmlrpc.com/) [ping](https://wordpress.org/documentation/article/glossary/#pingback) each time you create or update a post. In turn, Update Services process the ping and updates their proprietary indices with _your_ update.
## Common Usage
Most people use [Ping-o-Matic](https://pingomatic.com/) which, with just one "ping" from you, will let many other services know that you've updated. As for why, Ping-O-Matic puts it best:
> Ping-O-Matic is a service to update different search engines that your blog has updated.
> We regularly check downstream services to make sure that they're legit and still work. So while it may appear like we have fewer services, they're the most important ones.
If you do not want the update services to be pinged, remove all the update service URIs listed under "Update Services" on the [Settings](https://wordpress.org/documentation/article/administration-screens/#settings-configuration-settings)->[Writing](https://wordpress.org/documentation/article/settings-writing-screen/) administration screen of your WordPress installation.
Certain web hosts – particularly free ones – disable the PHP functions used to alert update services. If your web host prevents pings, you should stop WordPress from attempting to ping.
## XML-RPC Ping Services
```
https://rpc.pingomatic.com/
https://rpc.twingly.com/
http://ping.blo.gs/
```
## Alternatives
An alternative is [Feed Shark](https://feedshark.brainbliss.com/), which pings over 60 services for free.
## WordPress Multisite Network
By default, editing the Ping Services field is disabled for individual sites in a WordPress Multisite network. To restore this option, you can add a small custom plugin or must-use plugin with the following code:
```
add_action( 'init', function() {
if ( is_multisite() ) {
// Allow the Update Services configuration screen to appear.
add_filter( 'enable_update_services_configuration', '__return_true', 11 );
// Whitelist the 'ping_sites' option so changes can be saved to the database.
add_filter( 'whitelist_options', function( $options ) {
$options['writing'][] = 'ping_sites';
return $options;
}, 11 );
}
} );
```
# 编辑 wp-config.php 文件
WordPress 安装中最重要的文件之一是 `wp-config.php` 文件。该文件位于 WordPress 文件目录的根目录，包含网站的基本配置信息，例如数据库连接信息。
首次下载 WordPress 时，`wp-config.php` 文件并不包含在内。WordPress 安装过程会根据您在[安装](https://developer.wordpress.org/advanced-administration/before-install/howto-install/)过程中提供的信息为您创建 `wp-config.php` 文件。
非开发人员通常不需要编辑 wp-config.php 文件，但如果您正在按照技术人员或网络主机提供的故障排除步骤操作，此[页面](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/)应该会有所帮助。
# wp-config.php
临时说明：这可能链接到简单部分，指向：
* https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
* https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
## 高级选项 {#advanced-options}
以下部分可能包含高级信息，某些更改可能导致不可预见的问题。在修改这些设置前，请确保您已进行[定期备份](https://developer.wordpress.org/advanced-administration/security/backup/)并了解如何恢复。
### table_prefix {#table-prefix}
**$table_prefix** 是放置在数据库表名称前的值。如果您不想使用 **wp_** 作为数据库表前缀，请更改此值。通常在以下情况会修改此值：在同一数据库中[安装多个 WordPress 站点](https://developer.wordpress.org/advanced-administration/before-install/multiple-instances/)，例如使用多站点功能时。
如果为每个安装设置唯一的前缀，则可以在一个数据库中拥有多个安装。如果选择这样做，请务必注意安全性。
```
$table_prefix = 'example123_'; // 请仅使用数字、字母和下划线！
```
### WP_SITEURL {#wp-siteurl}
WP_SITEURL 允许定义 WordPress 地址（URL）。所定义的值是 WordPress 核心文件所在的地址。它也应包含 https:// 部分。末尾不要加斜杠 "**/**"。在 `wp-config.php` 中设置此值会覆盖 **siteurl** 在 [wp_options 表](https://codex.wordpress.org/Database_Description#Table:_wp_options) 中的值。定义这些常量会将您网站的 URL 配置硬编码，从而提高可移植性，并有助于防止因仪表盘中的拼写错误或配置错误导致的问题。**注意：** 这**不会**更改数据库中存储的值。如果从 `wp-config.php` 中移除此行，URL 将恢复为旧的数据库值。[使用 **RELOCATE** 常量](https://developer.wordpress.org/advanced-administration/upgrade/migrating/) 来更改数据库中的 **siteurl** 值。
如果 WordPress 安装在 [域名](https://en.wikipedia.org/wiki/Domain_name_system) example.com 下名为 "wordpress" 的目录中，请像这样定义 `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 是由 PHP 根据请求中 HTTP HOST 标头的值动态创建的，因此可能允许 [文件包含漏洞](https://en.wikipedia.org/wiki/File_inclusion_vulnerability)。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) {#blog-address-url}
与 WP_SITEURL 类似，WP_HOME _会覆盖数据库 [wp_options 表](https://codex.wordpress.org/Database_Description#Table:_wp_options) 中_ home _的值，但不会在数据库中更改它。_ **home** 是您希望用户在浏览器中输入以访问您的 WordPress 博客的地址。它应包含 https:// 部分，并且末尾不应有斜杠 "**/**"。定义这些常量会硬编码您网站的 URL 配置，这可以提高可移植性，并有助于防止因仪表盘中的拼写错误或配置错误导致的问题。
```
define( 'WP_HOME', 'https://example.com/wordpress' );
```
如果您正在使用 [为 WordPress 设置独立目录](https://developer.wordpress.org/advanced-administration/server/wordpress-in-directory/) 中描述的技术，请遵循以下示例。请记住，如果您使用类似这样的设置，您还需要在网站根目录中放置一个 `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 文件夹 {#moving-wp-content-folder}
您可以将存放主题、插件和上传文件的 `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' );
```
### 移动插件文件夹 {#moving-plugin-folder}
将 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' );
```
### 移动主题文件夹 {#moving-themes-folder}
您无法移动主题文件夹，因为其路径是相对于 `wp-content` 文件夹硬编码的：
```
$theme_root = WP_CONTENT_DIR . '/themes';
```
但是，您可以使用 [register_theme_directory](https://developer.wordpress.org/reference/functions/register_theme_directory/) 注册额外的主题目录。
了解如何[移动 wp-content](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/) 文件夹。有关主题文件夹如何确定的更多详细信息，请参阅 `wp-includes/theme.php`。
### 移动上传文件夹 {#moving-uploads-folder}
将 UPLOADS 设置为：
```
define( 'UPLOADS', 'blog/wp-content/uploads' );
```
此路径不能是绝对路径。它始终相对于 ABSPATH，因此不需要前导斜杠。
### 修改自动保存间隔 {#modify-autosave-interval}
在编辑文章时，WordPress 会使用 Ajax 自动保存修订版本。您可能希望增加此设置以延长自动保存之间的间隔，或减少此设置以确保不会丢失更改。默认值为 60 秒。
```
define( 'AUTOSAVE_INTERVAL', 180 ); // 秒
```
### 文章修订版本 {#post-revisions}
默认情况下，WordPress 会保存对文章或页面所做的每次编辑的副本，从而允许恢复到该文章或页面的先前版本。可以禁用修订版本的保存，也可以指定每个文章或页面的最大修订版本数。
#### 禁用文章修订版本 {#disable-post-revisions}
如果您**不**设置此值，WordPress 默认会将 WP_POST_REVISIONS 设为 _true_（启用文章修订版本）。如果您想禁用这个强大的修订功能，请使用此设置：
```
define( 'WP_POST_REVISIONS', false );
```
注意：部分用户需要将此命令移至 `wp-config.php` 文件初始块注释后的第一行才能使其生效。
#### 指定文章修订版本数量 {#specify-the-number-of-post-revisions}
若要指定 WordPress 存储的修订版本最大数量，请将 _false_ 更改为整数/数字（_例如_，3 或 12）。
```
define( 'WP_POST_REVISIONS', 3 );
```
注意：部分用户需要将此命令移至 `wp-config.php` 文件初始块注释后的首行，方可使其生效。
### 设置 Cookie 域名 {#set-cookie-domain}
可为具有特殊域名配置的用户指定 WordPress cookie 中设置的域名。例如，如果使用子域名提供静态内容，您可以将 cookie 域名设置为仅限您的非静态域名，以防止每次向子域上的静态内容发送请求时附带 WordPress cookie。
```
define( 'COOKIE_DOMAIN', 'www.example.com' );
```
### 启用多站点/网络功能 {#enable-multisite-network-ability}
WP_ALLOW_MULTISITE 是用于启用多站点功能的特性。如果 `wp-config.php` 文件中缺少此设置，则默认值为 false。
```
define( 'WP_ALLOW_MULTISITE', true );
```
### 重定向不存在的博客 {#redirect-nonexistent-blogs}
如果访问者尝试访问不存在的子域名或子文件夹，可以使用 NOBLOGREDIRECT 来重定向浏览器。
```
define( 'NOBLOGREDIRECT', 'https://example.com' );
```
### 致命错误处理程序 {#wp-disable-fatal-error-handler}
WordPress 5.2 引入了[恢复模式](https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-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](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) 选项控制某些错误和警告的报告，并启用 WP_DEBUG_DISPLAY 和 WP_DEBUG_LOG 设置。默认布尔值为 false。
```
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 及更高版本
define( 'WP_DEBUG', true );
```
[仅当 WP_DEBUG 设置为 true 时才会打印数据库错误](https://trac.wordpress.org/ticket/5473)。数据库错误由 [wpdb](https://developer.wordpress.org/reference/classes/wpdb/) 类处理，不受 [PHP 错误设置](https://www.php.net/errorfunc) 影响。
将 WP_DEBUG 设置为 true 还会将 [错误报告级别](https://www.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting) 提升至 E_ALL，并在使用已弃用的函数或文件时激活警告；否则，WordPress 会将错误报告级别设置为 E_ALL ^ E_NOTICE ^ E_USER_NOTICE。
### WP_ENVIRONMENT_TYPE {#wp-environment-type}
WP_ENVIRONMENT_TYPE 选项控制网站的环境类型：`local`、`development`、`staging` 和 `production`。
环境类型的值按以下顺序处理，每种后续方法会覆盖之前的值：WP_ENVIRONMENT_TYPE [PHP 环境变量](https://www.php.net/manual/en/reserved.variables.environment.php) 和 WP_ENVIRONMENT_TYPE 常量。
对于这两种方法，如果提供的环境类型值不在允许的环境类型列表中，将返回默认值 `production`。
最简单的设置方法可能是通过定义常量：
```
define( 'WP_ENVIRONMENT_TYPE', 'staging' );
```
注意：当 [wp_get_environment_type()](https://developer.wordpress.org/reference/functions/wp_get_environment_type/) 返回 `development` 时，如果网站的 `wp-config.php` 文件中未定义 WP_DEBUG，它将被设置为 `true`。
### SCRIPT_DEBUG {#script-debug}
[SCRIPT_DEBUG](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) 是一个相关常量，它会强制 WordPress 使用 `wp-includes/js`、`wp-includes/css`、`wp-admin/js` 和 `wp-admin/css` 目录中的“开发”版本脚本和样式表，而不是加载 `.min.css` 和 `.min.js` 版本。如果你计划修改 WordPress 内置的 JavaScript 或层叠样式表，应在配置文件中添加以下代码：
```
define( 'SCRIPT_DEBUG', true );
```
### 禁用 JavaScript 合并 {#disable-javascript-concatenation}
为了提升管理后台页面的加载速度，所有 JavaScript 文件会被[合并](https://en.wikipedia.org/wiki/Concatenation)至一个 URL。若管理后台页面的 JavaScript 功能失效，可尝试禁用此功能：
```
define( 'CONCATENATE_SCRIPTS', false );
```
### 配置错误日志记录 {#configure-error-logging}
配置错误日志记录可能有点棘手。首先，默认的 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 错误常量](https://www.php.net/manual/en/errorfunc.constants.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 及更高版本
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' );
/* 就这些，停止编辑！祝您博客愉快。 */
```
另一个记录错误的示例，由 Mike Little 在 [wp-hackers 邮件列表](https://lists.automattic.com/pipermail/wp-hackers/2010-September/034830.html) 中建议：
```
/**
* 这会将所有错误、通知和警告记录到 wp-content 目录下名为 debug.log 的文件中
* （如果 Apache 没有写入权限，您可能需要先创建该文件并设置适当的权限（例如使用 666））
*/
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
```
来自 Mike Little 在 [曼彻斯特 WordPress 用户组](https://groups.google.com/g/manchester-wordpress-user-group/c/tHJxMGhcnZs/m/dn-8yjYIq9wJ) 的一个改进版本：
```
/**
* 这仅在 WP_DEBUG 为 true 时，将所有错误、通知和警告记录到 wp-content 目录下名为 debug.log 的文件中。
* 如果 Apache 没有写入权限，您可能需要先创建该文件并设置适当的权限（例如使用 666）。
*/
define( 'WP_DEBUG', true ); // 或 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'，如果 WP_DEBUG 被定义为 false，WordPress 会将其设置为 4983。其次，即使 WP_DEBUG 为 true，其他常量也只有在它们也被设置为 true 时才起作用。如果它们被设置为 false，PHP 指令将保持不变。例如，如果您的 `php.ini` 文件中有指令 ('display_errors' = 'On')；但您在 `wp-config.php` 文件中有语句 define( 'WP_DEBUG_DISPLAY', false );，错误仍然会显示在屏幕上，即使您试图通过将 WP_DEBUG_DISPLAY 设置为 false 来阻止它，因为这是 PHP 配置的行为。这就是为什么在任何相关的 WP 常量被设置为 false 的情况下，将 PHP 指令设置为您需要的值非常重要。为了安全起见，请明确设置/定义这两种类型。关于 WP 常量的更详细描述，请参阅 [WordPress 中的调试](https://developer.wordpress.org/advanced-administration/debug/debug-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 );
```
The default debug log file is `/wp-content/debug.log`. Placing error logs in publicly accessible locations is a security risk. Ideally, your log files should be placed above you site's public root directory. If you can't do this, at the very least, set the log file permissions to 600 and add this entry to the `.htaccess` file in the root directory of your WordPress installation:
```
Order allow,deny
Deny from all
```
This prevents anyone from accessing the file via HTTP. You can always view the log file by retrieving it from your server via FTP.
### 增加分配给 PHP 的内存 {#increasing-memory-allocated-to-php}
**WP_MEMORY_LIMIT** 选项允许你指定 PHP 可以消耗的最大内存量。当你收到类似“允许的内存大小 xxxxxx 字节已耗尽”的消息时，可能需要此设置。
此设置仅针对 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 内存限制也可能带来问题。随着你添加更多插件或功能，你可能会掩盖问题的根源，导致问题在以后发生。
如果你在提高了内存限制后仍然遇到内存不足问题，你应该正确调试你的安装。很可能你有太多内存密集型函数绑定到特定操作，应该将这些函数移动到定时任务中。
将 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 之前。
### 缓存 {#cache}
**WP_CACHE** 设置项若为 true，则在执行 `wp-settings.php` 时会包含 `wp-content/advanced-cache.php` 脚本。
```
define( 'WP_CACHE', true );
```
### 自定义用户与用户元数据表 {#custom-user-and-usermeta-tables}
**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` 中的 define 语句指向 `wp_users` 数据默认存储的位置。完成第一个站点设置后，将可正常工作的 `wp-config.php` 复制到下一个实例仅需更改 `$table_prefix` 变量。请勿使用原始安装中已使用的电子邮件地址。完成设置过程后，使用自动生成的管理员账户和密码登录。接着，将您的普通账户提升为管理员级别并退出管理员账户。重新以您自己的账户登录，删除管理员账户并根据需要提升其他用户账户的权限。
### 语言与语言目录 {#language-and-language-directory}
WordPress [4.0 版本](https://wordpress.org/documentation/wordpress-version/version-4-0/) 允许您在 WordPress [管理界面](https://wordpress.org/documentation/article/administration-screens/) 中更改语言。要更改管理设置界面的语言，请前往 [设置](https://wordpress.org/documentation/article/administration-screens/#settings-configuration-settings) > [常规](https://wordpress.org/documentation/article/settings-general-screen/) 并选择站点语言。
#### WordPress v3.9.6 及更低版本 {#wordpress-v3-9-6-and-below}
**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 语言代码，请[参考此处](https://make.wordpress.org/polyglots/teams/)。WP Local 列中的代码就是您需要的。
### 保存查询以供分析 {#save-queries-for-analysis}
**SAVEQUERIES** 定义会将数据库查询保存到一个数组中，并且可以显示该数组以帮助分析这些查询。该信息会保存每条查询、调用它的函数以及查询执行所花费的时间。**注意：** 这会对您的网站性能产生影响，因此请确保在非调试时关闭此功能。
首先，将此添加到 `wp-config.php` 文件中：
```
define( 'SAVEQUERIES', true );
```
然后在您主题的页脚中添加此代码：
```
if ( current_user_can( 'administrator' ) ) {
global $wpdb;
echo "
";
print_r( $wpdb->queries );
echo "
";
}
```
或者，可以考虑使用 [Query Monitor](https://wordpress.org/plugins/query-monitor/)
### 覆盖默认文件权限 {#override-of-default-file-permissions}
**FS_CHMOD_DIR** 和 **FS_CHMOD_FILE** 定义语句允许覆盖默认文件权限。这两个变量的开发是为了解决核心更新功能在运行于 [suexec](https://en.wikipedia.org/wiki/SuEXEC) 环境下的主机上失败的问题。如果主机对所有用户文件使用限制性文件权限（例如 400），并拒绝访问设置了组或全局权限的文件，这些定义可以解决该问题。
```
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );
```
提供 setgid 的示例：
```
define( 'FS_CHMOD_DIR', ( 02755 & ~umask() ) );
```
注意：'**0755′** 和 '**02755**' 是八进制值。八进制值必须以 0 为前缀，并且不使用单引号（'）分隔。另请参阅：[更改文件权限](https://developer.wordpress.org/advanced-administration/server/file-permissions/)
### WordPress 升级常量 {#wordpress-upgrade-constants}
**注意：请根据解决更新问题的实际需要，尽可能少地定义以下常量。**
需要定义这些常量最常见的原因是：
* 主机运行在涉及符号链接的特殊安装配置下。您可能需要定义与路径相关的常量（FTP_BASE、FTP_CONTENT_DIR 和 FTP_PLUGIN_DIR）。通常，仅定义基础路径就足够了。
* 某些 PHP 安装附带的 PHP FTP 扩展与某些 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 服务器的 主机名:端口 组合。默认 FTP 端口是 21，默认 SSH 端口是 22。这些无需特别说明。
* **FTP_SSL** 如果**底层传输支持**（并非所有服务器都可用），则设为 TRUE 以使用 SSL 连接。这用于"安全 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 );
```
Some configurations should set FTP_HOST to localhost to avoid 503 problems when trying to update plugins or WP itself.
#### 启用 SSH 升级访问 {#enabling-ssh-upgrade-access}
有两种使用 SSH2 进行升级的方法。
第一种是使用 [SSH SFTP 更新器支持插件](https://wordpress.org/plugins/ssh-sftp-updater-support/)。第二种是使用内置的 SSH2 升级器，这需要安装 pecl SSH2 扩展。
要安装 pecl SSH2 扩展，您需要执行类似以下的命令，或者联系您的网络托管提供商进行安装：
```
pecl install ssh2
```
安装 pecl ssh2 扩展后，您需要修改 PHP 配置以自动加载此扩展。
在大多数 Linux 发行版中，pecl 由 pear 包提供。要在 Redhat/Fedora/CentOS 中安装 pecl：
```
yum -y install php-pear
```
要在 Debian/Ubuntu 中安装 pecl：
```
apt-get install php-pear
```
建议使用不受密码短语保护的私钥。有许多报告称受密码短语保护的私钥无法正常工作。如果您决定尝试使用受密码短语保护的私钥，则需要将私钥的密码短语作为 FTP_PASS 输入，或者在安装更新时在显示的凭据字段的“密码”字段中输入。
### 替代性 Cron 任务调度 {#alternative-cron}
在某些情况下可能需要为 WP 使用替代性 Cron。最常见的原因是预定发布的文章未能按预期发布。这种替代方法采用重定向机制：当需要执行 cron 时，用户浏览器会收到重定向指令，使其立即返回网站，而 cron 则在他们刚中断的连接中继续运行。此方法存在特定风险，因为它依赖于非原生的 WordPress 服务。
```
define( 'ALTERNATE_WP_CRON', true );
```
### 禁用 Cron 和 Cron 超时设置 {#disable-cron-and-cron-timeout}
通过将 DISABLE_WP_CRON 设置为 true 来完全禁用 cron。
```
define( 'DISABLE_WP_CRON', true );
```
确保 cron 进程在 WP_CRON_LOCK_TIMEOUT 秒内不会重复运行。
```
define( 'WP_CRON_LOCK_TIMEOUT', 60 );
```
### 其他可定义常量 {#additional-defined-constants}
以下是其他可以定义的常量。除非已尝试过其他方法，否则可能不应设置这些常量。如果您有特殊的域名设置，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() );
```
### 清空回收站 {#empty-trash}
此常量控制 WordPress 在多少天后将永久删除回收站中的文章、页面、附件和评论。默认值为 30 天：
```
define( 'EMPTY_TRASH_DAYS', 30 ); // 30 天
```
要禁用回收站功能，请将天数设置为零。
```
define( 'EMPTY_TRASH_DAYS', 0 ); // 零天
```
**注意：** 使用此设置时，当有人点击“永久删除”时，WordPress 将不会要求确认。
### 自动数据库优化 {#automatic-database-optimizing}
系统支持自动数据库修复功能，您可以通过在 `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}
**DO_NOT_UPGRADE_GLOBAL_TABLES** 常量定义可阻止 [dbDelta()](https://developer.wordpress.org/reference/functions/dbdelta/) 和升级函数对全局表执行高开销查询。
对于拥有大型全局表（特别是用户表和用户元数据表）的站点，以及那些与 bbPress 或其他 WordPress 安装共享用户表的站点，可以通过将 **DO_NOT_UPGRADE_GLOBAL_TABLES** 定义为 true 来防止升级过程中修改这些表。由于 ALTER 操作或无限制的 DELETE 或 UPDATE 操作可能需要很长时间才能完成，大型站点通常希望避免在升级过程中运行这些查询，以便自行处理。此外，如果多个 bbPress 和 WordPress 安装之间共享用户表，您可能希望指定一个站点作为升级主控。
```
define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );
```
### 查看所有已定义的常量 {#view-all-defined-constants}
PHP 提供了一个函数，可以返回包含所有当前已定义常量及其值的数组。
```
print_r( @get_defined_constants() );
```
### 禁用插件和主题文件编辑器 {#disable-the-plugin-and-theme-file-editor}
有时您可能希望禁用插件或主题文件编辑器，以防止过度热心的用户编辑敏感文件并可能导致网站崩溃。如果黑客获得了高权限用户账户的访问权限，禁用这些功能还能提供额外的安全层。
```
define( 'DISALLOW_FILE_EDIT', true );
```
**注意**：某些插件的功能可能会因其代码中使用 `current_user_can('edit_plugins')` 而受到影响。插件作者应避免检查此权限，或至少检查是否设置了此常量并显示适当的错误消息。请注意，如果插件无法正常工作，这可能是原因。
### 禁用插件和主题更新与安装 {#disable-plugin-and-theme-update-and-installation}
这将阻止用户在 WordPress 管理区域使用插件和主题的安装/更新功能。设置此常量也会禁用插件和主题文件编辑器（即您无需同时设置 DISALLOW_FILE_MODS 和 DISALLOW_FILE_EDIT，因为单独设置 DISALLOW_FILE_MODS 会产生相同效果）。
```
define( 'DISALLOW_FILE_MODS', true );
```
### 为管理员和登录强制使用 SSL {#require-ssl-for-admin-and-logins}
**注意：** WordPress [4.0 版本](https://wordpress.org/documentation/wordpress-version/version-4-0/)已弃用 FORCE_SSL_LOGIN。请使用 FORCE_SSL_ADMIN。
FORCE_SSL_ADMIN 用于保护登录和管理区域，确保密码和 Cookie 永远不会以明文形式发送。更多详情请参阅 [HTTPS](https://developer.wordpress.org/advanced-administration/security/https/)。
```
define( 'FORCE_SSL_ADMIN', true );
```
### 阻止外部 URL 请求 {#block-external-url-requests}
通过将 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 自动更新 {#disable-wordpress-auto-updates}
网站可能因某些原因（如自定义修改或主机提供的更新）需要禁用自动更新。在重大版本发布前，也可先禁用自动更新，以便在开发或测试环境中进行充分测试，再在生产站点执行更新。
```
define( 'AUTOMATIC_UPDATER_DISABLED', true );
```
### 禁用 WordPress 核心更新 {#disable-wordpress-core-updates}
控制核心更新的最简单方法是使用 `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 中禁用自动更新](https://make.wordpress.org/core/2013/10/25/the-definitive-guide-to-disabling-auto-updates-in-wordpress-3-7/)
### 清理图片编辑 {#cleanup-image-edits}
默认情况下，WordPress 每次编辑图片时都会创建一组新的图片，并且在恢复原始图片时，会将所有编辑版本保留在服务器上。将 IMAGE_EDIT_OVERWRITE 定义为 true 可以改变此行为。系统只会创建一组图片编辑版本，并且在恢复原始图片时，编辑版本会从服务器上移除。
```
define( 'IMAGE_EDIT_OVERWRITE', true );
```
## 保存前请仔细检查 {#double-check-before-saving}
_**请务必检查您输入的上述任何值前后是否有空格，并且不要删除单引号！**_
在保存文件之前，请务必**仔细检查**您是否意外删除了参数值周围的任何单引号。确保文件中的 PHP 结束标签后没有任何内容。文件的最后内容应为 **?>**，别无其他。没有空格。
要保存文件，请选择**文件 > 另存为 > wp-config.php**，并将文件保存在 WordPress 安装的根目录中。将文件上传到您的 Web 服务器，您就可以安装 WordPress 了！
```
### 更改地址 {#changing-addresses}
如果您当前正在使用其他网志软件并打算切换到 WordPress，或者正在将您的网志迁移到新位置，您可以通过在 `.htaccess` 文件中使用文件重写和重定向来将 RSS 阅读器“转发”到您的新 RSS 源。
编辑您根目录中的 `.htaccess` 文件；如果文件不存在，请创建一个。
以下是一个 b2 源的示例：
```
RewriteRule ^b2rss2.php(.*)? /wordpress/?feed=rss2 [QSA]
```
以下是一个 MovableType 用户的示例：
```
RewriteRule ^index.xml(.*)? /wordpress/?feed=rss2 [QSA]
```
# 导入内容
使用 WordPress 导入工具，您可以将内容从另一个 WordPress 站点或其他发布系统导入到您的站点。
您可以在 WordPress [管理屏幕](https://wordpress.org/documentation/article/administration-screens/)左侧导航栏的 [工具](https://wordpress.org/documentation/article/administration-screens/#tools-managing-your-blog) -> [导入](https://wordpress.org/documentation/article/tools-import-screen/) 下找到此处描述的许多导入器。
您还可以从管理屏幕所列系统之外的发布系统导入内容。每个系统的操作步骤不同，因此请根据需要参考以下列出的步骤和插件。如果您是 WordPress 新手，请查看 [WordPress 功能](https://wordpress.org/about/features/) 和 [使用 WordPress](https://codex.wordpress.org/Working%20with%20WordPress) 页面以开始使用。
如果遇到问题，请在 [WordPress 支持论坛](https://wordpress.org/support/forums/) 中搜索解决方案，或尝试查看 [常见问题解答](https://wordpress.org/documentation/article/faq-work-with-wordpress/)。
## 导入前注意事项
如果导入的文件过大，服务器可能在导入时内存耗尽。若发生这种情况，您将看到类似“致命错误：允许的 8388608 字节内存大小已耗尽”的错误提示。
若您拥有服务器足够权限，可通过编辑 `php.ini` 文件来增加可用内存。或者，也可联系托管服务提供商协助处理。否则，您可以将导入文件拆分为多个较小文件分别导入。
若导入过程失败，仍可能已创建部分内容。当您解决问题后重新尝试时，可能会产生重复数据。请在导入失败后检查网站，必要时删除相关记录以避免此问题。
## b2evolution
有两种方法可以将 b2evolution 内容导入 WordPress。
* **Movable Type 导出格式**：您可以重新设计 b2evolution 博客的皮肤，使其在查看源代码时显示为 [Movable Type 导出格式](https://movabletype.org/documentation/appendices/import-export-format.html)。您可以保存导出文件并将其作为 Movable Type 数据导入。请参阅 Movable Type 和 TypePad。
* **BIMP 导入脚本**：您可以使用 [BIMP 导入脚本](https://wittyfinch.com/bimp-importer-migrate-b2evolution-to-wordpress/) 将 b2evolution 的博客、分类、文章、评论、文件和用户导入您的 WordPress 安装（v3 及以上版本）。请注意，此服务需要付费。
## Blogger
您可以从 Blogger 导入文章、评论、分类和作者。WordPress 包含一个专门用于从 Blogger 导入内容的导入工具。
1. 将您的 Blogger 内容导出为 XML 文件。
2. 在您的 WordPress 站点中，于管理屏幕左侧导航栏选择 工具 -> 导入。
3. 在 "Blogger" 下，如果您尚未安装 Blogger 导入器，请点击 "立即安装"。
4. 点击 "运行导入器" 链接。
5. 点击 "选择文件" 并找到您的 Blogger XML 文件。
6. 点击 "上传文件并导入"。
## Drupal
有多种资源可帮助您将内容从 Drupal 迁移到 WordPress。这里重点介绍几种，您可能还会在网上搜索到许多其他工具。
* [FG Drupal to WordPress](https://wordpress.org/plugins/fg-drupal-to-wp/)。兼容 Drupal 4、5、6、7、8 和 9。
* [Drupal2WordPress Plugin](https://github.com/jpSimkins/Drupal2WordPress-Plugin)。使用此插件可导入分类、内容、媒体、评论和用户。您 Drupal 站点中包含的任何外部图像都可以获取并添加到媒体库，并添加到您的页面和文章中。
* [Drupal to WordPress migration SQL queries explained](https://anothercoffee.net/drupal-to-wordpress-migration-sql-queries-explained/) 包含针对某些迁移问题（如重复分类、分类超过最大字符长度和重复 URL 别名）的解决方案。
## XML 与 CSV
以下资源可帮助您将 XML 或 CSV 内容导入 WordPress。
* [WP All Import](https://wordpress.org/plugins/wp-all-import/) 插件可导入任何 XML 或 CSV 文件，并与 [WP All Export](https://wordpress.org/plugins/wp-all-export/) 插件集成。
## Joomla
对于 Joomla，您可以使用 [FG Joomla to WordPress](https://wordpress.org/plugins/fg-joomla-to-wordpress/)。该插件已在大型数据库上通过 Joomla 1.5 至 4.0 版本测试，并兼容多站点安装。
## LiveJournal
WordPress 包含一个专门用于从 LiveJournal 导入内容的导入工具。
1. 在您的 WordPress 站点中，于管理屏幕左侧导航栏选择 工具 -> 导入。
2. 在 "LiveJournal" 下，如果您尚未安装 LiveJournal 导入器，请点击 "立即安装"。
3. 点击 "运行导入器" 链接。
4. 输入您的 LiveJournal 用户名和密码，然后点击 "连接到 LiveJournal 并导入"。
## Live Space
请参阅 [Live Space Mover](https://b2.broom9.com/?page_id=519) 了解如何使用 Python 脚本将博客文章从 Live Space 导入到 WordPress。
## Magento
[FG Magento to WooCommerce](https://wordpress.org/plugins/fg-magento-to-woocommerce/) 插件可将您的 Magento 产品和 CMS 页面迁移到 WooCommerce。
## Mambo
您可以使用插件 [FG Joomla to WordPress](https://wordpress.org/plugins/fg-joomla-to-wordpress/)。此 WordPress 插件适用于 Mambo 4.5 和 4.6。
## Movable Type 和 TypePad
WordPress 包含一个专门用于从 Movable Type 和 TypePad 导入内容的导入工具。
1. 在您的 WordPress 站点中，于管理屏幕左侧导航栏选择工具 -> 导入。
2. 在“Movable Type 和 TypePad”下，如果您尚未安装导入器，请点击“立即安装”。
3. 点击“运行导入器”链接。
4. 点击“选择文件”并导航到您的导出文件。
5. 点击“上传文件并导入”。
以下文章提供了有关此过程的更多信息：
* [从 Movable Type 导入到 WordPress](https://codex.wordpress.org/Importing%20from%20Movable%20Type%20to%20WordPress)
* [导入和导出内容](https://www.movabletype.org/documentation/administrator/maintenance/import-export.html)
* [关于大规模 WordPress 迁移的注意事项](https://blog.birdhouse.org/2008/02/07/notes-on-a-massive-wordpress-migration/)
## Nucleus CMS
以下资源可帮助您将内容从 Nucleus CMS 迁移到 WordPress。
* [从 Nucleus CMS 导入指南](https://mamchenkov.net/wordpress/2005/04/26/nucleus2wordpress/)
* [从 Nucleus CMS 导入的脚本](http://james.onegoodcookie.com/pub/import-nucleus.phps)
* [Nucleus 转 WordPress](https://github.com/AbdussamadA/nucleus-importer)
## PrestaShop
[FG PrestaShop to WooCommerce](https://wordpress.org/plugins/fg-prestashop-to-woocommerce/)。此 WordPress 插件兼容 PrestaShop 1.0 至 1.7 版本。
## Roller
参见 [从 Roller 导入](https://codex.wordpress.org/Importing%20From%20Roller)。
另请参阅 [将 Roller 博客迁移到 WordPress](https://nullpointer.debashish.com/migrating-a-roller-blog-to-wordpress)。
## RSS
WordPress 内置了一个专门用于从 RSS 导入内容的工具。
1. 在您的 WordPress 站点后台，从左侧导航栏选择 工具 -> 导入。
2. 在“RSS”下方，如果您尚未安装导入器，请点击“立即安装”。
3. 点击“运行导入器”链接。
4. 点击“选择文件”并找到您的 XML 文件。
5. 点击“上传文件并导入”。
## 机缘巧合
* [从 Serendipity 迁移到 WordPress – 文章导入](https://obviate.io/2010/06/11/serendipity-to-wordpress-post-import/).
## SPIP
插件 [FG SPIP to WordPress](https://wordpress.org/plugins/fg-spip-to-wp/) 可将分类、文章、新闻和图片从 SPIP 迁移到 WordPress。它已在 SPIP 1.8、1.9、2.0、3.0、3.1 和 3.2 版本上测试通过，并兼容多站点安装。
## Sunlog
1. 打开 [phpMyAdmin](https://developer.wordpress.org/advanced-administration/upgrade/phpmyadmin/) 查看您 Sunlog 安装的数据库。您只需要两个表："blogname_entries" 和 "blogname_comments"。
2. 使用 phpMyAdmin 将这两个表导出为 XML 文件。
3. 在您的 WordPress 站点上安装 [WP All Import](https://wordpress.org/plugins/wp-all-import/) 插件。
4. 创建以下字段映射：
* `headline=title`
* `content=entry+more`
* `date=timestamp`（使用 Unix 时间戳格式）
* `categories="cat,"`（每个值用分号分隔）。
## Textpattern
* [修复 Textpattern 导入](https://wordpress.org/support/topic/fix-textpattern-import/)
* [Textpattern 到 WordPress 导出工具](https://github.com/drewm/textpattern-to-wordpress)
## Tumblr
WordPress 包含一个专门为从 Tumblr 导入内容而设计的导入工具。
1. 在您的 WordPress 站点中，在管理屏幕的左侧导航栏选择 工具 -> 导入。
2. 在 "Tumblr" 下，如果您尚未安装导入器，请点击 "立即安装"。
3. 点击 "运行导入器" 链接。
4. 点击 "选择文件" 并导航到您的导出文件。
5. 点击 "上传文件并导入"。
6. 在 Tumblr 上创建一个应用程序，为您的博客和 Tumblr 服务器之间提供连接点。
7. 复制并粘贴 "OAuth Consumer Key" 和 "Secret Key"。
8. 点击 "连接到 Tumblr"。
## Twitter
有多种插件可将您的推文导入 WordPress，例如 [将您的 Twitter 时间线导入 WordPress](https://blog.birdhouse.org/2008/08/17/get-your-twitter-timeline-into-wordpress/)。
## TypePad
请参阅 [Movable Type 和 TypePad](#movable-type-and-typepad)。
## WooCommerce 产品 (CSV)
如果您已安装 WooCommerce 插件，此导入器将已安装。点击“运行导入器”以上传 CSV 文件。
## WooCommerce 税率（CSV）
如果您已安装 WooCommerce 插件，此导入工具将自动安装。点击“运行导入工具”上传 CSV 文件。
## WordPress
WordPress 包含一个专门用于从其他 WordPress 博客导入内容的工具。
1. 在您的 WordPress 站点中，于管理界面左侧导航栏选择 工具 -> 导入。
2. 在“WordPress”下方，如果您尚未安装导入工具，请点击“立即安装”。
3. 点击“运行导入工具”链接。
4. 点击“选择文件”，然后导航至从源站点导出的 WXR 文件。
5. 点击“上传文件并导入”。
系统将首先要求您将此导出文件中的作者映射到博客中的用户。对于每位作者，您可以选择映射到博客中的现有用户或创建新用户。然后，WordPress 会将上传文件中包含的每篇文章、评论和分类导入您的博客。此外，您可以通过勾选“下载并导入文件附件”选项来导入附件。
## Xanga
[xanga.r](https://www.timwylie.com/xword.html) 是一个解析 Xanga 页面以获取帖子和评论的程序。然后，它可以将其输出为 WordPress RSS 2.0 XML 格式，供 WordPress 导入。
# 回环
回环是指您自己的服务器或网站尝试连接到自身。
WordPress 使用此功能来触发定时发布文章，以及插件或主题可能引入的其他定时事件。
在插件或主题编辑器中修改时也会用到回环，通过重新连接到网站来确保所做的更改不会破坏您的网站。
## 排查回环问题 {#troubleshooting-loopback-issues}
如果您遇到定时发布文章或其他定时事件无法运行的问题，或者看到关于回环失败的站点健康警告，您可能需要排查这些问题。
回环失败最常见的原因是插件或主题冲突，您应该首先按照常规的故障排除步骤操作：
## 常见故障排除步骤 {#common-troubleshooting-steps}
* **停用所有插件**（是的，所有插件）以查看是否解决了问题。如果有效，请逐个重新激活插件，直到找到有问题的插件。如果无法进入管理后台，请尝试通过 [SFTP/FTP](https://developer.wordpress.org/advanced-administration/upgrade/ftp/) 或 phpMyAdmin 重置插件文件夹（如果需要帮助，请阅读[无法登录 wp-admin 时如何停用所有插件](https://wordpress.org/documentation/article/faq-troubleshooting/)）。有时，看似未激活的插件仍可能导致问题。同时请记得停用 `mu-plugins` 文件夹中的任何插件。最简单的方法是将该文件夹重命名为 `mu-plugins-old`。
* 切换到 Twenty-Something 主题以排除特定主题的问题。如果无法登录更改主题，可以通过 [SFTP/FTP](https://developer.wordpress.org/advanced-administration/upgrade/ftp/) 删除主题文件夹，只保留 `twentytwentythree`。这将强制您的网站使用该主题。
* 如果可以安装插件，请安装 [Health Check](https://wordpress.org/plugins/health-check/) 插件。在故障排除选项卡中，您可以点击按钮来禁用所有插件并为您更改主题，同时您仍保持登录状态，**且不会影响网站的正常访客**。
# 多语言 WordPress
WordPress 当前并不原生支持双语或多语言博客。不过，WordPress 社区开发的插件使得创建多语言博客变得简单。WordPress Gutenberg 项目的第四阶段也是最后阶段，将为核心添加多语言站点支持，具体内容已列入 [WordPress 路线图](https://wordpress.org/about/roadmap/)。
创建多语言博客，本质上是安装多个语言版本的 WordPress，并让插件在它们之间切换。这包括安装 .mo 语言文件，大多数插件会要求您手动完成此操作。更多详情，请参阅[以您的语言安装 WordPress](https://developer.wordpress.org/advanced-administration/before-install/in-your-language/)。
## 多语言插件的不同类型 {#different-types-of-multilingual-plugins}
多语言插件主要有以下几种基本类型：
1. 每种语言使用单独的文章来管理多语言内容，然后将翻译版本相互链接，表明一篇文章是另一篇的翻译。
2. 将每种语言的文章变体都存储在同一篇文章中。
3. 在生成的页面上管理翻译，而不是在文章上下文中处理。
4. 通过相互引用，将网络（多站点）安装中不同语言的独立 WordPress 站点链接在一起。
### 每篇文章一种语言 {#one-language-per-post}
支持多语言的插件若采用每篇文章对应一种语言的方案，会允许用户选择文章的语言，并将翻译内容作为新文章添加（页面、标签和分类同理）。
随后，同一内容的不同版本会被链接在一起，形成翻译组。这种分组方式使用户能够切换显示语言。
优点：
1. 文章在数据库中的内容保持不变（易于安装和卸载）。
2. 默认情况下所有内容都会被翻译。如果文章包含自定义字段，这些字段会附加到该文章上，因此它们已与语言关联。
3. 部分插件会使用可本地化主题自带的语言文件（.mo）来翻译主题显示的术语。在 WordPress 中，本地化基于 [GNU gettext](https://make.wordpress.org/polyglots/handbook/#Localization_Technology) 技术。因此，当单篇文章为法语时，插件会将主题的所有术语切换为同一语言（此处为法语）。这些文件可以补充网站特有的术语（分类标题、小工具、链接等）。无需全部重新翻译，只需添加特定术语及其目标语言翻译即可。
4. 其他分析内容的插件（如相关文章推荐）仍能正常工作。
缺点：
1. 架构更复杂。插件需要挂钩到许多 WordPress 函数并进行过滤，以确保仅返回与语言匹配的内容。
2. 部分插件需要额外的数据表——通常用于存储翻译分组信息。较新的插件可能改用自定义分类法或文章元字段。
3. 可能导致数据库过度增长并拖慢性能。例如，一个拥有 10 万种产品的 WooCommerce 网站在翻译成 5 种语言后，将产生 50 万条记录。所有产品元数据（每个产品可能有数十个，临时数据也会被复制）都会重复存储，数据库可能变得非常庞大。
### 单篇文章包含所有语言 {#all-languages-in-a-single-post}
在同一篇文章中存储所有语言内容的多语言插件，使用语言元标签来区分不同语言的内容。当文章显示时，会先进行处理，只保留当前激活语言的内容。
优点：
1. 易于实现并排编辑。
2. 出错可能性更低。没有额外的数据表，WordPress 中需要修改的内容也更少。
3. 无论使用哪种语言的关键词进行搜索，都能找到同一篇文章。
4. 数据库中的记录数量保持不变。
缺点：
1. 卸载可能比较复杂，因为需要从数据库中清理多语言内容。
2. 文章固定链接可能无法翻译。
### 管理生成页面的翻译 {#manage-translations-on-the-generated-page}
多语言插件利用 WordPress 生成的内容页面，并在这些页面上执行翻译。当任何页面在 WordPress 上显示时，插件（无论是离线还是在线）会尝试使用机器翻译创建该页面的翻译版本。之后，该翻译可以手动更改或修改。
优点：
1. 安装简单，并提供页面上任何内容的翻译。
2. 可以轻松编辑翻译。
缺点：
1. 自动翻译效果不够好，网站上的页面可能翻译得很差。
2. 内容与翻译之间存在强耦合，原始内容的更改可能会破坏翻译。
### 将您导向外部翻译服务的插件 {#plugins-that-direct-you-to-external-translation-services}
这类多语言插件通常用于创建一个小组件，该组件为使用在线翻译服务（如 Google 翻译）提供快捷方式。内容由第三方引擎按需自动翻译。
优点：
1. 安装简单，并提供页面上任何内容的翻译。
2. 翻译过程是自动化的这一点非常明确，因此用户的期望值会降低。
缺点：
1. 自动翻译质量不够好，网站上的页面可能翻译得很差。
2. 由于无法修改翻译，这些插件限制了内容发布者提供高质量翻译内容的能力。
### 每种语言使用独立的 WordPress 安装 {#each-language-in-its-own-wordpress-installation}
为每种需要翻译的语言创建独立站点（例如在 [WordPress 多站点](https://developer.wordpress.org/advanced-administration/multisite/create-network/) 安装中）。所有站点需运行相同的主题和插件。当翻译保存时，源文章会收到翻译文章的关联通知，系统会通过独立数据表维护翻译关系。
优势：
1. 每个语言站点都是标准的 WordPress 安装，使用常规文章格式（翻译数据通过文章元数据和外部数据库存储）
2. 停用插件后内容仍可正常使用，仅失去与源文章/翻译的关联信息
劣势：
1. 独立站点会增加管理需求，这可能带来不便
## 语言协商 {#language-negotiation}
语言协商是指如何确定用户查看网站时使用的语言。
无论采用何种存储多语言内容的解决方案，多语言插件也需要能够选择显示哪种语言。
通常，URL 会指示显示语言。编码语言信息的不同 URL 策略包括：
* 将语言名称作为参数添加：example.com/?lang=en 或 example.com/?lang=es
* 添加虚拟“目录”作为语言名称：example.com/en/ 或 example.com/es/
* 对不同语言使用不同的域名：www.example.com 或 es.example.com
## 如何选择正确的多语言解决方案 {#how-to-choose-the-right-multilingual-solution}
为您的需求选择最合适的多语言插件需要一些时间。请查看 [WordPress 插件目录](https://wordpress.org/plugins/search/multilingual) 以获取多语言插件列表。
没有唯一的方法，只有适应内容策略、数据模型、文章和页面数量以及访客预期行为/体验的方法。对于 WordPress 网络（多站点），还需要具备良好的服务器管理知识。
无论如何，安装多语言插件对任何网站来说都是一项重大变更。最好先创建一个测试站点，验证所有必需的插件与主题之间一切运行正常，然后再进行安装。
由于许多多语言插件会显著改变数据库，因此在尝试前需要进行[数据库备份](https://developer.wordpress.org/advanced-administration/security/backup/database/)。
## 相关 {#related}
* [WordPress 本地化版本](https://developer.wordpress.org/advanced-administration/before-install/in-your-language/)
# oEmbed
简易嵌入功能主要由 oEmbed 协议驱动，该协议允许消费者（如您的博客）向提供者（如 YouTube）请求嵌入内容所需的 HTML。
oEmbed 旨在避免从托管您希望嵌入的媒体网站复制粘贴 HTML。它支持不同类型的内容，如视频、图像、文本等。
## 这适用于任何 URL 吗？
不，默认情况下不行。出于安全原因，WordPress 核心有一个[内部白名单](https://developer.wordpress.org/reference/hooks/oembed_providers/)，仅允许特定 URL 可嵌入。好消息是白名单可以修改，可以通过注册其句柄来添加新的网站和 URL。
## 如何添加或更改对网站的支持？
添加对额外网站的支持取决于该网站是否支持 oEmbed。[oEmbed.com](https://oembed.com/) 提供了数百个[支持的提供者](https://oembed.com/providers.json)的列表。
### 添加对支持 oEmbed 的网站的支持
如果网站支持 oEmbed，您需要调用 [`wp_oembed_add_provider()`](https://developer.wordpress.org/reference/functions/wp_oembed_add_provider/) 将网站和 URL 格式添加到内部白名单。
### 添加对不支持 oEmbed 的网站的支持
您需要使用 [`wp_embed_register_handler()`](https://developer.wordpress.org/reference/functions/wp_embed_register_handler/) 注册一个处理程序，并提供一个生成 HTML 的回调函数。
### 移除对支持 oEmbed 的网站的支持
如果您希望移除一个支持 oEmbed 的提供者，您需要调用 [`wp_oembed_remove_provider`](https://developer.wordpress.org/reference/functions/wp_oembed_remove_provider/)。
## oEmbed 发现功能呢？
自 4.4 版本起，WordPress 支持 oEmbed 发现，但对可通过非白名单网站嵌入的内容类型有严格限制。
具体来说，HTML 和视频内容被过滤为仅允许链接、块引用和 iframe，并且这些内容还会被额外过滤以防止恶意内容的插入。然后，HTML 会被修改以进行沙盒化，并对其施加额外的安全限制。
但是，如果您认为自己足够了解，不需要这种级别的安全性，您可以授予 `unfiltered_html` 用户（管理员和编辑者）从在其 `` 中包含 oEmbed 发现标签的网站嵌入内容的能力。
对于“链接”和“照片”类型的 oEmbed 发现内容，过滤方式并不那么严格；然而，出于安全考虑并防止任何恶意内容在网站上显示，它会进行适当的转义。
# 文章格式
## 简介
**文章格式**是随 [3.1 版本](https://wordpress.org/documentation/wordpress-version/version-3-1/)引入的一项[主题功能](https://codex.wordpress.org/Theme_Features)。文章格式是一种元信息，主题可利用它来自定义文章的呈现方式。文章格式功能提供了一个标准化的格式列表，所有支持此功能的主题均可使用。主题无需支持列表中的所有格式。新格式不能由主题甚至插件引入。该列表的标准化既保证了众多主题间的兼容性，也为外部博客工具提供了一致访问此功能的途径。
简而言之，使用支持文章格式的主题时，博主可通过单选按钮列表选择文章格式，从而改变每篇文章的显示效果。
以**日志**为例，过去需要创建一个名为“日志”的分类，将文章分配至该分类，然后基于 [post_class()](https://developer.wordpress.org/reference/functions/post_class/) 或 [in_category('asides')](https://developer.wordpress.org/reference/functions/in_category/) 的样式规则进行差异化显示。通过**文章格式**，新方法允许主题添加对文章格式的支持（例如 [add_theme_support('post-formats', array('aside'))](https://developer.wordpress.org/reference/functions/add_theme_support/)），随后在保存文章时即可通过发布元框选择文章格式。可通过调用 [get_post_format($post->ID)](https://developer.wordpress.org/reference/functions/get_post_format/) 函数确定格式，且 [post_class()](https://developer.wordpress.org/reference/functions/post_class/) 还会生成“format-asides”类，以便进行纯 CSS 样式设计。
## 支持的格式
如果主题启用了支持，用户可以选择以下文章格式。
请注意，虽然实际的文章内容输入不会改变，但主题可以根据用户选择的格式，使用此选择以不同方式显示文章。例如，主题可以不为“状态”文章显示标题。具体如何显示完全由主题决定，但以下是一些通用指南。
* **aside（日志）**：通常不显示标题。类似于 Facebook 的笔记更新。
* **gallery（相册）**：一个图片库。文章可能包含一个相册短代码，并附有图片附件。
* **link（链接）**：指向另一个网站的链接。主题可能希望使用文章内容中的第一个 `` 标签作为该文章的外部链接。另一种方法是，如果文章仅包含一个 URL，则该 URL 将成为链接地址，而标题 (`post_title`) 将成为该链接锚点的名称。
* **image（图像）**：单张图片。文章中的第一个 `