Test your plugins and themes on WordPress 7.1 Beta

Testing steps

1. 1 Create a new post and add a few paragraphs of content.
2. 2 Select some text inside a paragraph.
3. 3 Open the block toolbar (or the ⋮ options menu) and choose Add note (look for a note/comment icon).
4. 4 Type a note and save it. Confirm the note appears anchored to the text you selected.
5. 5 Reply to your own note and confirm the reply shows in the thread.
6. 6 Add formatting using keyboard shortcuts — there’s no visible toolbar. Select text and press ⌘/Ctrl + B (bold), ⌘/Ctrl + I (italic), or ⌘/Ctrl + K (link). To get code formatting, type text wrapped in backticks (`like this`). Confirm the formatting is kept after saving. (Formatting is intentionally limited to bold, italic, link, and code.)
7. 7 Start a second, separate thread on the same block and confirm both threads are tracked independently.
8. 8 Add a note that spans more than one block and confirm it’s tracked correctly.
9. 9 Add a long note and confirm the show more/less toggle collapses and expands it.
10. 10 @mention another user in a note and confirm the mention is inserted correctly.

Testing steps

Global Styles first (applies to all buttons)

1. 1 Open the Site Editor and go to Styles → Blocks → Button.
2. 2 Use the States selector to switch to the Hover state.
3. 3 With Hover active, set a different Background and Text color (and any other styles you like).
4. 4 Repeat for the Focus and Active states, giving each its own look.
5. 5 Save the styles.
6. 6 On the frontend, hover, focus, and click a button and confirm the correct styles appear for every button on the site.

Individual Button instance (applies to one button only)

1. 1 Add two or more Button blocks to a post or page.
2. 2 Select one of them and open its Styles settings.
3. 3 Open the state selector in the block card header (a small three-dot menu) and switch to Hover.
4. 4 Change a style — for example the Background color. The canvas should update immediately; toggle Show state on canvas off and on to confirm it’s previewing the hover look live.
5. 5 Save and view the post on the frontend. Hovering that one button should use the styles you set, while the other buttons stay unchanged.
6. 6 Switch to Focus and Active and repeat, giving that single button its own states.
7. 7 Reset the hover styles for that instance and confirm the other states and the global styles are unaffected.

Testing steps

1. 1 Set a Site Icon (Site Editor → Design → Identity, or Settings) if you haven’t already.
2. 2 Open the Post Editor (edit any post) and confirm the admin bar is visible at the top.
3. 3 Open the Site Editor (Appearance → Editor) and confirm the admin bar is visible there too (it used to disappear).
4. 4 Confirm the admin bar’s home item shows your site icon, not the old dashicon (with no site icon set, it falls back to the default icon).
5. 5 Confirm your profile avatar is a circle, not a square.
6. 6 Confirm there is no command palette icon in the editor toolbar anymore, and that the palette still opens with Cmd/Ctrl + K.
7. 7 Switch your Admin Color Scheme (Users → Profile) and confirm the admin bar in both editors follows the scheme.
8. 8 Resize to a narrow / mobile width and confirm the admin bar still looks correct in the editors.

Testing steps

1. 1 Open the WordPress Dashboard and go to Appearance → Editor.
2. 2 In the Site Editor, go to Design → Identity.
3. 3 Confirm four fields appear in order: Site Title, Site Tagline, Site Logo, Site Icon.
4. 4 Confirm the description text below each field is the same size and style.
5. 5 Edit the Site Title and watch the Site Title block update in the preview.
6. 6 Edit the Site Tagline and watch the Site Tagline block update in the preview.
7. 7 Click Save and confirm all edited fields appear in the save panel.
8. 8 Reload the editor and confirm your changes persisted.

Testing steps

1. 1 Go to Users → Profile and pick an Admin Color Scheme (e.g. Modern, Blue, Coffee, Ectoplasm, Midnight, Ocean, Sunrise).
2. 2 Open the Site Editor (Appearance → Editor).
3. 3 Confirm the sidebar and interface chrome reflect the chosen colour scheme, not a fixed dark background.
4. 4 Confirm the editing canvas / content area stays white and readable.
5. 5 Switch to a different admin colour scheme and confirm the Site Editor updates to match.
6. 6 Resize the browser to a narrow / mobile width and confirm the themed sidebar and white content still look correct.

Testing steps

1. 1 In the editor, press Cmd/Ctrl + K to open the command palette.
2. 2 Run a few different commands and close the palette.
3. 3 Reopen it and confirm a Recently used section shows the commands you just ran.
4. 4 Start typing and confirm results are grouped into recent, suggested, and matching sections.
5. 5 Reload the page (or start a new session) and confirm recently used commands persist.
6. 6 Check the layout is readable and easy to scan.

Testing steps

1. 1 In a post or page, add an Image block and upload or choose an image.
2. 2 Click the Crop button in the block toolbar and confirm a modal opens (instead of the old inline cropper).
3. 3 Try a freeform crop — drag the handles — and confirm it works.
4. 4 Try an aspect-ratio crop (a locked ratio) and confirm the crop constrains to that ratio.
5. 5 Use Rotate (and fine rotation / snap, where shown) and confirm the image rotates.
6. 6 Use Flip and confirm the image flips.
7. 7 Use the Zoom controls (+ / −) and confirm the image zooms within the crop frame.
8. 8 Toggle the crop handles on/off, if available, and confirm they behave.
9. 9 Edit the metadata (for example, alt text or caption) in the modal, then Save.
10. 10 Confirm the cropped/edited image is applied to the block and persists after saving the post and reloading.
11. 11 Repeat from the Site Logo and Cover block crop buttons to confirm the modal opens there too.

Testing steps

1. 1 Create a post and upload a few images to it, so they become “attached” to the post.
2. 2 Add a Gallery block and, in its empty/placeholder state, choose the Use attached images option (Dynamic Gallery).
3. 3 Confirm the gallery automatically shows all the images attached to the post.
4. 4 Save and confirm the same images appear on the frontend.
5. 5 Open the block’s Source settings, change the sort order, and confirm the images re-order accordingly.
6. 6 Convert the Dynamic Gallery to a static gallery and confirm you can now add, remove, or reorder individual images.
7. 7 Open the media inserter (the Media tab in the inserter) and find the new Attachments category.
8. 8 Confirm it lists the images attached to the current post.
9. 9 Use Attach to add an image and Detach to remove one, and confirm the Dynamic Gallery updates to match.

Testing steps

1. 1 Edit a published post, change some content, and trigger a server autosave (wait for it, or run wp.data.dispatch( 'core/editor' ).autosave() in the console). Reload without saving.
2. 2 On the autosave notice, click “View the autosave” and confirm the visual revisions view opens with the autosave selected and its changes highlighted (no page reload).
3. 3 Click Restore and confirm the autosave content is applied and the notice disappears.
4. 4 On a post with visual revisions disabled (e.g. classic meta boxes), confirm “View the autosave” falls back to the classic revisions screen.
5. 5 Open a post with both revisions and a recent autosave, open the revisions screen, and confirm the autosave row shows an “Autosave” badge (regular rows don’t), announced to screen readers too.

Testing steps

1. 1 Create a few posts with no title and different opening content (plain text, blocks, an image). Go to Posts → All Posts in Compact view.
2. 2 Confirm each untitled row shows “(no title)” followed by the first part of its content (up to 15 words, ending in an ellipsis), in a lighter weight than a normal title. A post whose content starts with only an image should show just “(no title)”.
3. 3 Add a post with a title and confirm no excerpt is appended — the feature only applies to untitled posts.
4. 4 Switch to Extended view and confirm the trimmed excerpt is not appended (the full excerpt already shows on its own line there). Switch back to Compact and confirm it returns.
5. 5 Create an untitled password-protected post and confirm it shows only “(no title)” — no excerpt.
6. 6 Repeat on Pages; trash an untitled post and confirm the excerpt still shows next to “(no title)” (the title isn’t linked in Trash, as expected).
7. 7 Confirm the list still sorts, searches, and paginates correctly, and that Quick Edit / Bulk Edit still work for untitled posts.

Testing steps

1. 1 Sign in to wp-admin and open the Dashboard.
2. 2 If today’s date has no posts from previous years, confirm the “On This Day” widget does not display by default — it is hidden (it’s still registered under Screen Options, but stays hidden until there is a matching post).
3. 3 Publish a post with its date set to today’s month and day in a previous year (for example, set the publish date to one year ago today).
4. 4 Reload the Dashboard and confirm the “On This Day” widget now appears, with that year shown as a heading and the post listed under it.
5. 5 Confirm each post is a link that opens its permalink.
6. 6 If a shown post was written by another user, confirm it displays “by [author name]” — posts written by you show no author label.
7. 7 Add a few more posts for today’s date across different previous years and confirm they are grouped by year, newest year first (up to 10 posts).
8. 8 Confirm a post dated today this year (same month/day, current year) does not show — only previous years count.
9. 9 Confirm a post from a different month or day does not show.

Testing steps

1. 1 On a post with threaded comments, go to wp-admin → Comments and click Edit on a reply.
2. 2 In the Save box, click Edit next to “In reply to:” and pick a different comment from the dropdown (the comment itself and its own replies are left out, so you can’t create a loop).
3. 3 Click OK, then Update.
4. 4 View the post on the frontend and confirm the comment is now nested under the new parent.
5. 5 Edit it again, set “In reply to:” to None, Update, and confirm it appears as a top-level comment.

Testing steps

1. 1 Add a Playlist block and upload a few audio files (e.g. MP3s). Confirm a track is added for each file, with a waveform player and a track list.
2. 2 Press play and confirm audio plays; click another track in the list and confirm it switches. Save and view on the frontend, and confirm playback works there too.
3. 3 In the block settings, open the Waveform panel and switch the Visualization style (Bars, Mirror, Line, Blocks, Dots, Seekbar). Confirm the waveform updates in the editor and on the frontend.
4. 4 Set a waveform color and a waveform background color (try the gradient options too) and confirm they render in both the editor and the frontend.
5. 5 Toggle the track-list options — Show tracklist, Show images (album-art thumbnails), Show artists, Show numbers, and Show track length — and confirm each shows or hides correctly.
6. 6 Turn on Show play button artwork and confirm the track’s artwork appears inside the play button.
7. 7 Change the font size in the typography settings and confirm it applies to the track list and the current track.
8. 8 Set a background color, padding/margin, and border on the block and confirm they apply in the editor and on the frontend.

Testing steps

1. 1 Add a Tabs block and confirm it inserts a tab list with two tabs and two matching panels. Then add, remove, and reorder a tab and confirm the corresponding panel syncs each time.
2. 2 Style the Tab List globally under Styles → Blocks and confirm the styles apply to the tab button elements (the block gap is the exception). Override the styles on a single instance and confirm only that one changes.
3. 3 Change the background color and confirm the tab buttons stay legible — their text and borders inherit the current text color.
4. 4 Inspect the markup: confirm tabs and panels are linked by generated IDs, and that a manually-set panel ID is respected.
5. 5 Save and view on the frontend; confirm clicking a tab switches the visible panel.
6. 6 On the frontend, use Tab to focus the tabs and panels, Left / Right arrows to move between tabs, and Enter to activate one. With a screen reader, confirm the tab list’s aria-label (default “Tabbed content”) is announced.

Testing steps

1. 1 Add one of the supported blocks — for example, a Group block with some content inside.
2. 2 In Styles, set a background image on the block.
3. 3 On the same block, also set a background gradient.
4. 4 Confirm both the image and the gradient show together in the editor, with neither cancelling the other out.
5. 5 Save and view on the front end; confirm both render together.
6. 6 Repeat on at least one other supported block (Verse, Accordion, Pullquote, Post Content, or Quote) and try a couple of different gradient/image combinations.

Testing steps

1. 1 Add an Image block and choose an image.
2. 2 Open the block’s Settings sidebar and find the “Mark as decorative” toggle.
3. 3 Turn it on.
4. 4 Inspect the image’s markup and confirm it gets an empty alt (or role="presentation" / aria-hidden, depending on output) so screen readers ignore it.
5. 5 View the post on the frontend and confirm the decorative markup is present there too.
6. 6 Turn the toggle off again, add meaningful alt text, and confirm the image is announced to screen readers once more.

Testing steps

1. 1 Add a Custom HTML block to a post or page, then open its Edit HTML modal.
2. 2 Paste this code — it has a Paragraph block delimited inside static HTML — and click Update: <div class="banner"><h1>Static heading</h1><!-- wp:paragraph --><p>Editable paragraph</p><!-- /wp:paragraph --><footer>Static footer</footer></div>
3. 3 Confirm the paragraph renders at its position inside the static markup and is editable in place (click into it and type).
4. 4 Confirm the paragraph cannot be moved or removed (no up/down movers, no Delete in its options menu) and offers no alignment controls.
5. 5 Open the block’s inspector and confirm the inner blocks list appears, acting as a navigation aid to the editable parts.
6. 6 Save the post and reload the editor: the saved markup should be identical to what you entered, and your paragraph edit persists at its position.
7. 7 View the post on the frontend and confirm the full structure renders (the heading, the editable paragraph, and the footer).
8. 8 Regression check: create a plain Custom HTML block with normal static content, edit and save it — the markup should be unchanged. Note that scripts no longer run in the editor canvas preview (styles still apply), although they still run on the frontend.

Testing steps

1. 1 Open the Post editor.
2. 2 Switch to the code editor.
3. 3 Use an embed shortcode like the one shown in the screenshot.
4. 4 Switch back to the visual editor.
5. 5 Click on the “Convert to blocks” toolbar button on the classic editor.
6. 6 Apply the transform and confirm the embed previews in the editor.
7. 7 Confirm the shortcode is correctly transformed to the appropriate embed block.

Testing steps

1. 1 Add a Shortcode block containing a known shortcode.
2. 2 Use a supported shortcode like the one shown in the screenshot below.
3. 3 Confirm a transform option appears to convert it to the matching block (Gallery / Audio / etc.).
4. 4 Apply the transform.
5. 5 Confirm the new block renders the same content.
6. 6 Save and view on the frontend to confirm the output matches the original shortcode’s result.

Testing steps

1. 1 Did any plugins or themes deactivate automatically after the update?
2. 2 Check the WordPress Site Health tool. Did you find any new warnings or issues?
3. 3 Check templates and patterns, and then actual posts and pages, for layout problems. Are all the elements lined up properly? Is spacing correct?
4. 4 Test links and permalinks to ensure there are no 404 or other errors.
5. 5 Do design elements, images, and media look the way they should? Do media files load and play properly?
6. 6 How are the sitemap and robots.txt files working?
7. 7 Can users at every permission level get to the admin dashboard without errors? Does each level show the right tools, and do they work?
8. 8 Does your site have custom blocks? Add content to a new block. Edit it. Now edit a block that already has content.
9. 9 Create a new post: add content, copy/paste text, add a few different kinds of media, save, and watch the console for issues.
10. 10 Create a new page, add content, and open it in several different browsers.
11. 11 Open the browser’s developer tools. Check each tab, plus the console, for errors, warnings, or notices.
12. 12 Check the error log file for notices, warnings, and errors — especially fatal errors.
13. 13 Have you set up scheduled posts or automated tasks (like backups)? Can you find them in the admin? Do they run on schedule?
14. 14 Check integrated services like payment gateways or analytics. Do they still connect? Do they execute?
15. 15 Open your site in different browsers and make sure all functionalities work as expected.
16. 16 Check site performance: page loading, API calls, database requests — on a few devices if you can.
17. 17 Use browser tools to simulate low bandwidth. How does your updated site handle it?
18. 18 Test accessibility basics: keyboard navigation, contrast, screen-reader behavior.
19. 19 Check your forms — contact, checkout, login, and more. Can you fill all the fields? Submit and clear? Does the data end up in the right place?
20. 20 Can you upload media? Edit images? Does gallery functionality work properly?
21. 21 Check your theme. Does the basic theme look right? Did Site Editor or Customizer customizations change in the upgrade?