Output replacement can fatal with nested output buffering

Start with inc/manager.php, especially start_capture_buffer(), captures_at_shutdown(), handle_buffer_fallback(), and replace_content(). Run the relevant cases in tests/test-zz-buffer.php, then compare the default behavior with commit d844ce28b008266c4560928260126954858e17d0 and v4.2.13. Done means the regression is reproduced or ruled out and coverage verifies that nested buffering in the active default path does not fatal.

Summary

Optimole page-processing requests are expected to complete normally. On affected requests, PHP terminates with Cannot use output buffering in output buffering display handlers instead, interrupting the frontend response or cron request.

Customer context

Product / area: Optimole page-content replacement
Version: Optimole 4.2.14; ThemeIsle SDK 3.3.62
Environment: WordPress 7.1.2; PHP 8.2.33
Integration / third party: The specific callback or integration involved is unknown.
Reported error / symptom: Optml_Manager::replace_content(): Cannot use output buffering in output buffering display handlers
Impact: The affected request terminates; two reported fingerprints are frontend requests and one is a cron request. Each fingerprint was observed on one site; overlap between sites is unknown.

Reproduction notes

Production telemetry reports the same fatal at SDK Promotions.php offsets 204 and 655 during frontend requests, and 1642 during a cron request. The precise callback and runtime configuration are unavailable, and a local runtime reproduction was not run. The inspected code reaches the reported failure condition when replacement runs in the output handler and a callback in that replacement flow attempts output buffering.

Diagnosis

Conclusion

The buffering fatal is consistent with Optimole processing page content from inside a PHP output-buffer display handler while a replacement callback uses output buffering. In the affected product line, Optml_Manager::handle_buffer_fallback() calls replace_content() in that handler by default. The same failure was previously tracked as issue #1126 and reported resolved in 4.2.12; the behavior was reintroduced in 4.2.14 and remains in 4.2.15. No open issue tracking this current regression was found.

Where this likely occurs

• inc/manager.php — Optml_Manager::start_capture_buffer() lines 935–939 registers handle_buffer_fallback() as the output handler.
• inc/manager.php — Optml_Manager::captures_at_shutdown() lines 951–964 defaults the shutdown-capture filter to false; Optml_Manager::handle_buffer_fallback() lines 982–993 then calls replace_content() from the display handler.
• inc/manager.php — Optml_Manager::replace_content() lines 503–548 runs the replacement flow and associated filters.
• tests/test-zz-buffer.php — Test_Buffer::test_default_processes_in_handler() lines 302–315 verifies the default handler mode; Test_Buffer::test_third_party_flush_with_ob_filter_does_not_fatal() lines 163–183 exercises a safe pass-through case with shutdown capture enabled.
• Git history: v4.2.13 has shutdown capture enabled by default; commit d844ce28b008266c4560928260126954858e17d0, included in v4.2.14, restores in-handler processing by default. The same behavior is present in v4.2.15.

Engineering notes

The three fingerprints report the same PHP error and the same product method, with different SDK source offsets and request contexts. The SDK offsets alone do not identify separate defects: in inspected src/Modules/Promotions.php, line 204 is in Promotions::load(), line 655 is in promotion data construction, and line 1642 is in Promotions::has_active_lms_plugin(); those locations do not call output-buffer functions. The exact callback that attempted the nested buffering is not included in the telemetry. This is routed to Codeinwp/optimole-wp because the implicated handler and replacement method are in the Optimole product. Closed issue #1126 concerns the same fatal in 4.2.11 and was marked resolved in 4.2.12; it is not an open issue covering the current 4.2.14+ regression.

Test coverage status

Relevant buffer lifecycle tests were found in tests/test-zz-buffer.php. They cover the default in-handler mode and nested buffering when shutdown capture is enabled, but no relevant coverage was found during inspection for a nested-buffer callback under the default mode that is active in 4.2.14 and 4.2.15. Tests were inspected, not run.

What to verify or explore next

• Reproduction may depend on a replacement callback that uses output buffering; the affected site's callback and plugin configuration are unavailable.
• The reported SDK offsets and exact call stacks may be worth correlating with full traces if they become available.
• The telemetry does not establish whether all three fingerprints came from the same site or integration.

Unknowns / follow-up

The telemetry lacks structured stack traces for these shutdown-detected errors, so the specific callback and trigger sequence remain unknown.

Confidence

Confidence: 93/100

The three buffering fingerprints share the same Optml_Manager::replace_content() fatal and are explained by one output-handler path reintroduced as the default in 4.2.14; it remains in 4.2.15, so the earlier closed report does not track the current regression. The timeout remains unconfirmed at 8 occurrences across 2 sites without a source-identified slow operation, and Optml_Media_Offload exists and resolves through the affected product's registered autoloader.

Crash telemetry

Fingerprint d370d7899bd2b5c32c1b5bef7b076168

Fingerprint 7ec8ad29348695dd97e8bb0b84f81d1a

Fingerprint 987880e67d9367b4ecfca9fc35fdefde

Source: automated crash report — optimole-wp, fingerprints d370d7899bd2b5c32c1b5bef7b076168, 7ec8ad29348695dd97e8bb0b84f81d1a, 987880e67d9367b4ecfca9fc35fdefde
Generated by bug-report-triage (ID: bug-report-triage_6abb54be3c1c94.91035943)