WDD File Permission Reset
A dashboard tool for finding and fixing incorrect WordPress file and folder permissions — the quiet cause behind a lot of broken updates, blank pages after a migration, and "failed to write file" errors.
Every run is broken into small batches, so it stays responsive whether your site has a few hundred files or several hundred thousand. Nothing changes on disk until you explicitly click Reset — and even then, only within the WordPress install itself, never outside it.
| r | w | x | |
|---|---|---|---|
| owner | ✓ | ✓ | ✓ |
| group | ✓ | – | ✓ |
| other | ✓ | – | ✓ |
| r | w | x | |
|---|---|---|---|
| owner | ✓ | ✓ | – |
| group | ✓ | – | – |
| other | ✓ | – | – |
Features
Ten modules, working together as one dashboard page under Tools → File Permission Reset.
Dashboard Overview
WordPress root path, file owner, PHP process user, writability, and totals from your last run — the context you need before touching anything.
File Permission Scanner
Walks the install once, comparing every file and folder against your target permissions, without changing a thing.
Dry Run
Runs the exact batch process a real reset would use — same progress bar, same live log — with nothing written to disk.
Permission Reset
Applies the change for real, behind a confirmation prompt. This is the only mode that calls chmod().
Progress Indicator & AJAX Batching
Every action runs in small requests with a live progress bar. If one is interrupted, running it again resumes automatically instead of starting over.
Export Reports
Download a complete plain-text report of any run — counts, timestamps, and a full list of anything that couldn't be changed.
Activity Logs
A running history of your last 25 scans, dry runs, and resets, so you can see what's changed over time.
Settings
Default permissions, what to reset, symlink and hidden-file behaviour, and batch size — all adjustable without editing code.
Help & Documentation
A short in-dashboard guide covering recommended order of operations and common questions, kept right where you need it.
Installation
-
Upload the plugin
Copy the
wdd-file-permission-resetfolder into/wp-content/plugins/, or install the zip directly through Plugins → Add New → Upload Plugin. -
Activate it
From the Plugins screen, activate WDD File Permission Reset like any other plugin.
-
Open the dashboard page
Go to Tools → File Permission Reset. You'll land on the Dashboard Overview.
Recommended workflow
These three actions run the same underlying process in three different modes — go through them in order the first time.
-
Scan Only
Get the full count of what's correct and what isn't, with nothing modified. This is the safest place to start.
-
Dry Run
Watch the batch process itself — the progress bar, the live log of "would change" items — so you can see exactly what Reset would do before it does it.
-
Reset WordPress Permissions
Apply the change for real. You'll get a confirmation prompt first, and a full results summary with a downloadable report afterward.
Settings
| Setting | Default | What it does |
|---|---|---|
| Folder permission | 0755 |
Target permission applied to every directory that needs a change. |
| File permission | 0644 |
Target permission applied to every file that needs a change. |
| Reset folders / Reset files | Both on | Turn either off to limit a run to just files or just folders. |
| Follow symbolic links | Off | When on, symlinked directories are walked into and symlinked files are considered — but a link resolving outside the WordPress install is still never touched. |
| Ignore hidden files | On | Skips dotfiles and dot-folders (like .env) beyond the ones already hardcoded below. |
| Ignore uploads folder | Off | Excludes all of wp-content/uploads, not just its cache subfolder. |
| Ignore caching-plugin folders | On | Adds known cache directories from popular caching plugins to the exclusion list. |
| Batch size | 300 | Items processed per AJAX request. Lower it on hosts with strict timeouts; raise it to finish large sites in fewer requests. |
Exclusions
These are never touched, regardless of settings:
Protected files
Excluded by default, with a checkbox to include each one manually if you really need to:
Custom exclusions
Add your own, one per line, in Settings. A bare name like backups matches at any depth in the tree; a path like wp-content/uploads/backups matches only that specific location.
Safety & error handling
Access control: every action requires the manage_options capability, a verified nonce, and runs only through admin-ajax.php — never as a directly loaded file.
Symlink containment: a symbolic link is never followed by default. Even with that setting turned on, the plugin resolves the link's real target and refuses to touch anything that falls outside the WordPress installation.
Handled gracefully, not fatally
None of the following stop the plugin or produce a fatal error — each is detected and reported clearly instead:
Detected automatically via disable_functions. Reset is disabled with an explanation; Scan and Dry Run keep working.
Flagged on the dashboard if it doesn't appear to cover the full WordPress root.
Common after a migration or restore. Reported per-file with the underlying system message where available.
Reported as a specific, per-item error rather than a generic failure.
A file that vanished between scan and reset (say, a cleared cache entry) is skipped quietly — not counted as an error.
A link with no valid target resolves to nothing and is skipped, rather than raising a filesystem warning.
Activity logs & reports
Every completed run — Scan Only, Dry Run, or Reset — adds one line to the Activity Log: date, mode, folders changed, files changed, and errors. The log keeps your last 25 runs and can be cleared at any time from the dashboard.
The Download Report as TXT button, shown after any run finishes, gives you the full detail behind that summary: every path that changed, its before-and-after permission, and the exact reason behind any error.
FAQ
Will this break my site?
wp-config.php, .htaccess, composer.json/.lock, and the system folders listed under Exclusions are left alone by default. Run Scan Only or Dry Run first if you'd like to see the full picture before anything changes.
What happens if my host disables chmod()?
The plugin checks for this automatically and disables the Reset button with a plain explanation. Scan Only and Dry Run keep working regardless, since neither one calls chmod().
A batch is slow, or my host times out. What now?
Lower the batch size in Settings. Every run already works in small AJAX requests and remembers exactly where it left off — running the same action again resumes rather than starting over.
Why do some items show errors?
The most common cause is the file being owned by a different system user than the one PHP runs as — typical after a migration or restore from backup. A recursive chown from your host usually resolves it.
Does this follow symbolic links?
Not by default. If you turn it on in Settings, a link resolving to somewhere outside the WordPress installation is still never touched — that protection stays on regardless.
Does the plugin send any data anywhere?
No. There's no telemetry, tracking, or external communication of any kind. Scanning and processing happen entirely on your own server.
Changelog
| Version | Notes |
|---|---|
1.0.0 | Initial release. |