Frontend header rendering can exhaust memory while collecting hooked markup #4674

Summary

A frontend request on Neve 4.2.17 exhausted PHP memory while rendering the header. The expected behavior is for the frontend request to render without a fatal error within the site's available memory; instead, PHP reported that the 15 MiB limit was exhausted while an additional 2 MiB was being allocated. The affected request failed.

Customer context

• Product / area: Neve theme, frontend header rendering
• Version: 4.2.17
• Environment: WordPress 7.1.3; PHP 8.2.35; reported PHP memory limit 15 MiB
• Integration / third party: Not provided
• Reported error / symptom: Allowed memory size of 15728640 bytes exhausted (tried to allocate 2097152 bytes) at header.php:107
• Impact: 15 occurrences across one site in the telemetry window; frontend requests failed.

Reproduction notes

No manual reproduction or structured stack trace was provided. Telemetry reports the failure on a frontend request running Neve 4.2.17 at header.php:107. The site configuration, header-hook callbacks, and their output are unavailable; a comparison against v4.2.16 under the same conditions has not been performed.

Diagnosis

Conclusion

Neve 4.2.17 adds an output buffer around the header hooks and converts all captured output to a string at the reported fatal line. This creates a new in-memory retention step on the affected path and is consistent with the reported memory exhaustion. The exact callback output and memory usage before reaching this line are unknown, so the connection is strongly supported by the code path and version timing but is not a site-level reproduction.

Where this likely occurs

• header.php — header.php template, approx. lines 87–107: starts buffering, runs the before-header, header, and after-header hooks, then collects the accumulated markup into a string.
• Commit a4aab6352331047a851fc1926f06e53bd57901b5, included in v4.2.17, introduced this buffering path; the preceding v4.2.16 header template emitted the hook output without this collection step.

Engineering notes

The buffer is started before the hook calls and is collected whether the regular header is enabled or disabled. Thus output from callbacks, including integration callbacks, remains in memory until the collection operation. The single-site report and 15 MiB configured limit constrain the demonstrated scope; telemetry did not capture a stack trace or callback output details.

Test coverage status

tests/test-neve-global-header-footer.php — test_header_wrapper_is_rendered_when_enabled() approx. lines 295–300 and the disabled-header hook tests approx. lines 348–371 — verify rendered markup and hook retention. No relevant memory-pressure or large-hook-output coverage was found during inspection.

What to verify or explore next

• Check whether the fatal recurs with Neve 4.2.17 when header callbacks emit substantial markup under a 15 MiB memory limit.
• Compare frontend memory use and outcome between v4.2.16 and v4.2.17 with the same callbacks and site configuration.
• Identify which callbacks and output were active on the reported site, if that telemetry becomes available.

Unknowns / follow-up

The callback source and size of buffered markup are unavailable. The amount of PHP memory already in use before the header template runs is also unknown.

Confidence

Confidence: 80/100

Neve 4.2.17 introduced output buffering on the reported header path, and the first fingerprint fails at the buffer-to-string operation; the webfont-loader fingerprint lacks evidence of a product defect and is omitted.

Crash telemetry

Source: automated crash report — neve, fingerprint 536b7af6a49954c3a01c455e52c022d8
Generated by bug-report-triage (ID: bug-report-triage_6adeed36f411c7.94695975)