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.
As we approach the end of 2020, it’s good to do a brief recapitulation of where we are standing with one of the major focus areas for 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/ Phase 2: site editing with blocks. If you are curious about the more detailed tasks ahead of us, the overview issue for full site editing is the best way to follow the updates and progress.
In this post I’ll describe the current state of all the primary projects and comment a bit on how they fit together. Worth noting this doesn’t cover the other projects still under the phase 2 umbrella (like the widgets screen updates).
For all the following items, keep in mind that they tend to illustrate the maximum amount of customization options — the ability to lock down templates, capabilities, design tools, etc, is still a prime focus to account for the different needs of different sites.
The site editor allows editing 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. themes and all their template files. It allows the user to swiftly navigate between the template hierarchy and make edits across an entire site. To accomplish this, it introduces some new interface elements, areas to manage, and the ability to browse the different templates a theme has to offer. Since the entire template is built with blocks, it leverages all the preview tools that have been built for blocks and patterns so far, allowing users to quickly visualize their contents.
The site editor engine is capable of knowing what elements of a site are being modified — whether a site option, a template part, or some local content, providing a much more powerful and flexible update flow. A site title block accurately saves its data as the site name option, not in the content, for example. While we are not yet focusing on editorial flows (that’s one of the aims of Gutenberg Phase 3) these foundational pieces can allow all sorts of integrations down the road, being very granular around what is being updated in a session.
The site editor opens up the ability to edit and customize parts of the site that used to be only accessible through code editors or ad hoc interfaces. For example, being able to edit the 404 template with the same familiar block tools. For 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 and block developers, that means all the blocks being created can now be used in plenty more places of a site without any extra work.
Most of the infrastructure needed to power this editor is already built. What remains to be done is stabilizing loading flows, refining design and interactions, introducing semantic template areas (such as headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. and footer), and connecting the creation flows with what block patterns offer.
The site editor depends on the ongoing focus of building themes with blocks to take advantage of the block editor interface. This year has seen a lot of great collaboration between the theme and editor development groups, which is paramount to ensure the WordPress block editing platform is powerful enough to support all the theme building needs and simple enough for users to interact with ease and confidence. This is an exciting area of collaboration, and something that needs the continued help and feedback from the community. If you are interested in helping shape these projects, the theme-experiments repository can be a good start to peek through.
To support this effort, outside of the template and template parts infrastructure, there’s an obvious need for creating many new blocks centered around theme functions. These includes blocks for the site title, navigation block, post title, content, excerptExcerptAn excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox., author, date, featured imageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts., and plenty more.
In the future, rich layout tools — such as full site grid support — will be able to cascade down through the entire experience of the block editor, allowing interactions like snap-to-grid and overcoming a lot of the hurdles alignments currently impose.
Out of all the theme related blocks, the navigation block has stood out as its own fundamental project for some time. The work that went into this block has allowed the various block APIs it depends on to evolve and mature substantially, including new support for horizontal inner blocks, a fully fledged block list view, and many more.
These are wonderful results of this specific project because it lifts up the available block tools for all third-party blocks. We are building the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks with the same tools that are offered through the standard block 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.. As an example, many of these capabilities are employed in the Buttons and Social Icons blocks.
With everything expressed in blocks, the opportunities for extending the navigation are also enormous — imagine adding with ease to your navigation a Search block, Social Icons, or a Cart block from WooCommerce. With the navigation becoming a more flexible container it opens a lot of integration points for already existing blocks. Each child block can be responsible for its own set of tools and capabilities while the user is presented with a unified way of building things.
Ultimately, the power of combining blocks is going to allow all sorts of menus to become possible. Themes will be able to provide more than one header pattern for users to choose or swap between them.
The biggest remaining challenge with the navigation block is also one of flexibility and ease of use. Flexibility needs to be balanced with intuitiveness and there’s more work to be done to get the user experience in a great place to be widely released. There’s also some work in ensuring smooth compatibility with current themes.
This is another major area of the site editing focus which also takes some of the block API infrastructure to the limit. If you are curious about block development tools and their latest capabilities, the Query block is a good one to explore, as it leverages nested blocks, inner blocks templates with live updates, block variations, contexts, etc.
Generally, the query block is responsible for controlling fetching and rendering of post types. It is naturally a core ingredient of block themes. It comes with a LoopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. block that is responsible for iterating on the results and rendering a template. One cool thing is that interacting with the Loop in the editor automatically updates the template used for all posts in that query. You can add a featured image, change the order of title and date, add a block to display the author, and see it all reflected instantly.
The next steps for this block are ensuring it plays well with the template hierarchy (global query), defining more user friendly block variations, and creating patterns that use it to build great layouts.
There are two major areas that fall underneath the global styles umbrella: centralized theme configuration and an interface for manipulating visual aspects of blocks globally.
Theme configuration absorbs things like declaring color palettes, presets, different supports and settings, as well as being able to toggle on or off the several block design tools that are available (typography, colors, dimensions, etc). It will also allow themes to specify how blocks should look by being able to specify all their default attributes. This accomplishes many goals at once, ensuring that the editor is more connected with how themes wants things to render, provides a solid interface for the mobile apps to understand block configuration, and opens the door for further performance optimization on the front-end since WordPress will be able to load the right styles for blocks when they are actually being used in the page instead of needing to load styles for all, all the time (like themes have to do now with widgets even if they might not be used).
The other major part of global styles is the interface for the user to make edits to blocks globally. This ranges from being able to set the color for Links across blocks to modifying how all Headings ought to look. Global styles operates both at the site level as well as allowing changes to each registered block. A lot of the tools that emerge from this work continue to be released in each major WordPress version in the form of block tools.
In terms of timelines, all of these are in advanced stages and can be used in the Gutenberg plugin already. The main hurdle to include the work in major WordPress releases are the various dependencies between each project when it comes to ensuring a great user experience. The immediate focus is then on completing the milestones, stabilizing the work, and doing as much testing with different kinds of users as possible. For that last purpose, there will be some calls for testing announced soon as part of the Site Editing Outreach Program.