Alynt Drime Backups Uploader WP Registry grade A. No security issues foundWP RegistryNo security issues foundOpen the reportA

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.

Diagnostics

Diagnostics are disabled by default. When enabled, the plugin stores a bounded event log in WordPress options and exposes a health summary, recent events table, JSON export, and clear action to administrators.

Diagnostics redact bearer tokens, authorization headers, cookies, nonces, passwords, request bodies, presigned URLs, and HTTP URLs embedded in scalar values.

See docs/STATUS_PAYLOAD.md for the redacted health/status payload contract used by WP-CLI, wp-admin, diagnostics, and authenticated central-dashboard polling.

For the central monitoring dashboard boundary, see docs/CENTRAL_DASHBOARD_READINESS.md. For the separate dashboard plugin preparation plan, see docs/CENTRAL_DASHBOARD_PROJECT_PLAN.md. The dashboard plugin remains separate; this uploader exposes the fixed status endpoint only after administrator opt-in, dashboard-origin review, and completed authenticated pairing. V2.1 action intents require a second dashboard-generated adb2a token and explicit local opt-in; the only accepted action is scan_upload_now.

Cron Health

The Scan State panel shows the current UTC time, the next automated scan, the last scheduled scan, the last detected scan runner, whether DISABLE_WP_CRON is active, and a server-cron health summary. The plugin records runtime evidence from WordPress; it does not read server cron files such as /etc/cron.d/wp-cron-sites.

Frequently Asked Questions

Does this delete local WPvivid backups?

No. Local deletion is disabled by default and only runs after confirmed upload when the administrator enables Delete Local Files. For WPvivid-listed split backup sets, the plugin waits until every listed part has uploaded successfully before deleting the local parts.

Does this delete local server-runner packages?

Not by default. When Prune Uploaded Server Packages is enabled, the plugin prunes only uploaded generic outbox/server-runner packages from the configured server outbox after they fall outside the newest retained package count. WPvivid files are not affected by that setting.

Does this permanently delete Drime files?

No. Remote retention is disabled by default, runs only from manual admin actions, and moves eligible plugin-owned Drime uploads to trash. It does not permanently delete remote files.

How are failed upload emails delivered?

Failure emails are disabled by default and use WordPress wp_mail(), so the active site mail stack or SMTP plugin handles delivery. Emails are plain text and include only safe operational details such as site URL, backup filename, sanitized reason, attempt count, timestamp, and the admin page URL. Transient Drime API responses such as 429 or 5xx remain queued for later workers instead of immediately becoming final failure emails.

Can a failed upload be retried?

Yes. Failed uploads appear in the admin status area with a retry action when the failed registry still points to a readable local backup file. Retrying puts that file back at the front of the queue with attempts reset to zero.

How do the Drime base folder and relative path work?

Select an existing Drime base folder, then enter the site folder or subpath in Relative Path. For example, selecting General/Files/Backups and entering site1.com resolves uploads to General/Files/Backups/site1.com. Browsing and previewing are read-only; missing subfolders are created only when an upload needs them.

When multiple producers are enabled, source-specific Drime relative paths can keep package types separate. For example, keep the shared path as /site1.com, then set the server path to /site1.com/server and the WPvivid path to /site1.com/wpvivid. Empty source-specific fields fall back to the shared Relative Path.

How does workspace selection work?

Use Load Drime Workspaces to retrieve workspaces available to the saved API token. During first setup, the workspace field may stay blank while you save the token and discover the correct destination. Choosing a workspace updates the numeric Workspace ID field and clears the selected base folder so folders from another workspace are not reused accidentally. Save settings after choosing a workspace.

Workspace ID 0 is blocked by default so backups cannot be configured into the personal/default Drime workspace. To lock a site to one or more approved workspaces after discovery, add a constant to wp-config.php:

define( 'ALYNT_DRIME_ALLOWED_WORKSPACE_IDS', '12345' );

Use comma-separated IDs when more than one workspace should be selectable:

define( 'ALYNT_DRIME_ALLOWED_WORKSPACE_IDS', '12345,67890' );

When the constant is present, the workspace picker, settings save, folder browser, destination preview, and upload worker all reject disallowed workspace IDs.

Does this upload incomplete WPvivid files?

The scanner waits until files are old enough and their size is stable across scans. WPvivid-listed split sets are queued only when every listed part is present and stable.

Can this run beside the old Alynt Drime WPvivid Uploader?

During migration, yes, but do not leave both plugins automatically uploading the same WPvivid backup folder. The health summary warns when the old WPvivid-specific uploader is active and this plugin is configured to use the WPvivid source.

Does this upload incomplete server-runner packages?

The generic outbox producer ignores temporary files and waits until archive size is stable across scans. The included server runner writes to temporary paths first and only renames completed package artifacts into the outbox.

Does this expose developer hooks?

No public custom actions or filters are exposed. See docs/HOOKS.md.

Changelog

See CHANGELOG.md.

License

GPL-2.0-or-later. See LICENSE.