Skip to content

Development diagnostics

Greg Bowler edited this page May 17, 2026 · 1 revision

WebEngine leaves a few useful traces behind during development so you can inspect what happened during a request without turning the whole application into a debugging exercise.

Response headers

One of the most useful diagnostics is the X-Logic-Execution response header.

When page logic runs, WebEngine records the functions that executed and writes them into that header in order. The values use a compact path:function format, for example:

  • page/index:go
  • page/account/settings:go_before
  • page/account/settings:do_save_profile

This is especially useful when shared logic, component logic, and page-specific logic are all involved in the same response. Instead of guessing which hooks actually ran, you can inspect the response headers in your browser's network tools and see the exact order.

Redirect handling can also expose development-oriented header information, which helps trace where a redirect rule came from.

Buffered debug output

If page logic or supporting code writes direct output with echo, var_dump, or similar calls, WebEngine captures that output instead of letting it corrupt the page response.

In development, that captured output can be surfaced through browser-side debugging support rather than becoming part of the page body. That makes accidental debug output easier to notice while still keeping the response shape intact.

This is useful while investigating a problem, but it should not become the normal way application pages communicate data. For normal behaviour, page logic should still bind data into the view model or set response state explicitly.

Practical use

When a request does not behave as expected, a good first pass is:

  • inspect the response status
  • inspect response headers such as X-Logic-Execution
  • check whether a redirect happened
  • look for captured debug output
  • then move on to application logs if needed

That usually gives enough signal to tell whether the problem is in routing, page logic, redirect rules, or lower-level application code.


Continue with the request-response lifecycle, or read about Errors and logging.

Clone this wiki locally