Confirm the intended WordPress installation and back up its wp-config.php. Check whether debug constants already exist; modify the existing definitions rather than adding contradictory duplicates.

Choose a writable log location outside the public document root where your service permits it. Replace the example path below with a real private path approved for the account. Do not assume the placeholder exists or create a publicly downloadable log by accident.

1. Use an authorised file-management method and place the settings before WordPress's stop-editing comment and bootstrap include.
2. Set the debug and logging values deliberately, keeping display disabled:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/private/path/wordpress-debug.log');
define('WP_DEBUG_DISPLAY', false);

3. Save the file without changing unrelated credentials or configuration.
4. Reproduce the failing task once and record the exact time.
5. Read the new log entries and confirm that the diagnostic information is not visible in the public response.

A log can contain account paths, request data or information written by plugins. Share only a sanitised relevant excerpt through the approved support channel. Do not publish the entire file or include passwords and tokens from request payloads.

Warnings and deprecation notices are not automatically the cause of a fatal failure. Match the entry to the test time and symptom, and inspect the component and stack trace where available.

Restore the intended production debug configuration, normally disabling temporary debug logging, and verify the site still works. Securely retain only the evidence needed for the support case and remove or rotate the temporary log according to your handling policy.

Leaving verbose logging active can increase storage use and expose sensitive details if permissions or web-server rules are wrong. Setting display false is useful, but verify the actual server response because other PHP configuration or code can still print information.

After carefully editing the existing debug constants in the correct wp-config.php, check its PHP syntax through an authorised shell where available. This command parses the file without running WordPress or displaying the configuration contents.

php -l /home/ACCOUNT/sites/example.com/wp-config.php

Use the appropriate PHP executable for the site. A successful syntax check does not prove that the private log path is writable or that no other code prints errors. Reproduce the original failing action once, note the time, inspect only the relevant new log entries, and verify the public response remains free of diagnostic details.

Expected result: The configuration remains syntactically valid and the expected event appears in the protected log. Restore the intended production debug settings after the diagnostic window, retaining only the sanitised evidence required to resolve the issue.

Check the chosen path, permissions and configuration placement. An early server-level failure may need the hosting PHP error log instead. Avoid setting directories to world-writable or pasting a whole configuration file into a ticket. Ask us to confirm the appropriate private logging route for the service when the path or access scope is unclear.

• Sharing a sanitised WordPress error log with support
• Reading a WordPress fatal error and identifying the component
• Using Site Health to collect useful WordPress diagnostics
• Troubleshooting redirect loops after enabling HTTPS

• WordPress: Debug WordPress
• WordPress: WP Debug Mode
• WordPress: WP Config

• PHP command-line options