Attach AJAX requests to the existing debug bar

[snapshotpl]

Closes #41, supersedes #40 (thanks @mostafasy for the report and the original patch).

The bug

Every AJAX response repeated renderHead() and the initialization code, so the browser built a second debug bar on top of the one the main request had already created — the stacking @tyrsson described in #41 — instead of adding the AJAX request as a dataset of the existing bar.

Requests carrying X-Requested-With: XMLHttpRequest now render only render(false), which php-debugbar displays as an (ajax) dataset.

Two things differ from #40:

• maximebf/debugbar is not pinned to an exact version (see below).
• shouldReturnResponse() keeps deciding on its own. AJAX request should not render the initialization code. #40 changed it to shouldReturnResponse(...) && ! $isAjax, which would attach the bar to AJAX responses even when X-Enable-Debug-Bar: false was sent. A test covers this case now.

The wrapper page built for non-HTML responses keeps its head and initialization code — it is a standalone document, not a fragment inserted into an already initialized page.

Dependencies

maximebf/debugbar minimum goes from ^1.4 to ^1.18. Releases before 1.18.0 miss #[\ReturnTypeWillChange] on DebugBar's ArrayAccess methods and fatal on load under PHP 8.1+, which this package claims to support (1.16.5 and 1.17.0 were verified to fail as well). The whole 1.x line stays allowed — no exact version.

Since 1.18 the DataFormatter goes through symfony/var-dumper's VarCloner, and its oldest allowed release (2.6) breaks on PHP 8.0, so there is now a require-dev floor for it. It only affects our lowest-dependency CI jobs, not consumers.

CI

The test container did not register MiddlewareFactoryInterface / RequestHandlerRunnerInterface, so MezzioTest failed against current Mezzio with ServiceNotFoundException.

The workflow now runs on pull requests, covers PHP 8.2 and 8.3, and drops the retired actions/checkout@v2 / ramsey/composer-install@v1.

PHP 7.3 and 7.4 leave the matrix. This is not caused by anything in this branch — the same failure reproduces on master. Composer 2.10, which setup-php installs today, only accepts laminas-diactoros 2.18.1+ as a provider of psr/http-factory-implementation, and those releases require PHP 8.0+:

Root composer.json requires psr/http-factory-implementation ^1.0
  -> satisfiable by laminas/laminas-diactoros[2.24.2, 2.25.2, 2.26.0].
  -> laminas/laminas-diactoros ... requires php ~8.0.0 || ~8.1.0 ...

So the dev dependencies can no longer be installed on 7.3/7.4 with a current Composer (an explicit laminas/laminas-diactoros: ^2.14 dev constraint does not help either). PHPStan moves to PHP 8.0 for the same reason. Whether "php": "^7.3 || ^8.0" in composer.json should follow is a separate support-policy decision and is left untouched here.

The lowest jobs run on PHP 8.0 only: Slim 3.0, Pimple 3.0 and vfsStream 1.6.8 predate PHP 8.1 and fatal on load there, and raising those dev bounds is not an option either, because the first Slim 3 release supporting PHP 8.1 (3.13.0) requires PHP 8.1.

Verification

Ran locally in Docker with Composer 2.10: highest on PHP 8.0, 8.1, 8.2, 8.3 and lowest on 8.0 — 30 tests each, plus PHPStan level 6 on src/. The new AJAX behaviour is covered by unit tests and by a case in AbstractMiddlewareRunnerTest, so it is asserted against both Mezzio and Slim 3.

🤖 Generated with Claude Code