by
FlexaTech
0 (0 reviews)
Flex Explorer
A sandboxed file manager for WordPress: browse, upload, zip, download and recover your site's files from a fast admin app.
Flex Explorer ranks #53,892 among WordPress.org plugins with 0+ active installations, and was last updated Oct 15, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Compatible with WP 7.1.4
v1.5.0
Current Version v1.5.0
Updated 3 weeks ago
Last Update on 15 Oct, 2026
Refreshed 1 week ago
Last Refreshed on
Actively maintained
Rank
#53,892
—
No change
Active Installs
0+
-100%
KW Avg Position
N/A
—
No change
Downloads
518
+5 today
Support Resolved
0%
—
No change
Rating
0%
Review 0 out of 5
0
(0 reviews)
Next Milestone 10
0+
10+
26,324
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 6 more installs to reach 10+
Rank Changes
Current
#53,892
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
0.0
0 reviews
Overall
0%
5
0
(0%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 1.5.0
- Last Updated
- Oct 15, 2026
- Requires WP
- 6.0+
- Tested Up To
- 7.1.4
- PHP Version
- 8.0 or higher
- Author
- FlexaTech
Support & Rating
- Rating
- ☆ ☆ ☆ ☆ ☆ 0
- Reviews
- 0
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade Now
Frequently Asked Questions
Common questions about Flex Explorer
Only users with the manage_options capability, which in practice means administrators. The gating capability is filterable via flex_explorer/capabilities/manage.
Yes, with access restricted to network super admins. manage_options is a per-site capability, but the sandbox root is the whole network's filesystem, so a subsite administrator would otherwise reach every other site's files. A network that does want per-site access can opt in with the flex_explorer/capabilities/require_super_admin filter.
The most likely reason is that your site defines DISALLOW_FILE_EDIT, which switches the plugin off completely: it is a much bigger lever than the core file editor that constant disables. The Plugins screen shows a note when this is the case. To keep the constant and still use the file manager, filter flex_explorer/capabilities/enabled to true.
Plugins distributed through the WordPress.org directory are not allowed to edit site files, so this build has no editor and no write-content route at all: only "new empty file" remains. Choosing Edit opens a dialog with a link to the full build at flexacommerce.com/products/flex-explorer,
and tables, so switching between them loses nothing.
No, and that is not configurable. wp-config.php, .htpasswd, .htaccess and the WordPress core files at the site root (wp-settings.php, wp-load.php, the root index.php, wp-login.php, xmlrpc.php, wp-cron.php and friends) are refused for delete, trash, rename and move, for everyone. The core-file guard matches only the copy at the site root, so a plugin's own index.php in a subfolder stays yours to manage.
Deleting, renaming, moving or overwriting an existing load-bearing file shows an extra confirmation. You control exactly what counts, with two lists under Settings → Risky operations: "Risky file patterns" (e.g. *.php, .htaccess) and "Risky folders" (the tokens @wp-core, @active-theme, @active-plugins, @mu-plugins, @self, or literal paths). A file is flagged only when it matches a pattern AND lives inside one of the folders.
Yes, within your WordPress install. The sandbox root defaults to ABSPATH, and the root_path setting can narrow it to any folder inside the install, for example wp-content to keep the file manager away from everything else. It
setting that reaches the rest of the server is not something a form field should be able to do. A site that genuinely needs a root elsewhere sets it in code, with the flex_explorer/sandbox/root filter.
Both live in a private folder that the plugin creates inside your uploads directory. The folder name includes 128 random bits generated once per site, and trashed items are stored without their original file extension, so there is no URL to guess and nothing in there can be executed. The plugin also writes .htaccess and web.config rules that deny direct access, which Apache and IIS honour; nginx ignores them, which is why the name is randomised rather than fixed, and why Settings → Trash warns you when it detects such a server. To take HTTP out of the picture altogether, define FLEX_EXPLORER_STORAGE_DIR in wp-config.php and point it at a writable folder outside your web root. Set it before you start using the trash: moving it later leaves the existing items behind at the old location.