Alynt Drime Backups Uploader

Companion WordPress plugin that scans completed local backup packages and uploads them to Drime. It currently supports WPvivid backup archives and a generic server outbox for packages produced by a server-side runner or another backup producer.

Features

• Scans configured backup producers through an adapter layer.
• Detects the local WPvivid backup folder, including verified Free/Pro path options.
• Scans a configured generic server outbox for completed archive packages with optional manifest, checksum, remote-index, and remote-catalog sidecars.
• Scans only stable backup files so in-progress archives are not queued.
• Handles WPvivid-listed split archives such as .part001.zip and .part002.zip as complete sets.
• Queues uploads, tracks attempts, enforces retry limits, prevents duplicate queue entries, and uses a renewable owner-aware worker lock so long multipart uploads cannot be taken over by another scheduled worker.
• Uploads small files through Drime direct upload and larger files through resumable multipart upload.
• Uploads each generic server-runner package set into its own Drime package folder, including the archive, manifest, checksum, package-level remote-index, and folder catalog snapshot sidecars, so fetched packages can be discovered and verified before restore staging.
• Shows failed uploads with per-file retry actions when the local file is still readable.
• Lets administrators load allowed Drime workspaces, browse existing Drime folders, and preview the resolved upload destination before backups run.
• Blocks the personal/default Drime workspace ID 0 for backup destinations and supports an optional ALYNT_DRIME_ALLOWED_WORKSPACE_IDS constant to lock a site to approved workspace IDs.
• Caches resolved Drime parent folder IDs so remote duplicate checks work after relative-path uploads.
• Supports duplicate handling by skipping existing remote files or asking Drime for an available filename.
• Provides manual admin actions for connection testing, scanning, upload, diagnostics export, diagnostics clearing, and active-upload recovery.
• Provides manual remote-retention preview and cleanup for plugin-owned Drime uploads, moving eligible remote files to Drime trash only.
• Provides optional server-specific local retention that prunes older uploaded generic outbox/server-runner packages while keeping the newest configured package sets.
• Sends optional plain-text failed upload notifications through WordPress mail with duplicate suppression.
• Tracks scheduled-scan cron health so administrators can see whether scans have run from WP-CLI or only from HTTP WP-Cron.
• Supports explicit central-dashboard V2.1 action opt-in for one bounded signed action, scan_upload_now, which asks this client to scan for ready packages and upload eligible items using its own local settings and Drime credentials.
• Provides WP-CLI commands for server-driven scan/upload/status workflows.
• Includes a standalone PHP CLI server runner that can create .tar.gz site packages for the generic outbox, record light consistency metadata, guide non-destructive restore staging, run staging and production-simulation restore workflows behind explicit safety gates, preview old local artifacts, and run operator-approved local cleanup behind an explicit confirmation flag.
• Stores bounded, redacted diagnostics when diagnostics are explicitly enabled.
• Keeps local backups after upload by default; deletion requires explicit opt-in.

Requirements

• WordPress 6.0 or later.
• PHP 7.4 or later.
• At least one local backup producer: WPvivid local backups, the included server runner, or another process that writes completed packages to the generic outbox.
• A Drime API token.

Installation

1. Upload the plugin folder to wp-content/plugins/alynt-drime-backups-uploader.
2. Activate Alynt Drime Backups Uploader from the WordPress Plugins screen.
3. Open Tools > Drime Backups.
4. Enter a Drime API token and destination settings.
5. Configure the WPvivid path override and/or server outbox path for the backup producer in use.
6. Use Test Drime Connection before scanning or uploading.

For development and release validation, use the packaged zip and the documented LocalWP confirmation gate before touching plugin-tester.local.

Development

Run npm run build after editing files in assets/src/admin/ or server-runner/src/. The build regenerates the enqueued assets/admin.js, assets/admin-workspaces.js, and assets/admin.css files plus the deployable server-runner/alynt-backup-runner.php. Edit the modular runner source, not the generated one-file artifact. Use npm run verify:runner and npm run lint:runner for deterministic freshness and PHP syntax checks, then run npm run test and npm run lint before packaging. The pot script requires WP-CLI on the command path.

GitHub Actions runs the reusable quality workflow on PHP 7.4 and 8.3, then verifies the Node build, generated assets, generated-runner freshness, and dependency audit. Release packaging depends on that quality workflow passing and validates that the installable ZIP contains the generated runner but excludes modular runner source.

Updates

The plugin includes GitHub Plugin URI: NichlasB/alynt-drime-backups-uploader for Alynt Plugin Updater compatibility. Release builds should be distributed from public GitHub releases using an attached WordPress-installable zip asset.

Configuration

The settings screen controls:

• Drime API token, non-personal workspace ID with optional workspace picker, selected or manually entered parent folder ID, and optional relative subpath.
• Optional WPvivid backup path override.
• Optional server outbox path for generic packages produced outside WordPress.
• Optional per-source Drime relative paths for separating server-runner/generic-outbox uploads from WPvivid uploads.
• Duplicate handling mode: skip existing files or rename new uploads.
• Automatic WP-Cron scanning.
• Optional server-cron expectation reminders for WP-CLI-driven scheduled scans.
• Minimum file age before queueing.
• Multipart chunk size for large Drime uploads.
• Optional local deletion after confirmed upload.
• Optional server-specific local retention for uploaded generic outbox/server-runner packages.
• Optional manual remote retention for old plugin-owned Drime uploads.
• Optional failed upload email notifications and recipient list.
• Maximum retry count.
• Diagnostics enablement, minimum severity, and retention.
• Central-dashboard read-only pairing and optional separate V2.1 action opt-in token.

See docs/SETTINGS.md for the full option schema.

Uninstall Behavior

Uninstall removes the plugin-owned WordPress options and scheduled cron hooks for each site on multisite installs. It does not delete local WPvivid backups, generic outbox packages, server-runner sidecars, restore staging folders, or manually installed runner directories; those files may be the only local backup copies and should be retained or cleaned up through an operator-approved server process.

Producer Adapters

Backup sources are implemented as producer adapters. A producer discovers completed local packages and returns normalized package records; the shared queue and Drime uploader handle the upload lifecycle.

See docs/PRODUCER_ADAPTERS.md for the adapter contract, package record shape, stability rules, and test expectations for future producers.

See docs/PRODUCER_ADAPTER_BACKLOG.md for the decision guide to use before adding any additional third-party producer adapter.

Server Runner

The server-runner/ directory contains a standalone PHP CLI runner for GridPane-style servers. It exports the WordPress database with WP-CLI, archives the WordPress files with tar, writes manifest/checksum/remote-index/remote-catalog sidecars, and atomically places completed packages in the configured outbox.

When the generic outbox uploader sends a server-runner package to Drime, it creates or reuses a child folder named after the package ID under the effective generic-outbox destination path. The archive and all recognized sidecars are uploaded into that package folder. For example, a package ID of example-com-20260702-010001 with server_relative_path set to /example.com/server uploads to /example.com/server/example-com-20260702-010001/.

See server-runner/README.md for the runner config shape and commands.

For onboarding a new GridPane site from install through first upload and server-runner restore staging proof, see docs/SITE_ROLLOUT_RUNBOOK.md.

The plugin settings screen generates a guided server setup flow with four copy-paste blocks: install/update the runner, create and verify one test package, scan/upload completed packages, and review/install cron. The install command embeds the non-secret config.json content, creates private directories, copies the bundled runner, sets permissions, and runs health in one single-line shell command. The cron review block uses single-line shell commands to build a proposed user crontab file, show a diff, and leave the final install command commented until an operator approves it. The cron snippet creates one daily server-runner package, runs the plugin's scheduled scan/upload hooks every 15 minutes through WP-CLI so cron health evidence stays accurate, and includes a lightweight status check line.

For the broader server-side automation model, including scheduling, multiple standalone site layout, disk retention, cleanup preview/execution, and high-write-site boundaries, see docs/SERVER_BACKUP_AUTOMATION.md. For several separate WordPress sites on one server, see docs/MULTIPLE_STANDALONE_SITE_RUNNER_GUIDANCE.md.

For restore validation, see docs/RESTORE_RUNBOOK.md. The server runner can fetch a known package from Drime, verify it, inspect it, print next-step guidance, stage it for inspection, write local restore evidence, and run a read-only restore-dry-run preflight. Restore staging now records deterministic SHA-256 integrity details for the extracted WordPress tree and database dump. Dry run also checks a pre-restore backup evidence JSON file before reporting that staging apply would be allowed. When explicitly requested with --write-report=1, a passing dry run writes a JSON evidence report under configured restore_reports_path. The separate restore-production-preflight command performs stricter target, package, staged-input integrity, disk, write-control, and native-backup readiness checks and can optionally write a redacted audit report. restore-production-create-pre-backup can create fresh private, hash-recorded recovery evidence only after that preflight and its own exact confirmation. Disabled-by-default production-simulation apply supports separately approved files-only, database-only, or combined rehearsals with exact target confirmations, evidence hashes, target-drift checks, maintenance control, post-apply verification, and rollback-ready reports. Combined production apply replaces files first and then imports the database under one maintenance window. Production apply binds the staged integrity record into private pre-restore evidence and recomputes it after maintenance activation immediately before target writes. Production file apply and rollback preserve only exactly enrolled symlinks and require the complete plugin, theme, drop-in, symlink path, and symlink target inventories to match before maintenance is removed; rollback validates extracted symlinks before target deletion, and both production reports use private mode 0640. Actual-production enrollment remains unavailable. restore-apply --scope=database can import the staged database, restore-apply --scope=files can replace the staging target files, and restore-apply --scope=files-and-database can run file replacement followed by database import, only after the exact --confirm=restore-staging-site phrase and passing dry-run/evidence gates. Add --create-pre-restore-backup=1 to a staging apply command to create matching pre-restore database/file backup evidence immediately before apply. File and combined apply report pre-restore symlinked drop-ins that are absent from staged files so operators can inspect or regenerate them after apply.

For recording restore proof during onboarding or periodic confidence checks, see docs/RESTORE_REHEARSAL_CHECKLIST.md.

For package integrity, extraction safety, storage-path, and encryption boundaries, see docs/PACKAGE_SECURITY.md.

For database/filesystem timing expectations and high-write site caveats, see docs/CONSISTENCY_MODEL.md.

For disaster discovery when the original WordPress plugin state is unavailable, see docs/REMOTE_RESTORE_DISCOVERY.md.