GUIDE ALL

Why WP Multitool Says Your Backups Are in a Public Folder

WP Multitool keeps database and wp-config backups above your website root, where the web server can't reach them. Some hosting won't allow that, so the files land in wp-content/uploads instead and the warning appears. Here's how to check what your site is doing and how to fix it.

What the Warning Means

When WP Multitool takes a backup, a database dump before a cleanup or a copy of wp-config.php before an edit, it tries to put the file one level above your website root. Somewhere the web server has no access to. A dump is a copy of your users table, password hashes included, and the web server has no business handing that to anyone who asks for it. To do that, PHP needs permission to create a folder in the directory above your site. On a VPS or a decent managed host it usually has that permission, and you never see this warning. On a lot of shared hosting it doesn't. The directory above your site belongs to root or to the hosting panel, and PHP can't write there. When that happens WP Multitool still takes the backup. Running a cleanup with no backup at all would be worse. It falls back to wp-content/uploads/wpmultitool-backups/ and it tells you, which is the warning that brought you here.

Step by Step

  1. Read the path in the warning

    The notice names the exact folder it's using. If it starts with your site's own directory and contains wp-content/uploads, the backups are inside the public part of your site. If it sits above that, there's nothing to fix and you shouldn't be seeing the warning at all.

  2. Find out whether your host runs nginx or Apache

    This decides how exposed you actually are. WP Multitool drops a .htaccess file with "deny from all" into the backup folder. Apache honours it and blocks the download. nginx ignores .htaccess entirely, so on nginx that guard does nothing. You can ask your host, or run: curl -I https://yoursite.com and look at the Server header. Plenty of hosts run nginx in front of Apache, so if you get nginx there, ask support which one actually serves your files.

  3. Test it yourself, don't take my word for it

    Take a backup from WP Multitool > Database Optimizer, then note the filename. Open https://yoursite.com/wp-content/uploads/wpmultitool-backups/THAT-FILENAME.sql in a private browser window. If your browser downloads it or shows SQL, the file is public. If you get a 403 or 404, the guard is working on your host. This is the only answer that counts, because it tests what the web server does rather than what the config says it should do.

  4. Ask your host for a folder above the site root

    This is the fix that usually works, and it costs the host about a minute. Ask them to create a directory called wpmultitool-backups in the directory directly above your WordPress root, and to make it owned and writable by the user PHP runs as. On cPanel or DirectAdmin that's normally one level up from public_html. Once it exists, WP Multitool finds it on its own, moves anything already sitting in uploads, and the warning goes away. You don't have to change a setting.

  5. Delete what's already there once you've moved

    WP Multitool moves its own backups for you. If you've been taking them for a while, or you've used other plugins that write into uploads, look through wp-content/uploads for anything ending in .sql, .bak, .old or .zip and get rid of what you don't need. Those extensions aren't PHP, so the server hands them over as plain text.

  6. If the host says no, that tells you something

    Some shared hosts won't do it, and a few can't. A host that gives PHP nowhere private to write is a host with a fairly relaxed idea of what belongs on the public web, and this is rarely the only place it shows. Moving is a bigger job than a support ticket, so it's worth doing on your own schedule rather than in a panic. Most decent managed WordPress hosts handle this out of the box.

  7. Or send it to me

    If you'd rather not deal with any of it, email contact@wpmultitool.com with your host's name and the path from the warning. I'll tell you which of the above applies to your setup, and whether it's worth moving. I wrote the plugin, so I know what it's asking for and how to word the ticket so support understands it.

FAQ

Has my data already leaked?

Probably not, and step 3 will tell you for certain. Backup filenames carry 20 random characters on top of the date, so nobody finds one by guessing. What can find one is a crawler that picked the address up somewhere, a referrer header, or another plugin that indexes your uploads folder. Unlikely, and not impossible. A database dump is the wrong thing to be relaxed about.

Why doesn't the plugin just refuse to take the backup?

Because then cleanups would stop working on a large slice of shared hosting, and you'd be running database deletions with no way back. A backup you can restore from, in a folder that's harder to reach than it should be, beats no backup at all. So it takes it, and it makes noise about where it had to put it.

Isn't the .htaccess file enough?

On Apache, yes. On nginx it does nothing, because nginx never reads .htaccess files. There's no way for a plugin to fix that from inside WordPress: the rule would have to go in the server config, which PHP can't write to. That's why the folder has to move instead.

Can I just turn the warning off?

You can hide it for 30 days. It comes back after that, because the condition that caused it is still true. It stops for good once the backups are somewhere private.

Does this affect Lite as well as Pro?

Yes. Both editions write database backups the same way, and the fix is identical. Config backups are Pro only, since Config Manager is a Pro module, but the folder is shared.

Not sure what your host will say?

Send me the hosting name and the path from the warning, and I'll tell you which of the steps above applies to your setup and whether it's worth moving. I wrote the plugin, so I know what it's asking for.

Email me about it