Update | WordPress 5.6 Release Progress

Welcome!

The WordPress coreCore Core 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 bugbug A 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.

Want to contribute? Get started quickly with tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on the reports page, like patches needing testing, and on feature projects page.

Other questions? Here is a detailed handbook for contributors, complete with tutorials.

The planned date for betaBeta A 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 is just about two weeks away on October 20, 2020. The release squad has been keeping me up to date on our collective progress, and I want to update our list of expected features!

Note: This update doesn’t include a number of cross-team initiatives, that could happen around the time of release, but may ship outside of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. itself. Progress on those will be shared in our quarterly updates on make.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//updates.

Planned for Beta 1

Automatic updates for major WordPress Core releases (opt-in)
New features from the blockBlock Block 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 upgrades
Widgets editing support in Core
Twenty Twenty-One theme
PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8 support
oEmbed updates

Not Planned for Beta 1

Twenty Twenty-One block-based/FSE-first – this will be available in the theme repo once completed.
Navigation menus block and screen – work will continue on the feature after 5.6. Find out more here.
CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. support – work will continue on this feature, but it won’t be ready for Beta 1. Find out more here.
Full Site Editing – Full site editing (FSE) will be added to the GutenbergGutenberg The 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/ pluginPlugin A 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 once available.
Drop support for PHP 5.6 – On hold until a decision is made on when to stop support for older versions. Find out more here.

Uncertain for Beta 1

There are a few proposals that are still settling, and it’s not clear whether they will resolve in time for beta. I’ve listed them below for better tracking and transparency.

I also enlisted the generous help of some Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors./TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress./Core folks to get a priority list of tickets that could be ready with a little more help. If you’ve got some spare time left in your contribution budget, head on over and see if any of those tickets call to you. 🙂

Thank you to the release squad for their help compiling and reviewing this post. Thank you to everyone who has contributed their time thus far!

#5-6, #planning, #update

Josepha 4:57 pm on October 7, 2020

I’ve been asked for a little more clarity on the status of FSE, and I’m so grateful that y’all raised a flag. 🙂

I don’t expect FSE to be feature complete by the time WP5.6 is released. What I expect is that FSE will be functional for simple, routine user flows, which we can start testing and iterating on.

That feedback will also help us more confidently design and build our complex user flows.
- Francesca Marano 7:56 pm on October 7, 2020
  
  Can we get a screenshot or a screencast about what
  
  simple, routine user flows, which we can start testing and iterating on
  
  would look like? Link to GH? I can not visualise it 🙁
Nick Halsey 4:45 am on October 12, 2020

Based on the link, I take “CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. support” to mean blockBlock Block 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.-based widgets in the customizer. There are some fundamental issues with how widgets are working with the GutenbergGutenberg The 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/ pluginPlugin A 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 currently. I get the impression that the team may not fully understand the “what” and “why” of the customizer, and what it can do for widgets. Here are some high-level ideas that I will also share with a more detailed proposal on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/.

The customizer is a framework for live-previewing changes to a site. It is not, necessarily, the specific interface that most of us are familiar with at wp-admin/customize.php. The power of the customizer is its APIAPI An 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. and its contextual live preview – the ability to instantly see edits as they apply on the frontend of the site. Users can navigate to different pages on the site within the preview; for widgets, this makes it easier to understand how dynamic and conditionally-visible widgets work across a site.

Most importantly, the customizer allows users to schedule changes, save draft changes, and even share a public link to navigate through the site with a preview of changes. The widgets screen has long suffered from a “change and surprise” publishing experience. The Gutenberg plugin’s new widgets screen has only a publish button with none of the other publishing options available in the customizer.

We can leverage the customizer API outside of wp-admin/customize.php to bring the enhanced publishing experience to the standalone widgets screen. We can also offer a preview of the frontend of the site reflecting changes to widgets. This preview could open in a new tab similar to the editor preview. But, because we’re using the customize API, we could also open it as a full-screen or modal overlay. The editor/preview toggle could be similar to the mobile interface that the customizer currently uses. This is contextual, but not live, preview. Exceptionally large (desktop) monitors might show a live preview next to the editor.

If the goal of the standalone widgets screen is to provide a full-screen experience for editing widgets, then it shouldn’t use the same interface that widgets in the customizer currently use. But with block editing incorporated into widgetWidget A 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. editing, maybe customizer widgets should also offer a more-full-screen editing interface. Customizer panels (widgets, menus, etc.) can take any form that’s appropriate for the feature. The theme browser takes over the customize preview to offer a full-screen experience. Why not do the same for widgets? With this approach, the widgets screen and widgets in the customizer can use exactly the same interface with exactly the same technical implementation as a customizer panel.

This brings me to a question that I’ve been asking for years: why not combine the two widget editors? Do we need to offer the same interfaces in two different places? We can keep links to the widgets screen as links that go directly to the full-screen widgets panel in the customizer. And users can also get to the widgets screen from directly within the customizer. Or, we can keep separate screens but use the same infrastructure and interface in both places. Either way, this general strategy brings Gutenberg into the customizer and demonstrates a path forward for integrating post editing with the customizer.

As it is, the widgets screen in the Gutenberg plugin still feels very “alpha”. We have an opportunity to significantly improve the experience and reduce technical debt. And we can bridge the gap between the editor, Gutenberg, the widgets screen, and the customizer in the process. This may not be achievable in time for WordPress 5.6. But it is a better approach than the current separate implementations. Focusing on a single implementation, we can focus on critical needs such as accessibilityAccessibility Accessibility (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 we can create a better editing experience for all users.

Comments are closed.

Welcome!

Communication

Planned for Beta 1

Not Planned for Beta 1

Uncertain for Beta 1

Share this: