-
Notifications
You must be signed in to change notification settings - Fork 0
Architecture
Fleet registers a hub App and an instanceable managed-site App. Each site's window receives a site ID belonging to the current hub administrator. There is no global active-site switch or remote wp-admin iframe.
PHP server views declare state, actions, forms, tabs, native tables, and pagination. OpenStation owns transport, loading, morphing, window chrome, and confirmations. Fleet's small JavaScript bridge handles named-instance identity, approval navigation, and unsaved-change guards.
Core discovery tries the query-form REST route before rewrites. A ten-minute per-user server record supplies the approval destination; client-state URLs are not trusted. The callback consumes the attempt and validates nonce/state/origin, introspects the password, and checks administrator capabilities.
An encrypted connection is saved with setup pending. A separate action installs/activates OpenStation and checks metadata. Repair verifies a replacement before swapping generations; current agency details survive and old-password cleanup failures stay visible.
Individual connection records and an index use WordPress user metadata. Search is separately stored, encrypted, and generation-bound. Repository leases and compare-and-swap checks prevent stale local workers from overwriting newer connection generations. Activity is bounded. There are no custom database tables.
The REST client decrypts credentials server-side, confines requests to the connected origin/REST root, and bounds timeouts and response sizes. Core batch reads are used where available. Explorer operates on advertised routes.
The App Framework's in-process WordPress REST helper runs against the hub, so it must not replace Fleet's remote client.
Lists load 12 compact records; opening content fetches raw source. Fresh fingerprints catch intervening edits, including same-second changes, but are not atomic remote locks. Core offers no compare-and-swap content write.
Creation carries a per-user/site request ID. A local lease and 14-day attempt marker refuse duplicate/uncertain replays. This is not remote exactly-once delivery: inspect WordPress after an interrupted request before starting another draft.
Unsaved source is held in page/session state, not localStorage. Navigation/unload guards protect normal navigation but cannot recover a browser crash by themselves. When a user explicitly enables recovery, Core Heartbeat sends bounded editor fields to encrypted, generation-bound hub transients; it never creates remote content or replaces a backup.
Connections remain owned by one hub administrator. Explicit Reader, Editor, and Operator grants are stored with the connection generation and indexed for the recipient's launcher. Every action and remote request resolves the live grant again, so revocation applies to an already-open window's next request. The remote WordPress site still sees the owner's approved account as the actor; Fleet grants are hub workflow permissions, not new remote identities.
Status, metadata/index, and health use five-minute, one-hour, and six-hour cadences. Scheduled runs stop around a 40-second budget, preserve a cursor, and back off failing sites. Production hubs with low traffic need a server-driven WP-Cron runner.