fix: print WordPress 7 block styles in the head of Blade pages - #379
Merged
Merged
Conversation
This was referenced Oct 2, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Under WordPress 7, a classic theme loads block styles on demand: they are printed at
wp_footer, once the page's blocks are known, thenwp_hoist_late_printed_styles()moves them —global-stylesincluded — back into the<head>through the template enhancement output buffer.WordPress only starts that buffer at
wp_before_include_template, intemplate-loader.php. Pollora renders Blade views into a Laravel response and never includes a template, so on every Blade page:global-stylesand the block styles (wc-blocks-style…) were printed just before</body>, after the content they style (FOUC on slow connections);wp-block-styles-placeholder,wp-global-styles-placeholder).Measured on pollora-test (Apiary, WordPress 7.1.2) before the fix.
Fix
A
WordPressTemplateEnhancementmiddleware, last inWORDPRESS_MIDDLEWARE(soRoute::wp()and the template hierarchy), plays the buffer's part on the response instead of PHP's output:wp_template_enhancement_output_buffer_startedbefore the view renders (this is what hooks the hoisting);wp_template_enhancement_output_bufferfilter +wp_finalized_template_enhancement_output_bufferaction on the HTML content.WordPress's own
wp_should_output_buffer_template_for_enhancement()decides, so a site that opted out (to stream) is untouched. JSON, redirects, streamed and binary responses are left alone; a throwing callback is reported and the page sent as rendered, like core. Any plugin built on that filter now sees Pollora's pages too.Plain Laravel routes do not get the WordPress stack; one that prints
wp_head()/wp_footer()can add the middleware itself (noted in the CHANGELOG).Tests
WordPressTemplateEnhancementTest(7 cases). Full suite 1382 passed, PHPStan, Pint, Rector, type coverage 99 % (new file 100 %).styles.spec.tspublishes a post with a separator block and asserts that its style andglobal-stylesare in the head, with no placeholder left. Fails without the middleware, passes with it (checked locally).