[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