Skip to content

WordPress 7.0 Connectors API — migration plan and open questions #985

@chubes4

Description

@chubes4

Context

WordPress 7.0 (April 9, 2026) ships the Connectors API — a core framework for registering and managing connections to external services. Initial scope is AI providers (Anthropic, Google, OpenAI), but the architecture is explicitly designed to expand to social media, payment gateways, messaging services, etc.

Dev note: https://make.wordpress.org/core/2026/03/18/introducing-the-connectors-api-in-wordpress-7-0/

What this means for Data Machine

Data Machine currently owns its own auth/provider layer:

  • BaseAuthProvider, BaseOAuth1Provider, BaseOAuth2Provider
  • Per-handler settings storage via get_option()
  • Custom settings UI in the DM admin
  • Provider configuration (OpenAI, Anthropic, Google, Grok, OpenRouter)

Long term, core Connectors API replaces all of this. DM stops shipping auth infrastructure and instead consumes connectors registered by core or by dedicated connector plugins.

Migration path

Phase 1: WP 7.0 ships (April 2026)

  • Connectors API available but scoped to ai_provider type with api_key auth only
  • DM can start reading AI provider keys from connectors (wp_get_connector('anthropic')) as a fallback alongside existing DM settings
  • No breaking changes — DM's existing auth continues to work

Phase 2: Core expands connector types

  • OAuth support lands in Connectors API
  • social_media, messaging, etc. connector types get admin UI
  • DM Socials migrates handler auth to core connectors
  • data-machine-events migrates any service auth to core connectors

Phase 3: DM auth layer deprecated

  • Remove BaseAuthProvider / BaseOAuth*Provider base classes
  • Remove DM-specific settings UI for provider configuration
  • DM becomes a pure consumer of wp_get_connector() for all external service auth
  • Massive reduction in DM surface area

Open questions

Architecture

  • Should DM register its own connectors via wp_connectors_init for services core doesn't ship (Grok, OpenRouter, etc.)? Or should those be separate connector plugins?
  • How does the Connectors API interact with multisite? Is the registry per-site or network-wide? DM's agent tokens are network-scoped — if connectors are per-site, there's a mismatch.
  • The Connectors API stores API keys unencrypted in the database (encryption tracked at core #64789). DM currently also stores unencrypted. Should we wait for core to solve encryption or implement our own layer?

Per-user / per-entity scoping

  • Core connectors are currently site-global (one key per provider per site). We need per-artist scoped OAuth for the social manager feature (see Extra-Chill/extrachill-roadie#8). Will core support scoped connectors, or do we build scoping on top?
  • The comments on the dev note already ask about scoping — Greg confirms keys are site-level with no per-plugin approval. This matches our concern.

OAuth expansion timeline

  • Core says OAuth support is planned but no timeline. Do we build interim OAuth infrastructure in DM that migrates to core later, or wait?
  • When OAuth lands, will it support the full flow (redirect URI, token refresh, revocation) or just token storage?

DM Socials specifically

  • DM Socials handles 8 platforms with site-global auth. Migration to connectors would mean 8 connector registrations. Should these be one data-machine-socials-connectors plugin or individual per-platform plugins?
  • Social posting requires more than just auth — it needs platform-specific API clients, rate limiting, media handling. Connectors API only handles the connection/auth piece. DM Socials' handler layer remains necessary.

WP AI Client interaction

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions