rubrojas06

Hi there @evermight,

Thanks for the very detailed report, including the exact line of minified code that helps a lot.

What’s happening technically: the Accordion block is built on WordPress’s newer Interactivity API, and the error you’re seeing is a known category of hydration race condition. When the page loads, the block’s JavaScript needs to build its accordionItems context array before any click can look up the clicked item by id. If a click happens (or the script re-runs) before that context is fully populated which can happen if scripts load “too fast” (before the DOM/context is ready) or “too slow” (if something delays the script further, causing a mismatch) .find() returns undefined, and accessing .isOpen on it throws exactly the error you’re seeing. This lines up with other race-condition issues already being tracked in the Interactivity API’s WordPress 6.9 iteration work.

Unfortunately is not something you can fix completely (well, not that I know of), however I can give some steps to somehow try to mitigate it.

Steps to narrow it down and mitigate for now:

1. Update WordPress to the latest 6.9.x minor release if you haven’t already, the Accordion block and Interactivity API are actively receiving bug fixes since they’re relatively new in core.
2. Check for caching/minification/defer-loading plugins (e.g. WP Rocket, Autoptimize, Perfmatters, or similar). Anything that changes the loading order or defers/async-loads core block scripts can trigger this exact timing issue. Try temporarily disabling script optimization/defer settings for view.min.js / block library scripts and see if the error stops.
3. Test with all other plugins disabled (you’re already on the default Twenty Twenty-Five theme, which is good) to confirm no plugin is interfering with script loading order.
4. Check if you have multiple Accordion blocks with duplicate content/IDs on the same page (for example, from copy-pasting or pattern reuse) duplicate context IDs can also cause the lookup to fail unexpectedly.
5. Since this looks like a genuine core bug rather than something fixable on your end, please consider reporting it on the Gutenberg GitHub repository with your reproduction steps, WordPress version, theme, and the exact console error this will help the Core team confirm and prioritize a fix:
   https://github.com/WordPress/gutenberg/issues

Reference:

• Interactivity API iteration for WordPress 6.9 (tracking issue): https://github.com/WordPress/gutenberg/issues/70883
• WordPress Interactivity API docs: https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/

If disabling caching/defer plugins resolves it, that would be very useful information to include in a GitHub bug report, let me know what you find and if the tips worked!

• This reply was modified 15 hours, 2 minutes ago by rubrojas06.

Hi @twelsy ,

Thanks for sharing the details. This notice means WooCommerce/plugin background tasks handled by Action Scheduler aren’t running on schedule usually because WP-Cron isn’t firing reliably, or because one task got stuck and is blocking the queue behind it (Action Scheduler processes actions one at a time by default).

Steps to diagnose and fix:

1. Go to Tools -> Scheduled Actions (the page you already found), filter by Pending, and try running a few of the oldest ones manually (there’s a “Run” link per row). If they complete successfully, the queue just needs a manual kick and the backlog should start clearing.
2. Sort/check the Hook column on that same page if most stuck actions share the same hook name, that points to a specific plugin (e.g. an SEO plugin, WooCommerce import task, etc.) that may be misbehaving. If so, try updating that plugin first, since older versions often have known issues with scheduled actions getting stuck.
3. Check Tools -> Site Health -> Info -> Scheduled Events / Loopback requests. If Site Health reports a loopback request problem, something on your server (a security plugin, firewall, or your host’s caching layer) is likely blocking the requests WordPress needs to trigger cron and Action Scheduler.
4. Check your wp-config.php for this line:

   define('DISABLE_WP_CRON', true);

If it’s there, WordPress’s built-in cron is disabled, and you need a real server-side cron job configured through your hosting control panel to hit wp-cron.php every 5 minutes, otherwise these tasks will never fire on their own and will keep piling up.
5. Make sure WordPress core, your theme, and all plugins (especially WooCommerce, if installed) are fully updated some past versions had known bugs causing this exact pile-up.
6. If a single action has been stuck “in-progress” for a long time (check the Status column), that one is likely blocking everything behind it. You can cancel/delete that specific one from the list to unblock the queue.

Reference documentation:

• Action Scheduler FAQ (official): https://actionscheduler.org/faq/
• WooCommerce guide on Scheduled Actions: https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/scheduled-actions/

If after trying steps 1–4 the count keeps climbing instead of going down, reply here with a screenshot of the Hook column from your Pending actions list that will help narrow down which plugin is causing it. Hope this helps!

Hi Shane,

Thanks for the very detailed report that made it much easier to narrow down. Based on your tests (fresh install, default theme, no plugins, and the HTML comparison you posted), this looks like it’s related to a change introduced in WordPress 7.0, not a plugin/theme conflict.

Here’s what’s likely happening:

1. WordPress 7.0 expanded “contentOnly” editing mode to unsynced patterns and template parts. The Core team specifically flagged the Buttons block as one of the blocks that received targeted contentOnly changes and may behave differently than before.
2. Your original pattern uses a standalone wp:button block without the standard wp:buttons wrapper <div class="wp-block-buttons">. This is valid block markup, but it’s not the structure WordPress normally generates (buttons are always inserted inside a wp:buttons group). It looks like the new contentOnly logic in 7.0 doesn’t handle this non-standard structure correctly, which is why the pattern shows up in the inserter but can’t actually be inserted.

Steps to work around this while it gets confirmed as a bug:

1. Edit your pattern’s HTML (via the Code editor / “Edit as HTML” option in the block editor, or Appearance -> Patterns -> your pattern -> Code editor) and wrap the button in a proper wp:buttons block, like this:

<!-- wp:buttons -->
<div class="wp-block-buttons"><!-- wp:button {"className":"ewww-button aligncenter"} -->
<div class="wp-block-button ewww-button aligncenter"><a class="wp-block-button__link wp-element-button" href="https://ewww.io/fake-link/" rel="">Fake Text!</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons -->

This matches the structure of your working pattern and should let it insert normally.

2. If you’d rather keep testing the original structure, you can try disabling contentOnly mode for unsynced patterns via the new disableContentOnlyForUnsyncedPatterns block editor setting (added in 7.0), using the block_editor_settings_all filter. This is more of a debugging step than a permanent fix, but it will confirm whether contentOnly mode is indeed the cause.
3. Since this reproduces on a fresh install with a default theme and no plugins, I’d recommend reporting it on the Gutenberg GitHub repo (https://github.com/WordPress/gutenberg/issues) with your exact HTML and reproduction steps — this looks like a genuine bug rather than something you can permanently fix on your end.

Reference: Pattern Editing in WordPress 7.0 — Make WordPress Core: https://make.wordpress.org/core/2026/03/15/pattern-editing-in-wordpress-7-0/

Let me know if wrapping the button in wp:buttons resolves it, that will help confirm the diagnosis!