Some hosts restrict write access to wp-config.php, the viewer directory, or debug.log beyond what GridPane or Flywheel use. WP Debug Toolkit’s (WPDT) permission elevation mechanism resolves this automatically for wp-config.php by temporarily changing its permissions to 0644, completing the write, and restoring the original value immediately afterward. Elevation works on hosts with a genuine file permission restriction, but not on hosts with a platform-level lock like Flywheel.
If WPDT can’t resolve the restriction through elevation, it reports that wp-config.php is not writable and cannot be temporarily elevated or the Site’s Health panel shows the Config Permissions, Viewer Permissions, or Log Permissions check in a failing state. A passing check shows wp-config.php at 0644, the viewer directory at 0755, and debug.log at 644 or lower. Common causes include security-hardened hosting configurations, file ownership that does not match the PHP process user, and non-standard umask settings.
When you save a debug constant or memory limit setting and wp-config.php is not already writable, WPDT attempts elevation automatically as part of that single save action. There is no separate elevation step you trigger yourself for wp-config.php.
WPDT first reads the file’s current permission value and stores it. It then changes the file’s permission mode to 0644. If the file becomes writable at that mode, WPDT proceeds with its normal backup-and-atomic-write sequence: it creates a one-time backup, writes to a temporary file, validates the result, and renames the temporary file into place.
Once the write attempt finishes, whether it succeeded or failed partway through, WPDT restores the file’s original permission value immediately. That restoration runs as a guaranteed cleanup step, and not as something you need to do manually. Therefore, a save attempt never leaves wp-config.php sitting at a different permission level than it started with.
This same elevate, check, and restore pattern also runs non-destructively when the Site’s Health checks evaluate whether elevation would work: WPDT briefly applies the permission change, checks writability, then restores the original value without performing any write at all. That non-destructive test produces a passing Config Permissions result, with a note that the plugin automatically elevates permissions when saving settings.
If WPDT changes wp-config.php to 0644 and the file is still not writable, the most common cause is that the PHP process doesn’t own the file, or the host blocks chmod() outright, as Flywheel does at the platform level.
When this happens, WPDT restores the original permission value immediately and does not attempt the write. Settings stored in the WordPress database still save normally, but the corresponding wp-config.php constant is not updated, and WPDT logs a warning naming the file, its current permissions, and a note that you may need to set the constant manually through your hosting control panel.
On the Site’s Health panel, the same failure shows as a Config Not Writable result, naming the current and expected permission values and recommending you contact your hosting provider. This check does not offer a Fix Permissions button the way Viewer Permissions does, because elevation for wp-config.php is tested and applied automatically during a save action rather than triggered by a manual repair button.
✅ Key Guarantees
wp-config.php to its original permission value after an elevation attempt, whether the write succeeded or failed.wp-config.php in a less secure state than it started in, since elevation is reversed even when the underlying write throws an error.| Term | What It Means |
|---|---|
| Permission Elevation | WPDT’s temporary chmod to 0644 followed by a restore, used to write to wp-config.php when its existing permissions block a direct write. |
| 0644 / 0755 | The two correct permission values WPDT checks for. 0644 applies to wp-config.php and other individual files; 0755 applies to the standalone viewer directory. |
| Directory Permission Repair | A separate, permanent correction WPDT can apply to the viewer directory when its permissions are too restrictive. Unlike elevation, this repair is not reversed afterward. |
| Config Not Writable | The Site’s Health status shown when wp-config.php is unwritable and elevation to 0644 fails to resolve it. |
There is nothing to configure. Permission elevation for wp-config.php runs automatically whenever a save attempt finds the file unwritable, and WPDT restores the original permission value as soon as the write finishes. See Permission Elevation for the complete write-and-restore sequence. If you’re troubleshooting a specific host, Flywheel Compatibility covers the one environment where elevation cannot work, and GridPane Compatibility covers a host where elevation isn’t needed at all.
Likely cause: The PHP process doesn’t own wp-config.php, or the host blocks chmod() at the platform level, the same restriction Flywheel enforces.
Fix: Confirm with your host whether file ownership matches the PHP execution user. If the host blocks chmod() entirely, you’ll need manual SSH or SFTP permission changes, or support intervention from your host, to make the file writable.
Likely cause: debug.log has permissions looser than 644, which the Log Permissions check flags regardless of whether the file is otherwise writable.
Fix: Correct the file to 644 or lower. WPDT does not auto-elevate or auto-repair debug.log permissions, so an administrator with SSH or SFTP access should make this change manually.
Elevation works when the restriction is a genuine file permission issue that chmod can resolve. It doesn’t work when the host enforces a platform-level lock, like Flywheel does, that ignores chmod regardless of what permission value WPDT requests.
No. Permissions are adjusted only for the duration of the write to wp-config.php and restored to their original value immediately afterward, including when the write fails partway through.
Permission Elevation – Walk through the complete write-and-restore sequence behind the mechanism explained here.
Flywheel compatibility – Find out why Flywheel’s platform-level lock blocks elevation entirely, and what to do instead.
GridPane compatibility – See how GridPane sidesteps the problem altogether by redirecting writes to a separate file.
