WordPress 7.0 updates can change editor output, block spacing, theme behavior, or the way custom classes appear in key layouts. A CSS regression test should focus on revenue and lead paths first.
Use this before updating business sites with custom CSS, block themes, form styling, WooCommerce blocks, custom landing pages, or page-builder-to-block migrations.
Quick answer
WordPress 7.0 Custom CSS Block Regression Test should be handled with a narrow evidence-first workflow: collect css sources, map risky selectors, test key pages, then verify the result before making broader changes.
What to check first
- Collect the custom CSS sources: theme file, Additional CSS, child theme, snippets, and plugin CSS.
- List selectors that target block classes, layout wrappers, forms, buttons, and WooCommerce elements.
- Test high-value pages before lower-risk blog archives.
- Compare desktop and mobile screenshots after the update.
- Remove dead selectors only after verifying they are not used by templates or patterns.
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 |
|---|---|---|
| Collect CSS sources | Collect the custom CSS sources: theme file, Additional CSS, child theme, snippets, and plugin CSS. | Forms, buttons, navigation, and checkout blocks match the approved screenshots. |
| Map risky selectors | List selectors that target block classes, layout wrappers, forms, buttons, and WooCommerce elements. | No CSS rule depends on a removed block wrapper. |
| Test key pages | Test high-value pages before lower-risk blog archives. | Mobile breakpoints are checked separately from desktop. |
| Compare screenshots | Compare desktop and mobile screenshots after the update. | Dead CSS removal is tracked as a separate cleanup task. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp option get theme_mods_$(wp theme list --status=active --field=name)
wp post list --post_type=wp_template,wp_template_part,wp_block --fields=ID,post_type,post_title,post_modified
rg "wp-block-|has-|is-layout|woocommerce" wp-content/themes wp-content/mu-plugins
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.
- Collect CSS sources
- Map risky selectors
- Test key pages
- Compare screenshots
- Clean dead rules
Production verification checklist
- Forms, buttons, navigation, and checkout blocks match the approved screenshots.
- No CSS rule depends on a removed block wrapper.
- Mobile breakpoints are checked separately from desktop.
- Dead CSS removal is tracked as a separate cleanup task.
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 custom CSS before WordPress updates.