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.
Core Editor Improvement: Advancing the Site Editor experience
These “CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Improvement…” posts (labeled with the #core-editor-improvementtagtagA 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.)) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects.
In the last few 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/ releases, a collection of work provides massive improvements to the Site Editor to scale the experience, provide clarity, and add new functionality with more planned. These features make it easier to get a complete view of your site and add more ways to make changes to it, from a new Navigation 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. experience to Custom CSSCSSCascading Style Sheets.. The improved experience also addresses key pieces of feedback that have come up in places like the FSE Outreach Program: frustration with the navigation block, confusion around what pieces are globally editable, desire to add custom CSS, a sense of overwhelm with the number of block settings, and more. While iteration will always be required, this marks a substantial shift in refinement, functionality, and ease, paving the way for wrapping up phase 2.
Providing clarity and ease
Previously, when making changes to your site, it was hard to know how those changes might impact other pieces. For example, if you opened up Styles and made changes to a block that wasn’t visible on the template you were on, it wasn’t clear how the changes might land. The same thing happened with Template Part blocks where changes made to one instance impacted all others. There was no indication in the interface that these blocks functioned differently.
Now, with both the Style Book and built in previews of the Styles system, it’s far easier to know the impact of what you’re doing with Styles. The Style Book accomplishes this by providing a way to toggle a view of Styles that shows all blocks, separated into sections:
Meanwhile, the previews baked into Styles offer another way to see at a glance the changes you’re making without needing to fully enter the Style book. Each offers a specific way to engage with styling your site as you see fit.
Site navigation is an incredibly important part of building most sites and the Navigation block has often struggled to offer an experience that covered the majority use case of building a simple menu. While improved fallbacks in 6.1 provided a big step forward, the base usability still needed to be refined. Over the last few releases, as an experiment in Gutenberg > Experiments, an editable list view in block settings has been added to the Navigation block. This editable list view feels reminiscent of the prior menu editing experience but rooted in the world of blocks. You can follow this work in the project’s dedicated GitHub board or the current Navigation block tracking issue.
Scaling the experience
With more templates being added, more functionality, and more types of content in the Inserter, there are numerous situations where the interface needed to scale to accommodate the growing nature of the site editor. This ensures that, as more is added to the experience, the complexity is managed in a way that still makes building a site delightful and intuitive.
Rather than being in a more narrow yet important part of your site when opening the Site Editor, you can now explore it in its entirety and edit from there with Browse mode. This new mode reorganizes the site editor by providing a way to move between templates and template parts. You can add new templates or template parts directly from this interface or choose to edit whenever you’d like. This stands in contrast to the prior experience of opening the Site Editor and being dropped into the template powering the homepage, without necessarily knowing how to get to other templates or template parts.
While the site editor, launched in WordPress 5.9, initially started in a more contained state, each WordPress release brings new functionality to accomplish more. In some cases, this means old things done in new ways to customize your content, like with Custom CSS, and in other cases it has more to do with easing embracing the Site Editor, like with the ability to migrate widgets to block themes.
Block themers and designers alike have long requested Custom CSS, even as design tools grow enabling you to use built in functionalitytools. For many, there are always going to be items that aren’t covered by Styles, As of Gutenberg 14.8, there’s now the option to add Custom CSS directly in the Style’s interface so you can customize directly while using the Site Editor and ensure those customization stick across themes. This is currently listed as an experiment in Gutenberg > Experiments with work underway to stabilize the feature. Alongside this effort, work is underway to add per block Custom CSS too so they can work in unison.
Previously when creativity struck in the Site Editor as you were styling an individual block, you’d have to copy what you came up with to the Styles system for that individual block at a global level. As of Gutenberg 14.9, that changes with the introduction of a “Push changes to Global Styles” button which automatically moves those changes to an individual block to Styles. This new functionality makes it easier to design on the go, knowing you can ensure consistency with a press of a button. Iterations are already underway to make this option even more user friendly.
Lastly, the Inserter now allows for media to be added directly so you can add blocks, patterns, and your recent media library items all from one place. Next up, Openverse integration is underway, meaning you’d soon have access to everything within Openverse to use as you create your site.
More work remains to be done around each of these areas and you can follow along in this tracking issue on GitHub where updates are provided weekly for a main set of tasks. If you want to help shape what’s being worked on, know GitHub issues/PRs are always welcome and the FSE Outreach Program continues to facilitate explorations and calls for testing to explore each of these features. All are welcome to join, regardless of experience level with the Site Editor or WordPress in general.
You must be logged in to post a comment.