WordPress 7.1 work includes media gallery improvements and better handling of legacy gallery shortcodes during conversion. Sites with years of Classic editor content need fixture tests for galleries, shortcodes, embeds, captions, custom HTML, and plugin markup before editors convert live posts.
Use this for publishers, universities, membership sites, and migrations where older posts mix Classic blocks, shortcodes, inline styles, media captions, and custom plugin output.
Quick answer
WordPress 7.1 Beta Classic Block Conversion Regression Test should be handled with a narrow evidence-first workflow: choose fixtures, save original evidence, convert once, then verify the result before making broader changes.
What to check first
- Export representative posts with gallery shortcodes, embeds, captions, custom HTML, lists, tables, and plugin shortcodes.
- Clone them to staging and save the original post_content, rendered HTML, screenshots, links, and accessibility tree.
- Convert each Classic block once on the selected 7.1 beta build and record block validation warnings.
- Compare frontend output, mobile layout, media order, captions, link targets, and shortcode execution.
- Test revision restore and document which fixtures should remain unconverted.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Choose fixtures | Export representative posts with gallery shortcodes, embeds, captions, custom HTML, lists, tables, and plugin shortcodes. | Gallery order, captions, links, embeds, and shortcodes match the original intent. |
| Save original evidence | Clone them to staging and save the original post_content, rendered HTML, screenshots, links, and accessibility tree. | No block validation warning is ignored without a documented decision. |
| Convert once | Convert each Classic block once on the selected 7.1 beta build and record block validation warnings. | Mobile and keyboard behavior remain usable after conversion. |
| Compare output | Compare frontend output, mobile layout, media order, captions, link targets, and shortcode execution. | A revision restore returns the original post content and frontend rendering. |
Why this usually happens
- Legacy HTML can be valid in the browser but not map cleanly to a modern block schema.
- Theme styles can make converted markup look different without a content error.
- Plugin shortcodes may be wrapped or escaped during conversion.
- A saved conversion can make the first bad version harder to compare without fixtures.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp post get 4821 --field=post_content > before-4821.html
wp post get 4821 --fields=ID,post_modified_gmt,post_status --format=json
wp post meta list 4821 --format=json > before-4821-meta.json
# Convert only the staging clone, then compare HTML, screenshot, links, and accessibility output.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Choose fixtures
- Save original evidence
- Convert once
- Compare output
- Test revision restore
What to tell the client or owner
List core build, post fixture, original content hash, conversion warnings, visual differences, link results, accessibility differences, and revision recovery result.
Production verification checklist
- Gallery order, captions, links, embeds, and shortcodes match the original intent.
- No block validation warning is ignored without a documented decision.
- Mobile and keyboard behavior remain usable after conversion.
- A revision restore returns the original post content and frontend rendering.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, test WordPress 7.1 content compatibility.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references