feat(plugins): post the theme and colors into plugin iframes, and let transparency show through - #182
Merged
Conversation
added 2 commits
September 22, 2026 11:03
A plugin iframe is a separate document that only ever receives the
static stylesheet, so its --accent stayed on the file's default while
the dashboard applied the picked interface colors to its own root. The
wrapper now posts { type: 'homeglow:theme', theme, colors } into the
frame on every load and whenever the theme or colors change, over the
same parent-to-frame path the event stream uses. The SDK validates the
values (hex colors, a decimal triplet, one of the two theme names) and
writes them onto the plugin's root under the same variable names, so
CSS that reads var(--accent) follows the pick with no plugin change.
HomeGlow.theme and HomeGlow.onTheme() expose the values for canvas
drawing. Stacks on the --accent-rgb helper from the palette commit.
…gh its box The plugin "transparent background" toggle only changed the iframe element's own background, while the widget box behind it always painted the card color, so both states looked the same. Widget entries now carry `transparent`, and the dashboard box and the mobile card stop painting the card color and the resting shadow for such a widget; the selection border stays. Built-in widgets get the same setting, stored beside `enabled` in widgetSettings and switched in the Admin Panel next to it. The wrapper passes `transparent=true` on the iframe URL, which the plugin guide has documented all along. The unused `.card.transparent-card` rule goes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Answers #179, both halves.
Plugins never see the picked accent. A plugin's document only ever gets the static stylesheet, so
interfaceColors(which live in the dashboard's browser storage) never reach it. The wrapper now posts ahomeglow:thememessage into each plugin frame on load and again whenever the theme or the colors change. The SDK applies it to CSS variables and exposesHomeGlow.themeandHomeGlow.onTheme()for plugins that want to react.The guard on the new surface: the sender must be
window.parent, and every value must match a hex or rgb-triplet pattern before it reachessetProperty.server/tests/pluginSdkTheme.test.jsruns the SDK in anode:vmsandbox and drives'red; background: url(x)'through the listener to assert it never lands. It also covers the parent-only check,onThemereplay and unsubscribe, and thathomeglow:eventstill reacheson()handlers.Transparency changed nothing visible. A widget could be marked transparent, but
WidgetContainerandMobileDashboardkept painting--card-bgand the resting shadow, so the page background never showed through. Both now skip them for a transparent widget, the Admin Panel gets the setting, and the wrapper passestransparent=trueto plugin frames so they match. No default was added toBASE_WIDGET_SETTINGS, since the settings tests assert exact shapes and absent already reads as false.Two commits, kept separate: one is a plugin-platform change, the other is widget rendering.
Both have been running on our production instance since 2026-09-16 and are confirmed on a wall display. Client suite 310 passing, server 253, translation parity 790/790.