fix: initialize interactions when configure runs after init (caching/defer plugins)

[bfintal]

Summary

Fixes gambitph/WP-Interactions#4 — interactions/animations sometimes don't start on the frontend when a caching/defer plugin (e.g. SiteGround Speed Optimizer with Minify JavaScript + Defer Render-blocking JavaScript) is active. The page loads but nothing animates until InteractRunner.init() is run manually.

Root cause

There's a race between InteractRunner.configure() (builds the interactions, output as an inline script) and InteractRunner.init() (scheduled by frontend.js on domReady).

• Normal load: the inline script runs configure() synchronously, then DOMContentLoaded runs init(). Order is correct.
• With defer/combine: the main bundle is deferred, so the inline "checkRunner" script can't find InteractRunner yet and starts polling every 10ms. When the deferred bundle finally runs frontend.js, the DOM is already parsed so domReady fires immediately and schedules init() at +1ms. init() wins the race and runs against an empty interactions list; configure() builds the interactions ~10ms later, but nothing calls init() again → inert page.

Fix

Make the runner order-independent in src/frontend/scripts/class-runner.js:

• Track _isInitialized (set in init(), cleared in destroy()).
• If configure() runs after init() already ran, initialize the freshly-built interactions immediately.

The normal path is unchanged (configure() runs first, _isInitialized is false, no extra init).

Test plan

• Build and load a page with an interaction (e.g. "On hover, fade out element") with no caching plugin — verify it still works.
• Enable SiteGround Speed Optimizer with Minify JavaScript Files + Defer Render-blocking JavaScript, load in incognito, and repeatedly trigger the interaction — verify it now consistently works without manually calling InteractRunner.init().
• Verify no duplicate event listeners / double-init in the normal (non-cached) flow.

Made with Cursor

Summary by CodeRabbit

• Bug Fixes
  • Improved interaction initialization when configuration occurs after startup.
  • Ensured interactions are correctly reinitialized after being destroyed and recreated.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[coderabbitai]

Warning

Review limit reached

@bfintal, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 55 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 68fb342a-dbb8-46d7-825b-80f9c63584b2

📥 Commits

Reviewing files that changed from the base of the PR and between fdd250a and 29ffe32.

📒 Files selected for processing (1)

• src/frontend/scripts/class-runner.js

📝 Walkthrough

Walkthrough

InteractRunner now tracks whether initialization has completed, initializes interactions added by later configuration, and clears the state when destroyed.

Changes

InteractRunner lifecycle

Layer / File(s)	Summary
Initialization state and late configuration src/frontend/scripts/class-runner.js	InteractRunner initializes _isInitialized to false, re-runs initialization after late configuration, marks initialization complete after init(), and resets the flag during destroy().
Estimated code review effort: 2 (Simple)	~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the init-order fix for deferred or cached frontend script loading.
Linked Issues check	✅ Passed	The change addresses #4 by initializing newly configured interactions even when plugins defer script execution.
Out of Scope Changes check	✅ Passed	The patch stays focused on interaction initialization state and does not add unrelated behavior.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/caching-defer-init-race

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🤖 Pull request artifacts

file	commit
pr36-interactions-36-merge.zip	29ffe32

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.