Browse, edit and manage files without ever leaving wp-admin
Set up a file manager WordPress admins can trust with real server access: a built-in code editor, path-traversal defense on every operation, upload blocking that catches double-extension tricks, and an optional FTP volume browser alongside the local one.
- Every path checked with realpath() — traversal and symlink tricks blocked.
- Upload blocking checks every extension segment, not just the last.
- WordPress's own CodeMirror editor, with Ctrl/Cmd+S to save.
- Local files and remote FTP volumes, in the same interface.
| Name | Size | Modified | Perms |
|---|---|---|---|
| plugins | — | Aug 12 | 755 |
| functions.php | 4.1 KB | Aug 11 | 644 |
| shell.php.jpg | upload blocked | ||
File manager WordPress: what does the module actually do?
This is what a file manager WordPress admins get with TheOneWP: TOWP_File_Manager adds a full local file browser rooted at the WordPress install itself, with upload, download, zip, move, rename, permissions and a built-in CodeMirror code editor, alongside a separate mode for browsing a configured remote FTP volume. Every path — local or remote — is validated against the configured root using full symlink resolution, uploads are checked extension-segment by segment against a configurable blocklist, and blocked attempts are recorded in the Audit Log. Access requires the manage_options capability throughout.
Editing a server file usually means leaving WordPress entirely
A quick edit to a config file or a one-off file upload often means opening a separate FTP client, entering credentials, and finding the right path all over again.
A naive file manager is a real security risk
Path traversal and disguised file uploads are classic attack vectors — a file browser that doesn't defend against both is a liability, not a convenience.
Local files and remote files usually mean two different tools
Working across a local WordPress install and a remote server typically means switching between an admin screen and a separate FTP application entirely.
Real file access, defended like it should be
The module treats every path as untrusted input and checks it accordingly, on both the local filesystem and remote volumes.
A real editor, not a text box
WordPress's own CodeMirror, with syntax highlighting and a familiar save shortcut.
Every path resolved, not just checked
realpath() resolves symlinks before a path is trusted — an existing safeguard many simpler tools skip.
Local and remote, one interface
Switch between the local install and a configured FTP volume without leaving the page.
The complete file manager WordPress feature set
Every capability below is present in the class's AJAX handlers or its path-resolution logic.
Built-in CodeMirror editing
WordPress's own code editor, with Ctrl/Cmd+S intercepted to save through this module's own AJAX action.
Extension-segment upload blocking
Every dot-separated part of a filename is checked, catching double-extension tricks like "shell.php.jpg," with blocked attempts logged.
Whole-folder upload
Upload an entire folder at once, with every individual path segment sanitized and validated before anything is written.
FTP volume browsing
A separate mode connects to a configured remote server for listing, reading, saving, uploading, moving, copying and deleting files.
Zip, search, tree view and permissions
Compress and download folders, search across the tree, browse a folder tree view, and change permissions directly.
Multi-select delete and move
Select several items at once for deletion or relocation, each still individually validated against the root.
Use a file manager WordPress workflow in four steps
Confirm you're on the right root before making a change that matters.
Open File Manager and pick Local or FTP Volume
Browse the local WordPress install directly, or switch to a configured remote server.
Navigate or search to the file you need
Use the folder tree or the search field to find it quickly on a large install.
Edit, upload, or manage it
Open code files directly in the built-in editor, or upload, move, zip or delete as needed.
Save with confidence
Ctrl/Cmd+S in the editor, or the toolbar action for everything else — each still checked against the root before it runs.
Where in-admin file access saves a real trip
The module fits situations where a separate FTP client would otherwise be the only option.
Quick config edits
Adjust a theme's functions.php or a config file without opening a separate FTP client for a one-line change.
Managing files on a remote host
Browse and edit a remote server's files through the FTP volume mode without switching applications.
Agencies doing hands-on maintenance
Zip and download a folder for backup, or clean up leftover files, directly from the WordPress admin they're already in.
File access that doesn't cut corners on safety
Every design choice in the verified code treats direct file access as something to defend carefully, not just enable.
Loaded only where file access happens
The verified implementation keeps its footprint to the screen where it's actually used.
CodeMirror loaded on demand
The code editor's assets enqueue only on the File Manager screen, not across the rest of wp-admin.
Directory listings, not a full tree scan
Browsing loads one directory level at a time rather than walking the entire filesystem up front.
Zipping happens on request, not automatically
Compression only runs when explicitly triggered for a specific folder, not as a background process.
Every path, every request, resolved and rechecked
Direct file system access is exactly the kind of feature that needs its safeguards to be real, not assumed.
realpath()-based traversal defense
Existing paths are fully resolved, including symlinks; paths that don't exist yet are validated by walking up to the nearest real ancestor — deny-by-default if none can be resolved.
manage_options and a nonce on every action
Local file operations and every FTP volume action both check this capability and a dedicated nonce before doing anything.
Per-segment extension blocking, logged
A blocked upload is checked against every extension in the filename and recorded in the Audit Log with the specific extension that triggered it.
A configurable blocklist covering PHP variants
php, phtml, phar, several numbered PHP extensions, pht, shtml, .htaccess, user.ini and .htpasswd are blocked by default — configurable, but conservative out of the box.
Uses WordPress's own editor and upload handling
The supplied code builds on core functions rather than reimplementing file handling from scratch. No compatibility claim beyond the verified implementation is assumed.
wp_enqueue_code_editor()
The same CodeMirror integration WordPress core uses for its own theme and plugin file editors.
move_uploaded_file()
Used specifically because it verifies is_uploaded_file() internally — the correct, safe function for handling HTTP file uploads.
TOWP_FTP_Volume
The same helper class used elsewhere in the plugin for encrypted credential storage, reused here for actual remote file operations.
TheOneWP versus common alternatives
Compare a real file manager WordPress implementation with a typical dedicated file manager plugin or a separate FTP client.
| Capability | TheOneWP File Manager | Other common solutions |
|---|---|---|
| Traversal defense | Full realpath() resolution, including symlinks | Varies; some tools use a simpler string-prefix check |
| Disguised uploads | Every extension segment checked, not just the last | Often checks only the final file extension |
| Local and remote | Both in the same interface | Usually one or the other, not both |
| Code editing | WordPress's own CodeMirror, familiar shortcuts | Varies; some tools use a plain textarea |
| Audit trail | Blocked uploads recorded in the Audit Log | Often a silent rejection with no record |
| Administration | One TheOneWP screen, submenu or standalone | May require a separate plugin and its own screen |
Use direct file access deliberately
A few habits keep this kind of access safe on a production site.
Limit who has manage_options
This feature is only as safe as the accounts that can reach it — keep that capability tightly held.
Back up before editing a core config file
A quick edit through the built-in editor still benefits from a way back if something goes wrong.
Keep the default blocked-extensions list conservative
Loosen it only for a specific, understood reason — it exists to keep executable file types out of uploads by default.
Check the Audit Log after an unexpected upload rejection
It records exactly which extension triggered the block, which is faster than guessing.
Avoid assumptions the code does not support
The module has a defined, verified scope — a few assumptions outside it cause confusion.
Expecting to edit a binary file directly
Images, video, audio, archives, fonts and office documents open for download, not inline editing — the editor is for text and code.
Assuming a blocked extension can be renamed around
The check runs on every dot-separated segment of the filename, so renaming to hide the real extension inside a longer name doesn't bypass it.
Expecting FTP volume access without configuring one first
The remote mode only works once a volume has actually been added and connects successfully — there's no default remote target.
File Manager FAQ
These answers come directly from the verified class and its path-resolution logic.
Can a file manager like this be tricked into uploading a PHP shell disguised as an image?
The check is built specifically against that trick. is_upload_allowed() splits a filename on every dot and checks each resulting segment against the blocked-extensions list, so a name like "shell.php.jpg" is caught on its "php" segment — not just its final extension.
What happens to a blocked upload attempt?
It is rejected, and the attempt is recorded in the Audit Log with the filename and which extension triggered the block — so a blocked upload leaves a trace, not just a silent failure.
Can someone browse outside the WordPress root using ../ in a path?
No. is_within_root() resolves the full real path with realpath() — which also resolves any symlink — and rejects anything that lands outside the configured root. For a path that doesn't exist yet, like a new folder, it walks up to the nearest real ancestor and validates from there instead of trusting the unresolved path.
Does renaming a file to ".htaccess" or ".env" get blocked by sanitization?
No, deliberately. sanitize_item_name() preserves a leading dot — unlike WordPress's own sanitize_file_name(), which strips it — while still removing null bytes and path separators that would enable traversal.
Which file types can be edited directly in the browser?
Anything not recognized as a binary format. is_editable() checks against a list of image, video, audio, archive, font, office-document and generic binary extensions and excludes only those — everything else, including any code or config file, opens in the built-in editor by default.
Does the code editor use a custom editor, or WordPress's own?
WordPress's own bundled CodeMirror, enqueued through wp_enqueue_code_editor() — the same editor WordPress itself uses for theme and plugin file editing, with Ctrl/Cmd+S intercepted to save through this module's own AJAX action.
Can I connect to a remote server instead of just browsing local files?
Yes. A separate "FTP Volume" mode connects through TOWP_FTP_Volume to a configured remote server, with its own list, read, save, upload, move, copy and delete actions — alongside, not instead of, the local file browser.
Can I upload an entire folder at once, not just individual files?
Yes. Whole-folder upload is supported using the browser's folder-selection API, with every path segment of every file individually sanitized and checked against the root before anything is written.
Stop switching to a separate FTP client.Manage files right from wp-admin.
Use a file manager WordPress admins can trust with real server access: traversal-checked paths, blocked disguised uploads, and a built-in editor that just works.