[wp-trac] [WordPress Trac] #64613: Add HTTP header declaring theme, plugins, blocks, and possibly patterns on each page
WordPress Trac
noreply at wordpress.org
Sun Feb 8 00:06:09 UTC 2026
#64613: Add HTTP header declaring theme, plugins, blocks, and possibly patterns on
each page
-----------------------------+------------------------------
Reporter: paolal | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting Review
Component: AI | Version:
Severity: normal | Resolution:
Keywords: | Focuses:
-----------------------------+------------------------------
Comment (by westonruter):
My first thought is that some site owners would be concerned about
revealing "how the sausage is made" by exposing all of the information
about what theme, plugins, and blocks are used to construct a page. I see
there is an opt-out in the proposal, but I wonder if enabling this by
default would be a big red flag for users who are concerned about exposing
this information. For prior art, there is also the Site Health info which
includes a lot of this information. But it is requires an administrator to
access, as it can have sensitive information. That said, users are often
asked to share when requesting support. At the very least, it should be
omitted by default if a site owner has done `remove_action( 'wp_head',
'wp_generator' )`.
That said, why introduce a new `X-WordPress-Stack` HTTP response header
and not just add this information to the existing generator tag that
WordPress outputs? Currently it outputs:
{{{
<meta name="generator" content="WordPress 6.9.1" />
}}}
When Elementor is active, it includes much more information in its own
generator tag:
{{{
<meta name="generator" content="Elementor 3.35.3; features:
e_font_icon_svg, additional_custom_breakpoints; settings:
css_print_method-external, google_font-enabled, font_display-swap">
}}}
Performance Lab also does something similar:
{{{
<meta name="generator" content="performance-lab 4.0.1; plugins: auto-
sizes, dominant-color-images, embed-optimizer, image-prioritizer, nocache-
bfcache, speculation-rules, view-transitions">
}}}
If the page information were added to this existing `META` tag, then there
wouldn't be concerns about an HTTP header being too long.
Closely related to this is #49509 for adding `Server-Timing` to core. This
is implemented in the Performance Lab plugin at present, and a user has to
opt-in to adding timing granularity (e.g. how long it takes a given hook
to run).
Given that HTTP headers are sent before the template is rendered,
something closely related here would be the “template enhancement output
buffer” introduced in #43258. This would allow the header to be sent after
the template is rendered. When using the `META` tag, the HTML Tag
Processor could be used to amend the `content` attribute with how the page
was constructed. (This was similarly leveraged in 6.9 for classic themes
to hoist stylesheets printed in the footer to `HEAD` via #64099.)
--
Ticket URL: <https://core.trac.wordpress.org/ticket/64613#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list