The Test Team helps manage testing and triage across the WordPress ecosystem. They focus on user testing of the editing experience and WordPress dashboard, replicating and documenting bug reports, and supporting a culture of review and triage across the project.
If you’d like to help test Full Site Editing, please join the FSE Outreach Program. You can find current calls for testing for this program here and you can join the fun in #fse-outreach-experiment.
This is a summary of a Hallway Hangout that was wrangled in the #fse-outreach-experiment channel as part of the FSE Outreach Program. Thank you to everyone who joined the conversation!
Attendance: 10 Attendees in total
You can watch the recording of the call here:
Notable Topics Covered:
The call for testing will remain open for feedback until July 14th. Please feel free to check the test here.
#fse-hallway-hangout, #fse-outreach-program, #full-site-editing
With WordPress 5.8 slated to ship on July 20th, this post seeks to consolidate ways for those in the FSE Outreach Program (anyone can join!) to help test specific features related to the overall full site editing project that will be included in this release. This is meant to bolster, not replace, overall 5.8 testing efforts. Theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. is explicitly not mentioned here as there’s currently a dedicated testing post for that feature with feedback open until July 14th.
For more information about the outreach program, please review this FAQ for helpful details and check out the latest schedule. To properly join the fun, please head to #fse-outreach-experiment in Make Slack for future testing announcements, helpful posts, and more.
Important note: Anything marked as [Technical] is best for those comfortable with more advanced testing steps.
Please only test on a development siteDevelopment Site You can keep a copy of your live site in a separate environment. Maintaining a development site is a good practice that can let you make any changes and test them without affecting the live/production environment. and not on 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.
Once a development site is set up, please install and activate the WordPress Beta Tester Plugin before setting it to:
If you need more specific steps, here are more detailed instructions you can follow.
The block widgets editor allows you to use blocks in widgets areas and control them further in the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. with live preview, scheduling, etc. The following items are considered a high priority to test:
For robust testing steps for each of these items, please review this specific call for testing from earlier in the release process. For more information about this new feature, check out this Dev note covering all of the details.
Template editing mode allows you to edit your content’s template with blocks, including some new theme blocks like the Site Title block or Page List block. As a reminder, template editing mode is opt in for Classic Themes and opt out for Block Themes. This means that if you want to test this, you’ll need to use a block theme along with both the Gutenberg plugin and the WordPress Beta Tester Plugin.
The following items are a high priority to test:
For robust testing steps around using and creating templates, please follow these previous calls for testing: create a custom portfolio page and create custom landing pages.
Note: If you use a block theme to test this, you will need to install the Gutenberg plugin alongside it in order for everything to work with WordPress 5.8.
Duotone is a feature that allows you to add colors to your images and enhance your content. It works best with high contrast images, so keep that in mind as you test the following priority items:
For more information about this feature, check out the WordPress news post that covers it in depth.
The Query Loop Block (previously called the Query Block) is a powerful new block that unlocks the ability to easily show off posts from a specific categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., allowing you to do things like quickly creating a portfolio or a favorite recipe page. Think of it as a more complex and powerful Latest Posts Block! Currently, this new block offers multiple ways for displaying lists of posts and comes with new block patterns that take advantage of its flexibility and creative possibilities.
To help test this, explore the patterns built into the block, try changing the default query 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. settings, placing it inside a columns block, and more. Keep in mind that to create a better user experience, the content within the Query Loop isn’t able to be edited but can be customized (i.e., Post Title text can’t be changed but you can change the color of the Post Title Block).
For robust testing steps around using the query block, please follow this previous call for testing that was focused on the Query Loop block.
If you find any issues, it’s best to share them on the alpha/beta forums, or Trac if you are more technically savvy and comfortable. Please share feedback before the release on July 20, 2021.
Props to @daisyo and @jffng for the massive amount of help in writing and perfecting this call for testing.
Important note: Compared to previous calls for testing for the FSE Outreach program, this is intentionally targeting a more developer-centric audience compared to site builders or end users in order to bring high impact feedback for theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., a new tool for extenders. You can read more about what to expect with upcoming efforts here.
At the highest level, theme.json is a configuration file used to enable or disable features and set default styles for both a website and blocks. Rather than dealing with a ton of theme support flags or alternative methods, theme.json provides a consolidated and canonical way to manage it all. These settings include options like:
This configuration file is a big part of what makes 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. themes so powerful as it allows for finer-grained control, and introduces the first step in “managing styles” for future WordPress releases. Here are a few of the top benefits of using this new mechanism:
While block themes won’t work with WordPress 5.8 without the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party due to some theme blocks being left out of the release that weren’t quite ready to ship, it’s still an important feature coming to 5.8 that needs testing and exploration. If you’ve been curious about the world of block themes or have started building your own, this call for testing is for you and should help you to continue to explore what’s possible with theme.json while giving you a chance to share what else you’d like to see.
You can read more about this feature in the documentation here.
This section is for those wanting to get a sense of what theme.json can control and what the output will look like.
This section is for those wanting to dig deeper into theme.json by writing their own file and exploring the various settings it can control.
Note: this mainly focuses on just theme supports and presets for blocks in the settings section of theme.json rather than Global Styles.
Set up your testing environment
Generally speaking, please use the latest versions of each part of the setup and keep in mind that versions might have changed since this post was shared.
Layout
contentSize value to a different pixel value in the layout section of theme.json.wideSize value to a different pixel value in the Layout section of theme.json.Typography
true in theme.json: Border
true in theme.json:"customColor": true"customRadius": true"customStyle": true"customWidth": truefalse in theme.json.Color
true in theme.json:"custom": true"customGradient": true"link": trueThis section is for those looking to create a more robust block theme using theme.json and who are experienced theme developers. This isn’t for everyone!
If you feel more comfortable with block themes and have ample time to dig into theme.json, try replicating a classic theme. Here are two options that should be fun to dig into but keep in mind any default theme should work well:
As you try to do this, write down what gaps remain, what proves to be the most difficult to do, and what feels surprisingly easy! Share in the comments below so we can learn from your experience. This is intentionally extremely open ended and advanced so don’t worry if you don’t feel up for the challenge. If you want to follow along while someone else explores doing this, check out @mkaz‘s exploration video on learning to create a block theme.
These questions are specifically for the Intermediate and Advanced sections:
Please leave feedback (questions, comments, concerns) in the comments of this post and be sure to note which section you followed. If you’d prefer, you’re always welcome to create issues in this GitHub repo directly for Gutenberg but, for this test, it’s unlikely you’ll need to. However, if you do leave feedback in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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 comment below with the link.
Join a hallway hangout for theme.json testing on July 7th
To help those who might want to explore this test and theme.json in a group, @daisyolsen will be hosting a hallway hangout specifically for this exercise. If you have never attended a hallway hangout, you can read more about them here. Ultimately, they are meant to be casual and collaborative sessions to bring like minds together.
Hope to see you there.
This post is a summary of the seventh 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.
On a more personal note, it’s so neat to see the various ways people engaged and to really feel the power of the WordPress community in these calls for testing — WordCamp Japan used the seventh call for group testing this week, a meetup in Philadelphia used it as part of their event (shoutout to @accessamy and @itsjusteileen), the call for testing was translated into Italian and Japanese (shout out to @piermario and the folks from WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Japan) and three folks did write ups encouraging others to test alongside their feedback (@greenshady, @bgturner, and @bobbingwide). Plus, I had some of my coworkers go through the test for good measure! I am super stoked to see a diverse set of ways folks are exploring this program and deeply appreciate you all making it happen.
Teamwork makes the dream work. Anything I can do to make participation easier and more fun, let me know!
How far can one go?
It’s hard to compete with @greenshady’s awesome explorations at this point! Check it out below:
High Level Feedback
Here’s what a few folks had to say about the overall experience that can help frame the following detail oriented feedback. Since this was a more open ended test compared to the prior one, it was interesting to hear about the ways in which people explored things on their own and the resulting joys/frustrations that caused.
Compared to the earlier tests, the overall experience is way more stable and polished. My biggest issue with the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ and FSE is still the same: lack of visual references while designing, unless I do some hovering dance on the blocks and – this time – I didn’t have a clear picture of how exactly changing some elements (site title, navigation) on the portfolio template would affect other pages, so I got a little lost between pages.
@piermario in this comment.
Generally I love the query 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. though. Really cool that you can do that now without coding! I am looking forward to using it in projects.
@michaelsndr in this comment.
I had a lot of fun with this. And frustration. Some more fun. And…you guessed it…some more frustration….I enjoyed the process — yes, I revel in both the fun and frustration. Aside from everything that I think is broken, the overall system is pretty dang sweet. There are far more things that the development team has nailed down than there are that feel janky.
@greenshady in this post.
Repeated Feedback: Switching between editing modes (template vs page/post) & various block improvements
This section is dedicated to repeated items from previous calls for testing. Once more, despite the three ways to visually distinguish the editing modes, there remains confusion around when one is in each mode. The deeper into these calls for testing we go, the more it becomes clear how valuable it will be to do things like view a template while editing content and have some good friction in place while interacting with post blocks in template editing mode.
Across a few blocks, some repeat items came up that are worth mentioning considering they were each mentioned at least two times:
Today I got lost quite often. I didn’t always know if I was editing the Portfolio Template or the Portfolio page.
@piermario in this comment.
However, once I was in the Template Editor it wasn’t clear when I was editing the template or the content itself. When I used the block navigator – I could see the post content block (which made sense) but only because I was already looking.
Automattic employee feedback.
Some general usability feedback of the column block: I’d love a way to make the vertical margins disappear so that full-width sections that have background colors don’t show any space between them.
@bjturner in this post.
Post Title Block – no way to style text (bold, italics etc), and no way to have a totally custom colour. Do these color options come from the theme itself?
Automattic employee feedback.
As a user, template editing is a great tool when you have a good visual understanding of what your post or page content will look like in the context of the full site. The issue is, when in the post editor I don’t know that, unless I am checking “Preview” as I create/edit my content. Has any thought been given to how we could improve this experience so users are more aware, as they’re editing, of how their content will be displayed on the site (depending on the template used)?
Automattic employee feedback.
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 & Related Improvements
Since the Query Loop Block featured heavily in this call for testing, it’s no surprise it was also an area of both great praise and criticism. On the whole, there was loads of excitement around this powerful block with folks keen to have access to it with WordPress 5.8. Outside of that though, the following items were raised for the Query Block itself and some of the related blocks used within it:
Tied to the above issues, there was repeated frustration around deeper customization and limits of the nested blocks within the Query Loop, especially if someone wanted to go well beyond what the current patterns offer. It’s also important to note that this test was done without this PR merged for the Query Loop block, which makes the Post Blocks uneditable within the Query Loop block itself ahead of WordPress 5.8.
The next section of template testing consisted of adding a Query pattern and customizing it. I have a love/hate relationship with queries in Gutenberg right now. The Query block itself works well. It has a solid balance between advanced usage and simplicity for the most part. I am amazed at what the development team has done over months upon months of iteration.The downfall is that the Query block is merely a wrapper. It is only as good as its weakest sub-block.
@greenshady in this post.
There’s a bit of a confusion point in the Query Block with Items per Page. Despite having multiple published posts only one appeared by default. I found the controls in the Block Toolbar to increase, but also found it a bit cumbersome to toggle between the Block Toolbar and Block 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. to refine the underlying query.
@dryanpress in this comment.
Query Block: Block outputs nothing on the frontend when there are no posts to show. Generally, it requires to show something that tells visitors that there are no posts or some custom message.
@sagarnasit in this comment
General Usability Enhancements
As people explored template editing mode, the following items came up as areas that would make the experience more intuitive going forward. Many of these were repeat items but it felt important to call these out separately, in particular the quotes describing the current experience. While some of these areas have design explorations in place for potential inclusion in the future, this section captures the current pain points:
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.
It appears that I didn’t save the template since it’s showing a 404, even though the title says “portfolio.” I think what confused me was the “Publish” button in the upper right corner. Coming from a WP background I think I understand that “Publish” meant to publish the page template I was editing, but on initial use, I was hesitant to push the button because my context was the original page that I had created, not the page template I was editing.
@bjturner in this post.
While in Template Editing Mode, I clicked the Preview button, clicked Preview in new tab and didn’t see the addition of the navigation block or other template changes. If this could work that’d be great, but if these won’t be available to preview outside Gutenberg due to how Templates are saved and stored, that preview dropdown item probably shouldn’t be available inside Template Editing Mode.
@dryanpress in this comment.
If I create a new template, the new template is not available in the drop-down selector until I refresh.
Automattic employee feedback.
When saving the template change, if I uncheck all the items that appear, the Save button gets defunct. If we are allowed to uncheck one of those, I think we should be allowed to uncheck all items too.
Automattic employee feedback.
The Update option isn’t available once I’ve switched alignments on the block. I needed to alter the post title to trigger the Update option.
Automattic employee feedback.
When you’re creating a new template, for each existing template part that you insert, you have to remember to set the same attributes for the template part as used in other templates. Attributes that will need setting include the Width and Colours.
@bobbingwide in this comment.
End-to-end (E2E) tests allow simulating user flows for an application, a site and validating them. They allow for automated testing of user interactions while providing a safety net for continuous development.
Over the past two years, the groundwork for implementing e2e tests in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has been laid. However, there hasn’t been much communication about the technical stack that is used for these tests or the next steps for adding more tests in WordPress.
The purpose of this post is to inform contributors about the current status of e2e testing in WordPress Core, the technologies being used, and what is currently being done to implement these tests.
E2e testing in WordPress Core is implemented with Jest as the testing framework and Puppeteer for browser interactions. This stack is relevant for Core use case because it is present in other parts of the CMS codebase.
On the other hand, it is used by 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/ for its tests. So we are not starting from scratch for the implementation in Core, as there is already some preliminary work done with the @wordpress/e2e-tests package and the @wordpress-e2e-utils utility package, which includes several basic flows that can be reused in tests.
Currently, only the setup for testing and a basic test of the WordPress Dashboard homepage are implemented in Core here. The @wordpress/e2e-tests-utils utility package (in the Gutenberg repository) contains various tests for installing, disabling, activating themes and plugins, navigating the different admin pages, etc.
There are currently efforts being made to implement more e2e tests in WordPress Core. Starting with this ticket, opened by @isabel_brison that presents an overview of the different tests that will be implemented.
There are also pull requests, and branches from contributors who have already implemented tests for some parts of WordPress:
The next step is to start on the overview of the e2e tests to be implemented by creating smaller tickets for each of the tests, and then write the tests.
Any interested contributor is invited to comment on the ticket to propose other test scenarios, learn, and/or help build tests. All are welcomed.
Introducing the WordPress e2e tests
E2E (End-To-End) Testing in Core Proposal
Overview of e2e tests to be written
Props @francina and @hellofromtonya for reviews and edits.
You must be logged in to post a comment.