Skip to main content
PodSaid
Skip to main content

Install PodSaid on Rock RMS

Rock RMS is a full church management platform with a built-in public-website engine. If your church runs its public site on Rock (as opposed to Rock for ChMS only with WordPress or Squarespace out front), the widget installs via an HTML Content block on the page — no plugin, no code deploy.

Time: about 5 minutes. Rock’s admin surface is denser than Squarespace’s, so most of the time is finding the right zone.

What you need before you start:

  • A PodSaid account with a feed set up (see Quickstart).
  • The embed snippet from Console → Settings → Embed Code. Your feed-id and pk_live_ key are already substituted.
  • Rock admin access with permission to edit the target page and add blocks. Your church’s Rock admin has this; the average staff content editor probably doesn’t.
  • All domains your Rock site serves from added to your Allowed Origins — Rock supports multiple domains per site, and every one is a distinct origin. See Allowed origins.

The 60-second version

Copy the snippet from your PodSaid console:

<script src="https://widget.podsaid.com/v1/widgets.iife.js" defer></script>
<ask-pod-widget
    feed-id="yourfeedslug"
    api-key="pk_live_xxxxxxxxxxxxxxxx">
</ask-pod-widget>

Navigate to the target page in Rock, enter admin mode, drop an HTML Content block into the zone you want, paste the snippet, save, then reload with a hard refresh to bypass the block cache.

If that just worked, skip to Verifying it works.

Where to paste the snippet

Option A — HTML Content block on a single page (recommended)

Use this for a widget on one page (a Sermons page, an Ask-the-Pastor page, a specific ministry landing page).

  1. Sign in to Rock as an administrator.
  2. Navigate to the front-end page you want to embed on.
  3. Enter admin mode: click the admin toolbar at the bottom of the page (the “cog” / “pencil” icons appear when you’re signed in as an admin). Click the block-configuration button (the grid/cube icon) to show block zones.
  4. In the zone where you want the widget, click Add Block.
  5. Choose HTML Content as the block type. Give it a name like “PodSaid Widget”. Save.
  6. Click the new block’s edit (pencil) icon to open the content editor.
  7. Switch the editor into HTML / Source mode (there’s a <> icon in the WYSIWYG toolbar). Paste the snippet. Save.
  8. Hard refresh the page (Cmd+Shift+R / Ctrl+Shift+R) — the HTML Content block caches by default for an hour, so a normal refresh will not show your change until the cache expires.

The widget will appear inline in the zone. If the block is caching too aggressively during testing, edit the block’s advanced settings and drop Cache Duration to 0 temporarily.

Option B — Site-wide via Site → Page Header

Use this for a persistent chat launcher on every page.

  1. Go to Admin Tools → CMS Configuration → Sites.
  2. Open the site your public pages belong to.
  3. Find the Page Header Content field on the site’s edit form.
  4. Paste the snippet. Save.

Everything served under that site now includes the snippet in the document head, and the widget’s launcher renders on every page. The <ask-pod-widget> element mounts its own floating launcher — no extra markup needed in the page body.

Option C — Per-page header via Advanced Settings

Use this when you want site-wide-ish behavior but only for one page or a small set (e.g. a “Sermons” section).

  1. Navigate to the target page in admin mode.
  2. Open the page’s Page Properties dialog (from the admin toolbar).
  3. Expand Advanced Settings.
  4. Paste the snippet into the Header Content field. Save.
  5. Hard refresh.

Common Rock RMS gotchas

1. The block cache masks your paste

Symptom: You saved the block. You reloaded the page. The widget isn’t there. You edited the block, checked the source — the snippet is still saved. But the live page doesn’t show it.

Cause: The HTML Content block has a Cache Duration setting that defaults to 3600 seconds (one hour) on many Rock installs. Your save is stored server-side; the rendered HTML in the block cache still reflects the pre-save version.

Fix: Either wait an hour, or:

  • Set the block’s Cache Duration to 0 during testing.
  • Or clear Rock’s cache: Admin Tools → System Settings → Cache Manager → Clear Cache.
  • Then hard-refresh the browser (Cmd+Shift+R / Ctrl+Shift+R).

Once the widget is working, you can raise Cache Duration back up — the widget snippet is static and benefits from caching.

2. Lava tries to parse the snippet

Symptom: You paste the snippet, save, and see a parse error about an unknown Lava tag. Or the widget attributes render as literal {{...}} text on the page.

Cause: Rock parses the HTML Content block through Lava (its dotLiquid templating engine) before rendering. If your snippet ever contains {{ or {% — even in a comment, an attribute value, or an inline script — Lava will try to interpret it and either error out or eat the braces.

Fix: Wrap the snippet in Lava’s {% raw %} block:

{% raw %}
<script src="https://widget.podsaid.com/v1/widgets.iife.js" defer></script>
<ask-pod-widget
    feed-id="yourfeedslug"
    api-key="pk_live_xxxxxxxxxxxxxxxx">
</ask-pod-widget>
{% endraw %}

The current PodSaid snippet does not contain {{ or {%, so {% raw %} is optional today — but wrap it anyway to future-proof against any snippet changes we make later.

3. “Requires Approval” workflow silently gates the change

Symptom: You edit the block, paste, save, log out. You come back later and the widget isn’t live. Nobody told you why.

Cause: The HTML Content block has a Requires Approval checkbox in its advanced settings. If your church has enabled it, every save enters an approval queue and isn’t published until an approver signs off. Your paste is saved as a draft.

Fix: Check with whoever administers your Rock install. If the approval workflow is intentional, ask them to approve; if it was turned on by accident, disable it in the block’s advanced settings.

4. Multiple domains, one Rock site

Symptom: Widget renders on one domain but the API rejects requests on another. Console shows [podsaid-widget] Auth failed (403): origin_denied.

Cause: Rock sites often serve from several domains at once — the “primary” domain, older redirected domains, staging subdomains. Each one is a distinct browser origin.

Fix: In Console → Settings → Allowed Origins, add every domain the Rock site responds to. To find them: Admin Tools → CMS Configuration → Sites → your site → Domains lists them.

You can leave staging domains in the allowlist indefinitely — costs nothing.

5. The zone is on the wrong layout

Symptom: You added an HTML Content block to a zone, but the widget renders in an odd place on the page — squeezed between a sidebar and the footer, or below content it should be above.

Cause: Every Rock page uses a layout, which defines the zones. The zone you dropped the block into may be a legitimate zone that just isn’t where you thought it was.

Fix: Either move the block to a different zone (block properties → move) or change the page’s layout to one whose zones match your intent. Layouts live under Admin Tools → CMS Configuration → Layouts.

For a floating launcher (Option B or C), the zone doesn’t matter — the launcher positions itself via position: fixed.

Verifying it works

  1. Open the target page URL in a normal browser window — signed out of Rock admin, so you see what a visitor sees.

  2. Look for the widget where you placed it, or for the floating launcher (default: bottom-right) if you used Options B or C.

  3. Click it. If a chat box slides in, you’re done.

  4. Open DevTools console (⌥⌘I on Mac, F12 on Windows). Look for:

    [podsaid-widget] v1.8.2 mounted (feed=yourfeedslug, api=https://api.podsaid.com)

If the widget appears but questions fail, jump to Widget errors — what each one means.

If the widget doesn’t appear at all, work down this checklist:

  • Hard-refresh (Cmd+Shift+R / Ctrl+Shift+R) to bypass Rock’s block cache and your browser’s cache.
  • Confirm the block is enabled and its Active date range covers today (HTML Content blocks have optional start/end dates).
  • Confirm the block’s Requires Approval setting isn’t holding your paste in a draft state.
  • Confirm the domain you’re testing on is in Allowed Origins.

When the widget shows “still preparing your content”

If ingest hasn’t finished for your feed yet, the widget renders a friendly placeholder instead of an error. Your paste is correct — you just don’t have content to answer questions against yet. Watch progress under Console → Feed → Ingest status, or wait for the “your widget is live” email.

See How ingest works (and why it takes hours).

Match your brand

The widget renders inside a Shadow DOM, so your site’s CSS can’t reach the widget and the widget’s CSS can’t leak into your site — nothing in your theme will accidentally break the widget’s look. To make it match your church or podcast brand, the widget exposes a set of CSS custom properties and Shadow Parts you can target from your own stylesheet.

See Customization (CSS) for the full list, with copy-paste examples.

Still stuck?