Profiler

PHP Information in the Symfony Profiler

Learn how to use Symfony's PHP information view to inspect the web PHP runtime, configuration, extensions, environment values, request context, and web-versus-CLI differences.

The Symfony profiler's PHP information view exposes diagnostic details about the PHP runtime that served a browser request. It is useful when you need to verify PHP versions, configuration directives, loaded extensions, server context, and request-specific values.

This view combines two kinds of information:

• Application-level debugging information, such as Symfony request, routing, database, and performance data.
• PHP engine and server information, such as the PHP build, Server API (SAPI), configuration files, extensions, environment variables, and request metadata.

Because the output can include sensitive implementation details, use it only in trusted development or protected debugging environments.

Opening the PHP information view

The panel is available through Symfony's development profiling tools when the profiler is enabled. Load a Symfony page in a development environment, open the web debug toolbar, and select the PHP information link or panel. You can also use the profiler interface to open Phpinfo.

The exact toolbar appearance depends on the Symfony version and profiler configuration. The important point is that the information describes the PHP process handling the web request, not necessarily the PHP process used by terminal commands.

If the panel is unavailable, check that:

• The request is reaching the Symfony application.
• The application environment has the profiler enabled.
• The profiler package and web debug toolbar are installed and configured.
• Application or network access rules are not blocking the profiler.

What the page tells you about PHP

Runtime identification

The runtime section identifies the PHP process behind the request. Important fields include:

• PHP version: The version executing this web request. It determines language behavior, available features, security support, and extension compatibility.
• Build information: Compilation options, operating-system details, compiler information, and linked libraries.
• Architecture: Commonly 32-bit or 64-bit. Architecture can affect available memory, binary extensions, and native dependencies.
• Thread safety: A build may be thread-safe or non-thread-safe. This matters primarily for how PHP is embedded in a server and which binary packages are compatible.
• Zend Engine details: The Zend Engine executes PHP code. Its version and related details help identify the engine underneath the PHP release.
• Server API: The interface through which PHP runs. Typical values include FPM/FastCGI, Apache module, CGI, and CLI.

SAPI means Server API. A browser request commonly uses PHP-FPM through FastCGI, while a terminal command uses the CLI SAPI. Different SAPIs can load different configuration files, extensions, environment variables, and permissions even when they are installed on the same machine.

Configuration files and load order

php.ini is PHP's primary configuration file. The information page reports the path to the loaded file and usually identifies an additional configuration directory, often called the INI scan directory. Files in that directory are configuration fragments loaded after the main file.

Effective settings can also be influenced by other layers:

1. The main php.ini file establishes base values.
2. Additional INI files can change or add directives.
3. Per-directory or virtual-host settings may apply to web requests.
4. PHP-FPM pool configuration can set web-process values.
5. A web server or hosting layer may provide PHP settings.
6. Application code can change directives at runtime when the directive permits it.

When a directive is shown with both a local value and a master value, the local value is the effective value in the displayed request context. The master value is the base value before a request-, directory-, pool-, or runtime-level override. For debugging, the local value is normally the one that matters.

Do not assume that editing a file named php.ini changes the web runtime. First identify the configuration path reported by the browser request, then inspect additional scanned files and higher-precedence settings.

Frequently inspected PHP settings

Search the PHP information page for a directive rather than reading the entire output manually. The following settings often explain application behavior:

Upload limits apply at more than one level. upload_max_filesize limits an individual file, while post_max_size limits the complete request body, including all files and form fields. Therefore, post_max_size should be larger than the largest permitted file. For example:

memory_limit = 256M
upload_max_filesize = 20M
post_max_size = 24M
date.timezone = UTC

Also inspect max_input_time when slow uploads or request parsing are involved. A directive's changeability determines whether application code can alter it at runtime. Some directives are available only in system, directory, or administrative contexts, so changing them in application code may have no effect.

Loaded extensions and Symfony dependencies

An extension is a compiled or dynamically loaded PHP module that adds functionality. The PHP information page lists loaded modules and commonly provides their versions or capability details.

For a Symfony application, commonly relevant extensions include:

• curl for HTTP requests and integrations.
• intl for internationalization, locale-aware formatting, and translation-related operations.
• mbstring for multibyte string handling.
• openssl for TLS and cryptographic operations.
• pdo with pdo_mysql or pdo_pgsql for database access.
• xml for XML processing and packages that depend on XML facilities.
• zip for archive handling and some package-management workflows.
• sodium for modern cryptographic operations.
• OPcache for PHP bytecode caching.

An operating-system package can be installed without being loaded by the web PHP runtime. The browser view is the authoritative check for the request-serving SAPI. If an application reports that intl is missing, search the browser output for the intl section, note whether it is loaded, and compare that result with the CLI module list.

Environment and request context

PHP diagnostics may expose several categories of request data:

• Server variables: Web-server and request values such as host, protocol, port, document root, script name, and server software.
• Environment variables: Values passed into the PHP process, including application configuration and sometimes secrets.
• Cookies: Browser cookies sent with the request.
• Request metadata: HTTP method, headers, query data, form data, client address, and proxy-related values.
• PHP variables: Runtime and request information exposed by PHP.

This information can confirm whether the request used the expected web server, proxy, host, protocol, document root, and request path. It is useful when diagnosing HTTPS termination, reverse proxies, incorrect trusted-proxy configuration, wrong virtual hosts, and requests reaching an unexpected container.

Comparing web PHP with CLI PHP

The PHP binary used by bin/console, Composer, or a terminal command may not be the PHP binary serving browser traffic. PHP-FPM is a FastCGI Process Manager commonly used for web requests; CLI PHP is a separate SAPI and process type.

Use these commands for the CLI side of the comparison:

php --version
php --ini
php -m
php -i | grep -i '^memory_limit\|^upload_max_filesize\|^post_max_size'

Then compare the results with the browser information view. Also consider separate container images, separate hosts, different extension directories, distinct FPM pools, and different deployment targets.

After changing PHP-FPM configuration, the existing worker processes may continue using the old values. Restart PHP-FPM or the applicable web service, then reload the profiler page:

sudo systemctl restart php-fpm

The exact service name varies by operating system and installed PHP version. A web-server restart may also be required when PHP runs as an Apache module or when the server owns the relevant configuration.

Practical diagnostic examples

Missing intl extension

1. Open the PHP information panel for a browser request.
2. Search for intl and confirm whether the extension is loaded.
3. Record the web PHP version, SAPI, configuration file, and extension directory.
4. Run php -m in the terminal and compare the CLI result.
5. If only CLI has the extension, install or enable it for the web PHP runtime and restart the relevant PHP-FPM or web-server service.

Large uploads fail

1. Inspect the effective upload_max_filesize and post_max_size.
2. Confirm that post_max_size is larger than the file limit and accounts for the complete request.
3. Check max_input_time for slow request parsing and memory_limit when application processing needs substantial memory.
4. Change the configuration used by the web runtime, restart the serving process if required, and reload the information page.

A configuration change has no effect

1. Identify the loaded php.ini path in the browser output.
2. Review the additional INI scan directory and its fragments.
3. Compare the directive's local and master values.
4. Check PHP-FPM pool settings, virtual-host settings, container variables, and runtime overrides.
5. Restart PHP-FPM or the applicable web service, then verify the effective value again.

Timezone-dependent dates are incorrect

1. Locate the effective date.timezone directive.
2. Distinguish PHP's default timezone from an application-configured timezone. Symfony or another library may explicitly configure its own timezone.
3. Confirm the desired value in the web runtime, not only in CLI PHP.
4. Use a consistent timezone policy, commonly UTC for server-side storage and processing, while applying presentation timezones deliberately.

Security and production safety

A PHP information page is a diagnostic facility, not a production status page. It may reveal PHP and extension versions, build flags, filesystem paths, document roots, server software, internal hostnames, environment variables, request headers, cookies, and configuration locations. These details help an attacker identify software and deployment weaknesses.

• Keep the Symfony profiler disabled outside trusted development or protected debugging environments.
• Restrict profiler access with application authentication, network controls, or both.
• Never expose a standalone public script that calls phpinfo().
• Remove accidental diagnostic scripts from deployed document roots.
• Redact diagnostic output before sharing it.
• Rotate credentials or tokens if they appear in output that unauthorized people could access.

Troubleshooting checklist

Profiler information is unavailable

• Confirm that the application is running in an environment where the profiler is enabled.
• Verify that the profiler package and toolbar are installed and configured.
• Check application and network security rules.
• Confirm that the request passes through Symfony rather than being served directly by the web server.

The displayed setting differs from php.ini

• Review the configuration path and scanned INI files reported by the web runtime.
• Compare local and master values.
• Check FPM pool, virtual-host, directory, container, and runtime overrides.
• Compare the browser output with php --ini and php -i; the terminal may be inspecting CLI PHP.

New configuration is not reflected

• Verify that the edited file is the one reported by the web runtime.
• Restart the process serving PHP requests.
• Check for a higher-precedence configuration source.
• Confirm that the request is reaching the intended host, container, and PHP-FPM pool.

Sensitive values are visible

• Restrict diagnostic access immediately.
• Rotate exposed secrets when appropriate.
• Review which environment variables and request headers are supplied to the application.
• Remove any standalone diagnostic script and verify that no public route exposes equivalent output.

Exam-relevant notes

• phpinfo reports the runtime, build, configuration, extensions, request, and environment details available to PHP.
• The Symfony profiler view describes the PHP runtime serving the browser request.
• SAPI identifies how PHP runs; FPM/FastCGI and CLI can use different binaries and configuration.
• The effective local value is generally more important for a request than the master value.
• post_max_size limits the complete POST body and should accommodate upload_max_filesize.
• An extension installed on the machine is not necessarily loaded by the web SAPI.
• Configuration changes may require restarting PHP-FPM or the web server.
• PHP information output is sensitive and must not be publicly exposed in production.