Blocks CSS additional CSS is missing on archive pages

[pirate-bot]

Summary

Blocks CSS additional CSS applied to blocks can be absent when those blocks appear on archive pages. The archive output is expected to retain the block-specific CSS configured in the editor, but the archive request does not collect CSS from the posts rendered in the archive loop. Affected archive entries therefore appear without their configured styling.

Customer context

Product / area: Blocks CSS, frontend archive rendering
Version: 3.2.5
Environment: WordPress version, theme, archive type, and PHP version were not provided
Integration / third party: None reported
Reported error / symptom: Additional CSS is not applied on archive pages
Impact: Archive content can render without block-specific styling
Usage context: The plugin had been active for 189 days before deactivation

Reproduction notes

Reported workflow:

1. Configure additional CSS for a block through Blocks CSS 3.2.5.
2. Publish content containing that block.
3. View an archive page that displays the content.
4. Observe that the configured CSS is absent.

Repository-confirmed limitation: the standalone frontend renderer processes at most one global post during wp_head and does not traverse archive-query posts. A runtime reproduction was not performed because the report does not provide the theme, archive type, or excerpt/full-content configuration.

Diagnosis

Conclusion

The standalone Blocks CSS frontend path does not collect custom CSS from all posts rendered by an archive query. In version 3.2.5 it runs during wp_head, gates processing on get_the_ID(), and parses only the current global post's content. Even if a global post is available at that point, the path has no iteration over the archive result set, so CSS belonging to other archive entries is omitted. This matches the reported archive-page symptom.

Where this likely occurs

• inc/class-blocks-css.php — Blocks_CSS::init() lines 25–36 registers render_server_side_css() on wp_head.
• inc/class-blocks-css.php — Blocks_CSS::render_server_side_css() lines 106–165 checks one get_the_ID(), reads one global $post, and parses only $post->post_content outside its narrow block-template branch.
• inc/class-blocks-css.php — Blocks_CSS::cycle_through_blocks() lines 176–210 extracts customCSS only from the supplied block tree, so archive posts not supplied by the caller cannot contribute their CSS.
• plugins/blocks-css/blocks-css.php — plugin header lines 10–22 identifies the reported standalone product and version 3.2.5.
• Closed issue Custom CSS styles missing on Archive pages #1373, Custom CSS styles missing on Archive pages, described the same symptom. It was closed in 2023 after limited testing and no additional reports, not because a source change was identified. The affected source path is still present in tag v3.2.5.

Engineering notes

The inspected defect is specific to the standalone Blocks CSS rendering path. When Otter Blocks is active, Blocks_CSS::add_css_to_otter() participates in Otter's separate CSS pipeline, so that combination has a different data flow. Archive behavior may vary by classic theme, block theme, and whether archive entries render full content or excerpts, but the standalone path does not enumerate multiple queried posts in any of those cases. WordPress core lifecycle details were not verified from local source; the confirmation does not depend on whether a first global post happens to be populated at wp_head, because the code still considers at most one archive post.

Test coverage status

No unit, integration, or end-to-end coverage for Blocks_CSS::render_server_side_css() or standalone archive CSS rendering was found during inspection. Existing CSS tests cover CSS utilities and file handling rather than this frontend archive path.

What to verify or explore next

• Reproduce with Blocks CSS 3.2.5 without Otter active, using a category or date archive containing at least two posts with distinct block-level custom CSS.
• Compare a classic-theme archive using full content with one using excerpts.
• Verify the same workflow with a block theme and an edited archive template.
• Check whether CSS is emitted for the first archive result, later results, or neither by inspecting the rendered page source.
• Run the relevant PHP and frontend suites if archive-path coverage is added.

Unknowns / follow-up

The feedback does not identify the archive type, theme, whether excerpts were used, or whether Otter Blocks was active alongside Blocks CSS.

Confidence

Confidence: 90/100

Version 3.2.5 source confirms that standalone Blocks CSS derives frontend CSS from only one global post during wp_head and does not traverse archive-query posts; the exact symptom was previously tracked in closed issue #1373, but the affected path remains in the reported release.

---

Source: automated uninstall feedback — blocks-css, 2026-09-20
Generated by bug-report-triage (ID: bug-report-triage_6ab0ba48227f36.80344460)

[girishpanchal30]

I have fixed it with PR #3070

[pirate-bot]

QA agent — 🟡 Needs human QA · Standalone archive CSS reaches every tested post, including after an unstyled first entry.

I installed standalone Blocks CSS and saved a block's custom CSS through the editor. On the classic archive, all four posts displayed their distinct styles; with the older base code, only the first post's rule appeared. An unstyled first entry no longer hid later CSS, locked posts did not expose theirs, and the block-theme archive retained all four rules. The PR's added PHP tests also passed.

Please still try

1. Try the customer's original theme, archive type, and excerpt settings when supplied; the report did not identify them.
2. Try the minimum supported WordPress 6.6 with this plugin; this run used WordPress 7.1.2.
3. Try an edited Site Editor archive template and block widgets if those generic PR checklist paths are important; only the stock block-theme archive was checked.
4. Try modified-attribute block copy/paste and measure Core Web Vitals in a production-like environment if the general PR checklist claims need separate validation.
5. Try an Otter-active archive only if compatibility with that separate unchanged CSS pipeline needs verification; this run targeted the standalone plugin.

Checks (6 passed)

• ✅ In standalone Blocks CSS, an editor can configure a paragraph block's additional CSS, publish the post, and reopen it with the CSS still saved.
• ✅ On a standalone Blocks CSS category archive displaying full posts, the first and all later published block entries retain their distinct additional CSS and visibly receive the corresponding styles.
• ✅ A standalone archive still emits and applies the later post's custom block CSS when its first post contains no blocks.
• ✅ Locked password-protected posts in the standalone archive do not expose their block's custom CSS, while public posts' CSS remains available.
• ✅ A single public post still includes its own additional CSS and does not include other posts' CSS.
• ✅ With a block theme active, a standalone category archive with multiple published block posts retains each post's distinct CSS in the page's emitted styles.

Full report, evidence and session trail

[rodica-andronache]

🤖 Automated QA Repro Steps

With the standalone Blocks CSS plugin (Otter not active), block-level Additional CSS only appears on archive pages for the first post in the list — every other post in the archive shows up unstyled. If the first post has no blocks, no custom CSS is printed for any post.

Reproduce on Blocks CSS 3.2.6 (Otter Blocks deactivated):

1. Create a category, e.g. "QA Archive".
2. Create three posts in that category, each with a Paragraph block. In each block's Custom CSS panel give it a distinct rule, e.g. selector { color: red; }, then blue, then green.
3. Publish all three.
4. Open the category archive (Posts → Categories → QA Archive → View).
5. Check each post's paragraph colour; optionally view the page source and search for color:.

• Bug: only the newest (first-listed) post's paragraph is coloured; the other two are default colour and their rules are missing from the page source.
• Fixed: all three paragraphs show their own colour, and each rule appears once in the page source.

Edge cases

• Make the newest post a plain (non-block) Classic post — the later posts still get their CSS.
• Password-protect one of the posts — its CSS is not printed on the archive; the others still are.
• Block theme (e.g. Twenty Twenty-Five) category archive — all posts keep their CSS.
• Single post view of each post — CSS still applies, no duplicated rules.
• Reactivate Otter Blocks — archive styling still works (Otter handles it through its own path).

Fix: #3070 (open)