[smoen-godaddy]

Summary

Fixes a _doing_it_wrong notice fired by SV_WC_Admin_Notice_Handler::render_admin_notice_js() on every block editor screen in WP 6.9+, caused by an inline-script timing conflict with WordPress's new iframed editor asset collector.

Story: MWC-20359

Release: TBD

Details

WP 6.9+ introduced _wp_get_iframed_editor_assets(), which calls wp_print_footer_scripts() during block editor initialization — before admin_footer fires — incrementing the global did_action('wp_print_footer_scripts') counter. When render_admin_notice_js() subsequently runs at admin_footer:20, ScriptHelper::addInlineScript() sees the counter already elevated and triggers _doing_it_wrong.

The fix guards the call with did_action('wp_print_footer_scripts'): if it has already fired, the script is output directly via wp_print_inline_script_tag() (available since WP 6.0) instead of routing through ScriptHelper.

This affects all framework-based plugins on WP 6.9+, not just Memberships companion fix in the woocommerce-memberships repo (MWC-20359) applies the same guard to a plugin-specific override.

UI Changes

None.

QA

Setup

• WordPress 6.9+
• Any plugin using this framework version, active
• WP_DEBUG enabled

Steps

1. Open any post/CPT edit screen in the block editor
   • No _doing_it_wrong notice referencing ScriptHelper::addInlineScript appears in debug.log
2. Confirm the admin notice JS still runs correctly (notices dismiss/hide as expected)
   • No regression in notice behavior

• Code review

Before merge

• I have confirmed these changes in each supported minor WooCommerce version

[Copilot]

🟡 Changes recommended

The fallback can call an unavailable function on supported WordPress 5.6 installations.

1 open finding

• Avoid calling unavailable wp_print_inline_script_tag on WordPress 5.6 · New

What changed in this PR

Prevents block-editor admin notice scripts from triggering _doing_it_wrong on WordPress 6.9+.

Changes:

• Detects when footer scripts were already printed.
• Directly outputs the admin notice JavaScript in that case.

File	Description
woocommerce/​class-sv-wc-admin-notice-handler.php	Adds fallback script rendering after footer scripts run.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[smoen-godaddy]

Hi @agibson-godaddy , #864 is ready for review (Copilot’s WP 5.6 finding is fixed in the second commit). One question on merge order: Memberships #1313 is on framework 6.2.1, so picking up this fix through a new framework tag would mean a namespace upgrade. Since #1313 already has its own guard for the Memberships override, could it merge independently, with Memberships picking up #864 at its next framework upgrade?

[agibson-godaddy]

@smoen-godaddy Thanks for tracking this down. I confirmed the cause in core: _wp_get_iframed_editor_assets() calls wp_print_footer_scripts() against throwaway WP_Scripts instances, which bumps did_action('wp_print_footer_scripts') before admin_footer fires.

I'm not sure this is the right layer for the fix, though. The false positive comes from the guard in ScriptHelper::addInlineScript(), so every other caller of that helper (and every plugin using it) will still hit the notice in the block editor. I'd suggest fixing it once in the helper. In admin, check did_action('admin_print_footer_scripts') instead, since that only fires for the real footer pass. That would let this method go back to the single ScriptHelper::addInlineScript() call.

[smoen-godaddy]

Thanks. I’ve moved the fix into ScriptHelper::addInlineScript() and reverted the change to SV_WC_Admin_Notice_Handler::render_admin_notice_js() (including the WP 5.6 wp_print_inline_script_tag() fallback), so it goes back to the single helper call.

In admin, the helper now checks did_action('admin_print_footer_scripts'). I confirmed in core that admin_footer (line 78) fires before admin_print_footer_scripts (line 95), and that _wp_get_iframed_editor_assets() only calls wp_print_footer_scripts() directly, never admin_print_footer_scripts.
Front-end behavior is unchanged, and addInlinejQuery() inherits the fix since it delegates to addInlineScript().
I added ScriptHelperTest covering front end and admin, including the regression case (wp_print_footer_scripts fired, admin_print_footer_scripts not). CI is green.

One open point: the _doing_it_wrong message still says “before the wp_print_footer_scripts action,” which is slightly inaccurate in admin now. I can reword it (e.g. “before the footer scripts are printed”) if you’d like, please let me know.

[agibson-godaddy]

One open point: the _doing_it_wrong message still says “before the wp_print_footer_scripts action,” which is slightly inaccurate in admin now. I can reword it (e.g. “before the footer scripts are printed”) if you’d like, please let me know.

Yep let's reword it. We should be able to customize the message per-environment so that the hook name is accurate for both.