Atomic Wind base CSS enqueue crashes when global post is a WP_Term

[pirate-bot]

Summary

Atomic Wind can trigger an uncaught TypeError while assets are enqueued if the current global content object is a term rather than a post.

Expected behavior: The asset-enqueue request completes without attempting post-content checks on non-post objects.

Actual behavior: The request terminates with a TypeError stating that post_has_atomic_wind_blocks() received WP_Term where WP_Post is required.

Impact: Affected frontend requests fail before the page header finishes rendering.

Customer context

• Product / area: Otter Blocks, Atomic Wind base CSS
• Version: 3.2.0
• Environment: WordPress 7.0.4, PHP 8.2.31
• Reported error / symptom: Uncaught TypeError in post_has_atomic_wind_blocks() because WP_Term was supplied for its post parameter
• Impact: 5 telemetry occurrences across 1 site between 2026-08-30 and 2026-08-31; request context was frontend.

Reproduction notes

1. Enable Atomic Wind blocks.
2. Load a frontend context where the global $post is a WP_Term during enqueue_block_assets (the precise route is unavailable from telemetry).
3. Otter Blocks 3.2.0 calls its Atomic Wind base-CSS enqueue callback.

Observed: Telemetry records an uncaught TypeError at this callback. Reproduction status: confirmed from the production stack trace and matching v3.2.0 source; no isolated local runtime reproduction was run.

Diagnosis

Conclusion

Production telemetry identifies enqueue_base_css() as the caller and records a WP_Term passed to the WP_Post-typed post_has_atomic_wind_blocks() method. The v3.2.0 source has that unguarded call, directly confirming the reported TypeError path.

Where this likely occurs

• inc/plugins/class-atomic-wind-blocks.php — Atomic_Wind_Blocks::run() approx. lines 46-47 in v3.2.0 registers enqueue_base_css() on enqueue_block_assets.
• inc/plugins/class-atomic-wind-blocks.php — Atomic_Wind_Blocks::post_has_atomic_wind_blocks() lines 73-75 in v3.2.0 declares \WP_Post $post.
• inc/plugins/class-atomic-wind-blocks.php — Atomic_Wind_Blocks::enqueue_base_css() lines 163-166 in v3.2.0 reads global $post and forwards any truthy object to that typed method without an object-type check. This exactly matches the telemetry location and caller line.
• inc/plugins/class-atomic-wind-blocks.php — Atomic_Wind_Blocks::output_cached_css() lines 259-266 in v3.2.0 contains a separate unguarded use of the same global, but it is not part of the supplied crash stack.

Engineering notes

• The crash occurred on a frontend request. The supplied stack reaches wp_enqueue_scripts through wp_common_block_scripts_and_styles and a WooCommerce template, then reaches enqueue_base_css().
• A non-null global $post is not guaranteed by this component's code to be a WP_Post; the telemetry provides the observed WP_Term case.
• The current checkout is v3.2.3, where enqueue_base_css() has a different frontend branch. The issue-facing evidence is specifically the released v3.2.0 implementation captured by telemetry.
• This is not established as a regression: v3.1.11 contains the same typed helper and the same unguarded global $post call in enqueue_base_css().

Test coverage status

tests/test-atomic-wind-blocks.php includes test_enqueue_base_css_registers_frontend_style_without_enqueuing_it() at lines 1497-1510 and other enqueue_base_css() callers around lines 1348, 1358, and 1441. No WP_Term or taxonomy-archive coverage was found during inspection.

What to verify or explore next

• Reproduce an asset-enqueue request with Atomic Wind enabled while the global $post holds a WP_Term.
• Check taxonomy, WooCommerce term, and other archive contexts that can establish a non-post global object before enqueue_block_assets.
• Run the Atomic Wind PHPUnit suite after adding a non-post global-object scenario.

Unknowns / follow-up

• The telemetry does not include the exact route, taxonomy, or plugin interaction that populated the global object with a term.
• The supplied crash stack establishes enqueue_base_css() only; whether output_cached_css() is reachable with the same object type remains unverified.

Confidence

Confidence: 98/100

Behavior inventory contained one independently testable failure: a frontend request can terminate when Atomic Wind's base-CSS enqueue callback receives a WP_Term instead of a post. Production telemetry provides a matching uncaught TypeError, and the v3.2.0 source passes the unvalidated global object into a WP_Post-typed method.

Crash telemetry

Occurrences	5
Distinct sites	1
First seen	2026-08-30 00:38 UTC
Last seen	2026-08-31 18:11 UTC
Crash location	product:inc/plugins/class-atomic-wind-blocks.php:73
Request context	frontend
Inside Themeisle SDK	no
Product versions	3.2.0
WP versions	7.0.4
PHP versions	8.2.31
SDK versions	3.3.58

---

Source: automated crash report — otter-blocks, fingerprint c4660c6d9f9dfb13c83a96b1a2573c34
Generated by bug-report-triage (ID: bug-report-triage_6a966a600ba843.09783045)

[selul]

Verified against the current development branch: the frontend path now returns before reading the global post, and the remaining typed helper calls are all gated by a WP_Post check. The reported 3.2.0 crash is therefore already covered by the current implementation.