Custom Power-Up connector iframe never loads on a board — reproducible with two independent fresh re

[Villy]

Hi everyone,

I'm building a custom (private, unlisted) Power-Up for internal use on my company's Trello Workspace, and I've run into a bug where the Power-Up's connector iframe never loads in the Trello web client, despite everything being correctly configured on the server side. Since Atlassian support isn't available for Free-plan accounts, I'm hoping someone here — ideally someone who's worked on Power-Up development, or from the Trello team who monitors this forum — has seen this before or can point me in the right direction.

Account and environment

• Account: salvitabulgaria
• Workspace: Salvita Bulgaria (salvitateam1, id 6331423ce094a3016b9a7918), Free plan
• Test board: "Test Board" (id 6a8193949dc5f545711941aa, https://trello.com/b/0GCzOT3g/test-board)
• Plugin IDs tested: 6a81a451987e63609644065d (deleted), 6a81bc178cafb54c7151635c (current)

Summary

A custom Power-Up, correctly registered and enabled on a board, never has its connector iframe loaded by the Trello web client — no network request to the connector URL is ever made, no iframe element is created in the DOM, and none of its registered capabilities (card-badges, card-buttons, card-back-section) ever render. This happens with zero JavaScript errors, on two completely independent, freshly-created Power-Up registrations. By contrast, an official "Made by Trello" Power-Up ("Card Aging") added to the exact same board in the same browser session renders and works immediately with no configuration beyond clicking "Add."

Steps to reproduce

1. Create a new custom Power-Up at https://trello.com/power-ups/admin/new under Workspace "Salvita Bulgaria."
2. Set the Iframe connector URL to a valid HTTPS page (an HTML wrapper that loads the Trello power-up.min.js script plus our connector script — verified reachable via curl with clean response headers, no X-Frame-Options/CSP present).
3. Enable capabilities: card-back-section, card-badges, card-buttons.
4. On the "Privacy and compliance" tab, answer "Does your Power-Up store any Trello user personal data?" = No, and Save (confirmed persisted — the board's Power-Up detail page shows "is in compliance with Trello's data and privacy practices").
5. Enable the Power-Up on the test board (confirmed via the board's boardPlugins REST endpoint — the plugin appears listed with promotional:false, and the board's Power-Ups > Enabled tab shows it with a working Settings gear).
6. Open any real, non-template card on that board.

Expected: the connector iframe loads, and card-badges/card-buttons/card-back-section render according to the registered capabilities.

Actual: nothing renders at all. No entry appears in the card's "Power-ups" tray. Zero network requests to the connector URL (confirmed via DevTools Network panel, filtered by the connector's domain — completely absent, not even a failed/blocked entry). Zero iframe elements matching the connector URL anywhere in the DOM (checked via a querySelectorAll scan for iframes at both board view and card-detail view). The browser console repeatedly logs a warning from Trello's own ltp.[hash].js asset file:

"board plugins are undefined"

This warning fires 4 times on board load and 4 more times on every card open, consistently, in every test.

What I've ruled out

• Wrong connector URL format (initially pointed directly at the connector script instead of the required HTML wrapper page — fixed).
• ngrok free-tier browser-interstitial silently blocking a hidden iframe (switched to Cloudflare Tunnel, which has no such interstitial — confirmed via the tunnel's own inspector logs showing zero real hits regardless).
• The Power-Up admin UI's "Save" button not actually persisting the connector URL (verified via the plugin REST endpoint after a hard reload — the value is correctly saved server-side).
• A missing/null "Privacy and compliance" answer (was null initially — fixed, verified persisted, and the board's Power-Up page now shows the compliance-confirmed message).
• The specific plugin registration being corrupted or "stuck": deleted the original Power-Up entirely and created a brand-new one from scratch (different idPlugin, different API key/secret) with capabilities, connector URL, and privacy answer all set correctly from the start. Identical failure.
• Workspace/board-level Power-Up restrictions: this Workspace is on the Free plan, which has no admin-level Power-Up allowlist/restriction settings available (confirmed in Workspace Settings — those controls are shown as Premium-gated and inactive).
• Board-level feature gating: the board's premiumFeatures list includes "plugins" (confirmed via the board REST endpoint with fields=all).
• The legacy board.powerUps field (as opposed to boardPlugins): confirmed empty even for the working Card Aging Power-Up, so this field is unrelated/vestigial for the current boardPlugins-based system and not the mechanism the client actually reads from.
• Browser/session/profile-specific caching: reproduced independently by the board owner in a genuinely fresh Incognito window with no shared session or extensions.
• Trello's "Labs" experimental feature flags: only "Rovo Chat" is listed there — nothing related to Power-Up development.
• CSP / X-Frame-Options headers on the connector: checked directly via curl on both the public tunnel URL and the origin server — no X-Frame-Options header and no Content-Security-Policy header present at all. Framing is not being blocked at the header level (and in any case, the client never even attempts to create the iframe, so it never reaches the point where CSP would matter).
• "Copy Board" as a fix for possibly-corrupted board metadata: copied the test board within the same Workspace, keeping cards. The copy correctly carried over both boardPlugins entries (Card Aging + our custom plugin). On the fresh copy, Card Aging still rendered instantly and correctly; our custom Power-Up still never attempted to load — same warning, zero network requests.
• "Remove personal settings" as a way to clear a stuck authorization token: this option isn't available for our Power-Up at all — its Settings menu only offers "Disable." (Per Trello's own docs, "Remove personal settings" only appears for Power-Ups using a personal-authorization capability, which ours doesn't use.)
• Testing on a different Workspace to isolate whether this is Workspace-specific: not possible to test as a private/unlisted Power-Up — Trello returns 403 Forbidden when attempting to enable it on a board outside its owning Workspace, and it doesn't even appear under that board's Power-Ups > Custom tab. This check is blocked by Trello's own design, not by whatever is causing the bug.

Control test proving this is specific to custom Power-Ups

I added the official "Made by Trello" Power-Up "Card Aging" to the same test board, in the same browser session, immediately after failing to get our custom Power-Up to load. Card Aging rendered correctly and instantly (its "Last updated" badge appeared on the card) with zero configuration beyond clicking "Add." This isolates the failure specifically to custom/private Power-Ups — the board, account, and browser session are otherwise fully capable of loading and rendering Power-Up UI without any issue.

Net result: the one variable that consistently correlates with the failure, after ruling out everything else through direct testing, is "custom/private Power-Up" versus "official Made-by-Trello Power-Up."

Evidence available on request

I have a sanitized HAR export (cookies/auth stripped) captured from a fresh page load of a card on the test board, showing the full set of network requests the Trello client makes on card open — notably, no request to our connector domain appears anywhere in it, which is the core of the bug. I haven't attached it here, but I'm happy to send it directly to anyone looking into this, or share a link separately.

Question for the community

Has anyone run into a Power-Up's boardPlugins entry being visible via direct REST API calls but never surfaced to the web client's plugin-loading logic — i.e. the "board plugins are undefined" console warning? Is there some additional registration step or account-level flag for custom Power-Ups on Free-plan Workspaces that I might be missing? Any pointers — even "check X" — would be a huge help at this point, since I've exhausted everything I can test from the outside.

Thanks!
Villy 

[Gabriela - LeanZero · Accepted solution]

Hi @Villy, that warning isn't coming from your Power-Up. "board plugins are undefined" appears zero times in power-up.js and zero times in power-up.min.js. It ships inside Trello's own BoardHeaderButlerButtonsModernized component as the value of an error field the hook hands to console.warn, and what sets it is the board's plugins collection reading as undefined in the client's own state. So it's the client telling you it has no board plugins, which is your symptom rather than a second fault.

One aside on that: your console attributed the line to ltp, and the string isn't in today's ltp build at all, so the frame has moved between deploys.

The part that answers your actual question sits next to it. The loader doesn't read the REST boardPlugins collection you verified. Plugins/loadPlugin.ts fires a GraphQL query called BoardEnabledPlugins against board plugins(filter: enabled), cache-first, selecting id, capabilities, iframeConnectorUrl, listing, moderatedState, public, idOrganizationOwner, name and icon. When your id isn't resolvable after that query it throws "plugin not available to board". Grep your console for that. The board field carries an @client directive, so it resolves out of the Apollo cache and there'll be no network request named BoardEnabledPlugins to find.

Then look at moderatedState in that selection. Atlassian stripped it from the REST plugin response in 2019, in their words "The following fields have been removed: apiKey, author, idAgreement, moderatedState, privacyUrl, supportEmail, tags, usageBrackets", so the loader reads a field your REST checks could not have shown you. The Power-Up security page says "A moderated Power-Up will remain enabled on all boards on which it is enabled, but it will never be initialized." That's your symptom in Atlassian's own sentence. I doubt a brand-new idPlugin inherits a flag like that, so treat it as the state to have someone read for you, not as a diagnosis.

Your read on support is half right. The Trello product portal is subscription-only, "Only Trello users with an active subscription can submit support tickets". The developer desk is separate and Trello's own dev docs point at it, go.trello.com/dev-support, landing on developer.atlassian.com/support. Its entitlement row names no plan, only "Partners and developers looking to extend the functionality of Atlassian apps". In July a developer hit a Trello-wide Power-Up iframe regression, got no forum reply, raised ECOHELP-148080 as a P1, and Trello confirmed and fixed it. I haven't tried that desk from a Free workspace with an unlisted app, and the packaging line does read "a valid customer license or any tier of the Marketplace Partner Program", so that's where I'd expect friction. Send them the HAR.

Atlassian's Power-Up guide will send you to the developer community, and I'd not lean on it. Of the 18 Trello topics opened there during 2026, 14 still have no reply of any kind, and I didn't find an Atlassian staff reply on any of them. Topic 99226 is the closest to your shape, a required Trello script asset for which no request is ever made, and it got nothing.

[Villy]

Thanks for digging into this — really useful breakdown of how the GraphQL loader and support tiers work.

Good news: we actually found the root cause independently before seeing this, and it wasn't a Trello-side plugin state issue at all. The connector script URL from Trello's own older docs/examples — p.trello.com/power-up.min.js — turned out to be a dead domain (confirmed via direct nslookup/curl: NXDOMAIN, not blocked, just doesn't exist anymore). The current docs point to p.trellocdn.com/power-up.min.js instead. Our Power-Up was still loading the old URL in a few HTML files, so the client never even fetched the library, which is exactly what produces the generic "board plugins are undefined" warning downstream.

After switching to the new CDN domain (plus fixing two follow-on issues — Power-Up capability responses need absolute URLs, not relative signUrl output, and the show-settings capability needed manually enabling in the Power-Up admin panel, separate from the manifest), everything loads and renders correctly on live boards.

So no need to pursue the developer support desk or the moderatedState theory on our end — but flagging it here in case it helps anyone else who searches this warning later, since apparently no one else has documented this exact symptom-to-cause chain publicly yet.

[Gabriela - LeanZero]

Hi @Villy, thanks for coming back with the cause and not only the fix. That symptom to cause chain isn't written down anywhere I could find either.

One addition for whoever searches this next. Checked from here today, p.trello.com doesn't answer NXDOMAIN: the name still exists in the trello.com zone carrying a single TXT record, v=spf1 -all, and an A lookup comes back NOERROR with zero records. Same answer from 8.8.8.8, 1.1.1.1, 9.9.9.9 and from the authoritative AWS nameserver, so it isn't my resolver being odd. Yours may well have said NXDOMAIN when you tested it. Either way there's no address behind the name, so curl and the browser both report they can't resolve the host, while p.trellocdn.com/power-up.min.js returns 200 from the same machine. That distinction bites: someone who checks with dig, sees NOERROR and reads it as a healthy host will go hunting for the fault somewhere else.

The absolute URL point on t.signUrl is the one I'd expect people to hit straight after.

[Villy]

SOLVED — Custom Power-Up connector iframe never loads / "board plugins are undefined": the client library URL is dead

Follow-up to my earlier post about a custom Power-Up's connector iframe never loading, with the console repeatedly warning "board plugins are undefined." Posting the actual root cause here since I couldn't find this documented anywhere, and I don't want the next person to lose the weeks I did chasing it.

Short version: it wasn't a Trello platform bug, a Free-plan restriction, or anything account/board-specific. It was a dead script URL in my own connector page.

The fix

https://p.trello.com/power-up.min.js — the client library URL used in a lot of older examples and tutorials — no longer resolves. A direct nslookup/curl against it returns NXDOMAIN: the domain is gone, not blocked, not slow, not rate-limited. That's why nothing in the Network tab ever showed a request to it — the browser gave up before it could even try loading the connector.

The current, working URL per Atlassian's own docs (developer.atlassian.com/cloud/trello/guides/power-ups/building-a-power-up-part-one/) is:

https://p.trellocdn.com/power-up.min.js

Swap that in every page that loads it (in my case: the connector's index page plus every popup/view HTML file that also pulls in the library), and the client starts actually initializing the Power-Up — the "board plugins are undefined" warning disappears because the board's plugin state stops being undefined once the library that populates it is actually loaded.

Two follow-on gotchas that showed up right after, in case they save someone else time

1. Capability responses (card-badges, card-buttons, card-back-section icon fields, content.url, and the url passed to t.popup(...)) need absolute URLs. t.signUrl('/path') only returns path + '?signed-token' — no origin prepended — even though the official examples show relative paths. The console just says a generic "Invalid URL detected in Power-Up response" with no field name, so it's easy to miss. Fix: always prepend your own origin, e.g. ORIGIN + t.signUrl('/path').

2. If you add a new capability like show-settings in code, it also has to be manually enabled as a checkbox in the Power-Up's admin panel (trello.com/power-ups/admin) — the admin panel does not read manifest.json to auto-detect newly supported capabilities.

Why this was hard to find

The symptom (a generic client-side warning, zero network requests, zero JS errors) looks exactly like a platform-side registration/permissions problem, which sent me down the path of ruling out privacy-compliance answers, Workspace restrictions, board metadata corruption, CSP headers, etc. — all dead ends, documented in my original post below. A local network/DNS filter blocking the same "p." subdomain pattern also produced a convincing-looking red herring for a while (turned out that domain was dead for everyone, not just blocked locally — worth checking with nslookup against a public resolver like 1.1.1.1 before chasing router/DNS theories). None of that mattered once the actual dead script URL was found — it was a one-line fix in our own HTML, not a Trello issue at all.

Hope this saves someone the same rabbit hole.

Villy