Perpetual Adoration — Installation Guide

This guide assumes you have read Getting Started. It covers only where Perpetual Adoration differs from the standard path.

Built on the MinistryPlatform Custom Widget framework and the community FullCalendar widget, with a login gate matching the one used by the My Household widget.

What you need before starting

SQL Server Management Studio access to the MinistryPlatform database, edit access to the church website, and the three core files that ship with this guide:

• api_custom_PerpetualAdorationCalendar_JSON_Deploy.sql — the calendar (read) procedure.
• api_custom_PerpetualAdorationRegister_JSON_Deploy.sql — the registration (write) procedure.
• perpetual-adoration-signup.html — the entire front end.

Two optional maintenance scripts are also included for keeping the calendar populated over time and clearing out old slots: custom_PerpetualAdoration_GenerateSlots.sql and custom_PerpetualAdoration_PurgeOldSlots.sql . See Keeping the calendar populated and Removing old slots below.

Step 1 Run the two database scripts

Open each script in SSMS, confirm you are connected to the MinistryPlatform database and not master — check the database dropdown — and execute it.

The calendar (read) procedure

api_custom_PerpetualAdorationCalendar_JSON_Deploy.sql does three things, all required:

1. Creates dbo.api_custom_PerpetualAdorationCalendar_JSON , which returns approved, non-cancelled Perpetual Adoration events in a date range, with a registrant count and the first committed adorer's name per event.
2. Registers the procedure in dp_API_Procedures so the MinistryPlatform API is allowed to call it.
3. Links the procedure to the Administrators security role in dp_Role_API_Procedures .

The registration (write) procedure

api_custom_PerpetualAdorationRegister_JSON_Deploy.sql performs the same three steps for dbo.api_custom_PerpetualAdorationRegister_JSON , which creates an "02 Registered" Event Participant record for the signed-in user on each selected, still-available slot.

Each script ends with three verification queries. All three must return a row — Proc exists , API registered , Role linked. It is safe to re-run either script; CREATE OR ALTER and the IF NOT EXISTS -guarded inserts prevent duplicates, and re-running the registration procedure will not create duplicate sign-ups.

Step 2 Verify the API can reach the procedures

In a browser, open the following, replacing yourchurch with your MP host prefix:

 https://yourchurch.cloudapps.ministryplatform.cloud/sky/api/CustomWidget?storedProcedure=api_custom_PerpetualAdorationCalendar_JSON 

You should see JSON containing your Perpetual Adoration events. If instead you see "Procedure … does not exist or user does not have access to it" , see Troubleshooting below.

Step 3 Add the signup page to the website

Create a new page and add an HTML embed containing the full contents of perpetual-adoration-signup.html . Everything an administrator normally touches lives in one place: the ADORATION_CONFIG block at the very top of the file.

Step 4 Test

Open the new page while signed out: you should see the "Please log in" panel. Sign in through the site's Login and the calendar should appear on its own.

1. Choose a preferred time window, days of the week and a date range, then press Find Available Slots.
2. Open (green) hours appear on the calendar and in the Quick-select by time tool. Committed (red) hours show the adorer's name and cannot be selected.
3. Select one or more open hours — from the calendar or with a Select all button — and press Register for Selected. Confirm in the dialog.
4. You should see your success message, and the slots you claimed should immediately turn red with your name.
5. Confirm in the Platform that a new Event Participant record was created for your contact on each event, with Participation Status 02 Registered.

Keeping the calendar populated

Parishioners can only sign up for hours that exist, so you will want a standing supply of future slots — for example, always keeping the next six months populated. Rather than remembering to add a month by hand, run custom_PerpetualAdoration_GenerateSlots.sql once to create the procedure, then let a scheduled job call it.

The procedure is written to ensure the window is full rather than to add one specific month: each run creates any missing slots from today through the months-ahead horizon and skips slots that already exist. That makes it self-seeding, so the first run creates the whole window; self-healing, so a missed run is caught up on the next one; and safe to run as often as you like. It also reserves the room and maintains the event series automatically.

Run it manually to seed and test:

 EXEC dbo.custom_PerpetualAdoration_GenerateSlots
  @MonthsAhead = 6, @SlotMinutes = 60,
  @CongregationID = 1, @LocationID = 1, @RoomID = 1,
  @ProgramID = 1, @PrimaryContact = 2; 

Then schedule it with the SQL Server Agent job template at the bottom of the same file — monthly on the 1st, or daily for extra resilience. On hosted MinistryPlatform without Agent access, ask the professional services team to set up the schedule.

Removing old slots

Old adoration events are Private and off the public calendar, so they do not clutter anything visitors or staff normally see. Many parishes simply leave them. If you do need to reclaim space, custom_PerpetualAdoration_PurgeOldSlots.sql provides a careful, manual cleanup.

It has two safety features. By default it runs in preview mode, reporting only how many slots would be deleted; you re-run with @Preview = 0 to actually delete. And by default it keeps any slot that had a committed adorer ( @KeepFilled = 1 ), since that participation history is usually worth preserving — only never-filled past slots are removed. It deletes the child records (participants, room reservations, series links and other event children) in the correct order inside a transaction.

 -- 1) Preview only (nothing deleted):
EXEC dbo.custom_PerpetualAdoration_PurgeOldSlots
  @OlderThanMonths = 24, @CongregationID = 1;
-- 2) After reviewing, delete never-filled slots older than 24 months:
EXEC dbo.custom_PerpetualAdoration_PurgeOldSlots
  @OlderThanMonths = 24, @CongregationID = 1, @Preview = 0; 

If you would rather keep every record but simply hide old slots, set Cancelled = 1 on them instead of deleting — the calendar widget hides cancelled events.

Troubleshooting

This message comes from the MinistryPlatform API, not SQL Server, and almost always means a missed registration step rather than a SQL permission problem. Check in order: the procedure exists in the right database and in the dbo schema; a row exists in dp_API_Procedures with the exact name and no trailing spaces; and a row links it to a role in dp_Role_API_Procedures . Each deploy script's verification queries check all three. Remember there are two procedures — run both scripts.

The widget looks for the signed-in MinistryPlatform user that the standard Login widget stores in the browser. Make sure the page, or its layout, includes the site's MP Login widget, and that you actually completed sign-in. To make the calendar public while troubleshooting, set requireLogin: false in the config.

The read procedure filters to approved, non-cancelled Perpetual Adoration events, and deliberately does not require web-approval or Public visibility. Confirm your events have Event Type Perpetual Adoration and are approved, and that the date range and congregationIDs match events that exist. If you do want to limit the widget to the public calendar, re-add the commented _Web_Approved and Visibility_Level_ID filters in the stored procedure.

The API passed no user, or the signed-in login has no Participant record. Confirm the person is actually signed in, that their MinistryPlatform User account is linked to a Contact, and that the Contact has a Participant record. The widget passes the signed-in user's identity to the procedure, which resolves it through dp_Users → Contacts → Participants .

The MinistryPlatform API caches each procedure's parameter signature. If you edit a procedure's parameter list, recycle the MinistryPlatform API application pool in IIS — the application under the site at /ministryplatformapi — or wait for the scheduled recycle so the new signature is picked up. Full steps are in Getting Started.

MinistryPlatform caches widget reads for a few minutes. The shipped widget disables that cache on the availability read so the calendar refreshes immediately after a sign-up. If you customised the read call, make sure cacheData=false is still present.

The committed-adorer check counts participation statuses Registered, Attended and Confirmed only (IDs 2, 3, 4). Interested, Cancelled, Abandoned and Awaiting Payment do not count. Adjust the Participation_Status_ID IN (2, 3, 4) lines in the procedures if your parish uses different conventions.

The API may cache its procedure list. Recycle the MinistryPlatform API application pool in IIS or wait for the scheduled recycle.

Customization notes

The slot colours — green for needed, red for committed — are defined in the <style> block near the top of perpetual-adoration-signup.html ; search for .adoration-available and .adoration-reserved to re-theme.

The six preferred time windows (Midnight, Early Morning, Morning, Midday, Afternoon, Evening) are defined in the TIME_WINDOWS array in the script; relabel or re-bucket them there.

The confirmation-dialog wording is fully configurable in the ADORATION_CONFIG block — see Step 3. The default date range is Next 30 Days; other quick ranges (30, 60 and 90 days, and 1, 2 and 3 calendar months) are available in the dropdown.

A note on privacy

Committed (red) slots display the first adorer's name so people can see which hours are already covered. This is normal for adoration coverage and the page is login-protected, but if your parish would rather not show names publicly, ask to have the name suppressed — or the contact's Remove from Directory flag respected — in the calendar stored procedure.

MinistryPlatform configuration