Make WordPress Core

Opened 2 years ago

Closed 21 months ago

Last modified 20 months ago

#56068 closed enhancement (fixed)

Send HTTP headers after querying posts in WP::main()

Reported by: sergeybiryukov's profile SergeyBiryukov Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 6.1 Priority: normal
Severity: normal Version:
Component: Bootstrap/Load Keywords: has-patch needs-unit-tests needs-dev-note
Focuses: performance Cc:

Description

When trying to add or adjust some HTTP headers via the wp_headers filter or send_headers action, the $wp_query global is mostly empty and conditional tags don't work as expected, as posts have not been queried yet.

The earliest action where conditional tags like is_front_page() work correctly is currently wp.

In a discussion with @jonoaldersonwp and @joostdevalk it was pointed out that moving the send_headers() call after query_posts() in WP::main() would provide better context and more flexibility when manipulating HTTP headers. Implementing that seems to work in my testing, and all existing unit tests still pass.

If that happens, we could also move the X-Pingback header, which is currently sent in handle_404() after posts have been queried, as of [34442] / #20226, to a more appropriate place, which is send_headers() :)

However, that means sending headers after WP_Query runs all the post queries, filters, etc. and I'm curious if there are any performance considerations that should be taken into account here.

Attachments (2)

56068.diff (540 bytes) - added by SergeyBiryukov 2 years ago.
56068.2.diff (2.0 KB) - added by SergeyBiryukov 2 years ago.

Download all attachments as: .zip

Change History (10)

@SergeyBiryukov
2 years ago

#1 @peterwilsoncc
2 years ago

  • Focuses performance added

Adding the performance tag for the perf team to review.

The only back-compatibility issue I can see is if a developer is abusing a hook between the current send_headers location and the proposed relocation to exit early. I'm thinking something like this dreadful plugin to forbid certain query string parameters.

I do like this idea though, it will certainly help plugins determine if they need to send additional headers to avoid caching, indexing and the like.

#2 in reply to: ↑ description @SergeyBiryukov
2 years ago

Replying to SergeyBiryukov:

If that happens, we could also move the X-Pingback header, which is currently sent in handle_404() after posts have been queried, as of [34442] / #20226, to a more appropriate place, which is send_headers() :)

56068.2.diff addresses this part.

Instead of adding a new @since entry for X-Pingback header being moved back to WP::send_headers(), I think we can repurpose the existing one to describe more specifically what was done in [34442].

#3 @SergeyBiryukov
2 years ago

  • Milestone changed from Awaiting Review to 6.1

#5 @davidbaumwald
21 months ago

  • Milestone changed from 6.1 to 6.2

This still needs unit tests. With 6.1 Beta 1 releasing tomorrow, moving this to 6.2 for continued work.

#6 @SergeyBiryukov
21 months ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 54250:

Bootstrap/Load: Send HTTP headers after querying posts in WP::main().

By running WP::send_headers() after posts have been queried, we can ensure that conditional tags like is_front_page(), is_home(), etc. work as expected.

This provides better context and more flexibility when adjusting HTTP headers via the wp_headers filter or send_headers action.

Previously, the earliest action where conditional tags worked correctly was wp.

Includes moving the X-Pingback header, previously sent in WP::handle_404()​ after posts have been queried, to a more appropriate place in WP::send_headers().

Follow-up to [2627], [34442].

Props jonoaldersonwp, joostdevalk, peterwilsoncc, adamsilverstein, SergeyBiryukov.
Fixes #56068.

#7 @SergeyBiryukov
21 months ago

  • Milestone changed from 6.2 to 6.1

#8 @milana_cap
20 months ago

  • Keywords needs-dev-note added
Note: See TracTickets for help on using tickets.