Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Output replacement can fatal with nested output buffering

Đang mở
  • Có gì không ổn?
#1,163 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php, wordpress
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug bug-report bug-report-triage crash-report

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
Occurrences 155
Distinct sites 1
First seen 2026-09-26 12:35 UTC
Last seen 2026-09-28 21:58 UTC
Crash location sdk:src/Modules/Promotions.php:204
Request context frontend
Inside Themeisle SDK yes
Product versions 4.2.14
WP versions 7.1.2
PHP versions 8.2.33
SDK versions 3.3.62

Fingerprint 7ec8ad29348695dd97e8bb0b84f81d1a
Occurrences 63
Distinct sites 1
First seen 2026-09-26 12:33 UTC
Last seen 2026-09-29 00:26 UTC
Crash location sdk:src/Modules/Promotions.php:655
Request context frontend
Inside Themeisle SDK yes
Product versions 4.2.14
WP versions 7.1.2
PHP versions 8.2.33
SDK versions 3.3.62

Fingerprint 987880e67d9367b4ecfca9fc35fdefde
Occurrences 6
Distinct sites 1
First seen 2026-09-26 18:37 UTC
Last seen 2026-09-28 16:30 UTC
Crash location sdk:src/Modules/Promotions.php:1642
Request context cron
Inside Themeisle SDK yes
Product versions 4.2.14
WP versions 7.1.2
PHP versions 8.2.33
SDK versions 3.3.62

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

Ngôn ngữ chính
PHP
Star
74
Fork
14
Merge trung bình
2 ngày 12 giờ
Pull request đã merge (30 ngày)
21

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Codeinwp/optimole-wp

Tất cả issue của Codeinwp/optimole-wp

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.