Show progress while a server side backup runs (+ fix output buffering bugs)

[francescobragagna]

What this does

A server side backup submits the dialog form into its own iframe and writes the whole dump to a file, so nothing reaches the browser until php is done. The dialog sits unchanged for as long as the backup takes, with no way to tell whether anything is happening — and a proxy timeout in between is indistinguishable from a hang.

This adds progress reporting to the backup dialog, and fixes three bugs in Output found along the way.

Progress reporting

The request is sent in the background and the dialog polls status.php, using the getModuleStatus() hook already present for upload progress — no new endpoint, and the poll does not go through index.php (no MySQL connection per poll).

• lib/backupstate.php (new) keeps the state of a running backup in tmp/, keyed by a token the dialog generates. Writes are throttled to one every 0.4s and go through a scratch file, so a poll never reads a half written state. Stale files are cleaned up on the next run.
• modules/backup.php answers the poll, reports only on a backup started by the session that is asking, and releases the session lock immediately.
• modules/download.php registers the token before releasing the session, counts the selected objects, and updates the state per object and per batch of rows. ignore_user_abort() keeps a backup alive when the browser goes away; a shutdown handler records fatal errors so the dialog reports them instead of polling forever.
• lib/export/export.php gained an optional per batch progress callback.

Because the state lives in a file, the poll decides when the backup is over, not the request: a connection dropped by a proxy no longer loses the result. Selecting no object is now refused uroducing an empty file.

Bug fixes in Output (first commit, stands alone)

• ob_start() had no chunk size, so the entire dump w only at the end — memory_limit on a large database,and the request dies with nothing to show. Now flushes every 64 KB.
• When the target file could not be opened (backup fol buffering was started anyway, so the error messageprinted afterwards was swallowed and written nowhere. The user saw an empty page instead of the reason.
• end() called gzclose() and then fell through to , and re-ran ob_end_flush() when called a second timeby the destructor, ending a buffer it does not own.

Testing

Manual, against MySQL 8.4 on PHP 8.2, on this branch:

• 120,000 rows / 20.7 MB over 3 tables: 45 distinct progress updates in 17.5s, dump verified (3 CREATE TABLE, 120,000 INSERT, footer
  present, no php noise in the file).
• The sys schema, 151 objects across tables, views, procedures, functions and triggers: completes and reports correctly.
• Concurrency: with the backup running for 12s in one d in 4–26 ms throughout, confirming the session lock isgenuinely released.
• Error paths: invalid filename format, no objects selion that did not start the backup all behave asexpected.

Notes

• Only lang/it.php is updated; the new strings fall back to English elsewhere.
• The dialog no longer reloads itself when the backup e.
• tmp/ needs to be writable; it falls back to the system temp directory if it is not.