A site is one member-facing website with one domain name and one purpose. Your association might have one member portal, or it might run several sites side by side, such as a member portal, a donor portal, and an event microsite for one conference. Each page, menu, site setting, and installed feature belongs to one site only. Two sites do not share anything automatically, even when they are in the same Rhythm account.
A site is not the same as a page. A page is one piece of content inside a site, such as a single screen a visitor opens. The site is the container for related pages and menus that use one domain, one set of site settings, and one purpose. When you delete a page, you remove only that piece of content. When you delete a site, you remove everything built inside it.
Your Account Starts with a Site
When your account is first set up, Rhythm automatically creates a member portal site so you can start building pages right away. See Choose the Site You Are Working On to learn how staff find and work with the sites in your account.
Event Microsites Follow Their Event
An event microsite is tied to exactly one event. Two behaviors make an event microsite different from an ordinary site:
- Deleting the event deletes its microsite. When you delete the event that owns an event microsite, Rhythm deletes the microsite too. You cannot undo this or recover the microsite later, so treat deleting an event with its own microsite as deleting that site.
- A microsite is marked closed once its event has ended. After the microsite's event is over, Rhythm marks the microsite as closed wherever other parts of Rhythm list it. If the event has no end date, Rhythm never marks the microsite as closed this way.
Tip
If Rhythm cannot look up the event for an event microsite, the microsite still appears in the list. It appears without event dates and sorts to the end wherever your account's sites are shown in order.
flowchart LR
A[Event is created] --> B[Event microsite is built]
B --> C{What happens to the event?}
C -->|Event ends| D[Microsite is marked closed]
C -->|Event is deleted| E[Microsite is deleted, with no recovery]
Keep this lifecycle in mind before you delete an event that has its own microsite. Rhythm does not show a separate confirmation that calls out the site, and you cannot get the microsite back afterward. If you only want visitors to stop seeing an event as current, let the event end naturally instead of deleting it. The microsite stays in place and is marked closed.
How Other Parts of Rhythm See Your Sites
Outside the Portals Console, other parts of Rhythm list your account's active sites in a sensible order when staff need to choose one. Only sites marked active appear in that list. An inactive site is left out, even if it still has published pages. If a site you expect to see elsewhere in Rhythm does not appear, check that it is marked active before you look for another cause.
Building an Event Microsite's Pages
Clickable session and speaker names on an event microsite's schedule work only after the pages they open exist. Install the Required Pages and Schedule of Events microsite features first, because they create the session and speaker detail pages those links use. Then publish the speaker info page itself. A link to an unpublished speaker page will not open, even when the link is visible and the session page otherwise looks complete.
To add an event registration link to a microsite page, open the page in the microsite editor. Drag the Register for Event component from the Meetings & Shows section onto the place where you want the link to appear. The same Meetings & Shows section also includes a Landing Page component. When you add it to the microsite's Home page, it pulls in the masthead image from the event's details automatically, so you do not need to upload that image separately.
Tip
For a consistent look on a speaker listing page, upload speaker photos at 400×500 px, which is a 4:5 ratio. Mixed image shapes on that page tend to look uneven.
A microsite's header logo sometimes comes from a direct link managed in the Portals asset library, not from the page content itself. If you need to change it, switch to the correct microsite in the asset area first. Assets are scoped by site, so updating the wrong one will not affect the microsite you meant to change.
If you want to feature only some speakers instead of the full roster, the system-generated Speaker List page cannot be configured that way. Create a separate microsite page instead, leave the generated Speaker List page unpublished, and hard-code the featured speakers' names and images on the new page. Because this bypasses the normal speaker data, you need to update that page by hand whenever a featured speaker changes or the event is cloned for a new year.
Built-in elements such as the View Speaker List button are part of the microsite's base design and may not be removable through your account's page or menu configuration. Removing one can require help from Rhythm's web design team instead of a self-service setting.
Warning
An event microsite built from the same template as your member portal can inherit that template's footer. To remove it from existing pages, edit each page and delete the "main-footer" component. To keep future microsites built from that template free of the footer, clone the template first and remove "main-footer" from the clone before building new sites from it.
Which Page Visitors See First
An event microsite's root address, meaning the domain or path ending in /, always opens the site's default landing page. It does not open a separately created page with a similar name, even if you intended that page to be the real landing page. If you edit, save, and republish a page that is not actually the default landing page, visitors at the root address will not see your changes. To change what visitors see first, edit the default landing page itself, or copy your intended content onto it, then save and republish.
What Can Make an Event Microsite Look or Behave Unexpectedly
Some elements on an event microsite's homepage, such as a masthead banner, come from the event's own settings instead of a nearby page-builder component. If removing or editing a brick near that element does not change what visitors see, the element is likely coming from the event's configuration, so you need to change it there.
| Symptom | Likely cause |
|---|---|
| The schedule page cannot be filtered by day or date | The schedule component does not support filtering sessions by day through its configuration; changing that would need a code-level change to the component. |
| The countdown timer does not count down correctly | This is a known issue with the countdown timer component, and engineering is investigating it. It is not something you can configure around. |
| A masthead image looks cropped, a thumbnail is missing, or text is unreadable | These are usually design or theme styling issues, not event registration configuration problems. |
A large image embedded directly in a page's HTML, instead of inserted through the normal page content tools, can make that page load more slowly. Rhythm does not publish a fixed maximum size or file type for images on responsive microsite pages, so keep images reasonably small and let the page layout resize them instead of uploading oversized files.
Tip
Microsite pages do not include built-in page-view or analytics reporting. If you want to measure how a page performs, set up analytics with an external tool instead of looking for that data in the product.
If a form linked from your microsite lives on an external website, such as WordPress, Rhythm does not manage that form or its submissions. Investigate missing submissions with the administrator of that external site instead of inside your Rhythm account.
Recovering a Microsite After Copying, Cloning, or Rebuilding
If a copied or renamed event microsite still points to the old event's content or fails to load, open the site in Portals & Microsites › Setup › Sites and save it again. Re-saving the site's settings can refresh a stale event association and restore normal loading.
After you rebuild or recreate an event microsite, you may need to reinstall its microsite features from the portal features area before the site works again.
If a microsite page is accidentally deleted, restore it from the Console side. Open the Pages tab and use Create Page to add it back. A page or tab also needs to be created from that Console-side Pages area in the first place for navigation to work correctly. If you recreate it somewhere else, the tab can remain non-functional.
Cloning an event together with its microsite can leave the new microsite tied to the event it was cloned from, instead of cleanly switching to the new event. If this happens, the safer approach is to clone the event again without copying the microsite, then build the new event's microsite fresh instead of reusing the cloned one. This difference also shows up in publishing. Cloning an event and copying its microsite tends to leave the copied pages in a pending state, while cloning the event without the microsite and then creating a separate microsite tends to leave the new pages published.
Tip
Cloning or copying an event microsite's setup can also leave required account-related pages unpublished. This typically shows up as access failing only for visitors who arrive through registration, verification, or a similar account flow, while other pages work normally. Review the cloned site's pages and publish any that are still pending.
If an event microsite's URL stops routing to the right content, re-adding the same URL in both the event's meeting or show details and in Portals & Microsites › Setup › Sites has restored correct routing. Separately, reassigning a microsite's domain to a different event and then reassigning it back can leave a stale backend mapping. In that case, the event's settings can show the domain correctly assigned while the live site and preview still render the other event's pages. If a published microsite link shows a numeric identifier instead of its expected text-based address, check the microsite's publish configuration, because correcting that setting can restore the expected link.
A microsite can have every page approved and published and still not be visible to anonymous visitors. Public visibility is controlled by a separate access configuration beyond page approval and publishing. If a published microsite does not open for visitors who are not signed in, check that configuration instead of only the pages' publish status.
If an event is already active and you cannot restart its microsite from a freshly copied event, make the needed appearance changes directly on the landing page instead of trying to recopy the microsite.
Domains, External Publishing, and Search Visibility
When you reuse one evergreen domain for an annual event microsite, hand it off carefully each year. First move the prior year's microsite to a year-specific domain, then assign the evergreen domain to the new event. Use redirects as needed so the prior year's microsite stays reachable instead of the main domain continuing to point at the old event.
Publishing a microsite into your organization's main external website is usually your web platform team's responsibility. Rhythm support does not have platform-specific implementation instructions for that integration, so plan to work with your web team and, if needed, your website's hosting vendor.
A standalone microsite's own URL may not be enough for it to appear in Google search results on its own. Search visibility can depend on also publishing the same content through your organization's main website.
Warning
Setting an event microsite's Welcome Landing Page to open and public can cause it to take over routing for a shared portal domain. If that happens, visitors are sent to the event microsite instead of your intended member portal sign-in or home page. Setting the Welcome Landing Page to closed or private resolves the conflict.
If an event microsite's registration button or link does not appear at the top of the page, check whether the site's legacy stylesheet is enabled in site settings. Some microsites depend on that setting for the registration control to display.
Custom tracking scripts, such as Google Tag Manager code, can be added only to a standalone event microsite, where Google Analytics can be enabled and script tags can be added to pages. That customization is not available for a portal-integrated event site. If you need custom tracking on registration pages, moving the event to a standalone microsite is a prerequisite.
Event Microsites Vs Portal-Integrated Events
Exhibitor registration is available only on a standalone event microsite. A portal-integrated event site is more limited, and its menu cannot be edited to add exhibitor signup pages.
Portal-integrated events now support a schedule of sessions and group registration for attendees, so do not assume those features are limited to standalone microsites when you compare the two options. In some cases, a portal-integrated event's page package has still included abstract-related pages or links even when abstract submission is not actually supported for that event. That can be misleading, so treat any abstract-related page you see on an integrated event as something to verify rather than evidence that abstract submission works there.
If you add an image banner to the main portal page used for integrated event registration, remember that page is a shared route. The banner is not event-specific, and it will display on every integrated event's registration page that uses it, not just the one you meant to brand.
When a visitor who is not signed in starts registration from an event microsite and chooses to create a new account, the sign-up and first-time account-completion steps happen through the main portal's standard account-creation experience. After that, the visitor returns to the microsite to finish registering. The process does not stay entirely inside the microsite.
Portal-integrated event microsites can normally be opened directly by their own URL, even though they are portal-integrated. If one unexpectedly behaves as though it can only be reached through the member portal, treat that as something to fix rather than the intended access model.
If you need to show only one sponsorship process on a microsite's Purchase Sponsorship page, administrators have worked around this by adding custom code to that page that hides every process row except the one you want to keep. This depends on correctly identifying the target process in the page's custom code, and you should preview the result before publishing.
Attendee Lists and Registration on a Microsite
The page at the registration-view URL (/events/registrations/view/[event_id]) belongs to the Registration History feature. To use it on an event microsite, add the page to the microsite's menu and add its ID to that feature's component configuration in Portals & Microsites. When the results option is left at its default, the attendee list on that page is visible and takes a visitor to attendee information when selected.
For a regular event microsite, put attendee-list access on the microsite menu instead of on the View Registration page, because that page is not the right place for it. The View Registration page itself can still be added to the microsite menu and configured with the needed ID, as described above, when that is the behavior you want.