Debugging PrestaShop 9 HTTP 500 Errors Without Public Debug Mode

An HTTP 500 response tells you that a request failed on the server. It does not identify the failing layer, and it does not justify exposing a debug page to every visitor. The fastest useful investigation starts by narrowing the request and correlating private evidence.

For a PrestaShop 9 store, the failure may occur before the application initializes, inside a module, during template rendering or after a business operation has already changed data. Those cases require different recovery decisions. This workflow keeps customer-facing error output separate from the information engineers need.

For regressions encountered while evaluating a release candidate, use the isolated RC1 staging workflow to reproduce the failing request away from production side effects.

Establish the incident boundary before changing configuration

Record the first known failure time, affected hostname, request method, page or operation and whether the problem affects all users or one scenario. Include the most recent deployment or configuration change, but treat it as a lead rather than a proven cause.

Ask whether the failed request could have produced a side effect. Retrying a product page is different from repeating an order submission or a fulfillment action. If the request may have committed work, inspect the resulting state before replaying it.

Preserve a short evidence window around the failure. Logs can rotate, deployments can replace source files and repeated requests can obscure the original sequence. Copy only the relevant material into restricted incident storage according to your operating process.

Avoid changing several things at once. Disabling modules, clearing every cache and restarting services may temporarily change the symptom while destroying the ability to identify the cause. Make each intervention answer a specific question.

If the store is severely affected, apply the established containment or rollback procedure while preserving evidence. Diagnosis and service recovery can proceed together, but neither should depend on showing internal exceptions to customers.

Locate the request in the web-server evidence

Start with the access log for the actual virtual host or reverse proxy serving the request. Confirm the timestamp, path, method and status. If a proxy is involved, distinguish its response from the upstream application response where the configured logs provide that information.

Log paths are deployment-specific. PrestaShop’s Nginx documentation provides example access and error log locations, explicitly requiring adaptation to the server. Do not assume those example paths match your host. Official Nginx configuration example.

Find the corresponding error log entry. A missing upstream socket, denied file access or unavailable worker points to a different layer from an application exception. A web-server error can occur before PrestaShop has an opportunity to write its own log.

For Apache, inspect the active virtual-host configuration and the host’s configured error destination. For containers, the relevant output may be collected from standard streams by the runtime rather than written to a conventional host file.

Keep URLs and query strings private when they contain tokens or customer information. A support report usually needs the route and sanitized parameters, not the entire raw request.

Read PHP-FPM and application logs as complementary evidence

PHP errors and application exceptions do not necessarily share one destination. Inspect the active FPM pool configuration, PHP error settings and application logging configuration rather than guessing a universal filename.

PHP-FPM supports pool-specific logging controls and a slow-request log, but a slow log is not a substitute for the error evidence explaining a fatal failure. Use each source for the question it answers. PHP-FPM configuration reference.

Within the PrestaShop deployment, locate the configured Symfony or application log handler and its environment-specific destination. Look for the first relevant exception and its preceding context. A later rendering exception can be a consequence of an earlier failure, not the original cause.

Compare runtime contexts. A successful CLI command does not prove that the web process uses the same PHP version, extensions, environment or permissions. If the failure occurs only through HTTP, inspect the web runtime rather than relying on php --version from an administrator’s shell.

Check file ownership and access using the actual service account’s expected permissions. Do not resolve a permission error with broad world-writable permissions. Identify the specific directory or file and restore the intended deployment ownership.

Keep error logging enabled and public display disabled

PHP distinguishes logging errors from displaying them in the response. A typical production intention is represented by these PHP configuration directives:

display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL

These are PHP directives, not a complete PrestaShop configuration or an instruction to overwrite an existing host-managed file. Apply them through the deployment’s supported configuration mechanism, confirm the effective web-runtime values privately and ensure the log destination is writable and access-restricted. PHP error-configuration reference.

Keep PrestaShop’s own production/debug setting appropriate as well. PHP display settings alone do not guarantee that an application will not render its own debug exception page. Use the project’s configuration documentation and inspect the actual response after a controlled test. PrestaShop configuration reference.

Do not publish a phpinfo() page to discover the effective configuration. Use the host’s private diagnostic facilities or a tightly controlled internal method, and remove temporary diagnostics when the investigation ends.

Logging every warning indefinitely can create noise and storage pressure. Preserve the evidence needed for diagnosis, then address repeated errors and maintain normal rotation. The solution is not to hide the original fatal error from the engineering team.

Correlate one request across components

Timestamps help, but a request identifier is more reliable when several requests occur together. If your infrastructure already generates and propagates a trusted identifier, include it in application and integration logs.

Do not blindly trust an arbitrary client-supplied header as the authoritative identifier. Validate or replace it at a trusted boundary, and avoid letting it contain control characters that can corrupt log structure.

For a module you maintain, structured diagnostic context can include a request ID, shop ID, operation name and exception class. Avoid logging credentials, full payment payloads or entire customer records. The goal is to connect evidence, not to copy the database into logs.

If correlation was not configured before the incident, do not pretend it can be reconstructed perfectly. Use time, route, process information and sanitized entity identifiers to narrow the match, and state the remaining uncertainty.

A useful incident timeline distinguishes request arrival, application failure, any external call and the final response. This can reveal the critical case where an operation completed but the response failed afterward.

Reproduce privately and change one cause at a time

Build a private reproduction environment with the same application and module revisions and a minimal synthetic fixture. Preserve the relevant configuration while isolating mail, payments and other external effects.

If necessary, enable detailed application debugging only in that restricted environment. The public store can continue using its normal error response while engineers inspect a full trace privately.

For a module-related exception, identify the first frame belonging to your code and the input or dependency that violates its expectation. Do not assume the last module named in a trace caused the problem; it may simply be the caller that encountered an invalid state.

Apply one focused correction and rerun the original sequence. Then exercise an adjacent case likely to share the same boundary. A fix for a missing combination value should include a product with and without a combination, not an unrelated tour of every Back Office page.

If the issue only occurs under concurrent requests, preserve that condition in the reproduction. A single-threaded success does not disprove a race that requires overlapping writes.

A useful support handoff contains the sanitized request timeline, affected revision, first relevant exception and the smallest reproduction. Include what was checked and ruled out, but distinguish evidence from assumptions. “No matching application entry was found in this configured destination” is more precise than “the application did not log anything.” The entry may have gone to another process or handler.

Also state whether the original operation’s business outcome is known. That single fact helps the next engineer decide whether a replay is safe or whether reconciliation must happen first.

Verify recovery at the business level

After deploying the correction through the normal process, confirm that the original operation succeeds and that new matching failures stop appearing. Check more than the HTTP status: inspect the order, saved configuration or integration result the request was meant to produce.

Reconcile requests with uncertain outcomes before replaying them. An HTTP 500 after payment or order persistence can leave valid business data even though the browser saw failure. Recovery should not create duplicate charges or orders.

Keep the deployment revision and verification time in the incident record. If the error recurs, those details distinguish a failed fix from a new issue with a similar symptom.

Remove temporary diagnostic changes, confirm that customer responses do not expose traces and retain the minimal evidence needed for support. Write a brief cause-and-prevention note: the failing assumption, the trigger, the correction and the test that now covers it.

Private diagnostics are not less informative than public debug mode. With the right request boundary, log correlation and controlled reproduction, they provide better evidence while keeping the live storefront’s behavior predictable.

For the underlying platform context, see our PrestaShop 9 system requirements and apply the version-specific checks above to the installation you are evaluating.