12 Commits

Author	SHA1	Message	Date
jmiller	a2362d5400	@ ... feat(runbackup): opt-in auto-continue + manual continue on pre-update screen The pre-update/uninstall full-screen backup now shows an "Automatically continue the update when the backup finishes" checkbox (ticked by default, so the seamless flow is unchanged). If unticked, the screen stops on completion and offers a link to the new backup record plus a "Continue the update" button, so the user can hand back to Joomla manually — a reliable fallback when auto-continue does not fire. Also drop the hard-to-read `small` text class from the progress screen. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 20:44:10 -05:00
jmiller	83b261db02	@ ... style(runbackup): gray card via bg-body-secondary utility class Move the card background off a custom CSS rule and onto a Bootstrap utility class (bg-body-secondary) on the card element itself, so the gray panel background is declared in the markup. Supersedes the .card background-color rule added in the previous change. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 19:54:01 -05:00
jmiller	f5bcc7c457	@ ... fix(css): reliably load component stylesheets (progress bar was unstyled) The full-screen backup progress bar lost all styling after the CSS moved to the Web Asset Manager: this component's WAM style assets do not emit a <link> on the admin document. The asset resolves without error (Joomla lazily registers media/com_mokosuitebackup/joomla.asset.json, so useStyle does not throw) yet no stylesheet tag is rendered — and the same was already silently true of com_mokosuitebackup.admin (it was just cosmetic, so unnoticed). Confirmed live: neither runbackup.css nor admin.css loads, body stays white, the bar has no track/fill. Attach the external media stylesheets directly to the document (addStyleSheet), which renders reliably via <jdoc:include type="styles">. The joomla.asset.json + useStyle calls are kept so the WAM path resumes automatically if/when it starts emitting. Fixes both runbackup and the profile edit screen. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 19:05:15 -05:00
jmiller	d658019007	@ ... refactor(runbackup): move screen CSS into the Web Asset Manager All full-screen backup CSS now loads through Joomla WAM instead of an inline <style> block (and the redundant inline style="width:0"): - New media/css/runbackup.css holds the whole stylesheet. - Registered as asset com_mokosuitebackup.runbackup in joomla.asset.json. - tmpl/runbackup/default.php loads it via getDocument()->getWebAssetManager()->useStyle(com_mokosuitebackup.runbackup), matching the existing com_mokosuitebackup.admin pattern. The css folder already ships via the manifest <folder>css</folder>, so no manifest change is needed. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 18:18:08 -05:00
jmiller	8a783aa25a	@ ... style(runbackup): black backdrop on the full-screen backup screen Set html/body background to #000 so the full-screen pre-update / Backup Now progress screen runs on a black backdrop (the card + Atum-coloured progress bar sit on top). Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 18:13:51 -05:00
jmiller	3eb2562abd	@ ... fix: pre-action backup fires for every extension, not one per 10 min Root cause of "pre-update backup only fires on the backup extension": a coarse 600s session throttle. Whenever ANY pre-action backup ran (including updating MokoSuiteBackup itself, or a core Joomla update), the key mokosuitebackup.preaction_backup_before_update was armed for 10 minutes. onBeforeCompileHead read it as `recentBackup` and DISABLED the client-side interceptor for all extensions, and runPreActionBackup was throttled by the same window. So after updating one extension, every other extension update silently skipped its backup for 10 minutes. Replace the time window with "one backup per Update action": - runPreActionBackup dedupes per-request (a batch update fires the event once per extension in a single request -> back up once) via instance flags, and consumes a ONE-SHOT session skip flag for the re-fired client update/uninstall (skip once, next distinct action backs up). - ajax.preupdateAck sets the one-shot flag for the SPECIFIC action (update|uninstall), passed from installer-backup.js via &msb_action and surfaced by Runbackup HtmlView -> CFG.action. A core update passes no action, so it never suppresses an extension backup. - onBeforeCompileHead drops the recentBackup time-suppression (the re-fire loop is already guarded client-side by window.__msbResuming). - The core Joomla update path uses its own key (mokosuitebackup.core_update_backed_up), decoupled from extensions. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 17:48:09 -05:00
jmiller	f9c1c6b186	@ ... fix(review): open-redirect, btoa UTF-8 safety, honest duplicate-mode txn Pre-release review findings on dev -> main: - Return-URL open-redirect (MED): a base64 returnurl like "/\evil.com" passed the root-relative allow-list (raw[1] is "\", not "/"), and a browser normalises leading "/\" to "//", yielding a protocol-relative redirect off-site. Reject any backslash or control char in the decoded return URL outright — legitimate Joomla admin URLs never contain them. - installer-backup.js btoa() (LOW): btoa() throws on non-Latin1 input (e.g. a UTF-8 filter value in the list query string), and the throw was uncaught after preventDefault(), leaving the toolbar button dead. Build the redirect (UTF-8-safe base64) BEFORE swallowing the click; if it still fails, bail without preventing so Joomla proceeds normally. - Snapshot duplicate-mode transaction (HIGH): restore() wrapped duplicate mode in transactionStart()/Rollback(), but duplicate mode writes via Joomla Table API whose Nested tables (categories/tags) issue LOCK TABLES, which implicitly COMMITS the open transaction in MySQL — so the rollback promise was illusory and a mid-inject failure left a slave half-updated. Run only the raw-DB modes (replace/create/merge) inside the transaction; duplicate mode runs outside it, matching its existing per-item defensive design (bad item skipped + logged, never fatal). Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 17:14:10 -05:00
jmiller	4d476fde5d	@ ... style(runbackup): drop max-width/margin so the card spans full width The backup screen was centred in a 720px column; unset max-width and the auto margins so it fills the available width. Keeps the horizontal padding. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 16:41:47 -05:00
jmiller	4bc8b47d05	@ ... fix: reliably intercept extension update/uninstall + polish backup screen The full-screen pre-action backup did not fire for extension updates/uninstalls because Joomla 6 renders the com_installer toolbar Update/Uninstall buttons as `<button task="update.update">` web components, not inline onclick="Joomla.submitbutton(...)". Wrapping Joomla.submitbutton never caught them. installer-backup.js now uses a capture-phase document click listener on any `[task]` element matching update.update / manage.remove(/uninstall), so it runs before the toolbar web component. It captures the checked cid[] selection, runs the full-screen backup, and on return restores the selection, sets the boxchecked list-guard field, and re-fires the real toolbar button with __msbResuming set so it is not re-intercepted. Also polishes the runbackup screen: the progress bar is now a full-bleed strip along the bottom edge of the card (edge-to-edge, clipped to the rounded corners) instead of a boxed bar crowding the status text, and it is coloured from the Atum template CSS custom properties (--template-link-color / --template-special-color / --template-success-color / --template-danger-color) with Bootstrap and literal fallbacks. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i @	2026-07-12 16:07:36 -05:00
jmiller	7a0636606e	feat: full-screen backup for extension update/uninstall + view-record button ... Extend the full-screen backup screen beyond core Joomla updates: - Extension updates/uninstalls (com_installer): update.update and manage.remove are POST + checkToken with a checked cid[] list, so a server-side GET redirect can't resume them. New client-side interceptor (installer-backup.js, injected via onBeforeCompileHead on the update and manage views) wraps Joomla.submitbutton, stores the selection, sends the browser to view=runbackup, and on return restores the selection and re-submits the real POST form. Gated by backup_before_update / backup_before_uninstall, super-user only, skipped within the throttle window. - runbackup: on manual 'Backup Now' completion, show a 'View backup record' button (links to view=backup&id=<record_id>); not shown for the pre-update/uninstall flow (which hands back to Joomla). SteppedBackup Engine now returns record_id in its step result. - runbackup arms the pre-action throttles on success (ajax.preupdateAck, now arming both update+uninstall keys) so the following server-side onExtensionBefore(Update|Uninstall) backup is skipped (no duplicate). - Plugin manifest re-registers media/js. NOTE: untested end-to-end (no dev build available this session) — verify the com_installer resume flow on a dev build before relying on it. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i	2026-07-10 10:53:46 -05:00
jmiller	4311ec8f99	fix(security): enforce scheme allow-list on runbackup return URL ... The pre-update return URL is assigned to window.location.href, so a javascript:/data: URI (empty host) would have passed the host-only check and executed. Require an absolute http(s) same-host URL or a single-slash root-relative path; reject javascript:/data:/vbscript: and protocol-relative //host. Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i	2026-07-05 22:57:40 -05:00
jmiller	8cfa46d985	feat: full-screen backup screen for pre-update + Backup Now (Akeeba-style) ... Replace the popup-modal pre-update approach with a dedicated full-page backup screen, modelled on Akeeba Backup-on-Update, and fix the white screen caused by running a backup synchronously inside the update request. - New view=runbackup (View/Runbackup + tmpl/runbackup): full-screen progress page that auto-starts the stepped backup (ajax.init -> loop ajax.step), then redirects to a validated returnurl on completion or shows a completion/retry panel. Auto-resolved by MVCFactory. - System plugin: on com_joomlaupdate task=update.install (when backup_before_update is on), redirect to the full-screen backup screen with returnurl back to update.install&is_backed_up=1; on return, arm the throttle so onExtensionBeforeUpdate does not run a duplicate backup. No synchronous backup in the update request. - Dashboard 'Backup Now' navigates to the full-screen screen instead of the inline modal; the inline modal + stepped JS are removed. - Retire the popup modal: delete media/js/update-backup.js, remove the plugin <media> element and the preupdate_auto_intercept param. - Dashboard: warn when Global Config live_site is empty (CLI/scheduled backup naming + URL generation depend on it). Refs #196 Claude-Session: https://claude.ai/code/session_01WbGBN9VyRK61zczYWcCQ2i	2026-07-05 22:55:28 -05:00