Release notes
What changed, version by version
These are the releases of the WP Safer agent — the plugin installed on the WordPress sites you manage. Your sites update to it from the panel, or on their own if you let them.
Current agent version: 1.5.14
-
- Updating a single-file plugin no longer removes the other plugins. A plugin that sits as one file directly in the plugins folder, with no folder of its own (Hello Dolly is the common one), made the update treat the whole plugins folder as that plugin's folder. When such an update could not go ahead, rolling it back emptied that folder, and every plugin on the site went with it. A single-file plugin is now backed up and restored as that one file, its download is looked up under its real WordPress.org name, and no step of an update can clear the plugins folder itself.
- Old update copies are cleaned up per plugin. Removing the leftover copies of one plugin could also remove those of another plugin whose name started the same way.
-
- Backups no longer come out empty on sites with file names that are not valid UTF-8. A single such name — typically a Latin-1 name carried over from an older server — kept the backup's file list from being written, so the backup held only the database. These names are now stored safely and the file goes into the archive under its exact name on disk. If the file list still cannot be written, the backup stops with a clear error instead of finishing as an empty archive.
- Restores put those files back under the same name. Names inside the archive are read exactly as stored, so a non-UTF-8 name is no longer turned into a different one on the way back.
-
- The plugin's own screens are fully Turkish again. Sixty-three sentences added since the last translation round — the security-plugin allow list, the WordPress network rules, backup cancellation and several error messages — were still shown in English on Turkish sites. All of them are translated now, so every string the plugin prints has a Turkish version.
-
- Updates now arrive from WordPress.org. The agent is in the official plugin directory, so a new version shows up on your site's Plugins screen like any other plugin's and the package is downloaded from WordPress.org instead of our own servers. You can update it yourself, and the panel still updates it for you. Your site key, settings and backups are unaffected.
- The Turkish translation travels with the package again. The directory package had left it out, so a site updating from WordPress.org would have seen the agent's own screens in English. The compiled Turkish file ships with the package until translate.wordpress.org carries it, and a translation delivered by WordPress takes precedence over it automatically.
- The "Review us" link now points at the agent's reviews page on WordPress.org. It had nowhere to go while the directory listing did not exist.
-
- A backup taken more than an hour ago can be downloaded again. When the panel asked a site about its most recent backup, the site answered from a saved copy of that result which it keeps for a day — but the download addresses inside the answer were only valid for an hour. So for the remaining twenty-three hours the site reported a backup as ready and handed over addresses that its own download gate then refused. The archives themselves were never affected and were never deleted; only the addresses had gone stale. They are now generated fresh every time that answer is given.
- The time a backup took is reported correctly on sites that are not on UTC. The moment a backup started was recorded in the site's local time but measured against UTC, so on a site three hours ahead of UTC a backup that took twenty minutes was reported as having taken minus two and a half hours — and the same wrong figure was stored in the site's backup log. Both now use the same clock, and a figure left behind by an earlier version reads as zero instead of a negative number.
-
- The panel has a new address. WP Safer's server moved, so the address the panel calls your site from changed from 65.21.186.173 to 188.245.5.241. The agent only accepts calls from that address, so a site still holding the old one turns the panel away and reports nothing back. Updating fixes it.
- That address can now be set in wp-config.php. Add define('WPSAFER_IP_WHITELIST', '188.245.5.241'); and it takes precedence over the value built into the agent. It is there so a site that gets locked out by a future address change can be recovered with one line, instead of an edit inside the plugin that the next update undoes.
- The address check could be skipped by the way a request was shaped. The check read the first action by its literal position, so a request that listed its actions under any other position was not checked against the address list at all and ran anyway. The positions are normalised before the check now. A caller still had to hold the site's key to get that far — the signature was always verified — so this closed a second fence, not the lock itself.
-
- A scan of a large site now needs about half the memory it did — on a site with 18,742 files, 16 MB instead of 32 MB for one comparison round. What the scan reports does not change: changed, added and deleted files are still found exactly as before, and unchanged files are still skipped without being read.
- Because the stored format changed, the first scan after this update rebuilds the site's baseline from scratch. That round deliberately reports no findings — there is nothing yet to compare against — and the round after it compares normally again.
-
- A site that has run out of PHP memory now tells your dashboard so, instead of only looking broken. In that state WordPress answers every request with its generic "critical error" page, so the panel could report nothing but an error; it now receives the actual reason, along with the site's PHP version and memory ceiling, so a site that needs more memory can be told apart from one that is genuinely broken.
- Your dashboard now shows the site's real PHP memory ceiling, and whether the agent is allowed to raise it. Some hosts pin that ceiling so firmly that a request for more memory is ignored without any error — meaning a backup could believe it had four times the memory it actually had. The backup log now records it when that happens.
- A scan that cannot read its own baseline no longer reports every file on the site as newly added. On a site short of PHP memory the scan would skip reading the baseline — correctly, to avoid crashing the site — but then carried on comparing against nothing, so a clean site could be reported with thousands of new files. Such a round is now treated as what it is: a fresh baseline, with no findings claimed either way, and the reason is recorded.
- A scan of a large site uses noticeably less memory besides: the list of files to check is no longer held in memory in full, so its cost no longer grows with the size of the site. Scan results are unchanged.
-
- Updating a plugin no longer switches it on. A plugin you had deliberately left inactive was being activated as soon as it was updated from your dashboard — so an update quietly put code back into service on the site. An update now leaves a plugin exactly as it was: inactive stays inactive, and a plugin that was active is switched back on afterwards, as before. On a WordPress network, a plugin active for the whole network is switched back on for the whole network rather than for the main site alone.
-
- Backups of large sites no longer slow to a crawl as the archive grows. Every time a batch of files was added, the whole archive was written out again from the beginning, so a 6 GB backup was rewriting gigabytes for every few megabytes of progress — and on hosts with a strict time limit it could reach a size where it stopped progressing at all. The archive is now built in volumes, so closing it never costs more than one volume, and the site needs far less free space while a backup runs.
- Sites small enough not to need volumes produce exactly the same single archive as before.
-
- A backup that is running — or one that has stopped moving — can now be stopped from your dashboard. Until now there was no way to call one off: a job that hung stayed listed as running for two hours before the system gave up on it, and no new backup of that site could take its place in the meantime. Stopping one clears the half-written archive it left behind, and the last backup you actually took is left untouched.
-
- A backup taken before a WordPress core update no longer copies your media library. A core update never writes anything into your uploads folder, so copying it added nothing a rollback could use — on a large site that meant gigabytes, and hours, for no gain. The backup still carries everything a core update does touch: WordPress itself, your themes and plugins, your translations, and the database. Such an archive is labelled separately, and restoring it leaves your media exactly where it is.
- A backup no longer fails outright because of a single file or folder it cannot look at. Some hosts place links inside wp-content that point outside the area the site is allowed to read; one of those used to stop the whole backup in its first second, so the site ended up with no backup at all. Such an entry is now skipped — and it is never skipped quietly: the backup log records how many entries could not be inspected and names the first of them, because a file that was not looked at is not in the archive.
- Your dashboard now shows how far a running backup has got, instead of only saying that one is running. The figure comes from the backup's own position in its work — the database dump, then the files, then closing the archive — so a job that has stopped moving no longer looks the same as one that is making progress.
-
- Restoring the same site twice within a day no longer leaves a set of database tables behind for good. A restore sets the tables it replaces aside for 24 hours so it can be undone; a second restore started inside that window used to orphan the first set, and nothing ever removed it again. Those sets are now cleaned up whatever the order of events, and any left behind by earlier versions are removed once, on their own.
-
- A site that is one of several in a WordPress network can now be backed up and restored on its own. The whole network shares one database and one content folder, so a backup taken from one site quietly contained every other site in the network too — and restoring it would have rolled all of them back. A backup now covers only the site it was taken from, together with that site's own uploads folder.
- Accounts and the network's own records are kept out of a single site's restore, so bringing one site back never signs anyone out of the others or changes what the network knows about them. A backup also says which site it came from and is refused anywhere else, with the reason — every site in a network answers on the same address, so the address alone could not tell them apart.
- Backups taken in the day after a restore are no longer needlessly doubled in size. The restore keeps a copy of everything it replaced for 24 hours so it can be undone, and those copies were being swept into the next backup — which also made that backup impossible to restore later.
-
- WordPress networks (multisite) are now understood instead of being treated as ordinary single sites. Your dashboard can list the sites in a network, connect each of them on its own, and see which plugins are switched on for the whole network rather than for one site.
- Switching off a plugin that is active for the whole network no longer happens by accident. WordPress treats such a request as "switch it off everywhere", so asking for it on one site used to take the plugin off every site in the network without saying so. It is now refused with the reason, and only carried out when the whole network is explicitly meant.
- Updating WordPress core, or deleting a plugin or theme, is now only accepted from the network's main site: those files are shared by every site in the network, so the change was never really about the one site it was asked from. After a core update the dashboard is told that each site in the network still needs its database step, and can run it.
- Themes report whether they are enabled for the site in question, and a theme that is not can be enabled for the network from the dashboard instead of silently switching the site to a theme it cannot use.
-
- Fixed the "Allow WP Safer" button on the agent's own screen in WordPress: it did nothing until you pressed "Test connection" first, and after that a single click could fire the request several times.
- The security plugin card no longer squeezes the plugin name into a single-letter column; the name now sits on its own line above the status badge and the button.
-
- If a security plugin on your site is filtering your dashboard out, the agent now tells you and offers to fix it with one button. The address the dashboard connects from is added to the allow list of Wordfence, Jetpack, Solid Security or Limit Login Attempts Reloaded — but only after you press "Allow WP Safer". Nothing is written to another plugin's settings on its own.
- Each security plugin is approved separately and can be undone. Undoing takes effect immediately for Solid Security, Limit Login Attempts Reloaded and Jetpack's brute force protection, and the entry is genuinely removed from Jetpack's firewall list.
-
- A file integrity scan can now also look inside the files it already flagged, for code patterns worth a second look. The check is off by default and is turned on per site from your dashboard. It never calls a file malicious: it names the pattern it found and the line it sits on, and the decision stays yours. Nothing is quarantined or deleted.
- Only files that already drew attention are opened: files that do not match their official release, files that do not belong where they sit, files inside a plugin or theme that changed while its version did not, and executable files under uploads. With the check off, not a single extra file is read.
- The pattern list ships with the agent and is updated with it. Your dashboard only sends whether the check is on; it cannot send patterns to your site.
-
- A file integrity scan no longer lists a whole plugin or theme file by file when the package on disk is not the release it claims to be. That folder is now reported as one line, with the number of files behind it; files that genuinely do not belong are still listed one by one.
- Files the hosting itself creates — PHP's own error_log wherever it appears, cPanel's .ftpquota — and compiled template caches under uploads no longer fill the report. A file standing on its own is still reported, however short it is.
- Compiled translation files that WordPress 6.5 and later write into a plugin's own languages folder are recognised instead of being reported as unexpected.
-
- A scan no longer gives up because of a single folder the hosting will not let it read. That entry is skipped, the rest of the site is scanned as usual, and the report says how many entries could not be inspected — a folder nobody looked at is not a clean one.
- A scan that keeps failing in the same place now stops after a few attempts and reports what actually went wrong, instead of retrying for minutes and ending with a limit message.
-
- Deleting a theme from your dashboard now really removes it from the site. The request used to fail on its first step on most sites, and the dashboard read that failure as a success.
- A delete request can no longer be aimed at the themes directory itself, or at the active theme and the parent theme it builds on.
-
- The estimated backup size in your dashboard now measures the files the backup actually collects. Old archives left on the site, caches, log files and node_modules folders used to count towards a figure describing a backup none of them ever entered.
-
- The agent now installs into a directory named after the name it is published under, so its folder and its identity agree. A site can only ever hold one copy of it.
-
- If a site ends up with two copies of the agent, the first one loaded runs and the other makes itself inert instead of competing with it. The admin screen says which directory is redundant, and both copies share the same site key, so the site stays connected either way.
-
- The IP allow-list firewall for the WordPress admin area is managed per site from the panel: single addresses (IPv4 and IPv6), CIDR ranges, wildcards such as 192.168.1.* and ranges such as 1.2.3.10-50. Anything the list cannot read is reported back instead of being dropped in silence.
- admin-ajax.php and admin-post.php are left alone by default — a site's own front end uses them too — and a request whose address cannot be determined is let through rather than locking anyone out.
Updates arrive on their own
The panel installs a new agent version on your sites when you ask it to, or automatically if you turn that on. Nothing here needs an FTP client.