6.0.11August 17, 2026

This week’s work gives church teams three practical wins: a built-in path for event tickets, safer handling for People data, and a more guided beginning for new church websites.

The common thread is confidence. Staff can prepare an event without stitching together a separate ticketing tool, bring People records into the system with fewer surprises, and begin a new website with clearer choices before content is applied.

Event Tickets Are Ready for Real Church Events

Digital Church now includes an Events ticketing foundation with ticket types, capacity, sale windows, admissions rules, schedules, attendee records, QR redemption, reports, and audit history. Stripe Checkout handles paid orders; complimentary tickets, staff lookup, and roster-ready attendance records are part of the same system.

A church may need tickets for a conference, retreat, camp, dinner, class, or community event without making staff export a list from one tool and check people in with another.

Ticket availability now accounts for both issued tickets and held checkout reservations. When an event is nearly full, the platform protects the remaining capacity instead of letting two people claim the same last seat. Paid orders are verified before tickets are issued, and a repeated payment notification cannot create duplicate tickets.

Guests receive a ticket reference that staff can look up at the door. The QR check-in code is kept separate from the public ticket code, so a printable reference does not become a reusable admission credential.

People Imports Protect Existing Records

People CSV imports now use stronger ownership, duplicate, household, and concurrency safeguards. The import and export paths share typed contact, visibility, address, profile, activity, communication, social, and structured-link fields so a clean export can return through a clean import.

Moving People data from a spreadsheet or another church system is one of the moments when a small mismatch can create hours of cleanup. Duplicate family rows, overlapping staff imports, ambiguous email matches, and private-document access all need careful treatment.

Digital Church now keeps existing People records in place when a duplicate household requires review. It also protects linked WordPress-user and private-document ownership, serializes overlapping import work, and stores staging uploads outside public media paths with restrictive permissions.

The result is less manual repair after an import and a clearer answer when a row needs human review.

New Church Sites Start With More Clarity

The onboarding flow now presents authoritative previews for the Discover and City templates, keeps selected locations easy to confirm, and preserves a saved form state without shifting the page when a newer version is recovered. It also supports a controlled content-adaptation flow for the Home, New Here, Plan a Visit, and Next Steps pages when a client has authorized use of its source content.

Starting a church website should not feel like choosing a template blind or wondering whether a saved answer disappeared. Church leaders need to see the direction they are choosing, confirm location information clearly, and keep their work steady while background saves run.

The content process is deliberately narrow. It works only against reviewed template-owned fields, preserves template structure and system modules, and checks the final layout for unexpected drift before reporting a completed result. Churches that choose a Custom Build skip this path entirely.

What This Means for Churches

These changes reduce the awkward handoffs around three high-attention moments: selling or checking in event tickets, importing a large set of People records, and starting a new site.

The visible wins are practical: event capacity stays honest, People data arrives with fewer conflicts, and website setup offers clearer choices. The quieter win is trust. Staff get systems that protect the details when an event is filling up, a data file is imperfect, or a new site is taking shape.

6.0.11August 10, 2026

Better Sermon Media, Faster Editors, and Safer Event Data

This week’s Digital Church update focuses on the pieces church teams touch when Sunday content, event listings, and editor screens all need to behave without extra workarounds.

Sermon pages now handle video, audio, BoxCast playback, featured images, series selection, and editor timing more carefully. The update also adds a safer event GraphQL compatibility layer for the native app, improves Location editor performance, and gives churches a clearer path toward shared button styling that will not break existing plugin or Beaver Builder controls.

BoxCast Sermons Play the Right Broadcast

What changed: Imported BoxCast sermons now render BoxCast’s official player for the recorded broadcast when the sermon still matches the imported BoxCast channel and broadcast.

Why it matters: Churches using BoxCast need sermon archives to play the actual recorded service, not a fragile temporary URL or a generic channel embed. Digital Church now uses the provider player when the import relationship is still valid and falls back cleanly when an editor replaces the sermon video.

The update also adds an administrator-only BoxCast import history. Staff can expand the log from Sermons settings and see which broadcasts were imported, updated, skipped, or failed, with bounded storage that avoids autoload bloat.

Sermon Pages Respect Audio, Video, and Images

What changed: Sermon pages now hide the foreground featured image when a sermon has video, while still keeping the featured image for sermons without video. Audio players now render whenever audio exists, even when the sermon also has a video embed.

Why it matters: Sermons often ship in more than one format. A church may have a video for viewers, an audio file for listeners, and a featured image for archives or sharing.

Digital Church now treats those formats as complementary instead of competing. Visitors can choose audio or video from the canonical sermon page, and the visual layout no longer puts a redundant image in front of the primary media.

Sermon Editors Load More Reliably

What changed: The custom Sermon editor shell now uses a bounded retry with cleanup when WordPress’s iframe load event fires before the post title wrapper exists. The sermon-series selector was also rebuilt as a searchable REST-backed picker with removable multi-series tags.

Why it matters: WordPress 7 editor timing can be weird. Staff should not lose sermon controls because the iframe loaded a little too early.

The series picker change matters for real libraries, too. Churches with years of sermons should be able to search, add, remove, and create series without scrolling a giant checkbox list or accidentally selecting duplicates.

Native App Events Got Their Contract Back

What changed: The bundled Events GraphQL compatibility layer now restores the fields, ordering, upcoming filtering, Pie Calendar dates, venue data, imported event inclusion, recurrence handling, and detail lookup behavior expected by the native app.

Why it matters: The installed native app depends on stable event data. After removing older calendar providers, Digital Church needed to keep the app’s list and detail screens working without handing control to third-party GraphQL providers.

The compatibility layer stays scoped to the root bundled Event connection. It preserves provider isolation, respects visibility, supports recurring events at their next valid occurrence, and lets imported event_feed results resolve through the existing database-ID detail query.

Location Editing No Longer Pays for a Live Map Preview

What changed: The Location editor no longer creates an eager embedded MapKit preview inside the admin screen. Address autocomplete and latitude/longitude storage still work, but the editor avoids the canvas-backed live map instance.

Why it matters: The old preview could make Gutenberg and the Featured Image media modal feel stuck. Staff editing a location need address lookup, not an admin screen that drags because a map canvas is running in the background.

Digital Church also cleans up document listeners and pending search timers when the editor shell rebuilds or unmounts, reducing stale editor behavior during longer admin sessions.

Buttons Get a Safer Shared Utility System

What changed: Digital Church added a token-driven .dgtl-button utility system that only activates on direct eligible controls or outer Beaver Builder Button/Button Group wrappers.

Why it matters: Churches need consistent buttons, but global button CSS can quietly break WordPress controls, plugins, forms, and builder modules. This update keeps the new styling opt-in.

Existing .button, modifier classes, native controls, Beaver styles, and plugin buttons remain unchanged unless .dgtl-button is intentionally present. Opted-in controls get clearer hover, active, focus, disabled, forced-colors, reduced-motion, and minimum target behavior.

Editors Surface Privacy Warnings and Hidden Fields Again

What changed: Sermon speaker lookup now warns editors when the selected Person or Team Member profile is private and will not appear publicly. Connect Card, People, and Service tab fields also reappear above the WordPress editor canvas layers after the editor update.

Why it matters: Staff should know when a public sermon page will hide the speaker they selected. They also need tabbed fields to stay visible when WordPress changes editor layering.

These fixes reduce quiet publishing mistakes: missing speaker context on a sermon, hidden editor fields, or controls that appear broken even though the underlying content still exists.

What This Means for Churches

This release makes Sunday content and event data feel more dependable. Sermons can support BoxCast, audio, video, featured images, series, and private-speaker warnings without forcing staff to understand the technical edge cases behind them.

The broader win is calmer admin work. Editors load more predictably, map-heavy screens stop dragging, app event data stays compatible, and shared button styling can move forward without breaking existing site controls.

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.