WordPress 5.6中的新增功能（可訪問性，性能，安全性）

WordPress 5.6是即將推出的下一個主要WordPress版本。今天，我們很高興與您一起深入了解最有趣的功能，並將其他功能合併到Core中。

與以前的版本一樣，WordPress 5.6包含多個版本的Block Editor，為尚未在其網站上安裝和更新Gutenberg插件的WordPress用戶提供了增強的編輯體驗。

但是，並非所有內容都與塊編輯器有關。WordPress Core已添加了多個功能，例如新的默認默認二十一二十一主題，主要版本的自動更新，對PHP 8.0的更好支持，用於REST API身份驗證的應用程序密碼。

WordPress 5.6還有更多功能。我們將看到可訪問性方面的改進，UI的增強，大量錯誤修復以及針對開發人員的大量更改。

我們很高興與您分享WordPress 5.6的新功能。?不要錯過所有新功能，增強功能和全新的默認主題：二十一二十一?點擊鳴叫

如果您想了解有關WordPress 5.6開發周期的更多信息，請查看以下鏈接：

• 2020年10月20日：Beta 1
• 2020年10月27日：Beta 2
• 2020年11月2日：Beta 3
• 2020年11月12日：Beta 4
• 2020年11月17日：RC 1
• 2020年12月1日：RC 2
• 2020年12月7日：WordPress 5.6版本的試運行
• 2020年12月8日：WordPress 5.6發布的目標日期

準備潛水了嗎？讓我們來看看：

塊編輯器的新增功能

使用WordPress 5.6，Gutenberg插件的多個版本已合併為核心，因此WordPress用戶和編寫者應注意編輯器中的多項改進。我們將看到增強的塊模式，信息面板中的字數統計，改進的鍵盤導航，改進的拖放UI等等。

對於所有的改進和添加到塊編輯器的變化更全面的列表，請查看發布公告帖：8.6，8.7，8.8，8.9，9.0，9.1和9.2。WordPress 5.6中還包括在Gutenberg 9.3和9.4中實現的錯誤修復和性能改進。

讓我們深入研究我們將在塊編輯器中看到的更有趣的更改。

1. 塊，模式和UI改進
2. Block API V2
3. 針對塊開發人員的附加功能和改進

塊，模式和UI改進

新的塊功能，增強功能和錯誤修復將改善整體編輯體驗。另外，在可訪問性方面也做了大量工作。在將網站更新到WordPress 5.6後，您將在下面找到精選的精選功能，這些最有趣的功能將在塊編輯器中顯示。

封面中視頻的位置控制

自從Gutenberg 8.6以來已添加到Cover Blocks中，用於視頻的位置控制項允許用戶移動焦點並為視頻設置自定義位置。此功能以前僅適用於圖像背景。

封面的視頻位置控制

通過在焦點選擇器上的任意位置單擊和/或使用鍵盤上的箭頭鍵來設置位置值。您可以按住shift鍵將值跳10（另請參閱＃22531）。

塊模式更新

WordPress 5.6還包括在Gutenberg 8.6中添加的若干塊模式改進。

大標題和段落的布局，文本和顏色已更新（＃23858）

兩列文本中的標題已從文本塊中移出，並置於各列上方（＃23853）

所述報價圖案現在包括在頂部的圖像和底部的隔板。

新的Quote模式包括圖像和分隔符

Gutenberg 8.7（＃24143）添加了新的標題和段落模式。

WordPress 5.6中的標題和段落模式

塊插入器的一個很好的可用性改進是塊模式類別下拉列表，它允許您按類別過濾模式。當您有大量的模式可供選擇時（＃24954），這非常有用。

塊模式類別下拉列表

支持視頻字幕

視頻塊現在支持視頻字幕。

在視頻塊中添加視頻字幕

編輯者和內容創建者應提供WebVTT格式（Web視頻文本軌道格式）的視頻字幕，WebVTT格式是「使用<track>元素顯示定時文本軌道（例如字幕或標題）的格式」（＃25861）。

跟蹤鏈接到不同語言字幕的元素

載入.vtt文件後，將允許站點查看器啟用其喜歡的語言的字幕。

視頻字幕用戶設置

說到視頻，請確保訂閱Kinsta的YouTube頻道以每周獲取新視頻！

將多個塊轉換為列塊

一個有趣的可用性改進是將多個選定的塊轉換為Columns塊的能力。

選擇多個塊

您只需要選擇要在列中顯示的塊，然後單擊塊工具欄的右上方按鈕即可。

每個選定的塊都將轉換為Columns塊的一列。

三個塊轉換為三列

封面中的背景圖案

封面現在可以顯示背景圖案。

帶有背景圖案的封面

要添加背景圖案，請上傳圖案圖像，然後打開「重複的背景」選項（這是您需要了解的有關WordPress中的媒體庫的所有信息）。

完成後，根據需要調整焦點選擇器，並嘗試使用固定背景的不同組合。

圖像大小控制項已添加到媒體和文本塊

藉助Gutenberg 9.1，新的圖像大小控制項已添加到「媒體和文本塊」中的圖像。

用戶現在可以從所有可用的圖像大小中進行選擇（＃24795）。

媒體和文本塊中的圖像大小控制

Block API V2

新的Block API版本使塊能夠呈現其包裝器元素。新API版本的目標是減輕編輯器的DOM並使其與首頁內容匹配。根據Ella van Durpe的說法：

這樣做的最大好處是，如果標記和編輯器中的標記相同，則主題和插件可以更輕鬆地設置塊內容的樣式。

新版本要求apiVersion在塊類型註冊中聲明屬性：

registerBlockType( name, { apiVersion: 2 } );

新的API也需要使用block函數中的useBlockProps 鉤子Edit。該鉤子將塊的包裝器元素標記為塊元素。

傳遞給該鉤子的任何屬性都將被合併並返回給wrapper元素。開發說明中的以下示例顯示了一個簡單的用例：

import { useBlockProps } from '@wordpress/block-editor';

function Edit( { attributes } ) {
const blockProps = useBlockProps( {
className: someClassName,
style: { color: ‘blue’ },
} );
return <p { …blockProps }>{ attributes.content }</p>;
}

有關更多示例，請參見Block API版本2。

針對塊開發人員的附加功能和改進

除了Block API版本2，這裡還列出了供開發人員使用的其他功能。

塊支持API

Block Supports API允許塊開發人員向其塊添加功能。顏色，背景，字體大小只是可以通過Block Supports API添加到模塊中的眾多功能中的一部分。

WordPress 5.6還引入了幾個新的塊支持， 「以提高一致性並使其更容易將這些選項引入塊中」。

開發人員可以使用新的塊支持將相應的鍵添加到block.json文件的supports屬性中或直接添加到函數中。registerBlockType

以下來自Block Supports開發說明的示例顯示了其工作原理：

supports: {
color: {
background: true, // Enable background color UI control.
gradient: true, // Enable gradient color UI control.
text: true // Enable text color UI control.
},
fontSize: true, // Enable font size UI control.
lineHeight: true // Enable line height UI control.
}

樣式值將通過has-<value>-<preset-category>類（對於預設值）或與style元素（對於自定義值）自動附加到包裝器元素。

因此，塊支持旨在與新的塊API V2一起使用。

塊支持也可以與動態塊一起使用。

createBlocksFromInnerBlocksTemplate API

開發人員可以使用InnerBlocks組件創建包含其他塊的自定義塊。例如「專欄」欄和「社交鏈接」欄。

新的createBlocksFromInnerBlocksTemplateBlock API允許您從InnerBlocks模板創建塊。

有關開發人員視圖和代碼示例，請參見開發說明。

工具欄組件

還有一些更改也會影響工具欄組件：

1. ToolbarGroup組件

在WordPress 5.6之前，工具欄組件允許開發人員將相關選項組合在一個通用容器中。現在，應該改用新的ToolbarGroup組件。

<BlockControls>
<ToolbarGroup>
<ToolbarButton />
</ToolbarGroup>
</BlockControls>

2. ToolbarButton和ToolbarItem組件

不建議將Tabbable元素直接用作工具欄項（即<button>）。旨在提高可訪問性，工具欄項目可以使用添加的ToolBarButton按鈕和ToolbarItem其他控制項。以下示例顯示了一個按鈕和一個下拉菜單：

<BlockControls>
<ToolbarItem as="button" />
<ToolbarButton />
<ToolbarItem>
{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
</ToolbarItem>
</BlockControls>

禁用核心塊模式

現在可以使用core-block-patterns支持標誌（＃24042）禁用核心模式

禁用嵌入式圖像編輯器

Gutenberg 8.4添加了一個內聯圖像編輯功能，允許用戶直接從塊編輯器中編輯圖像。

內聯圖像編輯

開發人員現在可以使用block_editor_settings過濾器（＃23966）禁用圖像編輯器：

add_filter( 'block_editor_settings', function( $settings ) {
$settings['imageEditing'] = false;
return $settings;
} );

內聯圖像編輯已禁用

可重用塊已移至單獨的程序包

可重複使用的模塊，以前的部分@wordpress/editor包，已經被轉移到了@wordpress/reusable-blocks包，使他們在其他編輯器中可用。

新的默認主題：二十一二十一

WordPress 5.6包含一個全新的默認主題。二十一二十一是一個易於訪問的，極簡的WordPress主題，具有單列布局和頁腳側邊欄。

新主題使用系統字體堆棧和基於柔和背景色的最小調色板。

21個21個主題預覽（圖片來源：使WordPress成為核心）

您可以在我們的深入博客文章「二十一二十一：深入探討新的默認WordPress主題」中閱讀有關二十一二十一的更多信息。

自動更新主要版本

自動更新是WordPress 3.7中引入的一項核心功能，旨在提高網站安全性 ，並使網站管理員更輕鬆地維護其WordPress網站的最新狀態。

儘管在早期版本中已實現了自動次要核心更新，但藉助WordPress 5.6，站點管理員現在也可以手動啟用主要版本的自動更新（稍後將進行詳細介紹）。

不幸的是，對於非技術用戶來說，這項至關重要的維護任務可能仍然有些混亂。您可以在我們的「深入WordPress自動更新」博客文章中了解有關自動更新如何工作的更多信息。

因此，WordPress 5.6引入了一個新界面，該界面允許站點管理員為主要的核心版本啟用自動更新。

此功能的範圍在WordPress 5.6 Beta周期內已更改，原始的開發說明已被替換。用Jb Audras的話來說，

核心自動更新的初始範圍已移至：

• 提供一些有關UI設計的更新。
• 對於現有安裝，其行為將與今天相同：默認情況下選擇加入次要更新，但用戶必須選擇加入主要更新（主機或代理已使用的常量和過濾器仍會採用優先）。
• 對於新安裝，默認行為將更改：默認情況下選擇啟用次要更新，默認情況下選擇主要更新。

從WordPress 5.6開始，您可以在「更新」屏幕中選擇加入主要核心版本的自動更新，其中新的UI提供了一個複選框，允許您為所有新版本的WordPress啟用自動更新。

為所有新版本的WordPress啟用自動更新

為主要版本啟用核心自動更新後，即可通過單擊「僅切換為維護和安全性版本的自動更新」使它們僅觸發維護和安全性。

切換到自動更新，僅用於維護和安全性發行版

針對開發人員的主要自動核心更新

首先，當大核心啟動自動更新，該auto_update_core_major選項被存儲在資料庫與option_value啟用。因此，如果get_site_option( 'auto_update_core_major' )返回true，則會選中「自動更新」複選框。

然後WordPress檢查是否通過WP_AUTO_UPDATE_CORE常量或allow_major_auto_core_updates過濾器啟用了主要的核心自動更新，並相應地設置了複選框。

通過將WP_AUTO_UPDATE_CORE常量設置為false或minor，如下所示，開發人員還可以禁用主要的核心自動更新（另請參見通過wp-config.php控制後台更新）：

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables minor updates:
define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );

需要注意的是可能的值WP_AUTO_UPDATE_CORE是true（全部）， ，'beta'，'rc'，。'minor'false

默認情況下，禁用主要核心自動更新的另一種方法是使用新的allow_major_auto_core_updates過濾器：

add_filter( 'allow_major_auto_core_updates', '_return_false' );

關於向內核添加自動更新的幾點評論

早在2018年12月，Matt Mullenweg共享了2019年的九個優先事項，其中「為用戶提供選擇加入主要Core版本的自動更新的方式」是第7位。也許有點晚了，但是我們到了。

主要的核心自動更新應該會對WordPress安全性和整體體驗產生重大影響。有一件事似乎很清楚：從技術角度來看，主要的自動核心更新功能是一項複雜的任務，而WordPress 5.6的發布並不能100％完成。

在對Slack進行了周到的討論之後，Josepha Haden總結了核心貢獻者的關注和問題。

長期的主要目標是在大多數WordPress網站上提供自動更新，以提高整個WordPress生態系統（超過30％的Web）的安全性。

無論如何，根據核心首席開發人員HelenHou-Sandí所說：

在我看來，要執行一些非常困難的技術工作，這需要一些非常有紀律和專註的技術產品所有權

因此，隨著時間的推移，我們應該看到對主要的自動核心更新UI的其他更改和改進。從現在開始，這可能是我們期望的：

WordPress 5.6：

• 在現有安裝中，主要更新必須由用戶啟用。已經使用的任何常量和過濾器將具有優先權。默認情況下啟用次要更新。
• 在新安裝中，默認情況下啟用次要更新和主要更新。

WordPress 5.6.1：

• 我們應該根據反饋看到對核心自動更新UI的一些更改。

WordPress 5.7：

• 對於選擇退出主要自動更新的任何人，應將其添加到「站點運行狀況」屏幕。
• 應在WordPress 5.7的安裝過程中添加自動更新選項。

核心自動更新的一個主要問題是用戶的信任。據海倫說：

我相信我們仍然可以做很多工作來積極地徵求用戶的信任，尤其是那些以前對WordPress和/或更新有不良經驗的用戶

但是，每個WordPress網站都是由Core，plugins和theme組成的。用海倫的話來說：

核心更新大致上是相當安全的，並且內置了一些保護，但是由於站點可以從任何來源運行任何代碼，因此對於「每種WordPress網站」來說都沒有「 100％」之類的東西。

啟用了核心自動更新的用戶應定期備份其網站，或選擇一個在其計劃中提供自動備份的Web主機。

核心自動更新還將影響整體更新體驗，包括插件和主題自動更新。Joost de Valk在評論中指出：

如果默認情況下啟用WordPress核心自動更新，則對插件也應如此。否則，由於核心更新，插件和主題無法更新需要修復的內容。我認為用戶也會期望這樣：如果WordPress自動更新，插件和主題也應該自動更新。

WordPress 5.6中的網站運行狀況更改

除了此處討論的所有功能之外，WordPress 5.6還帶來了Site Health工具的改進版本，該工具現在在後台的行為有所不同。

站點健康檢查數據驗證

驗證程序現在檢查站點運行狀況測試的問題響應。驗證程序將丟棄任何無效響應，從而防止「站點運行狀況」工具引起致命錯誤並停止任何進一步的控制。

從現在開始，無效的響應不會影響「站點運行狀況」指示器（＃50145）。

通過REST Endpoind進行非同步檢查

網站運行狀況工具是功能強大的安全工具，它使網站所有者可以了解其網站的運行狀況。

該工具執行許多安全測試，以概述您網站的健康狀況。

這些測試分為兩類：直接測試（在頁面載入時運行）和非同步測試（可能需要一些時間才能完成，並且稍後會通過JavaScript調用運行）。

以前，這些測試是通過調用admin-ajax.php來執行的。使用WordPress 5.6，事情已經從admin-ajax.php移開了，將使用新的REST API端點代替。從WordPress 5.6開始，可以在名稱空間下找到非同步測試/wp-json/wp-site-health/v1。

由於有了新的REST API增強功能，插件和主題也能夠利用REST端點，而不僅限於進行健康測試的Ajax操作。

現在，每個非同步測試都可以聲明has_rest參數，默認為false。

以下來自wp-admin / includes / class-wp-site-health.php的代碼顯示了WordPress 5.6中的非同步測試數組：

'async' => array(
'dotorg_communication' => array(
'label' => __( 'Communication with WordPress.org' ),
'test' => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
),
'background_updates' => array(
'label' => __( 'Background updates' ),
'test' => rest_url( 'wp-site-health/v1/tests/background-updates' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
),
'loopback_requests' => array(
'label' => __( 'Loopback request' ),
'test' => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
),
'authorization_header' => array(
'label' => __( 'Authorization header' ),
'test' => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
'has_rest' => true,
'headers' => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
'skip_cron' => true,
),
),

計劃的站點健康檢查：

儘管已實現非同步測試以防止緩慢的頁面載入和超時，但計劃的測試並不存在此類問題。

考慮到這一點，除了has_rest上面提到的參數外，測試數組還可以聲明async_direct_test參數（使用上面的代碼），該參數應該是測試的可調用實例。

如果在預定事件期間運行測試，則該測試將不使用REST API端點，而是直接運行。

REST API身份驗證的應用程序密碼

應用程序密碼是用於向各種WordPress API發出經過身份驗證的請求的新系統。

密碼長度為24個字元，由大寫，小寫和數字字元組成，可以手動生成，也可以通過REST API生成。

要手動生成新的應用程序密碼，請瀏覽至「個人資料」屏幕並向下滾動頁面。

用戶個人資料屏幕中的應用程序密碼

選擇應用程序密碼的名稱並確認。WordPress將顯示您的新密碼。

新的應用程序密碼

應用程序密碼以4個字元的塊顯示，並用空格分隔，如下所示：

gsUc UhkU 0ScI gdRd TGoU vrW5

但是，密碼可以帶空格或不帶空格：

通過授權流返回的應用程序密碼不包含空格。嚴格來說，它們是為了使盯著長字元串的人更容易在手動輸入時保持位置。

可以分塊使用它們，而不能使用空格，或者-如果需要，可以在每個字元後添加一個空格。

在「用戶配置文件」屏幕中，您可以查看，創建和撤消應用程序密碼。「上次使用」和「上次IP」列使您可以輕鬆地找到不再使用的密碼，這些密碼應該撤消。

上次使用和最後一個IP欄位

在撰寫本文時，可以將應用程序密碼與REST API身份驗證請求以及舊版XML-RPC API結合使用。但是，將來我們應該會看到與其他API一起使用的應用程序密碼。喬治·斯蒂芬尼斯（George Stephanis）解釋說：

應用程序密碼身份驗證方案也可以應用於將來適用於WordPress的API。例如，如果在WordPress中啟用了GraphQL或其他系統，則應用程序密碼將為它們提供一個可靠的，已建立的身份驗證基礎結構，以立即可用。

對Postman中的REST API的經過身份驗證的調用

無法在wp-login.php上使用應用程序密碼。

有關此功能的詳細信息和更多技術見解，請確保檢查以下資源：

• 提案：REST API身份驗證/應用程序密碼
• 應用程序密碼：集成指南
• 應用程序密碼功能插件

更好地支持PHP 8

PHP 8.0引入了大量的新功能和優化，使其成為語言發展過程中的真正里程碑。PHP的較新版本引入了許多更新，這些更新打破了向後兼容性，並且許多不推薦使用的功能現已正式刪除。因此，在WordPress中添加對PHP 8的支持是一個巨大的挑戰。

實際上，即使WordPress核心貢獻者做出了巨大努力，使WordPress 5.6與PHP 8兼容，我們也不應該期望會發現所有可能的問題。這裡的目標是達到整個WordPress生態系統與PHP 8兼容的地步，目前看來，這確實是一個難以克服的難題。

此外，一個WordPress網站至少包含一個主題和可變數量的插件。因此，我們可能期望在WordPress Core中對PHP 8的良好支持，但是很難相信插件和主題會很快增加對PHP 8的支持。

我們同意喬納森·德羅斯（Jonathan Desrosiers）的話：

無法知道更廣泛的生態系統（插件，主題等）中對PHP 8的支持狀態。因此，WordPress 5.6應該被視為與PHP 8「 beta兼容」。

「 Beta與PHP 8兼容」似乎很好地表示了一個正在進行的過程，該過程仍需要大量的努力，但與此同時，也要承認迄今為止所做的出色工作。

然而，

所有插件和主題開發人員以及託管社區都被要求使其代碼與PHP 8兼容。這將使WordPress更快地實現真正的「完全兼容性」，而最終用戶不必承擔任何負擔。

儘管通過自動測試發現的大多數不兼容問題已得到解決，但仍需要進行一些手動測試。出於這個原因，強烈建議在將實時網站升級到PHP 8之前，在臨時環境或本地環境上運行嚴格的兼容性測試。

需要注意的一些PHP 8更改

如上所述，使WordPress與PHP 8完全兼容是一項正在進行的工作。Jonathan Desrosiers提供了PHP 8功能和WordPress開發人員應注意的更改列表。

命名參數

使用PHP，命名參數現在可以根據參數名稱而不是參數位置將參數傳遞給函數。這允許編寫自記錄的代碼，參數與順序無關，並且可以任意跳過默認值。

不幸的是，當前命名的參數可能會導致WordPress中的向後兼容性問題。主要原因是參數名稱如有更改，恕不另行通知，直到完成當前審核為止。因此，在撰寫本文時：

在完成此審核之前，明確不支持在調用WordPress函數和類方法時使用命名參數，並且強烈建議不要使用命名參數，因為在審核期間，參數名稱如有更改，恕不另行通知。審核完成後，將在以後的開發人員說明中宣布。

內部函數的嚴格類型/值驗證

傳遞非法類型的參數時，內部函數和用戶定義函數的行為會有所不同。用戶定義的函數會引發TypeError，但是內部函數會根據多種情況以多種方式運行。

為了消除這些不一致，在PHP 8中，內部參數解析API 始終會ThrowError在參數類型不匹配的情況下生成。

WordPress Core中未使用嚴格的類型聲明。但是，Core貢獻者正在努力防止將無效類型傳遞給Core函數。在該工作完成之前，此PHP 8更改可能會導致TypeErrors，「特別是如果通過掛鉤到過濾器的代碼錯誤地更改了值的類型」。

算術和按位運算符的更嚴格類型檢查

在以前的PHP版本中，允許對數組，資源或非重載對象使用算術和按位運算符，但有時行為不一致甚至不合理：

var_dump([] % [42]);
// int(0)

在PHP 8中，行為始終是相同的，並且TypeError當操作數是數組，資源或非重載對象時，所有算術和按位運算符都將引發異常（請參閱RFC）。

這是另一項更改，需要Core貢獻者進行一些額外的工作，例如許多錯誤，警告和通知更改。

同樣，由於仍未解決多個問題，強烈建議您在實時網站上切換到PHP 8之前，在臨時或開發環境上運行兼容性測試。閱讀有關WordPress和PHP 8.0的更多信息。

開發人員的其他變更

WordPress 5.6為開發人員帶來了許多變化，我們不能將所有變化都包括在列表中。但是在這裡，我們認為前三名值得一看：

1. wp_after_insert_post動作掛鉤

在WordPress 5.6之前，您可以save_posts在發布文章後使用或類似的操作來運行自定義代碼。現在WordPress 5.6引入了新的wp_after_insert_post動作鉤子，僅在保存術語和元數據後才會觸發。

此外，已更新了一些功能以防止激發這些掛鉤。新的$fire_after_hooks參數已被添加到wp_insert_posts()，wp_update_post()和wp_insert_attachment()功能。如果設置為false，則可防止後插入掛鉤被觸發。

查看開發者說明，以獲取更深入的概述。

2.類型轉換

類型轉換功能intval()，strval()，floatval()並且boolval()已經從核心支持直接的強制類型轉換的刪除：

1. intval() → (int)
2. strval() → (string)
3. floatval() → (float)

這種變化對直接影響表現為直接類型轉換是〜6倍快比類型轉換功能。

3. WP_Error對象

該WP_Error班已得到增強，允許合併多個WP_Error實例為一體。以前，您只能手動執行此操作。現在，WordPress 5.6引入了三種新方法來幫助處理多個WP_Error實例。下面的代碼是開發說明中的示例：

<?php
$error_1 = new WP_Error(
'code1',
'This is my first error message.',
'Error_Data'
);

$error_2 = new WP_Error(
‘code2’,
‘This is my second error message.’,
‘Error_Data2’
);

// Merge from another WP_Error.
$error_1–>merge_from( $error_2 );

// Retrieve all error data, optionally for a specific error code.
$error_1–>get_all_error_data( ‘code2’ );

// Export to another WP_Error
$error_1–>export_to( $error_2 );

開發人員的進一步閱讀

不可能提到WordPress 5.6引入的所有針對開發的更改，但是您可以使用以下資源閱讀有關它們的更多信息：

• 更新WordPress隨附的jQuery版本
• 將核心jQuery更新到版本3 –第2部分
• WordPress和PHP 8.0
• WordPress 5.6中的REST API批處理框架
• 其他開發人員專註於WordPress 5.6中的更改

PHP 8支持，應用程序密碼，站點運行狀況改進，Block API V2等更多信息……單擊此處，深入研究WordPress 5.6！?點擊鳴叫

概要

WordPress 5.6是主要版本，為用戶和開發人員提供了大量功能和更改。我們總是很高興看到網路技術的發展如何直接影響WordPress的安全性，性能，可用性和可訪問性。

但是發展永遠不會停止，我們已經可以窺見未來的潛在發行日期。