Test Chat Summary: 7 May 2024

On Tuesday, 7 May 2024 at 14:00 GMT +3, <test-chat> started in #core-test facilitated by @nhrrob. The agenda can be found here.

Attendance: @webtechpooja, @shiponkarmakar, @sumitbagthariya16, @zunaid321, @hage, @nhrrob, @hitendra-chopda, @monikarao, @lumiblog, @pooja9712, @rcreators, @krupajnanda, @voboghure, @devmuhib, @pbearne, @devsahadat.

1. Looking for Volunteer

  • Next meeting Note Taker – Looking for Volunteer.
  • Next meeting facilitator – @lumiblog

2. Announcements 📣

3. Test Team Updates

4. Focal Group Updates

5. Questions/Blockers

6. Call for Testers/Visibility

  • 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/ 18.3 is scheduled for May 8 and will include these issues.

7. Open Floor

@webtechpooja acknowledged @zunaid321 for facilitating the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-Test team table at WordCamp Sylhet 2024. @nhrrob also praised @zunaid321 on his recent involvement in the recent releases. 

@webtechpooja provided guidance on joining the Core Test team to @devsahadat who had asked how to join core-test, contribute and earn a Test Contributor badge.  She also shared the link to core handbook where one could learn more about testing. 

@nhrrob announced the impending release of WordPress 6.5.3 and encouraged participation in the release parties. 

@webtechpooja shared information on data liberation and WordPress Playground usage

The conversation shifted to holiday plans, with @shiponkarmakar mentioning Buddha Purnima/Vesak which is to be on 23rd May, and @nhrrob discussing Mother’s Day celebrations, 12th May. 

@pbearne raised questions about finishing @covers for tests and shared resources on PHPUnit annotations

@webtechpooja updated on changes to @covers and discussed plans for addressing them, involving the core team. 

@ironprogrammer informed @pbearne about the significant changes required to prepare for PHPUnit 10/11. He suggested revisiting plans to avoid potential rework and shared a link to a relevant ticket on WordPress TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. for further reference.

The discussion concluded with @pbearne and @webtechpooja agreeing to await further input before finalizing plans for the core test meeting.

8. Next Meeting 🗓

Next meeting will be on Tuesday, May 21, 2024 at 04:30 PM GMT+5:30, held on #core-test! </test-chat>

If anyone wants to take notes in the next meeting, please feel free to comment in this thread.

Thank you, @webtechpooja, for the peer review of this post.

#core-test, #gutenberg, #meeting-notes

Early opportunities to Test WordPress 6.6

Ahead of 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, let’s get testing for 6.6! What follows below are items pulled from the 6.6 roadmap that are ready for feedback and to be explored. The steps below are meant to kick off exploring and testing rather than to be overly prescriptive so please test further. Expect a more comprehensive post to come when we reach the beta period and more features are ready. To learn more about each feature, please refer to the 6.6 roadmap as this post is dedicated to testing items rather than explaining them in full. 

Testing setup

For testing each of these items, you can either use this Playground link to get started quickly or  set up your own test site with the latest version of 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/ and the noted experiments below enabled.

Data Views

Data Views is the new and improved experience of navigating and viewing information in the Site Editor as part of the groundwork for phase 3. This release focuses on bringing a new side by side layout, consolidating patterns and template part management, surfacing general management views sooner across the experience for easier access, and a wide range of refinements. 

Testing instructions

  1. Open Appearance > Editor and select Pages.
  2. In this view, you’ll see the new layout called “list” that shows a side by side view. 
  3. Underneath “Add New Page” select the View Options icon. 
  4. Change the layout of the view by selecting “Layout” and explore changing other options, like sort by or what fields are displayed. 
  5. Click the back arrow to return to the overall Design section and select “Templates”.
  6. Underneath the “Add New Template” select the View Options icon. 
  7. Change the layout of the view by selecting “Layout” and explore changing other options, like sort by or what fields are displayed. 
  8. Click the chevron back arrow to return to the overall Design section and select “Patterns”.
  9. Explore creating new patterns and template parts before exploring how the two are presented in the same section. For example, view the “All template parts” and “All patterns”, try using different sorting options, and different layouts. 

You can continue testing as you see fit by creating different types of content (patterns, template parts, templates, and pages in various states) and changing how that content is then displayed in each management section (Patterns, Templates, Pages). 

Overrides in synced patterns

Building upon the power of synced patterns, overrides allow you to ensure a synced layout and style across patterns while enabling each instance of the pattern to have customized content. This provides consistency in design across different pieces of content. For instance, consider a user creating a ‘Recipe’ pattern. With the enhanced feature, the user can insert this pattern into multiple posts, ensuring that the layout and styling components, such as the overall design of the recipe card, remain consistent across instances. Meanwhile, the content, such as Ingredients and Steps, would be local to each post, allowing for individual customization. Additionally, folks would then be able to revisit and modify the design of the recipe pattern without affecting the content in existing instances.

Testing instructions

Create a synced pattern with overrides

  1. Create a new post.
  2. Insert a mixture of blocks that include paragraphs, headings, buttons, images, and optionally other blocks too.
  3. Select the blocks, and ‘Create a pattern’ 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. options menu.
  4. Give the pattern a name and make it ‘synced’.
  5. Once the pattern has been created, note that the content is locked and uneditable.
  6. Click the ‘Edit original’ button on the toolbar, this will take you into an isolated view for editing the pattern.
  7. Select a paragraph block in the pattern, and in the block settings sidebarSidebar A 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. expand the Advanced section. Check the ‘Enable overrides’ option and give the override a name.
  8. Set overrides for a few blocks within the pattern, ideally including a heading, paragraph, button, and image block.  
  9. Use the ‘Back’ button in the headerHeader The 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. area of the editor to go back to the post.

Editing the instances

  1. Select the pattern and duplicate it.
  2. Now click the paragraphs for which you checked ‘Enable overrides’ and notice you can edit them. The updates don’t sync across instances of the pattern; the changes are local to the pattern.
  3. View the post, the frontend should match the editor.

Add the pattern with overrides to another page

  1. Create a new page and add the newly created pattern with overrides to it.
  2. Make local changes to the pattern based on what blocks are able to be overridden. 
  3. Hit save when done.
  4. Click the ‘Edit original’ button on the toolbar, this will take you into an isolated view for editing the pattern.

Remove override option

  1. Select one of the blocks with overrides turned on and in the block settings sidebar expand the Advanced section.
  2. Select “Disable overrides” and confirm your choice in the warning modal (read the modal and give feedback!). 
  3. Select save and use the ‘Back’ button in the header area of the editor to go back to the page.
  4. Confirm you can no longer edit the previous override that was just disabled and that the content matches the original pattern once more.

Zoom out view

A few different initiatives are coming together to allow one to focus on building with patterns rather than granular block editing, including advancing contentOnly editing and zoomed out view. Taken together, this work aims to offer a first step towards a new way to interact with and build with patterns. What follows below are ways to test and invoke this new zoomed out view. 

Testing instructions

Explore zoomed out with Style variations

  1. Open Appearance > Editor to open the Site Editor.
  2. Select the canvas to begin editing the blog home template.
  3. Open Styles and select “Browse styles” to open up the various style variation options. This will cause the zoom out view to automatically appear. 
  4. Scroll through different style options and explore what it’s like to enter and leave the zoomed out view (turn on/off the Style book, style blocks and return to the variations, etc). 

Build with patterns

  1. Click the chevron back arrow to return to the overall Design section. 
  2. Select Pages and “Add new page” to create a new page.
  3. Give the page a title and select “Create draft”.
  4. Close out of the pattern selection modal.
  5. Open the Inserter and navigate to the Patterns tab. 
  6. Go through different categories of Patterns and notice that upon viewing a specific categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., the canvas is zoomed out for a broader view.
  7. Add a few patterns to the page. Remember that you can drag and drop a pattern or click to add. 
  8. Click the chevron back arrow to return to the Manage pages section and edit a current page with content (you may need to create this). 
  9. Open the Inserter and navigate to the Patterns tab to explore adding a pattern to current content (are you able to place it where you want?). 

Unified and refreshed publish flowFlow Flow is the path of screens and interactions taken to accomplish a task. It’s an experience vector. Flow is also a feeling. It’s being unselfconscious and in the zone. Flow is what happens when difficulties are removed and you are freed to pursue an activity without forming intentions. You just do it.
Flow is the actual user experience, in many ways. If you like, you can think of flow as a really comprehensive set of user stories. When you think about user flow, you’re thinking about exactly how a user will perform the tasks allowed by your product.Flow and Context

The publish flows for both the post and site editor have been unified, bringing with it a new design and experience. Because publishing is such a critical part of the WordPress experience, it’s a key part to explore and find the edges of. 

Testing instructions

Create a page in the Site Editor

  1. Open Appearance > Editor to open the Site Editor. 
  2. Select Pages and “Add new page” to create a new page.
  3. Add some content and publish the page by changing the options in Block Settings under Page. 
  4. Please test further by adding a featured imageFeatured image A 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., changing the author, changing the date, etc. 

Create a post with the Post Editor

  1. Open the command palette with either Cmd+k on Mac or Ctrl+k on Windows and type “Add new post” before selecting the option that matches. 
  2. This will take you to a new post in the Post Editor.
  3. Repeat the process of adding some content and publishing.  
  4. Please test further by adding a featured image, changing the author, changing the date, adding categories, adding tags, setting an excerptExcerpt An 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., etc. 

You can continue testing as you see fit by going through the publish flow in each experience again, testing against different plugins, editing the template used, and exploring different post/page states (draft, pending, private, etc). 

Mix and match typography and color palettes from all styles variations 

Style variations allow you to change the look and feel of your site, all while using the same theme. To build on the design possibilities of a block theme with style variations, 6.6 aims to add the ability to mix and match the color and typography styles of each individual style variation. 

Testing instructions

  1. Open Appearance > Editor to open the Site Editor. 
  2. Select Styles and, upon scrolling down, notice there are now Color and Typography sections split out separately from the overall style variations.
  3. Mix and match different style options. For example, pick a style variation and then below change the typography used or select your own color and typography combination.
  4. Select “Save” below to save changes.
  5. From there, click on the canvas to edit the template directly.
  6. Open the Style icon in the top right corner (if it’s not open). 
  7. Select “Blocks” and make a few changes to individual blocks globally, like Buttons or Image blocks.
  8. From there, use the chevron back arrow to return to the main styling view and select Typography. 
  9. Notice how there’s now a section called “Presets” where you can select between different typography options. Make a new selection.
  10. From there, use the chevron back arrow to return to the main styling view and select Colors. 
  11. Notice how there’s now a section called “Presets” where you can select between different color options. Make a new selection.

You can continue testing as you see fit by making additional style changes, like changing the color palette of a color preset, or trying to roll back between different revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.

Grid layout

If you are using your own testing setup, you will need to enable the Grid Interactivity experiment by going to Gutenberg > Experiments. 

Grid is a new layout variation for the Group block that allows you to display the blocks within the group as a grid, offering new flexibility. There are two options for the Grid layout:

  • “Auto” generates the grid rows and columns automatically using a minimum width for each item. 
  • “Manual” allows specifying the exact number of columns.

This unlocks new layout possibilities that are prime for testing. 

Testing instructions

  1. Open Appearance > Editor to open the Site Editor. 
  2. Select Pages and “Add new page” to create a new page.
  3. Add a grid block. 
  4. Explore adding 3-5 blocks within the grid. For example, a set of headers or images or some combination.
  5. Use the drag handles on an individual block to change the row and column span. Try this a few times! If you are using your own test site and don’t see this option, please make sure you have enabled the Grid Interactivity experiment by going to Gutenberg > Experiments. 
  6. Select the overall grid block and open block settings.
  7. Under “Layout”, explore changing the various options between manual and auto, along with minimum column width.
  8. Return the settings to auto and change the column span of a few of the items either by using the drag handles or through the block settings under Dimensions for each individual item. 
  9. Once done, use the preview option to preview the grid layout in different screen sizes to check whether the layout remains responsive. 
  10. Continue making changes: add new blocks, change the column and row span, transform into/out of grid, etc. 

Note: The only responsive styles in place for Grid are when there are multi-column spans in auto mode which is why there are intentional steps to test this in steps 8 & 9. 

New patterns experience for Classic themes

After adding easy access to patterns with a new Patterns tab under Appearance, Classic themes are slated to have access to the pattern experience baked into the Site Editor in this release. This will provide an upgraded, modern experience of managing and creating patterns, including all of the work that’s gone into data views.

Testing instructions

Create some patterns

  1. Open Appearance > Editor to open the Site Editor. 
  2. Select Patterns and create a few patterns. As a tip to move quickly, you can always create a pattern and add in a current pattern from Inserter with a few customizations to make it your own. 
  3. Return to the admin dashboard by clicking the back chevron twice. 

Switch to a Classic theme

  1. Open Appearance > Themes.
  2. Install and activate a Classic theme. For example, Twenty Twenty-One or Twenty Twenty. 
  3. After activating, open Appearance > Patterns. You should see a more confined Patterns experience matching what you’d find in the Site Editor.
  4. Create a new pattern in this new experience and publish it. Ensure it shows up correctly. 

Access new patterns page

  1. Return to the admin dashboard by clicking the back chevron twice and create a new post under Posts > Add New. 
  2. Within this post, open the command palette with either Cmd+k on Mac or Ctrl+k on Windows and search for “Patterns”. Ensure it takes you to this new patterns experience. 
  3. Return to the post, open options and select “Manage patterns”. Ensure it takes you to this new patterns experience.
  4. Return to the post, create or insert a synced pattern and, select the three dot menu in the block toolbar and choose “Manage patterns”. Ensure it takes you to this new patterns experience.

Negative margins

A long-requested feature has finally arrived: you can now set negative margin values. As a guardrail, this option can only be added manually to prevent people from accidentally adding negative values they didn’t intend using the slider control. 

Testing instructions

Margin support is included on the following commonly used blocks: Group, Paragraph, Columns, Code, Cover, Separator, Spacer, Gallery. For a full list, please refer to this chart

  1. Open Page > Add New. 
  2. Open the Inserter > Patterns and add a few patterns. 
  3. Select or add blocks with margin support within those patterns. 
  4. Open block settings > open the styling section > head to Dimension settings.
  5. In the margin controls, manually enter a negative number and try making a few changes. 
  6. Publish and view on the front end to ensure it matches the editor. 
  7. Repeat this process with more blocks!

Rollback autoupdates

Please follow the testing instructions outlined in this merge proposal post:

There are no known issues directly related to Rollback Auto-Update that don’t currently exist in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. I (@afragen) have been testing using the test plugin. The 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 is on a test site, active, and set to auto-update. I have been running like this since the beginning of the year using the PR and on other sites for several years using the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins..

  1. Install the PR into WP 6.5.x or trunk.
  2. Install version 0.1 of the test plugin.
  3. Activate the test plugin and enable auto-updates.

The 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/ update 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. will serve the version 0.2 version of the plugin, which will cause a PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. fatal error. To confirm a rollback is successful, data is written to the error.log at every point in the auto-update process, creating an audit trail the user can use to discern the flow and results of rolling back an auto-update. This logging is only intended for testing purposes.

What to notice:

  • Did the experience crash at any point?
  • Did the saving experience work properly? 
  • What did you find particularly confusing or frustrating about the experience?
  • What did you especially enjoy or appreciate about the experience? 
  • What would have made this experience easier for site building and for writing new content?
  • Did you find that what you created matched what you saw on your site?
  • Did it work using Keyboard only?
  • Did it work using a screen reader?
  • Did it work while using just a mobile device?

Where to report feedback

As much as possible, please report issues directly in the Gutenberg GitHub repository for every feature except the rollback autoupdates which needs issues opened in Trac. In both cases, please check first to see if an issue is already open. If you are unsure of whether to report or are blocked for any reason, just leave a comment on this post and I’ll follow up to help ensure feedback gets to the right place. 

Leave feedback by June 4th, 2024

This lines up with the launch of beta 1, when a new testing post will be available with more features to explore.

#6-6, #gutenberg

Early Opportunities to Test WordPress 6.5

Ahead of 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 for WordPress 6.5 on February 13th, this is an early opportunity to provide feedback as features are rapidly underway. Of note, this is intentionally just a selection of what’s ready to test and doesn’t include everything mentioned in the roadmap. Expect a broader testing post, like this for 6.4, for the release once beta 1 is out in the world. 

Note: this post currently mentions setting up a test site with Gutenberg 17.5 RC1. This post will be updated once 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/ 17.5 is released on Jan 17th, 2024. 

New data views in the Site Editor

About the feature

This work kicks off aspects of the WP Admin Redesign efforts in an iterative and contained way by bringing a new experience to the template, template part, and pattern lists in the Site Editor. Right now, the following features are slated for inclusion:

  • Ability to display a table with specific fields, pagination and quick actions.
  • UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. for toggling fields and for sorting and filtering data by field.
  • UI for selecting entries and performing bulk actions.
  • Support for different layouts, like classic table, grid view (including gallery), with the option to display a side-by-side preview.
  • Support for saving and toggling between “views”, which are specific configurations of layouts, field visibility, etc.

For this early testing opportunity, not everything is yet in place. 

Prerequisites

There are a few different environments that can be used for testing. Pick one to use:

The experiment for ‘new admin views’ will also need to be switched on from the 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 experiments page (wp-admin/admin.php?page=gutenberg-experiments).

Testing instructions

Here are some suggestions for functionality to test, but you are encouraged to experiment beyond these. 

Templates

  1. Open Appearance > Editor and select Templates.
  2. From the list, select “Manage all templates”.
  3. In this view, you’ll see the new experience. 
  4. In the upper right corner under “Add New Template” select the View Options icon.
  5. Change the layout of the view by selecting “Layout” and try selecting different items.
  6. Change the “Sort By” option. 
  7. Change what fields are shown by selecting different options under “Fields”.
  8. Change how many items are displayed with the “Rows per page” option to 10 and try using the pagination.
  9. Add a filterFilter Filters 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. and reset it. Here’s a screenshot for guidance.
  10. Use the search box to search for “full width” (this is only available if you use InstaWP, otherwise create your own custom template), use the three dot menu to rename it before deleting it outright. 

Patterns

  1. Open Appearance > Editor and select Patterns.
  2. In this view, you’ll see the new experience. 
  3. In the upper right corner select the View Options icon.
  4. Change the “Sort By” option. 
  5. Change what fields are shown by selecting different options under “Fields” and enabling sync status. 
  6. Change how many items are displayed with the “Rows per page” option to 10 and try using the pagination.
  7. Add a filter to sort by synced or not synced and reset it. Here’s a screenshot for guidance.
  8. Use the search box to search for a pattern and use the three dot menu to duplicate it. 

Pages

  1. Open Appearance > Editor and select Pages.
  2. In this view, you’ll see the new experience. 
  3. Underneath “Add New Page” select the View Options icon. 
  4. Change the layout of the view by selecting “Layout”.
  5. Change the “Sort By” option. Note that there are pages in different stages of publication (draft, private, published) and two users on the site if you are using the InstaWP instance.
  6. Change what fields are shown by selecting different options under “Fields”.
  7. Change how many items are displayed with the “Rows per page” option to 10 and try using the pagination.
  8. Add a filter to sort by author and status. Here’s a screenshot for guidance. Note that there are pages in different stages of publication (draft, private, published) and two users on the site if you are using the InstaWP instance.
  9. Use the search box to search for the “About Me” page and use the three dot menu to view it. 
  10. On the left hand side under “Custom Views”, select the “+ New view” option to add a custom view.
  11. Name the view and select “Create”. From there, customize it to your liking.
  12. Select “Review 1 change” and save to ensure this view saves.
  13. Leave the Site Editor and return to ensure the view remains.

Pattern Overrides

About the feature

Building upon the power of synced patterns, pattern overrides allows you to ensure a synced layout and style across patterns while enabling each instance of the pattern to have customized content. This provides consistency in design across different pieces of content. For instance, consider a user creating a ‘Recipe’ pattern. With the enhanced feature, the user can insert this pattern into multiple posts, ensuring that the layout and styling components, such as the overall design of the recipe card, remain consistent across instances. Meanwhile, the content, such as Ingredients and Steps, would be local to each post, allowing for individual customization. Additionally, folks would then be able to revisit and modify the design of the recipe pattern without affecting the content in existing instances.

Prerequisites

There are a few different environments that can be used for testing. Pick one to use:

The experiment for ‘pattern overrides’ will also need to be switched on from the Gutenberg plugin experiments page (wp-admin/admin.php?page=gutenberg-experiments).

Testing instructions

Create a synced pattern with overrides

  1. Create a new post
  2. Insert a mixture of blocks that include paragraphs and optionally other blocks too
  3. Select the blocks, and ‘Create a pattern’ 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. options menu
  4. Give the pattern a name and make it ‘synced’
  5. Once the pattern has been created, note that the content is locked and uneditable
  6. Click the ‘Edit original’ button on the toolbar, this will take you into an isolated view for editing the pattern
  7. Select a paragraph block in the pattern, and in the block settings sidebarSidebar A 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. expand the advanced section. Check the ‘Allow instance overrides’ option
  8. Use the ‘Back’ button in the headerHeader The 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. area of the editor to go back to the post

Editing the instances

  1. Select the pattern and duplicate it
  2. Now click the paragraphs that you checked ‘Allow instance overrides’ for and notice you can edit them, and the updates don’t sync across instances of the pattern, the changes are local to the pattern
  3. View the post, the frontend should match the editor

Robust RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. 

About the feature

Templates and template parts will now show revisions, alongside broader upgrades to style revisions with more detailed descriptions, pagination, and the ability to view revisions with the Style Book enabled. 

Prerequisites

There are a few different environments that can be used for testing. Pick one to use:

Testing instructions

To better test this feature, two different prebuilt options are offered, with one containing a large number of revisions already and one completely fresh. See Prerequisites above for more information and please consider testing both scenarios!

For styles:

  1. Open Appearance > Editor and select Styles.
  2. Make a few changes to Styles and save your changes in between each change. For example, add some custom colors, change block specific styling, and switch to a new style variation. 
  3. After a few changes have been saved, open up the Styles panel and select the revisions icon. 
  4. Select a prior version and notice the description of the revision. 
  5. While selecting the prior version, toggle on the Style Book and explore that view. 
  6. Roll back to a prior version. 
  7. Make more changes to Styles, saving each time, and repeat the process until you see pagination in the style revisions if you’re using the fresh install.
  8. Try going to different pages of revisions and ensure you can roll back. 

For templates and template parts:

  1. Open Appearance > Editor and select a template. 
  2. Make a few changes to the template and save changes in between each change. For example, remove blocks, change block alignments, add blocks, change the order, etc. 
  3. Open block settings and 

Font Library

About the feature

The Font Library makes it easy for anyone to install, remove, and activate fonts across your site. It’s available globally, independent of the theme activated, similar to the Media Library. Any installed font, whether installed by a user or a theme, can then be selected across the editing experience.

Prerequisites

There are a few different environments that can be used for testing. Pick one to use:

Testing actions

Pulling from this prior dedicated post on this same feature, here are some suggestions for functionality to test, but you are encouraged to experiment beyond these:

  • Upload fonts using the upload dialog and drag-and-drop.
  • Install fonts from Google Fonts using the Install Fonts tab.
  • Verify that uploaded/installed font assets are stored in your site’s /wp-content/fonts/ directory.
  • Activate/deactivate individual font variants.
  • Compare active fonts with the list on the Styles > Typography sidebar.
  • Assign custom fonts to elements (like text or headings) on the Styles > Typography sidebar.
  • Assign custom fonts to specific block types (like buttons) in Styles > Blocks.
  • Check how the fonts appear on your site’s frontend.
  • Delete an uploaded font family, and verify that the font assets are removed from /wp-content/fonts/.

Additional technical feedback opportunities

Reporting bugs and enhancements 

Please report all bugs and enhancements in the Gutenberg GitHub repository. Thanks so much for helping test what’s to come in 6.5 early and often. Please note that both bugs and enhancements to improve current functionality are greatly appreciated and welcomed. 

If anything is amiss with this post or you’re having trouble contributing, please comment below or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me, @annezazu, in 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/ slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

#6-5, #gutenberg, #site-editor

Help Test the Comments Blocks for WordPress 6.0

The previously monolithic “Post Comments” 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. has been updated to work in a more flexible and modular way by using child blocks. The new version is now called the “Comments Query LoopLoop The 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, and it comes with new blocks that can be used as child blocks within it. These new Comments blocks allow users to define and change the layout of the post comments directly from 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/ editor.

Table of Contents

Help test this feature

This post is a call for users to test the new blocks that can be used to build a  comments section in a page or post (following the block paradigm). The results of this  testing will allow the contributors behind the development of these blocks to decide whether or not they are ready to be included in the next release of WordPress (v6.0) 

Please report your findings either as issues 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/ in the Gutenberg repository ,or in the comments below. If you have triage access, labelling any issue with “[Block] Comments Query Loop” would be very helpful. Alternatively, you can start the title of your issue with “Comments Blocks: ” to help those triaging the issues to label them appropriately. 

How comments currently work in Full Site Editing

The “Post Comments” block is the block that currently manages a comments section on a post or page, 

For example, the Twenty-Twenty-Two  theme uses this block in its “Single Post” template

But with this “Post Comments” block no option exists to change the styles and the layout of the comments from within the Editor. This block uses the comments_template() function internally to generate the HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. for that section and the styles are defined via CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. files.

So, in summary, if you want to customize your comments section (change styles and layout) when using this “Post Comments” block you have to do a bit of coding

What’s new?

With the new Comments Query Loop block, you now have available a set of child blocks that enable you to customize the layout and styles of this section directly from within the Editor.

The new Comments Blocks that are available from Gutenberg v13.0 are:

  • Comments Query Loop: An advanced block that  displays  post comments and allows for various layouts and  configurations.
    • Comment Template: Contains the block elements used to display a comment, such as  the title, date, author, avatarAvatar An 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. and more.
    • Comments Pagination: Displays next/previous links to paginated comments where this has been enabled in the comment settings in the WordPress admin
      • Previous Page: Displays the link to the previous page of comments.
      • Page Numbers: Displays a list of page numbers for comments pagination.
      • Next Page: Displays the link to the next page of comments.

The addition of these blocks to Gutenberg is just the beginning. With these blocks, in the future you will be able to create and share your own patterns for a comments section.

Testing Environment 

While there’s more information below to ensure you get everything set up properly, here are the key things to consider with regard to your testing environment: 

Testing Instructions

Set proper 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 and themes

  1. Have a test site using the latest version of WordPress (5.9.3 at time of writing). It’s important that this is not a production/live site. 
  2. Install and activate the Twenty Twenty-Two theme by going to Appearances > Themes. If you choose to use a different block theme, install and activate by going to Appearances > Themes > Add New and searching for the one that has the `Full Site Editing`  listed as a feature. 
  3. Install and activate Gutenberg 13.0 RC

Customize the “Single Post” template to use the new “Comments Query Loop” block

  1. Go to the “Single Post” template by:
    1. Going to Appearance > Editor
    2. From the Template Editor click on the drop down menu in top centre  to choose the template to Edit (“Home” template selected by default)
    3. From that menú: “Browse all templates” & select “Single Post”
  2. Remove the “Post Comments” block that you’ll find at the bottom with the text “Post comments block: no post found” 
  3. Insert in that same place the “Comments Query Loop” block
  4. Save the “Single Post” template with this new “Comments Query Loop” block inserted

Customize the Comments blocks styles and layouts and check the result of your changes in the frontend

In order to ensure you have comments to play with you can add demo content to your WordPress

  1. Go to the homepage of your testing site and go to the default “Hello world!” post to check how the Comments section looks by default with these new Comments blocks. You can also create a new post by going to Posts > Add 
  2. Go to the “Single Post” template and configure each comments block to set the styles and layout you want
  3. Save the template and go to the post page to see your changes in the frontend (you’ll probably need to refresh the post’s page)
  4. Repeat this process as many times as you want and take note of any bug or User Experience inconsistency you encounter during the process

Insert the “Post Comments Form” block to check the behavior of the Comment Reply Link and the ability to insert new comments

The “Post Comments Form” cannot itself be customised via the Block Editor as yet. There’s an issue open to work on this but for the purpose of this testing we can just use it as it is and focus the testing on the display of the comments

  1. Go to the “Single Post” template and insert a “Post Comments Form” just after  the “Comments Pagination” block
  2. Save the template and go to the post page to see if the form is available from that page (you’ll probably need to refresh the post’s page)
  3. Submit a new comment and check whether the new comment appears and whether the styles you defined for the Comments blocks are also applied to this new comment
  4. Check that the ”Comment Reply Link” and “Comment Edit Link” work properly 
  5. Take note of any bug or User Experience inconsistency you detect in the process

What to test

So, what type of things can you test with these blocks?

This Call for Testing is mainly to check that these blocks work as expected, that is, the changes in the styles and layout work as expected without bugs.

But just to provide some guidance, here are some aspects we specifically would like to have some feedback about:

Styles and Layout

Try to replicate a specific design on your comments section and check that you’re able to implement that design using just  the Block Editor. For example you could try to apply a Duotone filterFilter Filters 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 the Avatar, or perhaps a two column layout with the avatar on the left and rest of the content on the right – let your imagination run wild!

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)

Check that the comments section is fully accessible in both the Editor and the Frontend and report any issues you find in this regard.

Discussion Settings

Go to Settings > Discussion and check that the different options are fully compatible with the new Comments blocks (i.e. that they work as expected according to the options that have been enabled/disabled).

Pagination Links

Test that the pagination links work as expected. To test this you’ll need enough comments for the comments to actually paginate. Comment pagination also needs to be enabled in the WordPress admin under Settings -> Discussion -> Break comments into pages

Thank you!

Thank you for helping to test these new Comments Blocks! With the adoption of Full Site Editing, bringing the power and flexibility of blocks to more parts of the page  is really helpful in enabling  users to customise their layouts and take full control of their sites.

Thanks to @mburridge @cbravobernal @santosguillamot for reviewing and helping shape this post

#call-for-testing, #gutenberg

Proposal: Migrate e2e to Playwright!

Howdy, good people! 👋

In the spirit of improving the E2E developer experience, I’d like to make a case for migrating CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s browser automation library to Playwright. I was asked to write this post after opening an experimental pull request, where I migrated a selected portion of specs to Playwright, making them available for running both locally and on CI. That happened some time ago, so there’s already been quite a bit of discussion going on there! Having said that, I’m going to try making the case again here, taking the feedback I’ve received so far into consideration. I also encourage you to check out the PR to see the implementation details and Playwright advantages in action.

Why drop Puppeteer in favor of Playwright?

It’s easier to write stable tests.

There are a few reasons why. Please read on to find out which ones I think are the most relevant for the project.

The 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.

Playwright’s API is almost identical to Puppeteer’s, which means that the developer transition should be close to effortless. I think that’s a big factor here, as it significantly lowers the cost of this transition also from the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. side. A good thing to start with! 🤞

The Auto-Waiting Mechanism

From the documentation:

Playwright performs a range of actionability checks on the elements before making actions to ensure these actions behave as expected. It auto-waits for all the relevant checks to pass and only then performs the requested action. (…)

I think it’s the number one reason for the stability improvement over Puppeteer. In practice, it means the following:

No need to perform any additional presence checks

Most of the DOM changes happen asynchronously, so in order to avoid flaky behavior, a test usually explicitly wait for an element before performing an action on it. A good example would be the most frequently used click action, which usually looks like this when performed with Puppeteer:

const button = await page.waitForSelector( 'button' );
await button.click();

With Playwright, thanks to the auto-waiting mechanism it becomes just:

await page.click( 'button' )

No need to disable CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. animations

This is thanks to the stability check, which makes sure the element has a bounding box and is not moving before the action is performed. I think this is a major advantage because it allows to fully test the application, including the CSS animations, which are an integral part of the user interface.

In my PR, as a proof of concept, I removed the code that disables CSS animations and the forced reduced motion, which slowed down the refactored tests (21 suites) by around 37 seconds. This number will grow with every test, but judging by the current data it shouldn’t be more than a few minutes in total. I’d say the trade-off would still be worth it, but this can be discussed and decided upon later.

What do you think about testing without animations? Should they be enabled if it’s possible, even for the cost of extra wait?

Less code!

In general, all of the above comes down to writing less and simpler code to get the same or better results than Puppeteer. If you go to my PR, you’ll notice that there are more lines removed than added in the refactored tests!

With Playwright, the tests and test utilities are easier to write and follow, and the environment requires less customization (e.g. disabled animations) which actually makes it closer to what users are experiencing.

Are there any downsides to the auto-waiting mechanism?

There were some concerns about how this mechanism could affect the performance tests. Because it could potentially become a blocking factor for this migration, I decided to migrate Gutenberg’s performance specs to Playwright as a proof of concept and see what happens. So far, thankfully it looks like there isn’t much difference between Puppeteer and Playwright — the performance metrics are very close, which would be the desired outcome.

Do you think there could be any downsides to the auto-waiting mechanism? Please let me know in the comments!

The Advanced Selectors Support

This part has changed a bit due to some feedback received in the PR. Originally, I mentioned text selectors and layout-based selectors as the number one reason for making the tests and utilities easier to write and follow, as well as making them more resilient. While prioritizing user-facing attributes is still a good practice for most applications, 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/ is a bit different in this regard. Apparently, CSS classes are considered to be the API there, so they change less often than the user interface. Nevertheless, as some folks noticed advanced selectors are still a big win as they’d allow to, e.g. drop the use of cumbersome XPath selectors and more with powerful selector chaining. Currently, with Puppeteer, CSS selectors can only be used.

Learn more about Playwright’s advanced selectors from https://playwright.dev/docs/selectors.

The Debugging

Inspector

The built-in Inspector is also a big advantage of Playwright. It’s quite intuitive and has some neat features like stepping through the script while running headfully or dynamically recording actions to a script — a really convenient way of quickly drafting the test. See the video below for a short demo of the script recorder.

Code generation with Playwright inspector in action 💥

Trace Viewer

Playwright offers a complete tracing solution. Trace can be recorded and stored in a zip file, which then can be viewed via the Trace Viewer GUI:

Viewing a recorded trace in Trace Viewer

On the image above, you can see that the trace is displayed in a form of a film strip. Each frame can contain Before, Action, and After snapshots visualizing a complete action execution. On the left-hand side is a list of all the actions Playwright performed. Each of them can be inspected in more detail in the section on the right-hand side, where you can switch between the action log, location in the source code, and the network log.

I think it’s great to have that kind of functionality out of the box. It also shows how Playwright is intended to be a complete testing solution. With Puppeteer, there aren’t really any first-party tools for debugging, as far as I’m aware – The suggested way is to either slow down the tests in headful mode with DevTools open or use the Node.js Debugger when running headlessly.

Learn more about Playwright’s debugging tools from https://playwright.dev/docs/debug.

The Browser Support

If there’s a goal to expand testing to browsers other than Chrome, it wouldn’t be an issue for Playwright as it supports all other major players: Firefox, WebKit, and Microsoft Edge. At the time of writing this, Puppeteer supports only Chrome and Chromium, and the official support of Firefox is currently experimental.

Learn more about Playwright browser support from https://playwright.dev/docs/browsers.

The Dedicated Test-Runner

Playwright has a first-party test-runner, which is very similar to Jest test-runner (currently used for Puppeteer) but written from scratch. It contains a lot of end-to-end testing utils, tooling, concurrency, reporting, assertions, artifacts, etc., and extensive configuration support. Another quite nice thing to have without having to install and rely on third-party libraries!

Learn more about Playwright Test from https://playwright.dev/docs/intro.

The Documentation

I think it deserves a mention here, as it’s easy to navigate and really well written, in my opinion. Please take a few minutes and check it out for yourself at https://playwright.dev/docs/api/class-playwright – maybe you’ll find even more reasons to switch to Playwright? 😉


Writing good, stable E2E tests is often a struggle. If there’s a chance of improving that, especially with such a low cost, then it should be done. I would be happy to work on this task if there’s a consensus to move it forward.

Thanks for reading. I’m looking forward to all the feedback!

Props to @hellofromtonya and @boniu91 for proofreading!

+make.wordpress.org/core/

#core-test, #gutenberg

FSE Program: Bring your questions – Round Two

With the Go/No Go Next Steps outlined ahead of WordPress 5.8’s release in July 2021, let’s use this time to dig into any general questions you all might have around Full Site Editing! If possible, please focus questions specifically around WordPress 5.8 as those will be the most high impact to address. You are welcome to submit questions using the form below or to leave them as a comment on this post by May 12th

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 the 5.9 release.

Where will you share the answers? 

I’ll share a recap post on this blog (Make Test). Questions will be grouped with corresponding answers for easy review. You can see what the outcome will look like based on the first round here. I will track down answers to every question and share my work as I go by creating a collaborative Google doc where people can help find answers or simply see how the work evolves. I very much welcome collaboration here!

While the main result will be a lovely list of answers, this collective effort will also be useful for future documentation updates and potential tutorials. 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!

For more information about this experimental program, please review this FAQ for helpful details. To properly join the fun, please head to #fse-outreach-experiment in Make Slack for future testing announcements, helpful posts, and more will be shared there. To help with planning your involvement, you can see the upcoming/current schedule for the FSE Outreach Program here.

#fse-outreach-program #full-site-editing #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/ #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor #fse-testing-call

FSE Program Building a Restaurant Header Summary

The fifth call for testing is already underway, so join #fse-outreach-experiment in slack and/or subscribe to this Make blog and stay tuned for more. 

This post is a summary of the fourth call for testing for the experimental FSE outreach program. Thank you to everyone who participated, whether through testing directly or sharing the call for testing with others. It all helps! Special thanks to the following people:

How far can one go?

It’s always fun to see how far people can take these tests in creating something cool without code. Here are a few screenshots of people’s creations that make me hungry just looking at them:  

An image of a restaurant header with palm trees and a beach in the background alongside a menu and a prompt to order online.
 @greenshady’s exploration 
An image of a restaurant header with various types of food pictured and a prompt to order online.
A Yoast Employee’s exploration
An image of a restaurant header with a coupon code, prompt to order online, and an image of the imagined dining room featured.
A Yoast Employee’s exploration

High-Level Feedback

Here’s what a few folks had to say about the overall experience that’s important to keep in mind as you read the rest of this post:

All of this could be because of my inexperience with 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/ the 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. I’m used to working with Astra and other 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. libraries rather than the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks.

@suhayse in this comment

The most problematic issue is that what I saw in the editor was not what I got on the front end. I have played around with it enough to know in my mind what it might look like on the front end to make adjustments without previewing the changes. However, that is not the user experience that WordPress is shooting for.

@greenshady in this WP Tavern post

Most of us were confused by the current UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. and UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. of the full site editing experience. For some of our colleagues, this was the first time using the block editor for a whole day.

@francesca in this Yoast blog post

Repeated Feedback: Improving saving, desire for a preview option, and differences in spacing

As with last time, to better consolidate repeated pieces of feedback, this section only contains new bugs or enhancement requests while still sharing quotes that highlight how these areas continue to be a pain pointPain point Pain points are “places where you know from research or analytics that users are currently getting hung up and have to ask questions, or are likely to abandon the site or app.” — Design for Real Life. In this case, keep in mind that spacing refers to everything from differences between the front end and back end to enhancement requests around setting the width of various blocks. In general, though, it further underscores how the differences in experience between the editor and front end break the promise of WYSIWYGWhat You See Is What You Get What 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. currently. Thankfully, lots of work is underway to continue iterating on this aspect of the experience!

One frustration point was the ability to preview as others have mentioned (the live site definitely looked different from the dashboard preview). When I did view the live site, there wasn’t any margin or padding on the main headerHeader The 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. section but there was on the added column set on the top, even though both were set to full width. I tried changing that main header column width back to wide, saving, then going back to full width but it didn’t help.

@suhayse in this comment

Another thing I noticed was that some small changes, like adjusting the percentage width of the individual columns didn’t activate the “update design” button. 

@suhayse in this comment

I click to Update Design. As there is not yet any simple way to preview on the frontend like we do in the Post/Page screen. I copy the site address url and open a new browser tab and paste it into the new tab to see the frontend. The frontend does not show any margin along the left edge.

@paaljoachim in this comment.

I noticed along the way that the Update Design button was greyed out on occasion when I made some adjustments inside the Cover block and other inner blocks. I had to click into various blocks to get the Design button active again so that I could save. (This seemed a bit hard to track.)

@paaljoachim in this comment.

The site editor makes it looks like there is a small margin all around the full-width header. On the site itself, this isn’t seen. I had set a background color for the full-width header which is edge to edge on the site, but has a margin all around it in the editor.

@kristengunther in this comment.

Columns Block Improvements

Because this call for testing required people to make great use of the Columns Block, it was also the focus of a lot of feedback from various participants. Overall, this feedback mainly came down to two interrelated areas: difficulty navigating between nested blocks and confusion around properly setting width. What follows are the new issues created as a result of this call for testing: 

Testing was smooth overall except when it came to setting the Columns Block to full-width (both in the header and body of the page in the Site Editor). I was unable to set the block to full-width within the Block Toolbar settings. I was able to do this outside of the Site Editor on a fresh page though.  

@synorae in this comment.

I see no visual difference from selecting Wide width or Full width in the backend.

@paaljoachim in this comment.

It’s not clear that the symbol/icon is Full width. It would make sense to have arrows to indicate that it should be full width.

Anonymous Yoast employee in this GitHub issue

I don’t see an option for full width? Ah it’s under alignment. “Alignment” sounds like left/center/right, not the size. What’s the difference between wide and full wide? I don’t see much difference in the preview.

Anonymous Yoast employee in this GitHub issue

Setting Styles

As part of this test, people explored setting various styles to customize their heading to their liking and bring to life the feeling of a restaurant. Similar to the complexity in navigating between nested Column Blocks, though, setting styles proved to be pretty confusing considering how unintuitive it was to figure out how to properly select and then style the section one wanted to. Tied to this, it wasn’t always clear where one could find the setting that would do what they wanted since various settings are spread across the block toolbar and block settings. In some cases, the setting to accomplish something doesn’t exist yet too! As more work is underway to add in more styling options and normalize block level controls in a more intuitive way, this is an area ripe for continued iteration.  

This is global settings vs individual page template settings. It’s pretty confusing right now. I don’t know exactly where I would set universal global header colors. I would expect to be able to do that in the Template Parts/Header but I don’t immediately see how to do that. 

@suhayse in this comment.

I found I had to set the background color for my header 3 times, once for the index template (like in your video), once on the page home template, and once on the page template.

@kristengunther in this comment.

Discoverability of settings, not ideal. Some things are in the popup toolbars, others in the sidebarSidebar A 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. (both in Site Editor and Appearance), other in the top toolbar. You had to find the cog and the Global Style icons to open more settings.

@francina in this comment.

When you are new to this, you are really wondering if you need to find the settings in the list overview left sidebar, or the cogwheel right sidebar or on the block itself, all the options are all over the place.

Anonymous Yoast employee in this GitHub issue

Why does the column change size when changing the color in the settings? At least it definitely seemed like it happened that way. That’s unnecessary and unexpected.

Anonymous Yoast employee in this GitHub issue

General enhancements & feature requests 

As with every call for testing, it’s not just for finding bugs! It’s also important to hear about features that people reach for and find are missing. This section is a “catch-all” to cover all additional features that were reported that didn’t nicely correspond with a particular block or categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.. This only includes new feedback and doesn’t include previous findings from prior tests:

Like the first design I was shooting for, I wanted my Navigation items to look like individual buttons, each with a bit of whitespace in between. However, the Navigation block does not currently support adding backgrounds to each nav item. Even if it did, it also does not have a horizontal margin setting to add the spacing.

@greenshady in this WP Tavern post

Collection of Miscellaneous Bugs

Because this was a more open call for testing, not all bugs fit nicely into a category or theme with many of them being standalone problems. To make it easier for those working on full site editing to get a sense of bugs at a glance, they have all been shared here:

#fse-outreach-program, #fse-testing-summary, #full-site-editing, #gutenberg

FSE Program Build a Homepage Testing Summary

A third call for testing is already underway so join #fse-outreach-experiment in slack and/or subscribe to this Make blog and stay tuned for more. 

This post is a summary of the second call for testing for the experimental FSE outreach program. Thank you to everyone who participated, whether through testing directly or sharing the call for testing with others. It all helps! Special thanks to the following people:

Related feedback is grouped under high-level headings. As you read through it, please remember that feedback is welcome on the format of this post too.

High-level feedback

Here’s what a few folks had to say about the overall experience that’s important to keep in mind as you read the rest of this post:

Everything seemed intuitive for me (long time WordPress dev for whatever it’s worth). I recently did a site for a client in Squarespace, and I appreciated that everything was drag-and-drop and had blocks for all website sections. This full site editor gives that same experience. I think this will be great for empowering non-dev users.

@andystitt829 in this comment.

I did a demo of using FSE in December 2019 at meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. Tokyo. It did “work” then, but felt more of a prototype — kind of alpha or even pre-alpha stage of development. But this latest version is much more smooth, less buggy, and get overall feeling that it has come a long way and shaping up to be a feature.

@toru in this comment.

My main problem with this as a designer is that if we are building structure, don’t try to look like wysiwygWhat You See Is What You Get What 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.. If we are building design, then show it exactly. Current GB UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. isn’t an overlay, so it is pushing the layout completely out of shape. So you get a kind of Picasso view of your website. You have to take a big imagination leap to trust that you are designing this website well. –

@paullacey in this comment.

As you can tell, there’s a diverse set of reactions to this call for testing, which shows how far Full Site Editing has come and how much further it needs to go. 

Adjusting column widths

Adjusting column widths was one of the most mentioned issues that came up as people tried to customize their homepage to their liking! This coincided nicely with an important PR that started as a draft at the beginning of this call for testing and has moved into an open PR with numerous iterations since. As @youknowriad mentions in the PR, alignment in Full Site Editing currently works in a way that’s optimized for traditional themes that provide their own alignment styles. Still, this approach needs to be reconsidered moving forward as it doesn’t allow for a true WYSWYG experience. This leads to the problems described below in comments from some of those who tested: 

I inserted a 70/30 pattern for the Columns 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., then changed the alignment to “Wide”. The Columns block didn’t expand proportionally to fill the available space. When viewed on the front-end, the columns did display as expected.

@chthnc in this comment.

We noticed with columns that we had to assign the width of the block in order for the height of the site logo to align with the site title. We want to expand the width of the body content without using a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. to get closer to edge to edge layouts.

@courane01 in this comment.

I created an image in the SidebarSidebar A 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. that was wider than the column to see if there was any restriction on image width. When I went to view the page, the image had been resized to fit the column width.

@kforbz in this comment.


I really wanted something that was between the theme’s full and wide widths.

@greenshady in this WP Tavern article.

Previewing changes

Like adjusting width, previewing changes came up as a workflow people rely upon and deeply missed in this call for testing. This nicely echoes findings from the first call for testing, where people wanted to preview template changes and expands to previewing the entire site editing experience. Currently, a “Preview Site” option is under discussion here and this post is linked in a comment to ensure feedback makes it to those who explore this further. 

I do not see how to preview the layout on the frontend.

@paaljoachim in this comment.

Yes, but when I am done I don’t find a way to easily go and view my website. I turn off full screen mode and use the more classic view site link in the Dashboard.

@paullacey in this comment.

There were so many inconsistencies between the site editor and the front end that there is little point in listing them all. Spacing was grossly off. I generally see that as a theme issue. I spent much of my time in trial-and-error mode, making an adjustment in the editor and refreshing to see the front-end result. Rinse. Repeat.

@greenshady in this WP Tavern article.

Saving Process: auto drafts, keyboard shortcuts, and more

In line with the last call for testing, the saving process came up as an area people were keen to see iterated. 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: 

When editing, I expect CMD/CTRL + S to save my work. This works in a post/page editing experience. On OS X + Chrome, this prompts me to save the webpage.

@courane01 in this comment.

I can understand why there is a 2-step process here, but every time I clicked “Update Design” it intuitively felt like I shouldn’t have to then click a “Save” button as well.

@chthnc in this comment.

What if I want to save the template as a new template, Template Part as a new template part and not overwrite the existing templates? What if I decide not to save a template part? Can I revert changes by clicking an revert/undo changes checkbox?

@paaljoachim in this comment.

I didn’t experience any auto-saves. When my site crashed, it did not have any autosaves.

@courane01 in this comment.

General Usability Problems

Because this call for testing was more open-ended, this resulted in a wide range of general usability feedback that relate to the overall experience of building a homepage rather than a specific part of the experience. While these items can’t be easily organized and some were reported previously, they are extremely important to keep in mind: 

I see that blocks for FSE are under “design” categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. in the inserter, but I think it’s better to put them in their own category to avoid confusion with non FSE blocks.

@overclokk in this GitHub feedback issue.

I tried to insert a Post Tags block using the ‘/’ command but it didn’t appear as an option. I had to search and find the block via the block inserter panel. –

@chthnc in this comment.

Without the screen shot, I would have not been able to find where or guess which is the Navigation Toggle.

@toru in this comment.

The problem with switching to this mode is that my toolbar-choice was not saved. Each time I returned to the site editor, I had to enable it once again.

@greenshady in this WP Tavern article.

I wish I could put a background image (also in the body of the page), but I haven’t found a way to do it, nor have I been able to set the headerHeader The 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. color different from the rest of the body.

@ejca in this comment.

Individual Site Editing Block Feedback

Since this test relied on exploring Site Editing blocks, great feedback was given about the experience of specific individual blocks. To make it easier to go through, these issues are gathered in this section:

I was trying to size the logo I added using the what appeared to be resize handles. but it did nothing I expected. Eventually I found that the block had settings in the right panel, but I had to look quite hard for this.

@paullacey in this comment.

I inserted a Query block after choosing a pattern. I then changed my mind about the pattern and attempted to undo. Nothing happened.

@chthnc in this comment.

“It wasn’t obvious to me that the Social Icons block then needed to have individual social media blocks added. I couldn’t figure out why they weren’t showing up and looked in the settings and in my user profile to figure out where to add my social media links. I saw social icons in the footer and then clicked on the blocks and saw that the individual icon blocks needed to be added.”

@andystitt829 in this comment.

To me, I feel strange to be told to upload a featured image for each post here. I assume if each featured image are set, then this uploader won’t be shown. Still, I think it feels confusing.

@toru in this comment.

There is no way to set the size of the image output by the Post Featured Image block. The only way to get a uniform size at the moment is to pre-crop the images before uploading them to WordPress.

@greenshady in this WP Tavern article.

#fse-outreach-program #full-site-editing #gutenberg #core-editor #fse-testing-summary

FSE Program Testing Call #3: Create a fun & custom 404 page

This is the third call for testing as part of the Full Site Editing Outreach Program. For more information about this experimental program, please review this FAQ for helpful details. To properly join the fun, please head to #fse-outreach-experiment in Make Slack for future testing announcements, helpful posts, and more will be shared there. 

Feature Overview

Have you ever experienced a particularly delightful 404 page? Maybe it made you laugh or it was built in a way that made it super easy to find your way back to where you needed to be on the site. Currently, this is a part of one’s site that can only be altered with code and provided by the theme causing many of us to be unable to add some extra joy into the universe with helpful, fun 404 pages. 

With Full Site Editing though, this is now within our grasps to make our own. This test explores doing exactly that with the option to build a simple 404 page through template editing or to really dive in to make something unique. If you choose to get super creative, please share a screenshot in your comment so we can all marvel at what you’ve made. For inspiration, here’s an example I made:

Image showing a silly 404 page that says, "Oh no! 404. Where'd you go? I miss you so" with some additional emojis and a search field.

Testing Environment 

While there’s more information below to ensure you get everything set up properly, here are the key aspects to have in place with your testing environment: 

  • Use a test site. Do not use a production/live site. You can follow these instructions to set up a local installLocal Install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer. or use a tool like this to set up a development site
  • Use WordPress 5.7 (downloadable here).
  • Use the TT1 Blocks Theme. If you followed the first call for testing, you’ll need to double-check to make sure you’re using this theme!
  • Use 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/ 10.1.1 (latest version). 

Testing FlowFlow Flow is the path of screens and interactions taken to accomplish a task. It’s an experience vector. Flow is also a feeling. It’s being unselfconscious and in the zone. Flow is what happens when difficulties are removed and you are freed to pursue an activity without forming intentions. You just do it.
Flow is the actual user experience, in many ways. If you like, you can think of flow as a really comprehensive set of user stories. When you think about user flow, you’re thinking about exactly how a user will perform the tasks allowed by your product.Flow and Context

Here’s a basic flow to follow when testing this specific feature. If anything doesn’t make sense, just comment below!

Important Note: 

While this call for testing is focused on testing a specific feature, you’ll likely find other bugs in the process of testing with such a 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. feature! Please know any bugs you find are welcome in your report for testing, even if they aren’t directly applicable to the tested feature. 

Setup Instructions: 

  1. Have a test site using WordPress 5.7. It’s important this is not a production/live site. 
  2. Install the TT1 Blocks theme by going to Appearances > Themes > Add New. Once installed, activate the theme. 
  3. Go to the website’s admin.
  4. Install and activate the 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 from Plugins > Add New. If you already have it installed, make sure you are using at least Gutenberg 10.1.1.
  5. You should now see a navigation item titled “Site Editor (beta).” If you don’t see that in your sidebarSidebar A 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., you aren’t correctly using the Site Editing experiment. 


Testing Instructions:

Helpful Hint: As you go through this test, you might find the List View helpful while navigating between content.

Exploring the 404 template

  1. Navigate to the “Site Editor (beta)” view. This will automatically open the site editor to the template powering your homepage. 
  2. Open the Navigation Toggle and head to Templates > 404. This will take you to your site’s 404 page template.
  3. Using the List View, select the HeaderHeader The 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. Template Part and, using the three-dot toolbar menu, select “Remove 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.” to delete this.  
  4. From there, select the default Header Block that says “Nothing Here” and, using the three-dot toolbar menu, use the “Insert Before” option to add a block above. 
  5. Using your preferred method to insert a block, insert a Template Part Block and select the “New Template Part” option.
  6. Open the Block Settings for the new Template Part block and, under Advanced > “Title”, add in a custom title. For example, “404 Header”.
  7. When you’re done making the changes you want, select “Update Design” and go through the saving flow to save all changes. This should cause the new Template Part to reflect the title you chose.

Adding navigation and getting creative

  1. From there, make sure your focus is still within the new Template Part and add in a Navigation Block. You can choose whether to create a new menu or re-use a previous one.
  2. Add a few links including a link to a page that doesn’t currently exist. To do this, just start typing a title that doesn’t currently exist on your site. For example, “Help”. You’ll then see an option to create a draft page. Do this for at least one menu item. Remember to have fun with this! 
  3. Outside of the Navigation Block, add any additional blocks you’d like to in this new Template Part. For example, you can use the Social Icons Block, Search Block, Site Title, and more. Try to add anything that would help orient someone who got lost on your site.
  4. From there, edit the “Nothing Found” Header Block and Search Block to whatever you’d like. You can then add in anything you’d like including images, GIFs, etc. 
  5. When you’re done making the changes you want, select “Update Design” and go through the saving flow to save all changes.
  6. View your 404 page on your site by going to yoursiteurl.com/404 (replace yoursiteurl.com with your test site URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org). Notice that any items you added to the Navigation Block that are page drafts appear but are broken links. You should be able to still view the drafts since you are logged in as an admin. Note: this has been logged as a bug
  7. Return to the Site Editor and open the Navigation Toggle > Dashboard to view your wp-admin dashboard. Note: there’s a current bug that makes it so you can’t view Page Drafts meaning in the future this will be easier. 

Publish, review, and share

  1. Head to Page > All Pages and publish any that need to be. 
  2. Once more, View your 404 page on your site by going to yoursiteurl.com/404 and confirm any prior draft Pages now show up properly with correct permalinks.
  3. Share your experience in the comments below or in GitHub directly. You’re welcome to run through the experience multiple times to capture any additional feedback!

If you want to take this further, here are some extra items to explore:

  • Try adding in columns to your content! Columns are a powerful tool and it would be helpful to get feedback on the experience of using them in a real life scenario with site building.
  • Create a custom footer template part to replicate the process of creating a custom header template part.
  • Deeply customize the appearance of the page with custom colors, font sizes, and more. Here’s a quick video demonstrating some of what you can try.

Testing Video:

This video shows the testing flow after the initial testing setup is in place. Of note, this video purposefully does not go into depth in building out a 404 page in order to keep it concise. Don’t let this stop you from getting creative though when you’re testing!

What to notice:

Remember to share a screenshot of what you created if you’re up for it!

  • Did the experience crash at any point?
  • Did the saving experience work properly? 
  • Did the saving experience make sense when making changes to the Template Part vs the general content? 
  • What did you find particularly confusing or frustrating about the experience?
  • What did you especially enjoy or appreciate about the experience? 
  • Did you find that what you created in the Site Editor matched what you saw when you viewed your 404 page? 
  • Did it work using Keyboard only?
  • Did it work using a screen reader?

Leave Feedback by March 23rd, 2021

Please leave feedback in the comments of this post. If you’d prefer, you’re always welcome to create issues in this GitHub repo directly for Gutenberg and in this GitHub repo for TT1 Blocks. If you leave feedback in 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/, please do still comment below with the link. If you see that someone else has already reported a problem, please still note your experience with it below, as it’ll help give those working on this experience more well-rounded insight into what to improve. 

#core-editor, #fse-outreach-program, #fse-testing-call, #full-site-editing, #gutenberg, #usability-testing

FSE Program Testing Call #2: Build a Homepage with Site Editing Blocks

This is the second call for testing as part of the Full Site Editing Outreach Program. For more information about this experimental program, please review this FAQ for helpful details. To properly join the fun, please head to #fse-outreach-experiment in Make Slack for future testing announcements, helpful posts, and more will be shared there. 

Feature Overview

Before diving into the testing details, let’s pause to talk about the focus of this call for testing. With Full Site Editing unlocking the ability to edit all parts of your site, there comes a need for new blocks to help facilitate the experience. You might have seen some of these blocks already! For example, there’s a Site Title 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. that you can embed anywhere and update automatically any time you change your Site Title.

For this specific test, we’re going to explore using a few of these blocks to build a basic homepage with a sidebarSidebar A 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.:

  • Site Title Block
  • Site Logo Block
  • Post Lists Block
  • Post Tags Block
  • Navigation Block
  • Template Part Block

Think of this as a chance to both explore what’s possible currently to build something simple and as a chance to get more familiar with these new blocks. Eventually, these blocks will specifically be categorized in the Inserter as defined for Site Editing. 

Testing Environment 

While there’s more information below to ensure you get everything set up properly, here are the key aspects to have in place with your testing environment: 

  • Use a test site. Do not use a production/live site. You can follow these instructions to set up a local installLocal Install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer. or use a tool like this to set up a development site
  • Use WordPress 5.6.1 and above (downloadable here).
  • Use the TT1 Blocks Theme. If you followed the last call for testing, you’ll need to double-check to make sure you’re using this theme!
  • Use 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/ 10.0 (latest version). 

Testing FlowFlow Flow is the path of screens and interactions taken to accomplish a task. It’s an experience vector. Flow is also a feeling. It’s being unselfconscious and in the zone. Flow is what happens when difficulties are removed and you are freed to pursue an activity without forming intentions. You just do it.
Flow is the actual user experience, in many ways. If you like, you can think of flow as a really comprehensive set of user stories. When you think about user flow, you’re thinking about exactly how a user will perform the tasks allowed by your product.Flow and Context

Here’s a basic flow to follow when testing this specific feature. If anything doesn’t make sense, just comment below!

Important Note: 

While this call for testing is focused on testing a specific feature, you’ll likely find other bugs in the process of testing with such a 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. feature! Please know any bugs you find are welcome in your report for testing, even if they aren’t directly applicable to the tested feature. 

Setup Instructions: 

  1. Have a test site using WordPress 5.6.1. It’s important this is not a production/live site. 
  2. Install the TT1 Blocks theme by going to Appearances > Themes > Add New. Once installed, activate the theme. 
  3. Create either three fake posts with a few tags OR use the demo Gutenberg content found here. Here’s a short video explaining how to set up this content. 
  4. Go to the website’s admin.
  5. Install and activate the 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 from Plugins > Add New. If you already have it installed, make sure you are using at least Gutenberg 10.0.
  6. You should now see a navigation item titled “Site Editor (beta).” If you don’t see that in your sidebar, you aren’t correctly using the Site Editing experiment. 


Testing Instructions:

Helpful Hint: As you go through this test, you might find the List View helpful while navigating between content.

  1. Navigate to the “Site Editor (beta)” view. This will automatically open the site editor to the template powering your homepage. 
  2. Using the List View, see if the Query Block is present. If so, select and delete it. This is just a housekeeping step to keep things contained :). 

Make changes to your headerHeader The 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.:

  1. You’ll likely see a Header created for you that you can edit directly. Update the text in the Site Title block. Have fun with it! Some ideas to get you started: Pick a new heading size, change the content, or alter the block settings directly. 
  2. When you’re done making the changes you want, select “Update Design” and go through the saving flow to save all changes.
  3. Open the Navigation Toggle and head to Template Parts > Select “Header.” This will show you an isolated view of just the Header portion of your site. While in this view, add a Site Logo Block and configure it to your liking. 
  4. When you’re done making the changes you want, select “Update Design” and go through the saving flow to save all changes.
  5. Open the Navigation Toggle again and head to Template > Index to return to your homepage. 
  6. Once there, head to the Navigation Block that’s powering the menu in the Header (this is where you might find the List View helpful!). Explore the Navigation Block by making changes directly to the menu items or in the Block Settings to change the font, color, etc. 
  7. Using the List View, select the Header Template Part and, using the three-dot toolbar menu, use the “Insert After” option to add a block outside of the Header. 

Add your content:

  1. Add either a 70/30 or 30/70 column block. In the larger column, use the Heading Block to write “My Content.” In the smaller column, use the Heading Block to write “My Sidebar.” 
  2. In the larger column, add a Posts Lists Block and select the configuration you would like (Title & Date, Title & ExcerptExcerpt An 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., etc.). 
  3. From there, add a Post Tags Block to one of the posts displayed in the Posts Lists Block. Notice how if you add it to one post, it adds it to all of them!
  4. Repeat the previous step with the Post Author Block before deciding whether you’d like to keep or remove either additional block.  

Create a sidebar:

  1. In the smaller column, build out your sidebar how you’d like! For inspiration, try out the Social Icons Block, Latest Posts Block, or a simple Image block.
  2. When you’re done making the changes you want, select “Update Design” and go through the saving flow to save all changes.
  3. Share your experience in the comments below or in GitHub directly. You’re welcome to run through the experience multiple times to capture any additional feedback!

Testing Walkthrough Video:

This video shows the testing flow after the initial testing setup is in place and is using Gutenberg demo content found here. Make the flow you’re on though with your own unique changes and adjustments!

What to notice:

  • Did the experience crash at any point?
  • Did the saving experience work properly? 
  • Did you ever want to do something with a specific block that wasn’t possible? 
  • What did you find particularly confusing or frustrating about the experience?
  • What did you especially enjoy or appreciate about the experience? 
  • Did you find that what you created in the Site Editor matched what you see when you view your homepage? 
  • Did it work using Keyboard only?
  • Did it work using a screen reader?

Leave Feedback by March 5th, 2021

Please leave feedback in the comments of this post. If you’d prefer, you’re always welcome to create issues in this GitHub repo directly for Gutenberg and in this GitHub repo for TT1 Blocks. If you leave feedback in 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/, please do still comment below with the link. If you see that someone else has already reported a problem, please still note your experience with it below, as it’ll help give those working on this experience more well-rounded insight into what to improve.

#core-editor, #fse-outreach-program, #fse-testing-call, #full-site-editing, #gutenberg, #usability-testing