GroupEntry – Event Registration & Check-in

FAQ

Can I require payment before confirming a registration?

Yes, using administrator approval. Enter your payment instructions in the awaiting-confirmation email. The organizer checks payment outside GroupEntry and then confirms or rejects the registration. GroupEntry does not process or verify payments. Pending requests reserve capacity and do not expire automatically; review unpaid requests to release their places.

Changing confirmation mode does not change existing statuses. In manual mode, participant edits return a confirmed registration to pending; administrator edits preserve its current status. Approval and rejection are available only for pending registrations, and check-in requires a confirmed registration.

Can participants manage their own registration?

The contact person receives a private email link to view, edit or cancel the group registration. Changes are available before the original reserved time starts and before check-in. Do not share this link. Approval and resending an email generate a replacement management link; the previous link stops working even if sending the new email fails.

Does the contact person count toward capacity?

Only when entered in the participant list. Capacity counts named participants, and check-in applies to the entire group rather than individual participants.

Can I run several events at once?

This version manages one event at a time. To reuse it, close registration and remove the previous event’s registrations before configuring the next event. Date, hours, time zone and participant rules remain locked while any registrations exist, including cancelled registrations. Capacity can change if it stays at least equal to existing reservations in every slot.

How do time zones and daylight saving time work?

The initial event zone follows WordPress and is then saved separately. Choose a named city group for automatic daylight saving adjustments. Cities are grouped only when their known clock changes agree for the event and the following ten years. A saved fixed UTC offset is preserved and labelled; it does not adjust for daylight saving. An event crossing a clock change is rejected; choose different hours.

Why has automatic deletion not happened at the exact deadline?

The retention period starts at the event’s end time in its saved time zone. Cleanup checks once a day through WP-Cron, which normally runs when the site receives traffic. A check before the deadline can leave data until the next check. Use hosting cron if you need scheduled tasks to run independently of traffic. Cleanup requires an active plugin; deactivation or removal stops its scheduled cleanup. Reactivation resumes it and can remove overdue data.

Cleanup preserves event settings and time slot definitions. Emails, CSV/ZIP downloads and hosting backups are separate copies. Manual removal is available in Remove data after registration closes and requires typing DELETE.

What if registration email delivery fails?

The booking or administrator decision remains saved. Check the email status, verify your WordPress mail setup and use Resend email after fixing delivery. An accepted sending status does not prove inbox delivery. If a submission times out, retry the same form before refreshing so it keeps its request identifier.

How does staff access work?

Staff can use the [groupentry_checkin] page with a WordPress staff account or a shared access code. Shared codes do not identify individual operators in activity records; use individual accounts when attribution matters. Code sessions last up to 12 hours. Changing or disabling the code signs out existing code sessions.

Administrators can see the saved staff code on the Staff access tab. A legacy hash-only code needs to be re-entered once to enable its display. Changing WordPress authentication keys can make the encrypted display unreadable; re-entering the code restores it.

How do WordPress privacy requests work?

Use Tools > Export Personal Data or Tools > Erase Personal Data. GroupEntry also links to these tools from Settings. WordPress handles the request confirmation, capability and nonce checks.

For a contact email, export includes complete group registrations and participant details across all statuses. Erasure removes those entire registrations, participants and related activity/check-in records, releases capacity and invalidates private links without sending a registration email. Review the requester’s entitlement and group scope before processing a request. Individual participants without a stored contact email need organizer identity and group review.

For a matching WordPress staff account, export includes that user’s activity without disclosing other groups’ participant names or emails. Erasure anonymizes staff identity while preserving the groups and attendance. Shared-code activity cannot be matched to an individual worker. Security hashes, private tokens and staff codes are excluded from exports. Failed processing batches are rolled back and reported for retry. WordPress accounts, emails, downloaded exports and backups are separate and are not removed by a GroupEntry privacy request.

What happens when I delete the plugin?

Data is kept by default, including when older saved settings have no uninstall option. Deactivation and updates preserve data. To remove GroupEntry data permanently, enable the removal option in Settings > Uninstalling GroupEntry, save it, then deactivate and delete the plugin through WordPress.

Opted-in uninstall removes GroupEntry tables, options, database-backed staff sessions and plugin-specific roles/capabilities. WordPress accounts, other roles, pages, posts, other plugins, emails, exports and backups remain. Users with only the GroupEntry role are left without a site role. Staff sessions in an external object cache cannot be enumerated and expire within 12 hours; deleting the access code immediately prevents their use. Remove unused shortcodes from pages yourself.

What platforms have been tested?

Functional and language tests passed on WordPress 6.5 with PHP 8.1 and 8.3, and WordPress 7.1.3 with PHP 8.1; the ongoing development baseline also used WordPress 7.1.3 with PHP 8.3. Database testing used MariaDB 10.11.14 with InnoDB. The single-site plugin has also been tested on a separate live hosting installation. This does not cover every hosting, theme, browser, database version or caching configuration.