Summary
EditorConfiguration exposes plugins: Boolean and editorAssetsEndpoint: String? (URL? on iOS) as two independent fields, but only some combinations are meaningful:
plugins |
editorAssetsEndpoint |
Behavior |
false |
(any) |
Endpoint silently ignored — fetchManifest short-circuits |
true |
null |
Falls back to ${siteApiRoot}wpcom/v2/editor-assets |
true |
set |
Uses provided endpoint |
The (false, set) cell is a footgun. A caller that sets a non-functional endpoint (e.g. on a vanilla self-hosted site that doesn't expose wpcom/v2/editor-assets) is fine today because fetchManifest checks if (!configuration.plugins) return ... empty first, but the configuration object itself doesn't encode that the endpoint is conditional on plugins being enabled. We hit this in WordPress-Android while reviewing a builder change — the builder set the endpoint unconditionally, the URL would 404 on vanilla self-hosted, and the only thing keeping it harmless was the gate inside fetchManifest.
Proposal
Collapse the two fields into a single sealed/enum type so the dependency is encoded in the type:
Kotlin:
sealed class Plugins {
object Disabled : Plugins()
data class Enabled(val assetsEndpoint: String? = null) : Plugins()
}
Swift:
public enum Plugins {
case disabled
case enabled(assetsEndpoint: URL? = nil)
}
The four-cell table collapses to three meaningful states, and the silently-ignored combination is no longer representable.
Open questions
- Theme styles.
EditorAssetsLibrary's class doc says it backs both plugins and theme styles, but the only gate in fetchManifest is configuration.plugins. If theme styles will eventually consume the same endpoint, an Enabled.assetsEndpoint nested under Plugins is the wrong home — the endpoint should be a sibling field, with each feature gated independently. Worth pinning down before settling on shape.
- Migration. This is a breaking API change on both platforms. Could be staged: introduce the new type, mark the existing fields
@Deprecated, port callers, remove later.
Filing this so we can come back to it — not blocking any work today.
Summary
EditorConfigurationexposesplugins: BooleanandeditorAssetsEndpoint: String?(URL?on iOS) as two independent fields, but only some combinations are meaningful:pluginseditorAssetsEndpointfalsefetchManifestshort-circuitstruenull${siteApiRoot}wpcom/v2/editor-assetstrueThe
(false, set)cell is a footgun. A caller that sets a non-functional endpoint (e.g. on a vanilla self-hosted site that doesn't exposewpcom/v2/editor-assets) is fine today becausefetchManifestchecksif (!configuration.plugins) return ... emptyfirst, but the configuration object itself doesn't encode that the endpoint is conditional on plugins being enabled. We hit this in WordPress-Android while reviewing a builder change — the builder set the endpoint unconditionally, the URL would 404 on vanilla self-hosted, and the only thing keeping it harmless was the gate insidefetchManifest.Proposal
Collapse the two fields into a single sealed/enum type so the dependency is encoded in the type:
Kotlin:
Swift:
The four-cell table collapses to three meaningful states, and the silently-ignored combination is no longer representable.
Open questions
EditorAssetsLibrary's class doc says it backs both plugins and theme styles, but the only gate infetchManifestisconfiguration.plugins. If theme styles will eventually consume the same endpoint, anEnabled.assetsEndpointnested underPluginsis the wrong home — the endpoint should be a sibling field, with each feature gated independently. Worth pinning down before settling on shape.@Deprecated, port callers, remove later.Filing this so we can come back to it — not blocking any work today.