BackupYourSite

Changelog

1.1.1

• Security: wp-config.php is no longer included in a backup archive that leaves your server.
  It holds your WordPress authentication keys and salts and your database credentials, and
  uploading it put those on storage you do not control. wp-config-*.php variants,
  wp-salt.php, wp-salts.php and .env are excluded in the same way. Backups that stay on
  your own server are unchanged. See the FAQ for why nothing a restore needs is lost.
• Every internal name the plugin uses is now prefixed bysbackup — its options, database
  tables, scheduled task, hooks and admin page addresses. Your settings, schedule, backup
  history, stored backups and cloud connection are carried over automatically on the first
  load after the update; there is nothing to reconnect and nothing to set up again.
• Backups written by earlier versions stay restorable.

1.0.9

• Fixed: with both “This server” and “BackupYourSite cloud storage” ticked, a backup could be
  stored on the server only, with nothing at all going to the cloud — and still report
  “Backup complete”. A single failed upload request (a dropped connection, a brief server
  error, one part rejected) made the plugin abandon the whole offsite copy for that backup,
  permanently, because the part-upload was never retried. It is now retried, and an upload
  interrupted for a reason that passes is resumed on the next pass instead of being thrown
  away.
• Fixed: a part that failed its checksum was skipped instead of being sent again, so the cloud
  copy could be finalised with a piece missing from it. Every part is now re-sent until the
  server confirms it.
• Fixed: destinations are now independent. A destination that fails no longer stops the others
  from being written to, and no longer fails the whole backup — if your backup folder cannot
  be written to, the cloud copy still happens, and the other way round. A backup only fails
  outright when nothing could be stored anywhere.
• Fixed: a backup that did not reach one of your chosen destinations is reported as such —
  on the Dashboard, on the Settings screen (per destination), in the log, and by email. It is
  no longer counted as a clean run, and old backups are no longer deleted on the strength of
  one. A destination that missed a backup is also correctly treated as not having it, so the
  next backup to it is a full one.
• Fixed: a destination you had ticked could be silently un-ticked by saving the Settings page
  while it happened to be unavailable (for example a cloud account mid-reconnect).
• Fixed: the Settings screen could show “The folder could not be created or is not writable.”
  directly underneath the backup folder actually in use and working normally. That message is
  about a folder outside your website that could not be used, and now says so.

1.0.8

• Fixed: connecting cloud storage after you had already been backing up locally could put an
  incremental backup in the cloud with no full backup behind it — which is not restorable on
  its own. The plugin decided full-versus-incremental by looking only at your local backups,
  so a brand-new cloud destination inherited a baseline it did not have a copy of. Whether a
  full backup already exists is now asked of every destination a backup is being written to,
  separately; if any of them does not have one, that run takes a full backup. This also covers
  a cloud copy that was pruned, deleted, or never finished uploading.
• If you are affected, the next scheduled or manual backup after this update takes a full
  backup by itself — no action needed. Any incremental already sitting in the cloud without a
  full behind it is now labelled “No full backup behind it” under Stored backups, so it is not
  mistaken for a working backup.

1.0.7

• New installs now take a fresh full backup every 25 backups instead of every 7. On a daily
  schedule that is one full a month rather than one a week, so far less is re-uploaded and
  re-stored for the same protection — each incremental is still measured against the last
  full, so a restore still needs only two backups. Sites that have already saved their
  settings keep whatever number they chose; change it under Incremental backups.

1.0.6

• The “your backup files are publicly downloadable” warning now fixes itself instead of
  asking you to. On servers that ignore .htaccess — nginx, and Apache with
  AllowOverride None — rewriting those files could never have worked, so the plugin used
  to print the warning and leave the archives sitting at a URL that answered 200 until
  someone read it, edited wp-config.php over SFTP, or opened a support ticket. It now works
  through the remedies itself and re-tests after each one: it makes the archives readable
  only by your own account (decisive wherever the web server is a different user from PHP,
  which is the usual layout on exactly those hosts), and failing that it moves your backups
  out of the website folder altogether, where no web address can reach them.
• New button, “Move my backups out of the website” — one click, on any host where PHP may
  write above your website root. It moves what is already stored and remembers the new
  location itself, so BYSBACKUP_BACKUP_DIR in wp-config.php is no longer needed for this. The
  constant still works and still wins, as the escape hatch for layouts nothing can infer.
• Two candidate folders outside the website are now tried instead of one, so panels that
  place the account home directory an extra level above the web root are handled.
• Where a host allows none of the above — it serves the folder, ignores every rule, runs the
  web server as the PHP user, and confines PHP to the website — the storage folder is renamed
  to carry 32 random characters, on top of the 16 every backup set already carries. The
  dashboard says plainly that this is an unguessable address and not protection, rather than
  reporting the problem as fixed.
• Archives are clamped to owner-only as each one lands, not on a later sweep.
• Fixed: the warning led with “add a BYSBACKUP_BACKUP_DIR constant to wp-config.php” even on the
  many sites where a button could do it. It now names the button, and only falls back to
  naming your host when this server genuinely permits nothing else.

1.0.5

• Fixed the “your backup files are publicly downloadable” warning staying on screen after
  1.0.4 had already repaired the folder. 1.0.4 rewrote the protection files during the upgrade
  but never re-tested them, so the warning from before the repair was what you kept reading.
  The upgrade now re-tests, and an install that already upgraded re-tests itself once.
• When the stored result carries no recorded cause, the warning no longer claims your server
  ignores .htaccess. That advice was shown on servers that honour it perfectly well.

1.0.4

• Fixed a security bug that could leave the backup folder publicly downloadable. The
  protection files (.htaccess, web.config, index.php) were only written when absent,
  so a file that existed but was empty or half-written — a truncating “cleanup” plugin, an
  interrupted write, a host migration that copied names but not contents — passed the
  check while denying nothing. The folder was then open, and because the file existed it
  was never repaired: the “your backups are publicly downloadable” warning fired forever
  and told the user to contact their host about something the plugin could fix itself.
  Protection is now verified by content, not by existence, and repaired automatically on
  every backup run. A partial write is deleted rather than left in place.
• The exposure self-test now rewrites and re-verifies the deny rules and retests before
  reporting anything, so a repairable folder is simply repaired and never warned about.
  Only an exposure that survives a verified repair is reported.
• The exposure warning and email now distinguish the two real causes and give the right
  advice for each: a server that ignores .htaccess (usual on nginx), versus protection
  files the plugin could not write. Both now point at the BYSBACKUP_BACKUP_DIR constant, which
  moves backups outside the website entirely.
• Every backup run now re-verifies the deny rules across the whole storage folder, including
  the folders of backups taken earlier. Previously a run only guarded the folders it created
  itself, so a set from an earlier run whose protection had since been damaged stayed that
  way — and it holds the same wp-config.php and database as a fresh one. Activating or
  updating the plugin repairs the whole tree too.
• The storage folder is now guarded at the moment it is created, closing the short window
  between creating it and protecting it on first activation.

1.0.3

• Fixed a real data-integrity bug: fwrite() return values were unchecked at four
  chunked-copy sites (split-file reassembly and zip-entry extraction during restore, and
  the staged-file-list writer). A disk-full or short write mid-copy could silently produce
  a truncated file that the restore then treated as successful. All four now check the
  return value and fail the restore loudly (with a clear “disk full or write error”
  message) instead of continuing with a corrupt result.
• Replaced 62 bare // phpcs:ignore comments and a further ~30 category-only /
  unreasoned ones (// phpcs:ignore WordPress.DB, WordPress.Security.NonceVerification,
  Generic.CodeAnalysis.EmptyStatement) with specific sniff names and reviewed
  justifications, or removed them where nothing was actually being suppressed. A bare
  ignore silences every sniff on that line, so these lines were never actually examined by
  the previous Plugin Check pass; each was independently re-verified with the ignore
  stripped. No other real issue surfaced besides the fwrite bug above.
• No other functional/behavioural change to backup or restore.

1.0.2

• WordPress Plugin Check compliance pass: fixed a missing translators comment, removed the
  now-redundant load_plugin_textdomain() call (translations for WordPress.org-hosted plugins
  load automatically since WP 4.6) and the stale Domain Path header, and added scoped, reviewed
  justification comments (with matching notes in this readme’s reviewer section) for the direct
  file-streaming calls a backup/restore engine needs and the table-identifier SQL that
  $wpdb->prepare() cannot parameterize. No functional/behavioural change to backup or restore.

1.0.1

• Cloud upload and restore now run against the live BackupYourSite backend, not a
  contract mock.
• Fixed a cloud-restore bug where an already-downloaded volume was fetched again on
  every step; downloaded volumes are now cached and their size verified before use.
• A failed restore now reports the real reason instead of a generic failure message.
• Restore now reports step-by-step progress in the admin while it runs.

1.0.0

• First release: scheduled backups, incremental backups, verification, local storage with
  exposure self-check, retention, restore with pre-restore snapshot.