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.
Full Site Editing (FSE) is a major focus of Gutenberg’s Phase Two work and for 2021 goals and 2022 goals. The Full Site Editing Outreach Program was created as an experiment to get feedback early and often from the community about this feature. While calls for testing are shared as frequently as possible, there are times when there isn’t an active call for testing but that doesn’t mean you can’t help test this feature. This guide aims to give you everything you need to start testing Full Site Editing.
What’s the minimum viable productMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia (MVPMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia)?
Currently, the minimum viable product should make it possible to replicate the major functional elements of the Twenty Twenty-One theme, using only blocks, without any coding knowledge. You can read more about this MVP and the timeline here.
Why should I help test Full Site Editing?
Following open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. philosophy, “given enough eyeballs, all bugs are shallow”. For this feature to be a success for as many people as possible across as many situations as possible, it’s important to get this work to people early to improve future iterations. Think of this as a great way to help create the future of WordPress!
Individual Testing Process
For anyone looking to test Full Site Editing as an individual, please follow these steps.
Step 1: Setup your site
Before you can begin to test, you need to have a site that can allow you to use this experimental feature. Please do not test on a production siteProduction SiteA production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing.. You can follow these instructions to set up a local installLocal InstallA local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer. or you can use a tool like this to set up a development site.
Use the latest version of WordPress or at least WordPress 6.0 (downloadable here).
Use the latest version of GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ or at least Gutenberg 13.3 (latest version).
Once you have all of these items in place, you should now see a navigation item titled “Editor (betaBetaA 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.)”. Here’s a screenshot of what you should see:
If you don’t see that in your WordPress admin, you aren’t properly using the Site Editing experiment. If you need help, please ask in the #fse-outreach-experiment channel in WordPress.org slack.
Step 2: Explore and test different features
While you’re welcome to test any aspect of the experience, it sometimes can help to know where to start. Here are some options below inspired by the Site Editing Milestones to help you get started.
Use different Full Site Editing specific blocks like the Posts Lists BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience., Site Title Block, Template Part Block, Site Logo Block, Navigation Block, and more.
Explore Global Styles (screenshot of where to find this option). Try changing settings for blocks globally.
Edit Templates like the 404 Page Template or Single Page Template.
Explore Template Editing Mode.
Explore the various browsing options between your content and Templates.
Try building a site.
Try using a Theme other than Twenty Twenty-Two.
Try the Query Block and see how you might be able to use it for future Theme building. Here’s a short video walking through how to get started.
PluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors: Create a Block by following this tutorial. If your current plugins impact Navigation or Widgets, review the respective projects underway to add block functionality to those experiences. Both of those projects help pave the way to Full Site Editing.
For feedback that relates to the Full Site Editing experience, please open issues on Gutenberg’s GitHub repository. Of note, as you can, please file issues either as Bug Reports or Feature Requests.
If feedback you have doesn’t fit into either option, you are welcome to open a blank issue using the option shown below at the bottom of the New Issue page:
If you do this, please make sure to still include what version of Gutenberg and WordPress you’re using.
Group Testing Process
If you’re looking to facilitate a group testing Full Site Editing, whether through a meetupMeetupAll 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., a group of friends, or internal to your company, here are a few guidelines to keep in mind in order to make it as high impact and seamless as possible. If you can, please let @annezazu know in the #fse-outreach-channel if you are going to do this as it allows her to plan for a potential influx of feedback.
Have clear instructions to help people set up their testing environment
Test sites can be a big hurdle to get over when it comes to testing FSE as you do not want to test it on a production site. Before starting the process with the group, it’s recommended that you send out instructions ahead of time so people can begin testing sooner rather than later. Generally speaking, you can have people follow these instructions to set up a local install or you can have them use a tool like this to set up a development site. From there, ensure everyone is using the following:
Use the latest version of WordPress or at least WordPress 6.0 (downloadable here).
Use the latest version of Gutenberg or at least Gutenberg 13.3 (latest version).
Create testing instructions/reuse calls for testing
If you’re unsure what to have people test, going through previous or current calls for testing is a great way to ease people into the experience. It’s best to follow the current call for testing as it’s likely that the experience has changed since previous calls for testing were run.
Generally speaking though, because Full Site Editing is a collection of features, it’s important to have a loose plan for how you want people to explore the experience.
Plan ahead for gathering feedback
Before running the group through the testing process, create a plan for where the feedback should go. It’s recommended to follow one of these approaches:
Have each individual person comment on the current call for testing to share their feedback individually.
Assign one person to be in charge of gathering feedback from everyone, compiling it into one spreadsheet, and managing the process.
If someone in your group is comfortable and well versed in Full Site Editing, it would be a big help to have them manage triaging the feedback that came in and figure out what, if any, GitHubGitHubGitHub 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/ issues need to be created. If this is not possible, please reach out to @annezazu as she can facilitate the triaging process.
You must be logged in to post a comment.