WooCommerce is testing a React-rendered Settings UI for extension settings while preserving the legacy PHP settings array and save flow. That makes migration safer, but only if every field type, default, option ID, custom component, and save path is checked.
Use this for WooCommerce sites with payment, tax, shipping, subscription, CRM, tracking, wholesale, or custom extensions that expose settings pages in WooCommerce admin.
Quick answer
WooCommerce Extension Settings UI Migration QA should be handled with a narrow evidence-first workflow: inventory settings, enable on staging, test field types, then verify the result before making broader changes.
What to check first
- Inventory every extension settings page and section that touches checkout, tax, shipping, tracking, email, or payment behavior.
- Enable the Settings UI feature flag on staging only and test one extension page at a time.
- Confirm checkbox, text, select, number, textarea, multiselect, and array-backed fields render with expected labels and defaults.
- Save each setting, reload the page, and confirm the stored option value matches the legacy admin behavior.
- Capture console warnings, missing scripts, failed component registration, and settings that save but do not affect runtime behavior.
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 |
|---|
| Inventory settings | Inventory every extension settings page and section that touches checkout, tax, shipping, tracking, email, or payment behavior. | Every critical field renders, saves, reloads, and affects runtime behavior as expected. |
| Enable on staging | Enable the Settings UI feature flag on staging only and test one extension page at a time. | The browser console has no missing script or component registration errors. |
| Test field types | Confirm checkbox, text, select, number, textarea, multiselect, and array-backed fields render with expected labels and defaults. | The same extension page still works when the feature flag is disabled. |
| Save and reload | Save each setting, reload the page, and confirm the stored option value matches the legacy admin behavior. | Checkout, payment, tax, shipping, and tracking settings are tested through real workflows. |
Why this usually happens
- A migrated settings screen can render correctly while saving a different value shape than the legacy PHP table expected.
- Custom React components need their script handles loaded before the Settings UI app mounts.
- Some extension settings control checkout behavior indirectly, so the real test is a checkout or order result.
- A page can pass visual QA and still fail because default values, descriptions, or section grouping changed.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
add_filter('woocommerce_admin_features', static function (array $features): array {
$features[] = 'settings-ui';
return array_values(array_unique($features));
});
wp option get woocommerce_tax_settings
wp option get woocommerce_stripe_settings
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.
- Inventory settings
- Enable on staging
- Test field types
- Save and reload
- Retest checkout
What to tell the client or owner
Report settings UI readiness per extension, not as one global yes or no.
Production verification checklist
- Every critical field renders, saves, reloads, and affects runtime behavior as expected.
- The browser console has no missing script or component registration errors.
- The same extension page still works when the feature flag is disabled.
- Checkout, payment, tax, shipping, and tracking settings are tested through real workflows.
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, keep WooCommerce extensions tested during updates.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references