[personal-wp] Backup reminder UI

[akirk]

Based on #3157.

Motivation for the change, related issues

Personal Playgrounds store data in the browser's Origin Private File System (OPFS), which can be cleared unexpectedly by the browser. Users need a gentle reminder to back up their work periodically to avoid data loss.

This PR adds a backup status indicator that tracks usage days since the last backup and prompts users to download backups based on urgency.

Screenshots

(No button when the backup is up to date)

Auto-Backup

Implementation details

New files:

• backup-status-indicator.tsx - Component showing days since last backup with color-coded urgency (green ≤1 day, yellow 2-4 days, red 5+ days)
• backup-status-indicator.module.css - Styles for the indicator button
• use-backup.ts - Hook that handles backup creation using zipWpContent and file-saver

Modified files:

• slice-sites.ts - Added metadata fields:
  • backupHistory - Array of recent backups (filename + timestamp)
  • lastAccessDate - Timestamp for tracking usage days
  • daysUsedSinceLastBackup - Counter reset on backup
• persistent-browser-chrome/index.tsx - Added BackupStatusIndicator to toolbar

Behavior:

• Indicator only appears after the user returns on a different day than creation
• Tracks "days used" (not calendar days) - only increments when user actively uses the site
• Clicking the button downloads a self-contained zip backup
• Counter resets to 0 after successful backup

Testing Instructions (or ideally a Blueprint)

1. Create a new persistent Playground
2. Verify the backup indicator does NOT appear on the first day
3. Open browser DevTools and use the snippet below to fake the last backup date
4. The indicator should appear in yellow ("2 days since backup")
5. Click the indicator button
6. Verify a zip file downloads with format: {site-name}-backup-{date}-{time}.zip
7. Verify the indicator disappears (counter reset to 0)
8. Set daysUsedSinceLastBackup to 5 - indicator should appear in red

  // Fake old backup for testing (could be added to your snippets)
  window.fakeOldBackup = function(days = 3) {
    const store = window.__PLAYGROUND_STORE__;
    if (!store) {
      console.error('Store not available. Make sure you are in dev mode.');
      return;
    }

    const state = store.getState();
    const slug = state.ui.activeSite?.slug;
    if (!slug) {
      console.error('No active site');
      return;
    }

    const site = state.sites.entities[slug];
    if (!site) {
      console.error('Site not found');
      return;
    }

    const daysAgo = Date.now() - days * 24 * 60 * 60 * 1000;
    store.dispatch({
      type: 'sites/updateSite',
      payload: {
        id: slug,
        changes: {
          metadata: {
            ...site.metadata,
            whenCreated: daysAgo - 24 * 60 * 60 * 1000,
            lastAccessDate: Date.now(),
            daysUsedSinceLastBackup: days,
            backupHistory: [],
          },
        },
      },
    });

    console.log(`Faked ${days} days since backup for site "${slug}"`);
  };

  console.log('Run fakeOldBackup(3) to simulate 3 days since backup');

[adamziel]

Can we use WordPress HTML API for this? Or decode is in JavaScript? html_entity_decode doesn't do its job well.

[akirk]

What about using json_encode() in PHP and JSON.parse() in JS? That would fully avoid any HTML entities.

[akirk]

or actually, right now:

1. get_option() → Alex's WordPress
2. html_entity_decode() → Alex's WordPress
3. sanitizeForFilename() → Alex-s-WordPress (apostrophe becomes -)

I just verified that WordPress stores the blogname via

case 'blogdescription':
case 'blogname':
    // ...
    $value = esc_html( $value );
    break;

Which itself uses _wp_specialchars which itself uses htmlspecialchars for which html_entity_decode should be appropriate.

[adamziel]

I left some notes, the blocking ones are filename sanitization, HTML decoding of the title, and the import question. The rest I think is ready for merging.

[akirk]

I realized that the button started to get annoying, so I added an auto-download (or ignore backup) dropdown:

[adamziel]

nice comment

[adamziel]

We have some datetime formatting utils we could reuse here. Not a blocker.

[adamziel]

nice

[adamziel]

oh, you can switch to a different site here? how? or is this just "defense in depth" in case someone finds a button we forgot to hide?

[adamziel]

hm I can't see my previous comment, I'm pretty sure I've left it here 🤔 html_entity_decode is pretty bad, we'd be better off decoding in JS. I wouldn't say it's a blocker because of how the siteName is used, but changing it might save us some &amp literals.

[adamziel]

@copilot echo $name and decode the entity in JS in a secure way.

[Copilot]

@adamziel I've opened a new pull request, #3190, to work on those changes. Once the pull request is ready, I'll request review from you.

[adamziel]

nit: we could extract this to a shared package and import in both website and personal-wp. Not blocking.

[adamziel]

LGTM aside of the html encoding issue. I've asked copilot to adjust it. We can merge regardless.