6.0.11July 27, 2026

This week’s Digital Church update is about speed, safety, and admin work that feels normal again after the WordPress 7 editor changes.

Church teams get faster AI-powered content search when the site can safely use native vector indexing, better protection around login and account lookup flows, and cleaner editors for sermons, people, groups, resources, announcements, and connect cards. The release also improves Sentry reliability so site errors can be reported without creating new failures during a bad bootstrap.

AI Search Can Run Faster Without Losing Its Fallback

What changed: Digital Church added an optional sqlite-vec search mirror for semantic content search. When a site has the right SQLite extension configured, the platform can use nearest-neighbor search against a native vector table instead of relying only on PHP cosine search.

Why it matters: AI-assisted search is only useful if it is fast enough for real staff work. Churches may eventually use semantic search to find Guides, pages, sermons, people, events, and other site content by meaning instead of exact keywords.

The safe part matters as much as the speed. If the extension is unavailable, fails to load, needs rebuilding, or cannot serve the current filtered query, Digital Church falls back to the existing PHP search path. Status checks now show which engine is active and explain why native acceleration is not being used.

Login Flows Leak Less Information

What changed: Authentication responses now avoid account-existence signals, phone and user Meta Box fields stay out of public REST responses, magic-link requests use clearer cooldown and rate-limit behavior, and credentialed REST CORS is limited to approved same-site origins.

Why it matters: Church websites hold staff, volunteer, member, and donor-adjacent account data. Login screens should help real users sign in without telling bad actors whether an email, username, phone number, or account already exists.

The update keeps registration and approval flows working while making the public responses more neutral. It also reduces the chance that public REST endpoints expose private user metadata.

WordPress 7 Editors Got Their Controls Back

What changed: Announcement, Group, Location, People, Service, Team, Sermon, Connect Card, and Resource editor panels now mount inside the WordPress 7 iframe editor canvas, with their styles loaded in the right document.

Why it matters: WordPress 7 changed where editor UI lives. Custom field panels that worked in older admin screens could disappear, look wrong, or lose expected behavior if they only searched the parent admin page.

Digital Church now treats the iframe canvas as the first-class editor home. That restores tab layouts, field visibility, admin typography, and editor controls for the content types churches manage every week.

Sermons, People, and Announcements Have Better Writing Tools

What changed: Sermons moved into a native tabbed editor with General, Sermon Series, Media, and Extras sections. Person bios now use WordPress post content as their single source of truth, and Announcement content got a visual formatting toolbar for bold, italic, lists, links, undo, and redo.

Why it matters: Sermons and people profiles are public ministry content, not just admin records. Staff need editors that preserve the information they enter, show media previews clearly, and support basic formatting without fighting the page.

Person bios now avoid competing save paths that could overwrite edits. Sermon artwork, audio, thumbnails, notes, study guides, series relationships, speakers, and extra details live in clearer sections. Announcement content now feels less like a plain textarea fallback and more like an editor.

Groups, Resources, and Connect Cards Are Easier to Manage

What changed: Groups archives gained a page-size setting, safer coordinate parsing, and smarter map behavior when no mappable groups exist. Connect Cards and Resources moved from legacy metaboxes into iframe-native tabbed editors with media pickers, preview controls, action fields, and visibility/access sections.

Why it matters: These are the content types church staff use to keep ministry pages current. Groups need predictable archive behavior. Resources need clean media and access settings. Connect Cards need action controls that make sense for forms, redirects, files, and visibility.

The update preserves existing meta keys, GraphQL field names, SEO controls, taxonomies, Featured Image behavior, and legacy redirect values while making the editor experience cleaner for staff.

Page Builder Modules Handle Empty Results Better

What changed: Events, Groups, Sermons, Team Members, Campaigns, Locations, Resources, and Teams modules now share a “When there are no posts” setting. A module can show its message, hide itself, hide a containing column or row, or hide matching elements by class.

Why it matters: Church pages often include ministry sections that are seasonal. A sermon series can end, events can pass, groups can pause, or a team can temporarily have no listed members.

Page layouts should fail gracefully when that happens. Empty-result controls help staff keep pages clean without asking a developer to rebuild the layout every time a content list changes.

Sentry Reporting Fails Open

What changed: The Sentry MU-plugin no longer depends on WordPress formatting helpers during early bootstrap, avoids removed PHP 8.4 constants, isolates transport failures, and keeps sampled-out errors flowing to previously registered handlers.

Why it matters: Error reporting should never become the reason a site breaks. When WordPress is only partially loaded or already in a bad state, reporting code needs to preserve the original error instead of replacing it with a second failure.

This update makes production diagnostics safer and less noisy, especially during incomplete bootstraps, failed plugin loads, and PHP-version edge cases.

What This Means for Churches

This release tightens the foundation under daily website work. Staff get editors that behave better in WordPress 7, church admins get safer login and REST behavior, and technical teams get faster search plus cleaner diagnostics.

The visible win is simpler content editing. The quieter win is resilience: better fallbacks, safer defaults, and fewer ways for infrastructure tools to make a bad moment worse.

6.0.0July 20, 2026

This week’s update focuses on the practical work that sits between a church’s website and its ministry calendar: landing pages, event responses, staff access, resource archives, and public documentation. The common thread is control.

Church teams can prepare campaign pages, collect event responses, shape resource URLs, and grant narrower admin access without handing staff more permissions than they need. Search and sitemap behavior got safer too, so private or internal content stays out of public discovery paths.

Campaign Offers Are Ready for Beta Testing

What changed: Digital Church now has a default-off Offers feature for campaign landing pages, funnel tracking, and aggregate reporting.

Why it matters: Churches often need pages for giving campaigns, registration pushes, sermon series promotions, volunteer recruitment, or seasonal ministry launches. Those pages need to be public enough to share, but they should not always appear in navigation, site search, or public indexes.

Offers are built for that in-between case. A church can create a focused campaign page, track anonymous same-origin visits and CTA actions, connect confirmed form conversions, and review aggregate reporting without storing raw personal details in the reporting layer.

The first beta keeps privacy tight. Raw IPs, names, emails, phone numbers, arbitrary metadata, and raw event rows are discarded from the reporting path, while the feature still gives staff a useful view of whether the campaign is working.

Event Actions Can Collect RSVPs

What changed: Event action buttons can now open an RSVP modal for events and imported event-feed items, with optional attendee counts, notification email settings, attendee list review, CSV download, and a selected Digital Church form option.

Why it matters: Not every church event needs a full registration workflow. Some events only need a quick “I’m coming” response so staff can plan chairs, food, rooms, handouts, or childcare.

RSVP support gives those smaller events a cleaner path. Staff can keep a simple action button on the event page, collect the right level of response, and review attendee information from the editor without building a separate registration page every time.

Imported event items now have the same action controls as manually created events. That matters for churches pulling calendars from another system because the public event page can still show the right next step.

Resources Can Use Cleaner Archive URLs

What changed: The Permalinks settings screen now includes a Resources Page URL field, and Resources archives plus Resource Category rewrites follow that configured archive base.

Why it matters: Resource libraries are often one of the most used parts of a church website. They hold baptism information, small group materials, ministry forms, volunteer files, discipleship guides, and member-facing documents.

Churches can now shape the public Resource archive path instead of being locked into one generic URL. That helps the website match the words a church already uses, whether the section is called resources, files, documents, or something more ministry-specific.

The page-builder archive detection now follows the registered archive link too, so custom archive layouts stay aligned with the configured URL.

Special Permissions Got More Precise

What changed: Administrators can grant narrower access to selected posts, pages, custom post types, taxonomy terms, individual content items, navigation menus, and Digital Church forms.

Why it matters: Church websites usually have a mix of staff, volunteers, ministry leaders, and outside helpers. They do not all need full admin access, but many of them do need access to one page, one form, one ministry section, or one menu.

The new permission model gives administrators more exact control. A volunteer can be allowed to edit one form, a ministry leader can update one set of pages, and a staff member can manage selected menu items without receiving broad control over unrelated site settings.

Grants can include expiration dates and private admin notes, with audit records tracking changes over time. That makes temporary access easier to clean up after a project, season, or event has passed.

Public Search Paths Stay More Public

What changed: Guide sitemap queries are now restricted to published Guides marked as public, and Offers are excluded from public indexing paths while remaining shareable by direct link.

Why it matters: Church knowledge bases can include public help articles, internal staff docs, private ministry notes, and setup guides. Search engines should only see what a church intended to publish publicly.

The Guide sitemap guard tightens that boundary. Public Guides still remain discoverable, while internal or non-public Guides stay out of sitemap discovery.

Offers follow the same principle from another angle. Campaign pages can be public and shareable without showing up as ordinary site content in archives, menus, or search-oriented lists.

Podcast Imports Skip Repeated Episodes

What changed: Podcast RSS autopublish now treats an episode with the same audio file as a duplicate even when the feed ID changes, and a review command can move older duplicates to the trash after a dry run.

Why it matters: Churches should not have to clean up repeated sermon episodes by hand when a podcast host changes feed details. The audio file is the part listeners care about, so Digital Church now uses that as a stronger duplicate signal.

This keeps sermon and podcast archives cleaner. Staff can review before removing older duplicates, then move matched repeats to the trash when they are ready.

What This Means for Churches

This release gives churches more control where small details matter: campaign pages that stay focused, events that collect the right response, resources that use the right URL, and permissions that match real staff responsibilities.

It also tightens public discovery paths. Guides, Offers, podcast imports, event actions, and Resources now behave more like church teams expect, with safer defaults and fewer manual cleanup chores after launch.

6.0.0July 13, 2026

# WordPress 7, AI Providers, and Smarter Guides for Church Sites

This release moves the Digital Church platform into the next WordPress cycle while tightening the site features churches use every week: Guides, Events, Galleries, billing, and the admin command palette.

The headline is WordPress 7 readiness. Under the hood, the update also prepares the local platform for AI provider testing and gives staff cleaner tools for finding pages, posts, settings, and Guides from the dashboard.

WordPress 7 Is Now the Local Baseline

What changed: The local WordPress core was updated from 6.8.2 to 7.0, followed by the database update check and core checksum verification.

Why it matters: Platform work needs to happen against the same WordPress generation churches will rely on next. Testing against WordPress 7 means design-system, content, and admin features can be checked before they reach client sites.

The update also included a plugin and theme maintenance sweep. Available plugins and inactive themes were brought current, with package-unavailable commercial plugins handled separately where their ZIP updates were present.

AI Provider Plugins Are Ready for Testing

What changed: The local WordPress AI plugin and provider plugins for Anthropic, Google, and OpenAI were installed and activated. The MCP Adapter package was replaced with the official release ZIP.

Why it matters: Churches will not care that an AI feature exists unless it helps staff do real work. This gives Digital Church a safer local test bed for evaluating provider behavior, admin assistance, and future AI-connected workflows without experimenting directly on production sites.

The local setup now has the pieces needed to test WordPress AI features, MCP Adapter behavior, and Beaver Builder AI experiments from a controlled development environment.

Guides Understand Nested Collections

What changed: Guide permalinks now include parent Collection paths, such as /guides/website/global/example-guide/. Guide Collection archive links now live under the matching hierarchy, and older /guide/{collection}/{guide}/ links redirect to the current structure.

Why it matters: Church documentation often has layers: website guides, giving guides, ministry guides, and staff training guides. URLs should reflect that structure instead of flattening every Guide into the same bucket.

Nested Guide Collections now behave more like a real knowledge base. Staff can organize deeper documentation without creating confusing links or archive paths.

The Command Palette Finds More of the Site

What changed: The dashboard command palette now pulls commands from the current user's WordPress admin menus, published Pages and Posts, public custom post type archives, local Guides, and cached public Digital Church Guides.

Why it matters: Staff should not need to remember where every setting lives. A church admin can press Cmd+K or Ctrl+K, search for the thing they need, and jump directly to a page, post, archive, Guide, or settings screen.

The palette now refreshes results from an authenticated admin context, so user-specific settings pages and plugin admin screens can appear when that user has access.

Galleries Became a Platform Feature

What changed: The Star of Zion gallery functionality moved into a reusable bundled Galleries module with its own feature toggle, archive template, post image carousel meta box, [post_gallery] shortcode, REST fields, and legacy compatibility aliases.

Why it matters: A gallery feature should not be trapped inside one site customization when other churches need the same pattern. Moving it into the platform means existing gallery-heavy sites keep working while other churches can enable the same feature intentionally.

The migration keeps old storage keys and REST aliases intact, so current content does not have to be rebuilt just because the feature moved into the shared platform.

Events Handle Imported Calendars More Reliably

What changed: RDATE-only recurring events keep their original event date, TEC recurrence migration avoids duplicate generated occurrences, Pie Calendar Pro loads automatically with bundled Events, and imported events can expose featured-event controls.

Why it matters: Calendar imports are messy. Churches need event archives that show the right dates, avoid duplicate entries, and still let staff highlight the events that matter.

These fixes make the Events bundle safer for churches importing from older event systems or maintaining recurring events across multiple calendars.

Billing Has a Safer Stripe Key Fallback

What changed: The Please log in to manage your billing. shortcode now falls back to the existing live Stripe giving secret when a platform-specific billing portal secret is not configured.

Why it matters: Billing tools should fail less often. When the church already has a live Stripe giving key configured, the billing portal can keep working instead of breaking because a second, narrower key was not set.

This does not replace proper billing configuration. It gives the platform a safer fallback path when the older giving configuration already has the needed live Stripe secret.

What This Means for Churches

This release is mostly platform groundwork, but it changes the feel of daily site work. Admins can find more things from the command palette, Guides can grow into cleaner documentation trees, Events are more dependable, and billing is less fragile.

For Digital Church, the bigger win is readiness. WordPress 7, AI provider plugins, MCP Adapter testing, Galleries, Guides, Events, and billing now have a stronger local base for the next round of client-facing improvements.

5.6.9July 6, 2026

This update makes campus-based group ministry easier to present on church websites. Locations can now show their assigned groups, group maps can read the same MapKit address data staff enter in the editor, and exact meeting locations are private unless a church chooses to share them.

The goal is simple: help visitors find the right group without exposing more location detail than the church intended.

Campus Pages Can Show Their Groups

What changed: Single Location pages now include a dynamic Groups section after Upcoming Services and before the map. The section shows published Groups assigned to that campus location and reuses the newer Connect-style group cards.

Why it matters: Multi-campus churches often need location pages to answer more than “when are services?” A campus page should also help someone find community at that campus.

This gives each Location page a clearer ministry path. Visitors can see services, scan available groups, and understand the campus context without bouncing between unrelated archive pages.

Group Archives Stay Scoped to the Selected Campus

What changed: The Location page’s Groups heading now links to the full Groups archive filtered by that campus. The archive keeps the `campus_location` filter across list view, pagination, and heading links.

Why it matters: When someone clicks from a campus page, they expect the next screen to keep that campus selected. Losing the filter makes the site feel random, especially when one church has many groups across multiple campuses.

The filtered archive now behaves like a continuation of the campus page. Visitors can move from the short campus preview to the complete campus group list without re-filtering by hand.

Group Maps Now Use the Editor’s MapKit Address

What changed: Single Group pages parse the MapKit address JSON saved by the native Groups editor. Group archive map data reads those coordinates before falling back to older map fields.

Why it matters: Staff should not have to enter the same address in one place for the editor and another place for the public map. The saved MapKit address should be the source the public site trusts.

This makes map rendering more reliable for new Groups while keeping older data working. It also helps filtered campus maps show the right pins or privacy radius overlays when address data came from the newer editor.

Exact Group Locations Are Private by Default

What changed: Groups now hide exact locations by default. The old “Hide Exact Location” control became “Share Exact Location Publicly,” and the checkbox now acts as an opt-in for public exact-location sharing.

Why it matters: Group locations can be sensitive. Home groups, recovery groups, and family ministries should not accidentally publish exact addresses because a privacy field was never saved.

The new default is safer. Churches can still share an exact pin when that is appropriate, but the public site now starts from privacy and asks for an intentional choice before exposing the address.

Group Editing Handles Real Data Better

What changed: The native Groups editor now loads MapKit JS and the shared token endpoint for address search and preview. The leaders save path also collapses duplicate legacy leader meta rows into the single sanitized ID array expected by REST saves.

Why it matters: These are the kinds of admin fixes that keep staff from losing momentum. Address search should feel modern, and saving leaders should not fail because older metadata still exists in the database.

Together, the editor and frontend now agree on group location data, campus assignments, leader records, and public privacy behavior. That makes Groups feel less like a content type and more like an actual ministry tool.

What This Means for Churches

Campus pages can now tell a fuller story: service times, community options, and location context all in one place. Group maps are more dependable, and privacy defaults are more respectful.

If your church runs campus-based groups, this update is worth reviewing before the next group launch. The right settings can make the public site clearer for visitors and safer for group hosts.

5.6.9June 22, 2026

Mobile People, Guides, and Forms That Behave Better on Real Phones

This update tightens a handful of everyday moments that matter when church staff and visitors are working from a phone: browsing families, searching locations, and reading guide pages with long breadcrumbs.

The changes are small on paper. In real use, they remove the kind of visual friction that makes a church website feel unfinished even when the underlying tools are working.

Families Are Easier to Scan on Mobile

What changed: The People archive Families tab now switches to a compact vertical list on mobile. Family rows are full width, photo areas are stable, and paired avatars no longer overlap the family name.

Why it matters: Family directories are often checked quickly, usually from a phone. A layout that works on desktop can become cramped on a small screen when photos, names, and household details all compete for the same row.

The mobile list gives each family a clearer reading path. Staff and members can scan the directory without fighting overlapping images or squeezed card layouts.

Location Search Stops Triggering iPhone Zoom

What changed: Mobile text-entry controls now use a 16px font size, and Locations archive search fields follow the same rule in both standard and dynamic archive styles.

Why it matters: iOS Safari zooms the page when a focused input uses a smaller font. That behavior is technically normal, but it feels broken when someone taps a church location search box and the whole page jumps.

Raising the field size keeps the page stable. Visitors can search for a campus, service location, or ministry site without the interface suddenly changing scale under their thumb.

Guide Breadcrumbs Work Better on Small Screens

What changed: Single Guide pages now place the breadcrumb trail before the guide title, move the mobile Guides menu trigger into the breadcrumb row, use a Font Awesome bars icon for that trigger, and replace slash separators with angle-right separators. Long breadcrumb labels can wrap by word instead of forcing entire crumbs onto new lines.

Why it matters: Guide pages can become deep quickly: parent collections, child collections, guide titles, and sidebar navigation all need to make sense together. On mobile, the old header order and breadcrumb wrapping made that hierarchy harder to read.

The revised header makes the path visible first, keeps the mobile menu close to the navigation context, and gives long labels room to wrap naturally. Readers get a cleaner sense of where they are before they start reading the guide itself.

What This Means for Churches

This release cycle is about reducing the tiny points of friction that add up on real church sites. Directories should scan cleanly. Search fields should not make phones zoom. Guide pages should show their structure without crowding the screen.

Those details matter because they shape trust. When the basics feel stable on mobile, church teams spend less time explaining the website and visitors can get to the information they came for.

If your church has a directory, location archive, or guide library that feels awkward on mobile, this is the kind of cleanup worth scheduling. It is rarely flashy. It is often the difference between usable and frustrating.

5.6.9June 20, 2026

This update is about making the parts of a church website that staff touch every week feel less fragile: team pages, event feeds, resource archives, service planning, and the small frontend details visitors notice immediately.

The work since version 5.6.9 has not been one single giant feature. It has been a steady set of improvements that make Digital Church easier to run without turning every change into a developer ticket.

Teams Get a Cleaner Native Editor

What changed: Teams now have a native Gutenberg-style editor shell under the title, using the shared Digital Church tab pattern. Team details, files, and positions moved into a focused editing interface while SEO controls keep their existing behavior.

Why it matters: Church team pages often carry more than a name and photo. Staff may need positions, files, biographies, ministry roles, and planning context in one place.

The new Teams editor gives those details clearer homes. Positions are no longer a flat afterthought; they now have a list-first planning view and per-position assignment details, which makes team organization easier to understand before it becomes a public page.

Events Become Better at Pointing People to the Right Place

What changed: Imported event feeds can now capture the first event URL from an ICS description, use it as the single-event action button, and optionally redirect imported event posts to that source URL. Plain-text links in imported descriptions are converted into clickable links during import.

Why it matters: Many churches already maintain calendars in Google Calendar, Planning Center, or another source. When those calendars feed the website, the imported event should not trap visitors on a thin local page if the real registration or information page lives somewhere else.

This update lets imported events carry people to the best next step while still keeping the church website calendar current. It also reduces the cleanup work staff used to face when feed descriptions included raw URLs instead of readable links.

Guides and Resources Respect Real Content Hierarchies

What changed: Guide Collections and Resource Categories now preserve nested hierarchy during drag ordering. Guides sidebar navigation renders child Collections under their parents, and Resources archive tabs, child pills, and default-tab settings follow the saved category order.

Why it matters: Church content rarely stays flat for long. A discipleship guide, volunteer resource library, or ministry help center needs parent categories, child collections, and a visible order that makes sense to a reader.

These updates keep ordering tools from flattening carefully organized content. Editors can arrange siblings without accidentally breaking the structure around them, and visitors see navigation that matches how the material is actually grouped.

Services Gain a Real Order Planning Workflow

What changed: The Services editor Order tab now includes a sortable service order planner for songs, scriptures, prayers, announcements, offerings, communion, messages, and custom elements. Each element can store a leader from People, notes, and media-library attachments.

Why it matters: A service plan is not just a title and a start time. It is a sequence of ministry moments with people, files, notes, and responsibilities attached.

Moving service order planning into structured post meta gives churches a better place to prepare the details that support Sunday. Worship, preaching, media, and administrative teams can work from the same organized plan instead of scattering the information across documents and messages.

Archives and Frontend Details Feel More Consistent

What changed: Digital Church added a reusable compact archive pagination component and started rolling it across Stories, Emails, Sermon Series, sermon taxonomies, Ministries, Campaigns, Groups, Teams, Locations, and Resources. The same update cycle improved announcement bars, auth modals, event color precedence, toolbar shortcuts, and post-content background controls.

Why it matters: Visitors should not have to relearn the interface from one archive to the next. Staff should not need separate styling workarounds every time a content type gets a new listing page.

The shared pagination pattern gives archives the same previous/next controls, editable page number, total page count, result label, and per-page selector. The surrounding polish makes common frontend moments look more intentional: announcement bars use space better, auth modals align more reliably, event dots inherit better color rules, and post layouts can pick up site-level design choices.

What This Means for Churches

This release cycle is about practical control. Teams can manage staff pages with better structure. Event feeds can point visitors to the right next step. Guides and Resources can stay organized as libraries grow. Services can carry real planning details instead of living in disconnected notes.

That is the direction Digital Church should keep moving: make the common ministry workflow clearer, keep risky settings harder to misconfigure, and give church teams tools that live where the work already happens.

If your church wants to clean up team pages, improve imported event links, organize a resource library, or plan services with richer structure, reach out. We can help turn on the right pieces and fit them to the way your team already works.

5.6.9May 18, 2026

This release is about giving churches more complete building blocks for the pages people actually visit.

Digital Church now has a first-party classic theme foundation, richer music playlist support, and a cleaner single-page experience for Connect Cards. Together, these updates make it easier to build church websites that feel organized, flexible, and ready for real ministry use.

Here is what is new in version 5.6.9.

Doctrine Becomes a First-Party Theme Foundation

What changed: We added Doctrine as a first-party classic WordPress theme based on Underscores, with Beaver Builder and Beaver Themer support for headers, footers, part layouts, and full-width builder canvases.

Why it matters: Churches need pages that can be shaped without fighting the theme. A good theme should provide structure, not get in the way of the content and layouts a team needs to build.

Doctrine gives Digital Church a cleaner base for sites that need a classic WordPress theme with modern layout expectations. It supports builder-driven pages, dedicated hook locations before and after the header, content, and footer, and full-width templates that let Beaver Builder layouts render through normal WordPress content filters.

That means teams can create landing pages, homepages, event pages, and ministry pages without wrestling with theme defaults that were never built for this platform.

Navigation Gets a Cleaner Modern Pattern

What changed: Doctrine includes a React-powered navigation menu inspired by shadcn and Radix patterns, using WordPress wp-element. The menu supports desktop dropdown panels and a mobile off-canvas sheet.

Why it matters: Church navigation has to serve two groups at once: visitors who need a simple path and regular attenders who know exactly what they are looking for.

The new navigation pattern gives churches room for richer dropdowns on desktop while keeping mobile focused. The mobile panel now includes a search field above fallback menu links, accessible labels, WordPress search submission, focus handling, matching RTL styles, and a simpler canvas with no extra backdrop layer.

Small visual choices matter here. The release removes the remaining mobile menu top gap, removes the internal search shadow, extends the panel to the bottom of the viewport, and lets the full mobile menu canvas scroll smoothly.

The result is a navigation system that feels less patched together and more intentional.

Music Playlists Can Live Where People Already Are

What changed: Digital Church now supports Spotify, Apple Music, and SoundCloud setup in Dashboard → Integrations. Spotify and SoundCloud can connect through OAuth, while Apple Music supports MusicKit connection. A new Beaver Builder Playlist module can embed playlists from connected accounts or direct share links.

Why it matters: Music is part of church life beyond Sunday morning. Worship playlists, event sets, youth ministry mixes, Christmas music, sermon-series playlists, and ministry training resources often live on consumer music platforms, but churches still need a clean way to place them on their own site.

The new Playlist module gives teams that path. A page builder module can show a playlist from a connected account or from a direct Spotify, Apple Music, or SoundCloud link. The existing shortcode and Music settings tab now use the same shared embed helpers, so playlist handling is more consistent across the platform.

This gives churches a practical way to place music resources on ministry pages without sending people hunting through disconnected links.

Playlist Embeds Are Safer and More Consistent

What changed: The release hardens music embed URL handling with exact provider host allowlists, removes unnecessary iframe clipboard permission, and keeps Apple Music developer-token cache keys free of private-key material.

Why it matters: Embeds should be easy for church staff, but they still need careful boundaries.

Provider allowlists help make sure playlist URLs come from expected services. Cleaner iframe permissions reduce unnecessary access. Safer Apple Music token caching keeps private-key material out of cache keys.

Those details are not flashy. They are the kind of under-the-hood care that keeps a feature safe enough to use broadly.

Connect Cards Get a Focused Single Page

What changed: Connect Cards now have a custom single template that renders a page-style landing view with cover image, title, short description, editor content, and CTA handling.

Why it matters: Connect Cards are often used for the next step after a person shows interest. That might be a guest card, prayer request, baptism interest form, serving sign-up, small-group inquiry, or ministry-specific follow-up.

Those moments deserve more than a basic archive card.

The new single Connect Card layout lets each card become a focused page. The featured image sits above the title, the title and description align cleanly to the left, and the page can carry editor content before the CTA. When the card CTA is set to Form, Gravity Forms can render directly below the card content.

That gives staff a clearer path for simple landing pages tied to real ministry follow-up.

Redirect Cards Resolve Earlier

What changed: Connect Card Redirect and Latest CTA handling now runs during template_redirect, so redirect cards resolve before template rendering.

Why it matters: Redirect cards should feel instant. If a card is meant to send someone to the latest sermon, an external form, or another page, visitors should not see a partial template first.

Moving redirect handling earlier makes those cards behave more predictably. It also keeps the Connect Card system flexible: some cards can act like full pages, while others can route people to the best current destination.

What This Means for Churches

Version 5.6.9 is not one giant feature. It is a set of practical building blocks that make church pages better.

Doctrine gives the platform a stronger theme foundation. The new navigation pattern improves one of the first interactions visitors have with a church site. Playlist support helps ministry teams place music resources directly on their pages. Connect Card single pages turn lightweight next steps into focused landing experiences.

Each piece supports the same direction: fewer workarounds, clearer pages, and better paths for people trying to take a next step.

If your church wants to test Doctrine on a new layout, add a worship playlist to a ministry page, or turn Connect Cards into cleaner landing pages, reach out. We can help set up the right pattern and make sure it fits your site.

5.6.8May 11, 2026

This release is centered on generosity, event clarity, and cleaner people workflows. Churches now have more flexible ways to present giving options, better tools for People data, and a few quality-of-life updates that make special pages and everyday admin work feel more ready for real ministry use.

Here’s what’s new since our last update.

Giving Gets More Flexible

What changed: Campaign giving now supports provider tabs for Credit/Debit, Givelify, Cash App, Mail, and Bank giving, with settings that let churches choose which options appear and in what order.

Why it matters: Giving is personal. Some donors want to use a card. Some already use Givelify. Some prefer Cash App. Some still mail checks or give through their bank. A church should not have to force every donor through the same path when the congregation already gives in different ways.

Campaign pages can now present those options clearly inside one shared giving experience. Admins can turn on the providers that fit their church, add setup instructions where needed, and arrange the tabs so the most common options appear first.

That makes giving pages easier for donors and easier for staff. Instead of scattering instructions across pages, emails, or verbal reminders, churches can keep the next step close to the Campaign itself.

Campaigns Can Carry Their Own Giving Details

What changed: Campaign editors can now set provider availability, provider-specific links, button labels, and suggested amounts for each Campaign.

Why it matters: A building fund, mission trip, benevolence drive, and youth fundraiser may all need different giving prompts. Some Campaigns may need a suggested gift amount. Some may need a direct provider link. Some may need a softer call to action with offline instructions.

This release gives each Campaign more control over its own giving experience. The church-wide defaults still matter, but Campaigns can now carry the details that make sense for that specific moment.

For administrators, that means fewer one-off workarounds. For donors, the page feels more intentional because the giving options match the Campaign they are viewing.

Direct Stripe Giving Arrives

What changed: Digital Church now supports direct Stripe Giving as a Credit/Debit provider, including a Stripe Elements card form, PaymentIntent creation, confirmed transaction logging, and Stripe Connect support for routing gifts to the church’s connected account.

Why it matters: Card giving needs to feel simple on the surface and careful behind the scenes. Donors should see a clean checkout experience. Administrators need records they can search, filter, and trust.

Direct Stripe Giving adds that path inside Campaign tabs and the

shortcode experience. When configured, the card form can collect the gift, confirm the payment, and log the transaction with the Campaign, donor account, provider, payment method, status, reference, and supporting metadata.

The setup also supports platform-managed keys, connected account IDs, and webhook signing secrets through constants or environment variables when desired. That gives technical teams a safer way to manage sensitive values without storing every secret in the WordPress options table.

Giving Records Are Easier to Review

What changed: Digital Church now includes normalized Campaign giving transaction storage and a Give → Transactions dashboard screen with searchable and filterable records.

Why it matters: Generosity work does not end when someone clicks a button. Staff often need to answer practical questions later: Which Campaign did this gift support? Which provider was used? Was it confirmed, pledged, or redirected to another giving provider?

The new transaction record structure gives those answers a cleaner home. Confirmed card gifts, external provider redirects, and offline giving paths can be tracked with status and provider context instead of blending into a vague activity trail.

That helps finance and ministry teams work from the same facts. It also gives Digital Church a stronger base for future reporting, receipts, and Campaign-level giving insights.

People 2.0 Adds Safer Import and Export Tools

What changed: People 2.0 now includes CSV export modes, WordPress user preview, import tools with role scoping, automatic email-match linking, manual approval for name-only matches, and developer-role exclusions.

Why it matters: People data needs careful handling. Sometimes a church needs a safe export that avoids private notes and internal sync IDs. Other times an administrator needs a fuller export for controlled internal work.

This update supports both paths. The safe export is better for everyday sharing, while the full export is available when deeper administrative detail is required.

The import tools are careful too. Email matches can link automatically, but name-only matches ask for manual review. That helps prevent accidental merges while still giving staff a practical way to connect WordPress users with ministry records.

Events Can Point to the Right Landing Page

What changed: Events now include an optional redirect URL field so special Campaign or event pages can replace the default single event page when that creates a better visitor experience.

Why it matters: Some events deserve more than a standard event detail page. Vacation Bible School, Christmas Eve, Easter, conferences, fundraisers, and community outreach events often need a fuller landing page with richer copy, photos, forms, maps, FAQs, and next steps.

The new redirect field lets an event keep its normal calendar presence while sending visitors to the dedicated page built for that moment. Recurring event occurrence URLs are covered too, so special event links can stay consistent across the places people find them.

Small Frontend Polish That People Notice

What changed: The announcement bar now avoids single-slide loop warnings, and Connect Cards received a mobile grid fit improvement.

Why it matters: These are the kinds of details that make a site feel cared for. A single announcement should display without extra slider behavior. Connect Card layouts should fit cleanly on smaller screens.

Neither change needs a new workflow for church staff. They simply make common frontend moments behave better for visitors, especially on phones.

The Result: More Complete Ministry Moments

This release connects several practical threads. Giving pages can support more donor preferences. Campaigns can carry clearer instructions. People tools handle data with more care. Events can point visitors to the page that best serves the moment.

That combination matters because ministry rarely happens in neat software categories. A special event might need a landing page, a Campaign, a giving path, a follow-up form, and clean people records. Digital Church keeps getting better at holding those pieces together.

If your church wants to turn on Campaign giving tabs, try direct Stripe Giving, or set up a special event landing page, reach out. We can help configure the right pieces and make sure the workflow fits how your team already serves people.

5.6.4May 4, 2026

This release is about trust in the places churches touch every week: people records, sermon archives, modal interactions, and conditional page content. Some of the work is visible right away. Some of it is careful foundation work that makes future releases safer.

Here’s what’s new since our last update.

People 2.0 Enters Beta

What changed: Digital Church now includes the first beta foundation for People 2.0, including custom-table storage, migration tooling, audit and rollback support, REST integration, import compatibility, family relationship support, and a beta-gated tabbed editor under Settings → Features.

Why it matters: People data sits at the center of ministry operations. Names, households, family relationships, imports, and profile details need to be handled with care because churches depend on that data for follow-up, care, communication, and admin work.

People 2.0 is the next step toward a cleaner and more scalable people system. The new editor can run against existing legacy People fields while custom-table storage remains an explicit migration step. That keeps the beta useful without forcing churches into an all-or-nothing jump.

The release also adds a migration prompt when the People 2.0 editor is enabled but legacy People records have not been migrated yet. That small guardrail matters. It keeps the admin experience honest about what is active and what still needs attention.

Middle-name support was added across legacy People fields, imports, People 2.0 storage, migration, and family display paths too. It’s a small detail until you need it. Then it’s the difference between a record that feels complete and one that needs a workaround.

Sermon Archives Load with Less Waste

What changed: the sermons archive received performance work around initial rendering, archive payload caching, taxonomy count caching, and safer cache storage.

Why it matters: sermon archives can become busy pages. Recent sermons, total counts, series data, taxonomy tabs, and archive payloads all compete for database work during page load. This update reduces repeated query cost by caching archive payload and tab/count data through the object cache.

The archive also stopped using DB-backed transient writes in this path. That matters for sites where concurrent requests can create database lock pressure. Object-cache storage is a better fit for this kind of repeated frontend render data.

We also removed the React StrictMode wrapper from the sermons archive mount. StrictMode is helpful during development, but it can duplicate render work. Removing it from this archive path makes the production render lighter.

Latest Sermon Sections Now Respect Missing Video

What changed: the sermons archive template now shows the Latest Sermon section only when the newest published sermon has a saved video URL and usable embed output.

Why it matters: an empty or broken hero section makes the whole archive feel unfinished. If the latest sermon does not have video attached yet, the page now skips that section and starts with the Sermons heading and tabbed archive content.

That is a better default for real church workflows. Sermons are not always edited, uploaded, and embedded at the same pace. The archive should still look intentional while that work catches up.

Modals Are More Reliable for Forms and Content

What changed: the modal component and Beaver Builder trigger module now handle form loading and modal sizing more cleanly. Modal form content renders inline from shortcode context instead of depending on REST-only rendering, Contact Form 7 handling was removed from modal code paths, default sizing was adjusted, and close-button interaction styling was tightened.

Why it matters: modals are often used at high-intent moments: registering for an event, opening a form, reading details, or responding to a call to action. If the modal loads strangely or the form confirmation breaks, the site loses trust at exactly the wrong moment.

This release makes modal forms steadier and the interface more predictable. The defaults now keep modals viewport-safe, the close button behaves more consistently, and labels focus on the Digital Church forms flow instead of implying support paths that are not part of the current feature.

Conditional Logic Can Compare Against the Current Time

What changed: Beaver Themer gained a Digital Church conditional logic rule for comparing the current site time against a selected datetime using less-than and greater-than operators.

Why it matters: churches often need page content to change around real-world timing. Registration messages, event reminders, service details, and seasonal content may need to appear before a deadline and disappear after it.

This rule gives editors a cleaner way to handle that timing directly inside Conditional Logic. It includes server-side evaluation and client-side builder UI wiring, so the rule appears where editors expect it and evaluates consistently when the page renders.

The Result: Safer Foundations and Cleaner Sundays

This release has two tracks. People 2.0 moves the platform toward stronger long-term ministry data. Sermon, modal, and conditional logic updates make weekly site experiences feel cleaner right now.

That combination matters. Churches need big foundations to improve carefully, and they need Sunday-facing details to keep working while that foundation gets better.

If your church wants to try People 2.0 beta features or clean up sermon archives, modals, or time-based content, reach out. We can help you turn the right pieces on and make sure the workflow fits how your team actually works.

5.5.115April 13, 2026

This week’s work focused on three places churches feel every single week: planning services, helping people find the right campus, and getting signups through the door without friction. The result is a release that feels more prepared for Sunday morning, not just more feature-rich on paper.

Here’s what’s new since our last update.

Service Planning Finally Lives in One Place

What changed: Digital Church now includes a new Services beta feature built for worship planning, team assignments, and service-by-service coordination.

Why it matters: Sunday planning usually gets spread across texts, shared docs, screenshots, and whatever somebody remembers five minutes before rehearsal. Now your team can build a service plan inside the platform itself, map out the order of service, assign roles, and control whether people can sign up for open positions.

This new setup gives you a clearer flow from planning to participation:

• create a service with date, type, and location
• build the order of service in one place
• assign teams and positions with searchable planning tools
• allow signups only where you want them open
• keep helpful links attached to the service plan itself

For churches juggling multiple moving parts on a Sunday, this turns a scattered process into one shared workspace.

Locations Are Easier to Search, Even on Big Site Networks

What changed: fullscreen Locations layouts now include sidebar search, broader archive search, and better handling for churches with large location datasets.

Why it matters: When someone visits your site looking for the right campus, they shouldn’t have to scroll through a long list and hope they spot it. Search now sits right under the Locations heading, works across the full archive instead of just the visible set, and still returns entries even when a location doesn’t have map coordinates yet.

That means people can find the campus they need faster. It also means your team can publish useful location information before every map detail is perfect.

A lot happened behind the scenes here too. Large location datasets now behave more smoothly, fullscreen layouts stay easier to use, and search feels more like what visitors expect from a modern site.

Signups and Login Flows Stay on Track

What changed: the /auth experience picked up a string of improvements around styling, caching, usernames, and signup redirects.

Why it matters: when someone is trying to register, sign in, or claim an open team slot, every extra snag costs momentum. This round of updates makes that path cleaner.

A few of the biggest wins:

• auth pages now match the design system more closely
• public auth requests avoid stale nonce issues that triggered cookie-check errors
• the first login field can now accept a username as well as an email address
• asset cache busting updates automatically on deploy, which helps fresh changes show up faster
• signup redirects now carry people back where they meant to go, including open team signup flows

Put simply, the front door feels steadier. And that matters most when someone is taking action for the first time.

A Few Extras That Keep Things Tidy

What changed: we also shipped a small group of quality-of-life improvements around layout polish, search behavior, and feature control.

Why it matters: these are the sorts of changes that make the whole platform feel more settled. Services now appears as a beta feature in settings, so teams can turn it on intentionally. Locations search is more complete. Auth presentation is more consistent. And one experimental mega menu effort was cleanly removed so production sites stay focused on what’s ready.

That kind of cleanup work rarely gets the spotlight, but it helps every church get a more dependable platform.

We’re especially excited about where the new Services work is headed. If your team plans worship sets, coordinates volunteers, or manages multiple service details every week, this is the beginning of a much smoother rhythm. And as always, if you want help putting any of this to work on your site, reach out. We’re glad to help.