Safer Remote Site Backup & Manager

سجل التغييرات

1.5.12

• The plugin’s own screen is fully Turkish again. Sixty-three sentences added since the last translation round — the security-plugin allow list, the multisite rules, backup cancellation and several error messages — were still shown in English on Turkish sites. All of them are translated now, so every string this plugin prints has a Turkish version.

1.5.11

• Updates now come from WordPress.org. This plugin is in the official plugin directory, so new versions arrive the same way as every other plugin on your site: the Plugins screen offers the update, and the package is downloaded from WordPress.org instead of our own servers. You can update it yourself, and the dashboard still updates it for you. Nothing about your site key, settings or backups changes.
• Turkish is bundled again. The directory package left the Turkish translation out, so a site updating from WordPress.org would have fallen back to English on this plugin’s own screen. 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.
• “Review us” now links to the directory. The review request can finally point at this plugin’s reviews page on WordPress.org; it stayed silent while the listing did not exist.

1.5.10

• A backup taken more than an hour ago can be downloaded again. When your dashboard asked a site about its most recent backup, the site answered from a saved copy of the result that it keeps for a day — but the download addresses inside that 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. The addresses 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. 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.

1.5.9

• The dashboard has a new address. WP Safer’s server moved, so the address the dashboard calls your site from changed from 65.21.186.173 to 188.245.5.241. This plugin only accepts calls from that address, so a site still holding the old one turns the dashboard 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 plugin. 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 how the 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 this site’s key to get that far — the signature was always verified — so this closed a second fence, not the lock itself.

1.5.8

• The plugin now states the PHP version it needs. It declares PHP 7.3 — the version its backup engine has always required — so WordPress will not install or activate it on an older PHP. If it ends up on one anyway, it explains why and deactivates itself instead of failing with a fatal error.
• The dashboard can no longer ask this site for arbitrary configuration constants. The action that reads a named constant answered any name it was given, which included DB_PASSWORD, the authentication keys and the salts. It now answers from a fixed list of configuration switches, and a name that looks like a secret is refused even if a site widens that list with the new wpsafer_constants_allowlist filter.
• Database names are escaped in the backup dump. Table, view and column names went into the archive’s SQL as they were. A name carrying a backtick or a line break could end the quoting — or a comment — and continue as SQL when the archive was restored. Names are now quoted with doubled backticks, and anything written into a comment has its control characters stripped. A dump of a site with ordinary table names is byte-for-byte what it was before.
• The backup folder is closed to the web before the first byte is written into it, not after, and the intermediate database dump now carries an unguessable name for as long as it exists. Until now the engine could create that folder itself on a cron run, leaving it briefly readable.
• The bundled Turkish translation actually loads. The compiled translation file carried a header WordPress refuses to read, so the plugin’s screens stayed English on Turkish sites no matter what. The file is rebuilt; its contents are unchanged.
• A scan of a large site now needs about half the memory it did. The record the scan keeps for every file was stored as a structure with five named fields, which PHP holds at several times the cost of the same data as plain text — repeated for every file on the site. On a site with 18,742 files this measured 32 MB for a comparison round; it is now 16 MB, and the stored file itself is smaller too. 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.

1.5.7

• A site that runs out of PHP memory now tells your dashboard so, instead of just failing. When the site’s memory ceiling is reached, WordPress answers every request — including ours — with its generic “critical error” page, so the dashboard could only report that the site returned 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 plugin is allowed to raise it. Some hosts pin that ceiling so firmly that a plugin’s 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 and no deleted ones. 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. The list of files to check was held in memory in full, which on a site with tens of thousands of files cost around 10 MB on top of everything else WordPress was already using — enough to push a busy WooCommerce site over its limit. The list is now read a line at a time, so the cost no longer grows with the size of the site. Scan results are unchanged.

1.5.6

• 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 activated for the whole network is switched back on for the whole network rather than for the main site alone.

1.5.5

• 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.

1.5.4

• 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.

1.5.3

• 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.

1.5.2

• 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.

1.5.1

• A site that is one of several in a WordPress network can now be backed up and restored on its own. Until now 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 can no longer be restored onto the wrong site in a network. Every site in a network answers on the same address, so the address alone could not tell them apart; a backup now says which site it came from and is refused anywhere else, with the reason.
• 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.

1.5.0

• 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 to a theme the site cannot use.

Only releases from 1.5.0 onward are listed here: WordPress.org caps the length of this section. Earlier releases are recorded in the plugin’s own source history.