The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
WordPress 5.2 is officially the best WordPress 2019 has seen that rhymes with wp_nav_menu()! Users will see new coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks available, and an added ability to enable or disable blocks within the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. inserter, along with a multitude of other block editor updates.
There are also new features to protect sites from the dreaded “White Screen of Death“, a new area for users to view, copy, and share important debug information, improvements to AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) and theming Privacy Policy pages. Developers will love the various new filters and functions, and will also be able to take advantage of 62 enhancements and feature requests, 228bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, and more! Let’s look at the many improvements coming in 5.2…
Site Health and WSOD Protections
WordPress 5.2 includes portions of the Site Health and Servehappy projects. A new Site Health page nested under the “Tools” menu will run a series of tests on a site pointing out potential issues that site owner should be aware of. Plugins and themes may add their own tests, or modify/remove existing ones using filters. More debugging and support information is displayed within an “Info” tab in the same area of the adminadmin(and super admin). This information can help developers troubleshoot user issues.
From the Servehappy project comes the addition that allows administrators to fix or mitigate fatal errors on their site that would previously have been impossible to address without developer interference and modifying the codebase. This includes five ways that developers can integrate with the new recovery mode features.
The block editor has continued its rapid iteration since WordPress 5.0, and now has GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ version 5.4 bundled with WordPress 5.2. The most significant change in core is the addition of a a reusable block-editor module to expand the usage of the Block Editor in a context independent from the post editor without any dependency to the post object (e.g., to other WordPress admin pages like the widgets screen).
A new asynchronous mode for block rendering has also been added, new RSS and Amazon Kindle embed blocks were added, and a block management modal with the ability to enable/disable blocks from the block inserter. Improvements to the end-to-end tests have been made (including support for aXe Accessibility testing), as well as improvements to the accuracy of WP_Screen::is_block_editor(). Core blocks (aside from the Classic block) are also no longer using TinyMCE under the hood.
Accessibility updates in 5.2 include improvements to markup for Admin tabs, to post formats in list tables, to Admin Bar submenu link markup, and to the Archive WidgetWidgetA WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. dropdown all to help assistive technologies.
The Privacy component has been enhanced with the addition of four new features to make customizing and designing the Privacy Policy page easier. Tag restrictions for User Data Exports have also been relaxed.
Note the shim provided for plugins and themes wanting to support the is_privacy_policy() function in older versions of WordPress
Security
5.2 includes several security-related updates like protection against supply-chain attacks and modern cryptography for WordPress plugins; read below for details and examples.
There are even more goodies in 5.2 like the addition of 13 Dashicons and the WOFF 2.0 file format, the addition of short circuit filters to WP_Site_Query and WP_Network_Query, the addition of the wp_body_open() function to trigger a wp_body_open action, the addition of the category_list_link_attributesfilterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to Walker_Category, the addition of the users_have_additional_content filter, the update to @wordpress/scripts package to include webpack and Babel configurations, and more!
Note the shim provided for themes wanting to utilize the wp_body_open() function in older versions of WordPress and prevent fatal errors from the undefined function
Embeds: YouTube embeds lack title attribute (#40245)
Export: Issue with WP Export – adding spaces to .xml file (#46575)
Feeds: Feeds now respect the Last-Modified headers (#4575)
General: Add sodium_compat — a libsodium-compatible cryptography APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. for PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher <7.2 (#45806)
I18Ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.: The Personal Data Erasure Fulfillment email is now in the Users LocaleLocaleA locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. (#44721)
I18N: The Personal Data Export email is now in the Users Locale (#46056)
Networks and Sites: Introduces the ms_user_list_site_class filter (#41146)
Networks and Sites: Introduces the populate_site_meta filter (#46437)
Privacy: The ‘Download Personal Data’ admin action no longer triggers a completion of the request (#44644)
Privacy: Users are now able to make additional requests when identical previous requests are in a complete or archived state (#44707)
UPDATE on 7 May 2019: Added “Changes to post globals setup and usage in get_the_content() and related functions in WordPress 5.2″ dev notedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. to the Other Developer Updates section.
UPDATE #2 on 17 May 2019: Added “Security in 5.2” dev note to the newly created Security section.
WordPress 5.2 will allow administrators to fix or mitigate fatal errors on their site that would previously have been impossible to address without developer interference and modifying the codebase. Even in the case where a fatal error would commonly have made the backend completely inaccessible (for example through a so-called “white screen of death”), administrators will now still have the chance to log in and do something about the issue.
When a fatal error occurs, a user-facing error screen will display that informs the user/visitor that the site is experiencing technical difficulties. More importantly though, when such an error occurs, an email will be sent to the adminadmin(and super admin) email address, informing about the issue and including a secret link to new feature called the “recovery mode”. Clicking this link will have the user enter this recovery mode, which works by placing a cookie on the current client.
When in recovery mode, plugins and themes (also referred to as “extensions”) which are causing a fatal error are paused for that client, ensuring they can work around these errors and access their admin backend as regularly. After entering recovery mode, the user needs to log in. It should be highlighted though that recovery mode itself is not tied to a specific user, but only to the cookie existing on the client.
After logging in, an admin notice will indicate that recovery mode is enabled. Furthermore, the user will be informed about which plugins/themes are currently paused due to fatal errors, and what exactly these errors are. They then have the possibility to address the issue in their preferred way:
They can completely deactivate the extension, e.g. when maintaining a working version of the site matters more than that extension’s functionality. This is typically a temporary solution, but provides an immediate resolution.
They can fix the problem if they have the technical capabilities, and afterwards resume the extension.
They can file a support ticketticketCreated for both bug reports and feature development on the bug tracker. with the author of the respective extension or contact a developer, pointing out the exact error.
At any time, the user can decide to exit recovery mode, by clicking a button that permanently appears in the admin bar while in recovery mode. Exiting recovery mode will wipe the cookie from the client and thus cause all extensions to run as usual again. Keep in mind that if an extension is still broken, the fatal error will remain.
Admin backend while in recovery mode
The main benefit of recovery mode is to inform administrators about fatal errors on their site and allow them to still access their backend and decide what to do about the problem, rather than presenting them with the typical “white screen of death” which they cannot do anything about. It is impossible to automatically fix such errors, but recovery mode allows working around them by pausing the broken extensions. Pausing only happens for the client that is in recovery mode, and thus does not have any global implications. With a broken extension, only the user in recovery mode can access the broken areas; for the other users the site remains in a broken state until the issue has been fixed or mitigated.
Developers
There are a couple of ways that developers can integrate with the new recovery mode features:
Plugins that would like to enhance recovery mode can call a new function wp_is_recovery_mode() to check for whether it is active.
Environments can override the way that recovery mode is set up and validated if they prefer to use a different method or to purely enable it via code. A must-use pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for example can set a constant WP_RECOVERY_MODE_SESSION_ID that needs to contain an arbitrary session ID, which will then be used to store recovery mode-specific data for that session. Having the constant available will force-enable recovery mode. However, this mechanism must be used with special care, as setting the constant unconditionally would result in recovery mode being globally enabled.
The template for the screen indicating that a fatal error occurred can be customized by using a php-error.php drop-in, similar to other previously existing drop-ins such as db-error.php.
The entire shutdown handler can be overridden by using a fatal-error-handler.php drop-in. This drop-in must return an instance of a class extending the default WP_Fatal_Error_Handler class. If that is the case, the instance will be used instead of the default one.
Environments that would like to disable the fatal error handler and recovery mode functionality altogether can do so by setting a WP_DISABLE_FATAL_ERROR_HANDLERconstant, typically in wp-config.php. The enabled status for the handler should be checked for by using a new function wp_is_fatal_error_handler_enabled().
Background
The fatal error recovery mode is a revised approach for what was originally the fatal error protection mechanism slated for WordPress 5.1, but then reverted due to some critical concerns. The client-specific recovery mode mitigates these concerns, so this time it is here to stay.
It’s been over 3 years since Dashicons has been updated (see #34221 from version 4.5). But, they have not been forgotten about! In 5.2, the Dashicons will see several changes, including 13 awesome new icons.
New Build Process
A new build process has been implemented in the Dashicons GitHub repository to make adding new icons easier. Now, when SVG files are added for new icons they are automatically included in the font and CSSCSSCascading Style Sheets. files. This change will not be noticeable from the WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. code base, but it’s worth noting.
New Font File Format: WOFF 2.0
This release will see the introduction of a new font file format, WOFF2 (Web Open Font Format 2). WOFF2 is a more modern replacement for the original WOFF 1.0 format that uses an improved compression, which results in lower networknetwork(versus site, blog) consumption.
The WOFF 1.0 file will remain in WordPress Core to ensure backwards compatibility for plugins and themes loading the wp-includes/fonts/dashicons.woff file directly. This file has not been updated to include the new icons below. The new build process currently only allows one WOFF format file to be built. Since WOFF2 is more modern, that is the file format being built moving forward.
However, WOFF 1.0 is compiled and included as an embedded font directly in the dashicons.css file. The embedded WOFF format has been updated to include the new icons. If you wish to use the new Dashicons and require the WOFF 1.0 format for IE support, it is recommended that you use the dashicons.css file included in core to define the Dashicons font face.
Alternatively, you can use the Embedded OpenType format file at wp-includes/fonts/dashicons.eot (supported by all versions of IE). This file does include the new icons.
New Icons
In 5.2, 13 completely new icons were added. However, 18 additional icons that were previously included in the font files but did not have a corresponding CSS declaration are now available. These icons are marked with an asterisk (*) below.
Buddicons
The Buddicons were all previously included in the icon font, but each is now accompanied by new a dashicons-buddicons-* class.
With the introduction of 3 new icons in 5.2, there are now 4 total site icons. No matter where you are located in the world, there is now an icon for you! (GH-95)
WordPress 5.2 introduces new short circuit filters to WP_Site_Query and WP_Network_Query.
These two filters, sites_pre_query and network_pre_query, were introduced in [44983] and run before the database queries are executed. This enables short-circuiting the database query entirely to return custom results. Returning a non-null value from either filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. will bypass WordPress’s default networknetwork(versus site, blog) and sites queries respectively (similar to the users_pre_query filter introduced in #44373).
Sites Query Filter
Developers should note that filtering functions that require pagination information are encouraged to set the found_sites property of the WP_Site_Query object (which is passed to the filter by reference). If WP_Site_Query does not perform a database query, it will not have enough information to generate these values itself.
Using the Filter
Below is a rough example of how a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party can use the filter to replace the default behavior of WP_Site_Query with a call to a remote data store.
Developers should note that filtering functions that require pagination information are encouraged to set the total_networks property of the WP_Network_Query object (which is passed to the filter by reference). If WP_Network_Query does not perform a database query, it will not have enough information to generate these values itself.
Using the Filter
Below is a rough example of how a plugin can use the filter to replace the default behavior of WP_Network_Query with a call to a remote data store.
A short circuit for WP_Term_Query with a plan to add a terms_pre_query filter (#41246).
Why Add These Filters?
These query pre-filters enable plugins to use an alternate database store for queries, for example returning results from an external service such as an Elasticsearch server. The process started with the main post query, and these are now being expanded that to other queries in WordPress.
Five days left to submit a talk for WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US at WordCamp US 2019
5.2 updates
BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 3 is Thursday, April 11th; target release is April 30, so focus is on final pushes.
Bug Scrubs
There are two planned bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs prior to RC1. Check the post here for the schedule.
Dev Notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.
Deadline for dev notes is this Friday, April 12.
Two were published on Make/Core; two more went up to Make/Themes but consensus was to move to Make/Core after some discussion. Three to four more are in the pipeline for Friday. A post on the new Site Health tool from @clorith will also get the dev-notestagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.).
All 5.2 dev notes will go in the Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page., which will go live with the RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). on April 17.
@jeffpaul has volunteered to help with the Field Guide.
Per the notes @williampatton wrote for Make/Themes: @chanthaboune clarified that she thought the best plan was to move all dev notes to Make/CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. to keep them all together and ensure broader reach.
GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg//editor
Deadline for Gutenberg changes to make 5.2 is also Friday, April 12. This is limited to bug fixes only.
Open Floor
Visibility of Dev Notes
@xkon started a discussion on the best way to surface dev notes for easiest access. He and other folks are now looking for All The Links and will comment on this post with their findings.
From there we’ll revisit the issue and use it to inform any changes to Make/Core and what we put on a proposed Core Contributor Handbook page.
WP TranslationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. Day
The following bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs will help us drop to 0 tickets in the 5.2 milestone by RC1 on Wednesday, April 17th:
One of the goals of the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project’s phase 2 is to expand the usage of the BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor to other WordPress adminadmin(and super admin) pages like the widgets screen.
In order to achieve this goal, it’s important to be able to reuse the block editor in a context independent from the post editor without any dependency to the post object. That’s where the new block-editor module comes in.
Reorganization
In WordPress 5.1 and earlier, the block editor relied on the editorJavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. module in order to fetch the post being edited and render the block editor corresponding to this post. This module is available as a registered WordPress script using the wp-editor script and style handles and under the wp.editor global variable.
WordPress 5.2 extracts some parts of the editor module into a new module called block-editor. This module is now available as a registered WordPress script using the wp-block-editor script and style handles and under the wp.blockEditor global variable.
Important distinctions about the new block-editor module:
The editor module is kept, but is only responsible for fetching/updating post objects, and rendering post specific UIUIUser interface components.
The block editor module is a generic module responsible for rendering block editor UI, updating the list of blocks, and providing reusable components for third-party blocks.
Backward Compatibility
There’s no backward compatibility breakage involved in this reorganization, as usage of the editor module provides proxies for APIs that were moved to the block-editor module in WordPress 5.2.
For example, in WordPress 5.1, blocks had to use the wp.editor.BlockAlignment component to support alignment. This component will continue to work as expected, but wp.editor.BlockAlignmentToolbar is now just a proxy to the block editor component wp.blockEditor.BlockAlignmentToolbar.
However, relying on the editor module as a dependency means that your block/code is loading the full editor module, which might not be needed for the block editor that will be included in the widgets screen in the future.
For this reason, it’s recommended that you make your blocks independent from the editor module and any post object. Instead of relying on the editor module proxies, you are encouraged you to your code to target the block-editor APIs instead.
This involves:
Using wp-block-editor instead of wp-editor as script and style dependencies for your WordPress registered/enqueued scripts and styles.
Using the wp.blockEditor.* components instead of wp.editor.* ones.
Using the core/block-editor data module selectors and actions instead of the core/editor ones.
Components and Higher-Order Components Moved to block-editor
This is the exhaustive list of the components and higher-order components that were moved to the block-editor module.
Autocomplete
AlignmentToolbar
BlockAlignmentToolbar
BlockControls
BlockEdit
BlockEditorKeyboardShortcuts
BlockFormatControls
BlockIcon
BlockInspector
BlockList
BlockMover
BlockNavigationDropdown
BlockSelectionClearer
BlockSettingsMenu
BlockTitle
BlockToolbar
ColorPalette
ContrastChecker
CopyHandler
createCustomColorsHOC
DefaultBlockAppender
FontSizePicker
getColorClassName
getColorObjectByAttributeValues
getColorObjectByColorValue
getFontSize
getFontSizeClass
Inserter
InnerBlocks
InspectorAdvancedControls
InspectorControls
PanelColorSettings
PlainText
RichText
RichTextShortcut
RichTextToolbarButton
RichTextInserterItem
UnstableRichTextInputEvent
MediaPlaceholder
MediaUpload
MediaUploadCheck
MultiBlocksSwitcher
MultiSelectScrollIntoView
NavigableToolbar
ObserveTyping
PreserveScrollInReorder
SkipToSelectedBlock
URLInput
URLInputButton
URLPopover
Warning
WritingFlow
withColorContext
withColors
withFontSizes
Selectors Moved to block-editor
This is the exhaustive list of the data module selectors that moved to the core/block-editor store.
canInsertBlockType
getAdjacentBlockClientId
getBlock
getBlockAttributes
getBlockCount
getBlockDependantsCacheBust
getBlockHierarchyRootClientId
getBlockIndex
getBlockMode
getBlockName
getBlockOrder
getBlockRootClientId
getBlockInsertionPoint
getBlockListSettings
getBlocks
getBlocksByClientId
getBlockSelectionStart
getBlockSelectionEnd
getClientIdsOfDescendants
getClientIdsWithDescendants
getFirstMultiSelectedBlockClientId
getGlobalBlockCount
getInserterItems
getLastMultiSelectedBlockClientId
getMultiSelectedBlockClientIds
getMultiSelectedBlocks
getMultiSelectedBlocksEndClientId
getMultiSelectedBlocksStartClientId
getNextBlockClientId
getPreviousBlockClientId
getSelectedBlockCount
getSelectedBlockClientId
getSelectedBlock
getSelectedBlocksInitialCaretPosition
getTemplate
getTemplateLock
hasInserterItems
hasMultiSelection
hasSelectedBlock
hasSelectedInnerBlock
isAncestorMultiSelected
isBlockInsertionPointVisible
isBlockMultiSelected
isBlockSelected
isBlockValid
isBlockWithinSelection
isCaretWithinFormattedText
isFirstMultiSelectedBlock
isMultiSelecting
isSelectionEnabled
isTyping
isValidTemplate
Actions Moved to block-editor
This is the exhaustive list of the data module actions that moved to the core/block-editor store.
clearSelectedBlock
enterFormattedText
exitFormattedText
hideInsertionPoint
insertBlock
insertBlocks
insertDefaultBlock
mergeBlocks
moveBlocksDown
moveBlocksUp
moveBlockToPosition
multiSelect
receiveBlocks
removeBlock
removeBlocks
replaceBlocks
resetBlocks
selectBlock
setTemplateValidity
showInsertionPoint
startMultiSelect
startTyping
stopMultiSelect
stopTyping
synchronizeTemplate
toggleBlockMode
toggleSelection
updateBlock
updateBlockAttributes
updateBlockListSettings
Styles and Class Names
The components that moved from the editor module to the block-editor module are internally using CSSCSSCascading Style Sheets. class names that follow the package they’re declared in.
For example, the editor-inserter__toggle class name is now renamed block-editor-inserter__toggle.
The old class names have been retained to minimize any backward compatibility concern, but the CSS styles are now targeting the new class names.
Ideally, you should rely on components in your own code instead of the internal class names used in the WordPress admin. But if you do use those classes, make sure to rename them accordingly.
@audrasjb@jeffpaul will be coordinating some bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs to help achieve this goal. Anyone else with contribution bandwidth is asked to focus on this list leading up to RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).. If you currently own any tickets in this list, please work on those tickets and ensure they are accurate and ready.
Anyone is welcome to lead a bug scrub! If you have time and are interested in leading one during the next 13 days, please reach out to @chanthaboune, @audrasjb, @jeffpaul, or @desrosj.
Dev Notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.
Please keep an eye out for 5.2 dev notes. @earnjam is coordinating these for 5.2. If you have a change that you feel warrants a dev notedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., please reach out to him.
Since the last dev chat, the following note was published:
Also, please refer to the most recent “What’s New in Gutenberg?” post for details on the features and changes that will be included in 5.2. The updated packages will be published to NPM and a ticketticketCreated for both bug reports and feature development on the bug tracker. on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. will be opened to merge them into trunk.
@pento noted his appreciation for the great feedback on the proposed coding standards changes. He is planning on sorting through all of the comments in the coming week.
@jorbin noted that the public announcement for the PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher minimum version bump went out on Monday. It’s happening! 🎉
@kadamwhite mentioned that the REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. and Mobile teams are collaborating on a feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. for JWT authentication to allow mobile apps to communicate to GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ Endpoints. Those interested should check out the GitHub repository, or join the weekly REST API meetings at 18:00 UTC on Thursdays in the #core-restapi room on the Making WordPress Core Slack instance.
The next CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. dev chat will be held on Wednesday, April 10, 2019 @ 20:00 UTC. Please make sure to note the time as it changed this week to account for daylight savings.
Some tabs in the WordPress Adminadmin(and super admin) aren’t really ARIA tabs — they’re actually links wrapped in h2 headings and styled to look like ARIA tabs.
But since they’re just navigation menus, WordPress 5.2 changes their markup accordingly. That way, assistive technologies will reactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. to them correctly.
With #43398, WordPress 5.2 includes the following changes:
changes the wrapping <h2> to a <nav> element. It’s worth remembering that <nav> elements also define ARIA landmarks.
adds an aria-label to the <nav> elements so they can be distinguished from other <nav> elements in the page
If your pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme uses the same markup as CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., you’ll want to update it for consistency and to avoid future CSSCSSCascading Style Sheets. incompatibilities.
Please note: if your plugin or theme uses items that actually toggle the visibility of in-page content instead of linking to another page, then they are not navigation items. You should not use ARIA tabs nor <nav> element in that case.
BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 will be released today
You must be logged in to post a comment.