What you’ll do: Replace the default phpinfo() page with a searchable, dark-mode-friendly version and learn how to query the same PHP config data in code.

Who this is for: PHP developers, Laravel users, WordPress admins, and server troubleshooters who need to inspect PHP settings without digging through raw output.

Time: About 10 to 15 minutes.

Quick Answer

Install stechstudio/phpinfo with Composer, then call prettyphpinfo() instead of phpinfo(). You get a cleaner interface with search, dark mode, click-to-copy values, and the option to inspect the same data through STS\Phpinfo\Info::capture() when you need local versus master config values in code.

The default phpinfo() page is useful, but it looks like it escaped from a different decade and brought no search box with it. If you only need one trick from this package, make it this: turn that unreadable wall into something you can actually use while debugging deployments, extensions, upload limits, and environment mismatches.

This guide is based on the official package docs on GitHub, the package page on Packagist, the product site at prettyphpinfo.com, and the April 2026 write-up on Laravel News.

What you need before you start

  • A PHP project that uses Composer.
  • PHP 8.3 or newer, plus the ext-dom extension, as listed on Packagist.
  • Access to a local dev route, test script, or temporary admin-only endpoint.
  • A basic understanding of how to remove or protect debug routes when you are done. Showing full PHP info publicly is still a bad idea, just with better typography.

Why this trick is better than plain phpinfo()

According to the official docs, prettyphpinfo() is a drop-in replacement that adds instant search, dark mode, click-to-copy values, deep links, and no external asset requests. More importantly, the package also parses phpinfo() output into a queryable structure, which lets you inspect modules, directives, local values, and master values without stitching together ini_get(), extension_loaded(), and a small pile of annoyance.

Step 1: Install the package with Composer

  1. Open your project root in a terminal.
  2. Run:
composer require stechstudio/phpinfo

Expected check: Composer installs the package without dependency errors, and your autoloader updates normally.

Step 2: Replace phpinfo() with prettyphpinfo()

If you already have a debug script or route that uses phpinfo(), swap it for prettyphpinfo().

<?php

require __DIR__ . '/vendor/autoload.php';

prettyphpinfo();

In Laravel, a quick route example looks like this:

use Illuminate\Support\Facades\Route;

Route::get('/info', function () {
    prettyphpinfo();
});

Expected check: Visiting the page shows a modern PHP info screen with search, clearer layout, and a much more readable structure than the built-in output.

Step 3: Limit the output if you do not want to expose everything

The package accepts the same INFO_* constants as native phpinfo(). That means you can show only the sections you actually need.

prettyphpinfo(INFO_MODULES);

That is useful when you want to confirm loaded extensions or module settings without dumping environment variables and every other detail onto the page.

Expected check: Your page shows a narrower slice of PHP info, such as modules only, instead of the full kitchen sink.

Step 4: Capture the data in code when you need answers, not just a page

This is where the trick gets more interesting. The package can capture and query the same configuration data programmatically.

use STS\Phpinfo\Info;

$info = Info::capture();

echo $info->version();
var_dump($info->hasModule('mysqli'));
echo $info->config('post_max_size');
echo $info->config('post_max_size', 'master');

Per the official docs, the default config lookup returns the local or effective value, and passing 'master' returns the php.ini default when available.

Expected check: You can print values like your PHP version, confirm whether a module is loaded, and compare the effective upload limit against the master default.

Step 5: Use it to spot local versus master config mismatches

One of the most useful real-world checks is comparing what PHP is currently using against what the base config says.

use STS\Phpinfo\Info;

$info = Info::capture();

echo 'Effective: ' . $info->config('memory_limit') . PHP_EOL;
echo 'Master: ' . $info->config('memory_limit', 'master') . PHP_EOL;

This helps when a setting looks wrong in production because of pool overrides, per-directory config, or different PHP SAPIs. Native ini_get() only gives you the effective value, so this comparison is the part many people end up needing anyway.

Expected check: You can clearly see whether the live value differs from the master value from your base config.

Step 6: Iterate through modules and configs when you need a broader audit

The official docs also show that modules, groups, and configs are iterable. That makes it easier to inspect a whole chunk of PHP configuration without hardcoding every directive name.

use STS\Phpinfo\Info;

$info = Info::capture(INFO_MODULES);

foreach ($info->modules() as $module) {
    echo '<h2>' . $module->name() . '</h2>';

    foreach ($module->configs() as $config) {
        echo $config->name() . ': ' . $config->value() . '<br>';
    }
}

Expected check: Your script can loop through detected modules and output config values without manually listing them one by one.

Step 7: Remove or protect the route after testing

This package makes PHP info safer to work with, but it does not make public exposure safe. Once you confirm what you need, either remove the route, restrict it behind auth, or limit it to local environments.

For Laravel, that usually means wrapping the route in an environment check, admin middleware, or both.

Expected check: Your debugging page is no longer publicly reachable after you finish troubleshooting.

Common mistakes

  • Leaving the info page public: readable leaks are still leaks.
  • Forgetting the requirements: this package needs PHP 8.3+ and ext-dom.
  • Using full output when modules-only would do: show less when less is enough.
  • Assuming local and master values are always the same: they often are not, especially on shared or layered configs.
  • Skipping Composer autoloading in plain PHP: if you are outside a framework, include vendor/autoload.php first.

Troubleshooting

You get “undefined function prettyphpinfo()”:
Make sure the package installed correctly and your script loads Composer’s autoloader with require __DIR__ . '/vendor/autoload.php';.

The package will not install:
Check your PHP version and confirm ext-dom is enabled. The requirements are listed on Packagist.

You only need extension details, not the full page:
Use prettyphpinfo(INFO_MODULES) so you expose less data and get to the useful part faster.

You need to inspect saved phpinfo output from another machine:
Use Info::fromHtml(), Info::fromText(), or Info::detect() as shown in the official docs.

You are comparing CLI and web values and they do not match:
That can be normal. Different SAPIs can load different configs, so capture the output in the same environment you are actually debugging.

Where this trick helps most

  • Checking whether an extension like Redis, OPcache, or mysqli is really loaded
  • Comparing upload, memory, and execution limits during deployment debugging
  • Reviewing PHP config in a cleaner browser UI during client or team troubleshooting
  • Building small diagnostic tools that query PHP config values directly in code

Try this next

Install the package in a local or staging project, replace one old phpinfo() page with prettyphpinfo(INFO_MODULES), and test one config lookup with Info::capture(). If it saves you even one round of hunting through raw output, the trick already paid for itself.

Related reads