Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128364
Content-Type: text/plain; charset=utf-8; format=flowed
Message-ID: <1754055407326.2742915832.1385540561@yahoo.de>
To: xepozzd@gmail.com
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [DISCUSSION] Json version of PHP Info
Date: Fri, 01 Aug 2025 16:19:33 +0000
In-Reply-To: <CANTuiHtE-kDwo7_YGjTZdkbNYo4Vzdy6qEr+XtfiywSAK=0ZNA@mail.gmail.com>
References: <CANTuiHtE-kDwo7_YGjTZdkbNYo4Vzdy6qEr+XtfiywSAK=0ZNA@mail.gmail.com>
User-Agent: Vivaldi Mail/7.5.3735.56
Content-Transfer-Encoding: 7bit
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)




On Tuesday 29 July 2025 09:12:13 (+02:00), Dmitry Derepko wrote:

 > Hi, Internals!
 > 
 > I want to have a unified function phpinfo() for any environment.
 > 
 > Currently phpinfo works different in CLI and SAPI modes:
 > - SAPI mode enforces the function print HTML tags
 > - CLI mode enforces the function print text as is
 > 
 > Here is implementation of the function:
 > 
https://github.com/xepozz/php-src/blob/5dd9b0dcef229c55f67044537b076c6e4320f28c/ext/standard/info.c#L760
 
> 
 > So I'd like to create a separate function phpinfo_json() which will dump
 > pretty much the same text as a json structure.
 > Use-case as simple as absurd:
 > - PHP/php -S serves the content as a SAPI mode
 > - RoadRunner/Queues/Workers which run PHP scripts as `php index.php` run 
it
 > as CLI mode
 > 
 > It's not convenient to see CLI-like output when you run a web server.
 > It's not possible to fetch some info from the function output
 > User should write parsers for both function variations: SAPI and CLI to
 > parse something
 > There is no need to use the output buffers to get the information.
 > 
 > New function output could be an array-like structure or a json string. 
It's
 > open to discuss. I'm okay with any or even both with a flag "$asArray"
 > 

Hello Dmitry,

Reading about your improvement suggestion and wanted to share some feedback 
and commentary.

IIRC both the internal webserver (since 5.4) and the CLI interface (since 
5.0/1?) are a SAPI module of their own, packaged into the PHP cli binary.

As on the CLI SAPI it makes very little sense to have HTML output, and the 
CLI-SERVER SAPI actually serves under the default_mimetype directive which 
is text/html, it is available in the hypermedia format.

That only for clarification that both are SAPI modules and the reason why 
you (and me) see a difference is because a SAPI module can tell it's own 
preference whether it wants to have shown the phpinfo() as HTML or text.

1.) Format is controlled by the SAPI module
2.) The only option a SAPI module has is to say it prefers text over the 
HTML.

This is the difference we see and that struck you as inconvenient.

What you are asking for as I understand it is an alternative format 
controlled by the language user, not the SAPI module. So that it is always 
available regardless which preference a SAPI module has.

I think application/json would be a good choice of such an additional / 
alternative user format for both kind of SAPI modules you are mentioning in 
your example. 

And I can imagine as well for most if not all of the other existing SAPI 
modules (dbg?), but that is likely to be checked when you prepare the 
implementation as all SAPI modules need to be able to interact with the PHP 
information, same as all PHP extensions need to do.

Right now your suggestion covers one example for a SAPI module that prefers 
text (php_sapi_name "cli") and another one that does not (php_sapi_name 
"cli-server"), and both would get an additional phpinfo() format.

I think this is a great idea, and I would love to see even more integrated 
support, e.g. `php -j` (free choice of mine for the example) on the 
command-line gives you the JSON output, pipe it to jq, gron or what not. 
Same requesting a phpinfo() index.php with an accept-media-type 
application/json giving the JSON, I won't complain about, not at all. Quick 
checks for provisioning scripts that the new binary is running? 
Configuration updates worked as intended?

If you're looking forward to also bring some bonus to the table, it would 
be great if there is a JSON format for ini settings/directives 
introspection. not only their names, configuration defaults, runtime 
defaults and current values (as there is in phpinfo() already and in array 
form with other information functions), but also of which type an ini 
setting is, like does it require/supports quoting of value or not, the 
exact schema per setting (IIRC bool, number, string, quoted string, and 
some have enum type like multiple known values that do fold, e.g. 0 off 1 
stdout 2 stderr + ini-bool for display_errors)

Existing PHP scripts out there in the wild (Composer, Phpunit etc.) have 
the problem when invoking PHP_BINARY they are grabbing all ini settings to 
simulate the configuration but fail to address the correct encoding of the 
ini settings. My educated guess is that happens because the PHP information 
functions do not provide these important details as for the classic SAPIs 
each instance was configured, so the dynamic information processing never 
needed. Now 30 years later we do see the trend that you also describe that 
PHP scripts are invoking PHP scripts more dynamically and have some 
introspection, e.g. gathering the PHP information and then working with it. 
Mind thought, that I only note it down here as your example remembered me 
of that and what I know is missing in that regard. It may not be feasible 
and how I read your example / proposal not part of it. That is also why I 
wrote "bonus", mind the feature creep and this likely needs more research 
and perhaps gathering some data from sources, so likely not within your 
original scope.

And you are right: If every one re-invents the wheel and writes a phpinfo() 
output parser (your project has a vendor folder above 1.5MiB size? most 
likely you have at least one of such libraries in there) instead of 
addressing it at the source.

Ah, and perhaps consider to align with the existing interface. The 
phpinfo() function has flags, e.g. phpinfo(INFO_ALL | 
INFO_JSON_ALL_THE_THINGS) would be great, but others more clever than me 
would need to chime in as the current default INFO_ALL is -1 (~0) so 
setting all flags but  INFO_JSON_ALL_THE_THINGS should not be automatically 
set because that wouldn't be backwards compatible. It's likely possible to 
solve, but I don't know about the code style and internals about such 
things.

Out of my guts, I would not recommend to add another phpinfo_XXX() function 
for the JSON format but solely extend the the existing interface.

Just my 2 cents

-- hakre