[DISCUSSION] Json version of PHP Info

Just want to remind you about the topic.
If everyone has no objections I'll create an RFC during the next week.

--
Best regards,
Dmitrii Derepko.
@xepozz

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