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.
This post summarizes the top pieces of feedback of the current experience to help inform the next steps and as a follow-up to various previous editions. Compared to the previous related posts (March 2021, July 2021), this one seeks to focus on more specific and common items different types of folks might try to accomplish rather than more general themes that continue to come up. This is to help provide more specifics to designers and developers working on these various related features. The aim is that by examining FSE from the vantage point of common flows, contributors can improve specific features in a way that brings everything together intuitively. For example, this doesn’t go into depth around problems that come up when using FSE at scale, like needing to have more ability to sort templates.
Keep in mind that this post is simply a snapshot in time and is inherently going to leave out aspects of the experience that haven’t been the subject of calls for testing. It’s also not going to go into great detail about all of the hard work already done to address these items, whether through PRs or sharing designs that offer solutions.
Provide a better setup state when creating a new template or template part
When creating a new template or template part, the initial options offered to users are quite limited and, after creation, it’s not clear how to fully apply what was just created across the site. Tied to this, the difference between the Template editor in the Site Editor vs the Post Editor continues to be jarring with folks not clear around when and how best to use each at a glance.
When replacing the current template part, make it clearer which one is currently in use.
Unless you add a container 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. when creating a new template, any text runs to the edges. Below is a quick video example:
The most immediate issue when creating a new author template is that it was devoid of default blocks. Where was the—at minimum—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? The empty template would make sense if I was building something from scratch. However, this is not a from-scratch project. It was built from a theme with existing archive.htmlHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. and index.html files, ancestors in the template hierarchy. Since the author template is merely a more specific version of the archive template, it should be a copy of its “parent” in the hierarchy. Users will most likely want to make modifications rather than start from scratch. Using an ancestor template as a base means that they are less likely to unnecessarily deviate from the existing layout, especially with more complex designs.
Unify the Template Editor in the Post Editor with the Site Editor
For example, a template for posts/pages can only be added via the Template Editor in the Post Editor rather than in the Site Editor. This difference in functionality isn’t made clear at any point though, leading some to not be aware of the Template Editor in the Post Editor at all. Below is a short video discussing some of the differences:
The slightly different variations of the template editing screen were just too confusing for me. As someone who has been trying to work in the FSE for a few months now, I was completely thrown off by the slightly different screen you got when you launch the template editor directly from a post vs the template editor you get when you go to edit site, and then select a template to edit.
Improve the process of applying and viewing a template in action
After creating a new template that you might want to use for a page/post, it’s not clear that you have to assign it to that post/page. To ease this workflow, after a user creates a new template, they could be prompted to apply it to all child pages of a parent page. The same is true for creating new template parts and needing to actually apply them to each template you might want to use it in.
On a related note, after someone creates an author template or date template, they would have to know the relative link for their site to see the template in action. It would be great to connect the dots a bit more in the interface so that folks can see their changes after a new template has been created. This came up during a recent call for testing around creating an author template with folks not knowing how to see the template without being linked to an example.
I really do not know which template affects which pages/posts. So I assume that a Page template affects all the pages.
Tied into this is the general experience of when and why to use template part focus mode, since the advantages of doing so aren’t always clear and the general mode matches the appearance of the Template Editor in the Post Editor (dark background, back button, etc).
I went down a weird rabbit hole where I couldn’t figure out why we had the header block and the header template parts. I mean, what if I wanted to have two different headers with wildly different information in them? Whenever I changed the main header block (anything living inside it), it changed it in all the header template parts, and I found that very confusing and frustrating. I ended up removing the header block inside the header templates and keeping things just in groups. That made way more sense to me.
Placeholders need to be greatly improved as folks are accidentally deleting theme blocks like the Post Content block not realizing that it’s what will display their actual content in the template itself. The more robust the placeholders can be, the more visual clarity there can be between editing a template vs post/page. Keep in mind that when user content is displayed but not editable, there needs to be a clear way for folks to understand why they can’t edit their content directly.
I found it a bit strange adding a 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. block and a duotone 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. without seeing what the result would look like.
Ease the process of editing a template for currently viewed page/post
When you are viewing a page, it’s not always clear what template is currently in use, and it takes numerous steps just to get to a specific template in use outside of your homepage (wp-adminadmin(and super admin) > Appearance > Editor > W Menu > Templates > Select correct template). There are a few issues related to this to explore, including:
Provide consistent dimension controls across blocks
In nearly every call for testing, folks are left wondering why certain controls exist in some blocks and not in others. This current experience of dimension controls needs to be standardized and expanded appropriately.
The different controls for different blocks makes it really hard to make something that is consistent and nice. I decided it would be cool to make the user pictures a little bit bigger, like that might make the comments more inviting. Since I made the commenters pictures so big, I said, let’s add in a Post Author block so that the post author’s picture will be shown too! Wait, the AvatarAvatarAn avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. block in the Comments Query 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. and the Post Author have completely different control? I can make the avatar any size, but the post author I have a dropdown with 3 choices? I can but a border radius on the avatar block, but not the post author block? If it’s a picture, I should have all the same tools available to me as any other block that uses a picture.
Improve the experience of changing font sizes using the default options
Whether you’re selecting from the default options or trying to set a custom size, the UXUXUser experience is fairly quirky. Finding the custom size option is somewhat cumbersome and, if you select one of the default sizes but want to switch back, you have to “reset” the font selection from the ellipsis menu. The presentation of the font sizes isn’t easily known either, with “t-shirt” sizes currently being considered. Regardless, this is an extremely basic action to take that now takes numerous steps to complete as the video below demonstrates:
Ease switching to a block theme/between block themes
Switching to or between a block theme should feel seamless and there are a few issues to help get the experience where it needs to be:
This covers a large number of use cases, from using the same width for the rest of your content in a new template to wanting to have a site logo next to a site title. Beyond relying on patterns to set a header or footer layout, it’s incredibly difficult to create your own as you often need to use a group/row/stack block first and foremost. From there, getting the spacing right is incredibly difficult. This is true of individual experiences like with the Navigation Block and of trying to combine multiple blocks into one layout:
Users who want to even slightly change the spacing and positioning of content have to have deep knowledge of container blocks, design tools (often locked away in ellipsis menus), and the spacer block. While the spacer block is the most user-friendly option for controlling spacing, the problems below remain:
It’s not clear when to use spacer blocks.
Spacer blocks often aren’t robust enough.
Design tools are hidden in the ellipsis menu.
It’s not clear if one needs to use container blocks to have more control over layout/spacing.
Still trying to get “edge space” – ie margin from edge to orange borders I tried toggling on the “inherit default layout” This didnt make any different to the margin. It just changed the padding. I also added a zero to the block spacing field. Nothing changed. I tried changing the layout toggle to 80 % wide. This changed the internal padding of the block and didnt move the block away from the edges…Why are some settings in the block toolbar and some in the inspector? Why aren’t the same settings (where appropriate) in all similar blocks – ie padding, margins, width available in both groups, and columns?
With the Go/No Go session happening this week ahead of WordPress 5.9’s release in December 2021, let’s use this time to dig into any general questions you all might have around Full Site Editing! As it’s possible, please focus questions specifically around WordPress 5.9 as those will be the most high impact to address and not on larger strategic decisions. You are welcome to submit questions using the form below or to leave them as a comment on this post by October 27th:
Keep in mind that because, depending on the questions it’s likely that some answers might take the form of “people are working to figure this out and feedback is welcome here,” rather than a definitive answer. This is especially true for features/milestones that are planned for future releases.
When and where will you share the answers?
I’ll share a recap post on this blogblog(versus network, site) (Make CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.) as soon as I possibly can and aim to do so no later than November 1st, 2021. If there are a ton of questions, they will be grouped with corresponding answers for easy review. You can see what the outcome will look like based on the first round and second round. I will work in the open as I go in a collaborative Google doc that will be shared in #fse-outreach-experiment for anyone who wants to collaborate or check in on the work.
Once the post is published, I will follow up via email with everyone who left their email and a question in the form. For anyone who leaves a question as a comment on this post, I will @ your username in the recap post so you don’t miss out too!
What else will this effort help with?
While the main outcome will be a lovely list of answers to grow community knowledge, this collective effort will also be useful for future documentation updates, potential tutorials, hallway hangout topics, and more.
This post summarizes the top pieces of feedback of the current experience to help inform ongoing efforts after the 5.8 release and as a follow up to a similar post from March. You might notice that some areas of feedback match the original post but that the specifics are different. This is to be expected due to efforts being consolidated around 5.8, causing some feedback to fall in priority.
Keep in mind that this post is simply a snapshot in time and is inherently going to leave out aspects of the experience that haven’t been the subject of calls for testing yet, for example, Global Styles. It’s also not going to go into great detail about all of the hard work that has gone into addressing these items already, whether through PRs or sharing designs that offer solutions.
This section pulls together everything from feature requests for additional options for different blocks, desire for more control over spacing especially for the Column and Query 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. blocks, general confusion around why certain settings exist in one place and not another (example with the Query loop block, with Color settings, and Columns block), and how to navigate the complexity of settings with more powerful blocks. As a specific example tying in these various items, let’s say you want the Query loop 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. to display 3 posts from a certain categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. and you want to set various colors for different parts of the set of posts. To accomplish that, you would have to interact with the block sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. settings first to set the category before using the block toolbar to select the number of visible posts. To set various colors, you’d have to use List View or navigate through the nested blocks before opening up the block sidebar settings once more to make sure you’re styling what you want.
Make editing modes distinct (Site, Template, Query Loop block, etc)
Since the calls for testing began to focus on items related to 5.8 in the last couple of months, understanding how best to navigate template editing mode and the Query Loop block became major focuses of feedback. For example, this partially led to the decision to make the Query Loop block’s post content blocks view only. However, while lots of work has been done to provide clarity around what one is editing and adding the right amount of friction, this was still repeated feedback in nearly every test as an area that needs refinement considering how new this functionality is. For example, sharing information in the sidebar upon entering the template editing experience could go a long way in getting a user acquainted with this new experience.
Refine Placeholders & Initial Configuration Steps
With new blocks and new features, the initial placeholders and configuration steps become key to get right in both setting expectations and guiding a person to create what they want. This cuts across many aspects of the full site editing project including template editing mode, the Query Loop block, Navigation block, integrated patterns, and more. For example, if one is adding the Query Loop block with the intent to show a collection of posts, it makes sense to display multiple posts at default rather than just one with the latest implementation. Currently, feedback points to work needing to be done to standardize approaches where it makes sense and to improve each experience overall.
Solidify WYSIWYGWhat You See Is What You GetWhat You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. & Desire for previewing content
Since many of the tests relied on interacting with the new theme blocks, numerous enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. requests were raised to improve the experience of using each. Rather than listing this under improving the settings experience, this felt worthy of a separate call out as leveling up these individual theme blocks will unlock more creative power in using these new features. Whether folks wanted more styling options in the Post Title block or to easily add pages in bulk to the Navigation block, people are already looking forward to the next version of these various blocks.
Increase usability of overall experience
This is a “catch-all” category but an important one nonetheless, as it will help various parts of the site editing experience become more intuitive and streamlined. Similar to last time, what follows is a sampling of items both to get a sense of the kinds of issues raised and the spread:
After a few months and a few rounds of testing for the Full Site Editing Outreach Program, this post summarizes the top pieces of feedback of the current experience to help inform ongoing efforts for an MVPMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia. Keep in mind that this post is simply a snapshot in time and is inherently going to leave out aspects of the experience that haven’t been the subject of calls for testing yet, for example, Global Styles. If you want a more in-depth look at feedback across the testing calls and a full summary of all issues rather than a sampling, please review the summary posts. If you want to help give feedback, join the calls for testing or test whenever you’d like.
While the saving experience was reliable technically and generally intuitive, it has left a lot to be desired and resulted in a fair bit of confusion around expected behavior. This is likely because multi-entity saving (saving multiple aspects at once) is a new WordPress concept and one that underpins every interaction in the Site Editor. Whether it was mentioning desired features, finding bugs, or confusion around how to accomplish a task, this proved to be a robust area of feedback.
The distinction between editing the entire site vs. specific content
Similar to the saving process feedback, this is another area where features technically work but are difficult to distinguish across the experience. For example, one can edit a template directly, but it’s not always clear when one is editing a template or editing an item of content. Beyond just clarity in what one is editing, there needs to be the right amount of friction when switching between content that impacts the entire site vs. content on an individual post/page. This is an area of active iteration and exploration to get the right amount of friction in place, as you can see in open issues like this one around clarifying template vs. content editing, and this one around refining the experience of editing a template part in isolation.
Currently, alignment in Full Site Editing works to optimize traditional themes that provide their own alignment styles. This approach has served the project well until this point, but it’s a key area to reconsider to ensure a true and reliable WYSIWYGWhat You See Is What You GetWhat You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. experience. Thankfully, work is already underway in an important PR by @youknowriad to reimagine how this dynamic should allow for more control over alignments/widths when using the Site Editor.
General Usability Improvements
As this work moves into a place of refinement, there are numerous enhancements to consider to improve overall usability of the Site Editor. This is a “catch-all” categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. but an important one nonetheless, as it will help the Site Editor experience move from functional to delightful. What follows is a sampling of items both to get a sense of the kinds of issues raised and the spread:
Placeholders for some of the newer blocks in the site editing experience prove to be both a powerful way to guide people and a point of confusion. This feedback mainly came into play with blocks like the Query Block (including 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. variations like Posts Lists), Social Icon Block, Featured Image Block, and the Navigation Block. Each currently gets users started in different ways. In the long run, it seems that users will benefit from a standardized, consistent way to interact with placeholder content across all blocks. This is particularly important when viewed through the context of editing a template where you might mostly see placeholder content.