davidpiesse/nova-phpinfo
Nova PHP Info adds a phpinfo() panel to Laravel Nova so developers can inspect their server's PHP configuration, loaded extensions, environment settings, and runtime details directly from the Nova dashboard, with no temporary phpinfo files needed.
Install the package:
composer require davidpiesse/nova-phpinfo
Register the tool (or card, depending on your Nova version) in app/Providers/NovaServiceProvider.php:
use Davidpiesse\NovaPhpinfo\NovaPhpinfo;
public function tools()
{
return [
new NovaPhpinfo(),
];
}
If the package ships publishable assets, publish them and rebuild Nova's frontend:
php artisan vendor:publish --provider="Davidpiesse\NovaPhpinfo\ToolServiceProvider"
php artisan nova:publish
Open Nova and look for the PHPInfo entry in the left sidebar. Clicking it renders the phpinfo() output directly inside the Nova shell.
First use case: quickly confirming which PHP version, SAPI, loaded extensions, and ini values an environment is actually running — without needing SSH or dropping a temporary phpinfo() file into public/. This is genuinely handy when you're debugging an "it works locally but not in staging" class of problem and need to verify, e.g., memory_limit, upload_max_filesize, or whether intl/gd/imagick are compiled in.
Environment-gated registration. The sensible way to use this package is to only register the tool outside production:
public function tools()
{
return array_merge(
[
// normal tools
],
app()->isLocal() || app()->environment('staging')
? [new NovaPhpinfo()]
: []
);
}
This keeps the phpinfo() surface out of production while still giving developers a one-click view in dev/staging.
Authorization via Nova gate. If you must run it in a shared environment, wrap it in Nova's viewNova gate or add a canSee check so only admins see the sidebar entry. Nova's Nova::auth() callback is the right place — not the tool itself, which has no built-in authorization.
Companion to php artisan about. Treat this as the visual counterpart to artisan about and artisan env. Where about gives you Laravel-level facts, this gives you PHP-level facts. Use it alongside a tool like nova-log-viewer or telescope when triaging environment-specific bugs.
Debugging workflows it fits well:
composer install in a container actually loaded the intended PHP version.opcache.enable, opcache.validate_timestamps) differ between app and queue workers.xdebug mode in local dev before chasing a performance issue.ini values across environments during an incident.Extension point (if you fork it). The underlying view just dumps phpinfo() output. If you need something narrower — say, only the "Core" and "Loaded Configuration File" sections — the simplest path is to copy the tool's controller/view into your app and register your own Nova tool rather than fight the package. Given the package's age, a local fork is likely the more sustainable pattern anyway.
Nova version compatibility is the big one. The last release is from January 2019, which predates Nova 3's frontend changes, and is far removed from Nova 4/5's Vite-based asset pipeline. Expect the tool to fail to mount, show a blank page, or 404 its compiled JS on modern Nova. If you're on Nova 2.x, it will likely work as-is; on Nova 4/5, plan to vendor or fork it and update webpack.mix.js/vite.config.js and the Tool.vue registration.
Security: never expose this publicly. phpinfo() leaks absolute paths, environment variables (potentially including DB credentials and API keys if they're exposed via getenv), server software versions, and compiled-in library versions. This is a genuine information-disclosure risk. Always gate registration by environment and, ideally, by role.
Asset publishing / cache. If you see a blank tool page or a broken sidebar item, in order:
php artisan nova:publishphp artisan config:clear && php artisan view:clearstorage/logs/laravel.log and the browser network tab for the tool's JS chunk.NovaPhpinfo class is actually in tools() (not cards() or vice versa — mis-registering produces a silently missing entry).Composer constraint conflicts. The package's composer.json was written against 2018-era laravel/nova and PHP. On current Laravel/PHP you may hit resolution errors; use --ignore-platform-reqs for a local install or, more honestly, fork the repo into your composer.json as a VCS dependency so you can bump constraints yourself.
Output is raw HTML and version-dependent. phpinfo() markup changes subtly between PHP minor versions, and the embedded CSS can collide with Nova's layout. On narrow screens the tables overflow. This is cosmetic but worth knowing before filing a bug — it's not something the package can generally fix.
No maintenance since 2019. With 13 stars and no commits in years, treat this as a frozen utility, not a supported dependency. If you need PHP-info visibility in Nova long-term, the cleanest option is a ~30-line custom Nova tool that calls phpinfo(INFO_GENERAL | INFO_CONFIGURATION) behind a gate — you'll get a maintained, auditable surface that matches your Nova version instead of fighting package rot.
How can I help you explore Laravel packages today?