=== WDD File Permission Reset ===
Contributors: webdevdoer
Tags: file permissions, chmod, security, maintenance, file management
Requires at least: 6.8
Tested up to: 7.0
Requires PHP: 8.0
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Scan, preview, and safely reset WordPress file and folder permissions from the dashboard, with AJAX batching, dry-run preview, and exportable reports.

== Description ==

WDD File Permission Reset gives administrators a safe, transparent way to find and fix incorrect file and folder permissions - a common cause of broken updates, blank pages after a migration, and "failed to write file" errors - without touching a terminal or FTP client.

Everything runs in small AJAX batches, so the plugin stays responsive even on sites with hundreds of thousands of files, and never leaves a run half-finished: if a batch is interrupted, running the same action again picks up exactly where it left off.

**Core features**

* **Dashboard Overview** - WordPress root path, file owner, PHP process user, writability, and totals from the last run, all in one place.
* **Scan Only** - counts what would change, changing nothing.
* **Dry Run** - walks through the same batch process a real reset would use, showing exactly which folders and files would be touched, with nothing modified.
* **Reset WordPress Permissions** - applies the change for real, behind a confirmation prompt.
* **AJAX batch processing** - built on `RecursiveDirectoryIterator` and a pruning `RecursiveIteratorIterator` filter, so excluded folders are never even walked into. Batch size is configurable for hosts with strict timeout limits.
* **Activity Logs** - a running history of past scans and resets, with folders/files changed and error counts.
* **Exportable reports** - download a full plain-text report of any run.
* **Sensible, safe defaults** - `.git`, `node_modules`, `vendor`, caching-plugin folders, `wp-config.php`, `.htaccess`, `composer.json`/`composer.lock` are excluded out of the box. Symbolic links are never followed unless you turn that on, and even then, a link pointing outside the WordPress installation is never touched.

**Built for real hosting conditions**

The plugin detects and gracefully handles the conditions that actually show up on shared and managed hosting: `chmod()` disabled via `disable_functions`, `open_basedir` restrictions, read-only mounts, ownership mismatches after a migration, files that vanish mid-scan, and broken symbolic links. None of these stop the plugin or produce a fatal error - they're reported clearly and the run continues.

= Default permissions =

* Folders: `0755`
* Files: `0644`

Both are configurable in Settings.

= Safety =

* Restricted to users with the `manage_options` capability.
* Every action is nonce-verified and reachable only through `admin-ajax.php`.
* All input is sanitized; all output is escaped.
* No telemetry, tracking, external requests, ads, or upsells of any kind.

== Installation ==

1. Upload the `wdd-file-permission-reset` folder to `/wp-content/plugins/`, or install the zip directly through **Plugins → Add New → Upload Plugin**.
2. Activate the plugin through the **Plugins** menu.
3. Go to **Tools → File Permission Reset**.
4. Run **Scan Only** first to see what would change.
5. Optionally run **Dry Run** to preview the exact batch process.
6. Run **Reset WordPress Permissions** when you're ready to apply changes.

== Frequently Asked Questions ==

= Will this break my site? =

The plugin excludes `wp-config.php`, `.htaccess`, `composer.json`/`composer.lock`, and common system folders (`.git`, `node_modules`, `vendor`, caching-plugin directories) by default. Run **Scan Only** or **Dry Run** first to review the full picture before anything is changed.

= What if my host disables chmod()? =

The plugin detects this automatically and disables the Reset button with a clear explanation. Scan Only and Dry Run keep working either way, since they never call `chmod()`.

= A batch is slow or my host times out. What do I do? =

Lower the batch size in Settings. Every run is already broken into small AJAX requests and remembers exactly where it left off, so re-running the same action resumes automatically instead of 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. Your host can usually fix this with a recursive `chown`.

= Does this follow symbolic links? =

Not by default. If you enable it in Settings, a symlink that resolves to somewhere outside the WordPress installation is still never touched - that protection isn't optional.

= Does this send any data anywhere? =

No. There is no telemetry, tracking, or external communication of any kind. All scanning and processing happens entirely on your own server.

== Screenshots ==

1. Dashboard Overview showing WordPress root, ownership, and writability status.
2. Scan results with folders/files needing changes.
3. Live progress during a batch reset.
4. Settings and Exclusions.

== Changelog ==

= 1.0.0 =
* Initial release.

== Upgrade Notice ==

= 1.0.0 =
Initial release.
