Skip to Content
RhythmHelp Center
/

Available Documentation

  • Platform
  • CRM
  • Portals
  • Security & Settings
  • Accreditation
  • Membership
  • Finance & Billing
  • Orders & Inventory
  • Events
  • Certifications
  • Awards
  • Careers
  • Fundraising
  • Integrations
  • Sponsorships
  • Submissions

Coming Later

  • DocumentsComing Soon
Portals
  • Overview

Subjects

  • Concepts
    • Overview
    • Portal Hosting Explained
    • How Portal Hosting Provisioning Works
    • How a Portal Site Starts and Finds Its Pages
    • Pages and Menus Explained
    • How Several Policies Combine on a Page or Menu Item
    • How Page Access Levels Work
    • How Portal Admission Works
    • Security Policies Explained
    • Site Settings Explained
    • Sites and Event Microsites Explained
    • Working Copies, Published Versions, and the Asset Map Explained
  • Get Started
  • Tasks
  • Portal
  • Configure
  • Reference
  • Troubleshooting
  1. Home
  2. Portals
  3. Concepts

Pages and Menus Explained

portal page ‧ portal menu ‧ working copy ‧ published copy ‧ publish a page ‧ page not updating ‧ image disappeared after publishing ‧ pasted image

On This Page
  • Every Page Has Its Own Address
  • What You Edit Is Not What Visitors See
  • What Happens to a Pasted Image When You Publish
  • Access and Publishing Are Separate Concerns
  • Related

A page is content with its own address on your portal site. A menu is a named list of links to pages, and staff add it to a page design wherever visitors need navigation. You build and edit pages and menus in the Console, and both follow the same visibility rules.

Every Page Has Its Own Address ​

When your site starts up, Rhythm gives every page in your site map its own address. Each page a visitor opens is a separate location on your domain that you can link to directly.

A menu does not have its own address. Rhythm displays a menu wherever the page design includes the menu widget, and the menu loads only after you publish it and include it in the site map. If the menu selected as your default has never been published, that default menu will not load, even though the rest of the site works normally.

A visible navigation item is not always a page you can edit. A menu item can point to a destination URL instead of opening a page you manage directly. If a tab or link goes to the wrong place, you usually fix the destination URL on that menu item instead of looking for a page to change. To find the page that controls visible content, check the current route in your browser’s address bar, such as /certifications/programs/view, and look for that same route under Pages in the Console.

Changing the menu assigned to a page’s starting template affects only pages created from that template after the change. An existing page keeps the menu already selected in its Bootstrap CSS Menu component, so update that component on each existing page if you want it to match the new default. Not every part of a site is edited as page content. For example, you edit the member portal home page’s promotional “What’s Happening” banner in the Member Portal Home Page Editor, not inside a page design.

What You Edit Is Not What Visitors See ​

When you edit a page or menu, you work on its working copy, which is the version you save while you build. Visitors only see the published copy. Saved changes that have not been published, and unsaved changes still in the designer, stay hidden from visitors. This rule applies to every page and menu on every site, so visitors cannot preview unpublished work by opening the page address.

This is why it matters how a site map keeps pages reachable. When Rhythm rebuilds your site map, it includes only content that has already been published. Unpublished edits can look like they disappeared from the rebuilt site until you publish them again.

After you save, reopening the page designer can occasionally still show content you already removed, such as an image, even though the live, published page reflects the change. The same kind of mismatch has appeared on the Account Home page: a logo that saves and publishes correctly, and displays on the live page, can still fail to reappear when you reopen that page’s settings. Neither situation is a concern by itself, because visitors see the published version.

What Happens to a Pasted Image When You Publish ​

A page must fit inside a fixed overall size limit when you save it, which is separate from each image’s own size allowance. Embedding images directly in a page design, instead of inserting them from file assets, is a common way to reach that limit. When that happens, the page fails to save with an item-size error, even if every individual image is within its own allowed size.

Warning

If you paste an image directly into a page design, instead of inserting it from your account’s uploaded file assets, Rhythm removes that embedded image from the saved working copy when you publish. You will not notice right away, because the version you just published still shows the image. The problem appears the next time you publish that page: the image was already removed from the working copy during the first publish, so it is gone from the second published version and cannot be restored from that page.

To avoid this, insert images from your account’s file assets instead of pasting them directly into a page. An inserted asset is a reference to a file, not embedded image data, so Rhythm leaves it in place each time you publish the page. See Assets, Kinds, and Folders Explained for how uploaded file assets work and where to manage them. You can manage a page’s images while editing the page’s content directly or from Assets, but only the Assets approach avoids embedding the image in the page itself.

Pasting rich content copied from Microsoft Word into a page design can cause a similar save problem, because Word can include hidden formatting that keeps the page from saving reliably. If a page will not save after you paste content from Word, format the content directly in the page editor instead, and add any images separately as file assets.

Access and Publishing Are Separate Concerns ​

Publishing controls which version of a page or menu item is available. A visitor’s visibility is decided separately by the page’s access level and any security policies attached to it. See How Page Access Levels Work and How Several Policies Combine on a Page or Menu Item for how those rules work.

Related ​

  • How Page Access Levels Work
  • How Several Policies Combine on a Page or Menu Item

Continue in This Subject

PreviousHow a Portal Site Starts and Finds Its PagesNext How Several Policies Combine on a Page or Menu Item

Related Articles

  • How Page Access Levels Work

    Every portal page is public, requires sign-in, or requires sign-in with a linked contact record.

  • How Several Policies Combine on a Page or Menu Item

    When a page or menu item carries more than one security policy, the portal can require a visitor to meet all of them, any one of them, or none of them.

On This Page

  • Every Page Has Its Own Address
  • What You Edit Is Not What Visitors See
  • What Happens to a Pasted Image When You Publish
  • Access and Publishing Are Separate Concerns
  • Related
Rhythm Help Center© Rhythm Software

Search article titles, settings, tasks, and troubleshooting topics. Press Enter to see results.

Browse Platform Documentation