How to Set Up bcons for PHP Debugging

bcons is a PHP debugging tool that displays log messages, errors, warnings, session data, cookies, and payload information in a browser console instead of raw server logs. Setup follows three steps: enable the bcons HTTP header in your PHP code, open the bcons console (via the browser devtools extension or the bcons website), and trigger your code so messages appear. This guide is for PHP developers who want real-time debug output in the browser rather than parsing error_log() output.

What bcons Does Before You Set It Up

bcons has two stated goals:

1. Display PHP messages in a clear, organized way.
2. Implement the browser Console API for PHP to make debugging more efficient.

Once active, any warning or error in your code is reported to the bcons console with the source file name, line number, and stack trace. Log messages appear in separate tabs with access to the time, domain, source file, and trace data.

Prerequisites

• A PHP application you can edit (to add the bcons header/enabling code).
• A browser where you can install the bcons devtools extension, or access to the bcons website console.
• The bcons library available to your PHP code (the page describes the mechanism but does not list install commands, so follow the setup instructions on bcons.dev for the current package).

Setup Steps

Step 1: Enable bcons in your PHP code

bcons works by sending an HTTP header that instructs the PHP code to enable sending error and debugging messages to the bcons console. Add the bcons enabling call to your PHP entry point or bootstrap file so the header is emitted on responses you want to debug.

Input: your PHP bootstrap or entry script. Action: include the bcons initialization so the HTTP header is sent. Expected result: responses from that script carry the bcons header, and the console is authorized to receive messages.

Step 2: Open the bcons console

The bcons console is available in two forms:

Open the console before or while you load the page you are debugging.

Step 3: Trigger your code and read the output

Load the page or run the request that executes your instrumented PHP. Messages, warnings, and errors appear in the console in real time.

Expected result: log messages, errors, warnings, session data, cookies, and payload information show up in separate tabs, each with time, domain, source file, and trace data.

What You Can Inspect After Setup

• Log messages and variable values at set points in your code.
• Errors and warnings, each with source file name, line number, and stack trace.
• Session data, cookies, and payload information — the page's example shows an order checkout request where the console surfaces the current user, the requested order ID, session userId, cookies (PHPSESSID, userLanguage), and the user's billing record, all as separate messages rather than one dense log line.

Practical Tips

• Ctrl+click any message element to copy it to the clipboard — useful for pasting a stack trace or payload into an issue or chat.
• The consoles shown on the bcons.dev page are live, so you can click around them to see how tabs and message details behave before wiring up your own code.
• Compare the output to the raw alternative: the same checkout flow above would otherwise appear as a single FastCGI stderr line mixing user info, payload, session, cookies, and redirect logic — hard to scan and easy to misread.

Common Setup Issues

• No messages in the console: confirm the bcons header is actually being sent on the response. If your code path exits before the enabling call runs (early redirect, fatal error before bootstrap), the header never goes out.
• Console open but empty for some requests: check whether the request you are testing passes through the file where you enabled bcons.
• Wrong environment: if you enabled bcons only in a local bootstrap, staging or production requests will not report to the console.

When This Setup Fits

Use bcons when you want browser-side, real-time visibility into PHP errors, warnings, and runtime data without tailing server logs. If your workflow depends on server-side log aggregation or you cannot modify the PHP entry point to send the header, this approach will not fit as-is.