How to Enable Debugging in WordPress for Aegisify

WordPress includes built-in debugging tools that can capture PHP errors, warnings, notices, plugin conflicts, and other technical issues. Aegisify Audit can retrieve this debugging information through the Aegisify Audit Agent, but WordPress, the Agent, and Aegisify Audit SaaS must all reference the same debug log file.

Instead of using the default /wp-content/debug.log, Aegisify supports a custom log location such as:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Using a custom filename also makes the debugging file less predictable than the standard debug.log filename.

Before You Begin

Before editing wp-config.php, create a recent backup of the website or make the change in a staging environment when possible.

You will configure the debug location in three places:

1. WordPress wp-config.php

2. Aegisify Audit Agent

3. Aegisify Audit SaaS

The path configured in all three locations must identify the same file.

For this example, we will use:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

---

Step 1: Access Your WordPress Files

Access the WordPress installation using one of the following:

• FTP or SFTP

• Your hosting provider’s file manager

• cPanel

• Plesk

• Another server-management interface provided by your host

Open the root directory of the WordPress installation and locate:

wp-config.php

---

Step 2: Configure the Custom Debug Log in wp-config.php

Open wp-config.php and look for an existing WordPress debugging configuration.

You may find:

define( 'WP_DEBUG', false );

Replace the existing debugging configuration, or add the new configuration before:

/* That's all, stop editing! Happy blogging. */

Use:

define( 'WP_DEBUG', true );

define(
    'WP_DEBUG_LOG',
    __DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'
);

define( 'WP_DEBUG_DISPLAY', true );

@ini_set( 'display_errors', 0 );

WordPress supports setting WP_DEBUG_LOG to a valid file path instead of only setting it to true. This causes WordPress debugging output to be written to the specified file rather than the standard /wp-content/debug.log.

In this example, the physical log file is:

<WordPress installation>/wp-content/path/to/file/file-dweih32afhi325oho23.txt

The corresponding portable path that will be entered into Aegisify Audit and the Aegisify Audit Agent is:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Do not enter __DIR__ into Aegisify Audit or the Agent. __DIR__ is PHP syntax used inside wp-config.php. Aegisify uses the WordPress-content-relative path beginning with /wp-content/.

---

Step 3: Save wp-config.php

Save the updated wp-config.php file.

If you are using FTP or SFTP, upload the modified file back to the WordPress installation.

The custom directory must exist and the WordPress/PHP process must be able to write the configured log file.

Your WordPress configuration should now point debugging to:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

---

Step 4: Configure the Same Path in Aegisify Audit Agent

In WordPress Administration, go to:

Aegisify Audit Agent → Agent Settings and Logs → WordPress Debug

Locate:

Location of Debug Log

Enter exactly:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Save the location.

The Agent path must match the file configured in wp-config.php.

After saving, the Protected Debug Log Viewer should read debugging information from that configured file.

If wp-config.php contains:

__DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'

the Agent must contain:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

---

Step 5: Configure the Same Path in Aegisify Audit SaaS

Log in to Aegisify Audit and open the WordPress logging page for the appropriate Target Domain.

Under:

Debugging

locate:

Location of Debug Log

Enter exactly:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Save the location.

The SaaS configuration and Agent configuration must be identical.

Correct:

WordPress:
__DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'

Aegisify Audit Agent:
/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Aegisify Audit SaaS:
/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Incorrect:

Agent:
/wp-content/debug.log

SaaS:
/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Aegisify intentionally requires the Agent and SaaS Debugging locations to agree so that a request cannot silently retrieve debugging information from a different file than the one configured for the site.

---

Step 6: Reproduce the Problem

Return to the WordPress site and repeat the action that generated the issue.

Examples include:

• Reloading the page that produced an error

• Submitting a form again

• Running the plugin feature that failed

• Repeating an administrative action

• Running a scheduled task

• Reproducing an AJAX or REST API failure

WordPress can record errors generated during requests that are not directly visible in the browser, which is one of the primary uses of WP_DEBUG_LOG.

---

Step 7: Verify the Protected Debug Log Viewer

Return to:

WordPress Admin → Aegisify Audit Agent → Agent Settings and Logs → WordPress Debug

Under:

Protected Debug Log Viewer

verify that entries from the custom file are displayed.

The Agent should now be reading:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

instead of assuming:

/wp-content/debug.log

If the expected entries do not appear, first verify that the path saved in the Agent is identical to the path configured in wp-config.php.

---

Step 8: Fetch the Debugging Log into Aegisify Audit

In Aegisify Audit, select the correct Target Domain and verify that Location of Debug Log is:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Then click:

Fetch WP Logs Now

The expected flow is:

WordPress
   ↓
Custom Debug File
   ↓
Aegisify Audit Agent
   ↓
Authenticated Aegisify Communication
   ↓
Aegisify Audit SaaS
   ↓
Debugging Ingestion and Analysis

The Agent retrieves the configured file and Aegisify Audit ingests the returned debugging information.

For this process to succeed, these locations must match:

wp-config.php:
__DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'

Agent:
 /wp-content/path/to/file/file-dweih32afhi325oho23.txt

SaaS:
 /wp-content/path/to/file/file-dweih32afhi325oho23.txt

If the Agent and SaaS paths do not match, correct the configuration before fetching again.

---

Step 9: Review the Latest Debugging Information

After the fetch completes, Aegisify Audit displays the retained Debugging information associated with the selected Target Domain.

Use the latest entries to investigate:

• PHP errors

• PHP warnings

• PHP notices

• Plugin failures

• Theme failures

• Background-processing errors

• REST or AJAX problems

• Scheduled-task failures

• Other WordPress application errors captured by the configured debug log

The physical debugging file remains on the WordPress server while Aegisify uses its authenticated Agent communication to retrieve the authorized debugging information.

---

Step 10: Turn Debugging Off When It Is No Longer Required

WordPress recommends debugging features primarily for development and troubleshooting rather than leaving them unnecessarily enabled on a production website.

When troubleshooting is complete, change:

define( 'WP_DEBUG', true );

to:

define( 'WP_DEBUG', false );

You can leave the custom file path documented so it is available the next time debugging is intentionally enabled.

---

Recommended Aegisify Debug Configuration

WordPress wp-config.php:

define( 'WP_DEBUG', true );

define(
    'WP_DEBUG_LOG',
    __DIR__ . '/wp-content/path/to/file/file-dweih32afhi325oho23.txt'
);

define( 'WP_DEBUG_DISPLAY', true );

@ini_set( 'display_errors', 0 );

Aegisify Audit Agent:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

Aegisify Audit SaaS:

/wp-content/path/to/file/file-dweih32afhi325oho23.txt

The important rule is:

The custom Debugging file configured in wp-config.php, Aegisify Audit Agent, and Aegisify Audit SaaS must all reference the same WordPress debug file.

Important Note About Displaying Errors

The configuration above uses:

define( 'WP_DEBUG_DISPLAY', true );

With WP_DEBUG_DISPLAY enabled, WordPress may display debugging messages in applicable page output. WordPress documents WP_DEBUG_DISPLAY as the control for whether debugging messages are shown in generated HTML.

If the objective is to log errors without displaying WordPress debugging information to website visitors, use:

define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

while keeping the same custom WP_DEBUG_LOG location.