-
Notifications
You must be signed in to change notification settings - Fork 0
Feature Backlog
Publishing review/revision recovery, per-site content views, and supported REST-enabled custom types shipped in 0.9.0-rc.1. The current 0.10.0 release adds optional encrypted hub draft recovery, author/featured-media/taxonomy controls, upload, reply/bulk moderation, synchronization diagnostics, and explicit team grants.
The remaining proposals are comment-based saved views, a missing-alt-text review queue, configuration comparison, a fleet publishing calendar, and client work summaries. None is included in the current consumer promise. See the release record for what is downloadable and Current scope for the 0.10 release.
The priorities below are product judgments informed by the current implementation and official Core API documentation reviewed September 4, 2026. They need pilot feedback. None requires adding an endpoint to a managed site, an OpenStation PR, or a custom authentication server.
Problem: With several client windows open, a correct edit on the wrong site is still a costly mistake.
Add a review step for publishing/scheduling: destination domain, title, status, time in the site's timezone, and a concise old/new diff. Add revision browsing and recovery of supported content fields. Use normal Core post updates after a fresh conflict check; Core revision retrieval is not an atomic restore endpoint. Autosaves could provide draft recovery once a parent post exists, subject to capability/type support and testing of the connected user's autosave ownership. Posts, revisions and autosaves
Start with review and revision comparison; pilot recovery next. Never silently create a remote draft just because somebody opened an editor. Keep recovered text editable before applying it.
Problem: Agencies repeat the same morning checks and rebuild the same filters every day.
Save views such as “Harbor Arts pending review,” “Scheduled this week,” and “Unanswered comments.” Store only view configuration in per-user hub preferences, through the existing app action mechanism; fetch bounded Core collections or use clearly dated caches. No new remote endpoint or browser copy of private content is needed. Core supplies status/date filters and comment relationships; a view must state exactly what “unanswered” means. Posts, comments
Acceptance: every row identifies its site, opening it targets the correct site window, stale data is visible, and large fleets do not trigger unbounded requests. Begin with read-only views.
Problem: “Posts and pages” excludes many agencies' events, portfolios, and other custom content.
Discover REST-enabled post types and their advertised namespace, base route, supports, and capabilities. Present supported fields through the same site-scoped editor. Only show types already exposed by the destination; this does not make non-REST plugins remotely manageable. Treat custom schemas and registered metadata conservatively. Core post-type discovery
First prove one simple REST-enabled events type and one restricted type. Keep site ID, type, and record ID together in routing and conflict protection. Do not market generic discovery as complete WooCommerce administration.
Problem: A source edit is incomplete when the author still needs another admin screen to set an image or organize the post.
The 0.10 release adds author, featured-image, categories/tags, and bounded media upload workflows. A missing-alt-text review queue remains proposed. Core exposes those post fields and media metadata. Empty alternative text can be intentional for decorative images; label it “review,” not an automatic accessibility failure. Post fields, media fields and upload route
Keep media and taxonomy IDs scoped to their destination site. Validate destination ownership, unsupported fields, pagination, size limits, and partial failures. Do not copy attachment IDs between sites.
Problem: Agencies can see work waiting but still lose time replying and moderating one site at a time.
The 0.10 release adds replies in context and reviewed, bounded bulk moderation. Core supports comment creation with parent/post relationships and comment status updates. Core comments API
Preview exact target sites and comments; preserve per-item outcomes; do not imply atomic changes across sites. A timeout after a reply is an uncertain write, not permission to blindly send the same reply again. Use batching only where the target explicitly supports it.
Problem: Small settings changes across a large fleet are easy to overlook.
Let an agency approve a per-site baseline for a small allowlist of Core-exposed settings, then show a read-only difference report with observation times. Begin with site identity, timezone, and discussion defaults. Core settings
This is not a backup, malware scanner, or whole-site audit. Do not offer blind “make every site identical” writes. An unavailable API produces unknown/stale status, never a clean bill of health.
- Complete the current dependency, endurance, hosting, and agency-pilot gates.
- Use pilot evidence to decide whether comment-based saved views or the missing-alt review queue removes more daily friction.
- Add read-only configuration comparison only after the freshness/error model is proven on independent hosts.
- Build a fleet calendar from verified site timezones and scheduled Core content.
- Build client work summaries from Fleet's bounded activity log, clearly labeled as Fleet activity rather than a complete WordPress audit.
A fleet calendar is a natural later view of scheduled posts, but it should follow verified timezone behavior rather than become another scheduling implementation. A client work summary could reuse Fleet's activity log, labeled as actions performed through Fleet—not a complete audit of everything done to WordPress.
Keep unscheduled proposals out of the consumer README and release promises. Record capability limits, failure behavior, cleanup, and tests before committing to implementation.