When viewing a page's properties in CMS Pages, the clickable URL uses a relative path instead of the full site domain. This causes the link to resolve to the internal Rock admin site rather than the external site the page belongs to — leading staff to unknowingly copy and share internal URLs.

Ministry Need

Churches and organizations rely on their web teams and administrative staff to manage, review, and share page links regularly — whether that's sending a giving page URL to a pastor, sharing a registration link in a newsletter, or verifying that a page looks correct after an update. Today, the most natural workflow (click the URL in Page Properties to preview or copy it) silently produces the wrong link. Staff don't realize they're sharing an internal admin URL until someone reports the link doesn't work, or worse, the internal hostname is exposed publicly. This erodes trust in the tools and creates friction for teams that need to move quickly — especially during time-sensitive campaigns, event launches, or weekend preparation. Every multi-site Rock installation is affected every time someone uses this link.

The Problem

Rock RMS supports multiple sites — an internal admin site, one or more external-facing sites, and potentially others. Each site is configured with its own domain(s) in Admin > CMS Configuration > Sites. When administrators manage pages through Admin > CMS Configuration > Pages, they frequently work across all of these sites from a single admin session.

The Page Properties panel (displayed when selecting a page in the page tree) includes a clickable URL field that shows the page's route. However, this URL is rendered as a relative path (e.g., /giving/scheduleeventpayments) rather than a fully qualified URL. Because it's relative, the browser resolves it against whatever domain the admin is currently on — which is almost always the internal Rock RMS admin domain, not the domain of the site the page actually belongs to.

What Happens Today

1. An admin navigates to Admin > CMS Configuration > Pages on the internal site (e.g., rock.mychurch.com)
2. They select a page belonging to the external site (e.g., “Bayside Church” site, configured with domain www.bayside.church)
3. The Page Properties panel shows:
   URL
   /giving/scheduleeventpayments   (clickable link)
4. Clicking that link navigates to rock.mychurch.com/giving/scheduleeventpayments — the internal admin domain
5. This is the wrong site entirely. The intended destination is www.bayside.church/giving/scheduleeventpayments

Why This Matters

• Accidentally sharing internal URLs. Admins frequently click this link to grab the URL to share with staff, volunteers, or the public. Because it resolves to the internal domain, they end up copying and sharing a link that either doesn't work externally or exposes the internal admin hostname.
• Confusion during page verification. After editing a page and saving, admins often click the URL to quickly verify their changes. Landing on the wrong site (or getting a 404 because the route doesn't exist on the internal site) creates unnecessary confusion.
• Multi-site environments are especially affected. Organizations running multiple external sites (e.g., a main church site, a camps site, a missions site) will consistently land on the wrong domain when checking pages from the admin panel.
• No visual indication of which domain. The relative path gives no hint about which site/domain the page lives on. The “Site:” label is shown elsewhere in the panel, but the URL itself doesn't reflect it.

Reproduction Steps

1. Ensure you have at least two sites configured in Rock — one for the internal admin and one external site with a different domain
2. Go to Admin > CMS Configuration > Pages
3. In the page tree, expand the external site and select any page with a route
4. In the Page Properties panel on the right, look at the URL field
5. Observe that it shows a relative path (e.g., /giving/scheduleeventpayments)
6. Click the URL — it navigates to the current (admin) domain, not the external site's domain

Technical Analysis

Where the URL Is Built

Rock has two versions of the PageProperties block:

Both versions construct the URL the same way:

var pageReference = new PageReference( page.Id );
var pageUrl = pageReference.BuildUrl();

PageReference.BuildUrl() (in Rock/Web/PageReference.cs) is designed to return only relative paths. It resolves the page's route and prepends the application path, but it never considers domain information:

public string BuildUrl()
{
    // ... resolves route and parameters ...
    url = "/" + url;  // Always returns relative, e.g. /giving/scheduleeventpayments
    return url;
}

The Infrastructure for a Fix Already Exists

The Site model already exposes a DefaultDomainUri property that returns the correct fully qualified base URL for any site:

// Site.DefaultDomainUri - already available in Rock
public virtual Uri DefaultDomainUri
{
    get
    {
        string protocol = this.RequiresEncryption ? "https://" : "http://";
        string host = this.SiteDomains
            .OrderBy( d => d.Order )
            .Select( d => d.Domain )
            .FirstOrDefault();

        if ( host != null )
            return new Uri( protocol + host );

        // Falls back to PublicApplicationRoot global attribute
        return new Uri( GlobalAttributesCache.Get().GetValue( "PublicApplicationRoot" ) );
    }
}

Both block versions already load the site object during rendering — the domain information is available but simply not being used.

Suggested Solution

Combine the relative page URL with the site's default domain to produce a fully qualified, absolute URL:

var pageReference = new PageReference( page.Id );
var pageUrl = pageReference.BuildUrl();

// Build absolute URL using the page's configured site domain
string displayUrl = pageUrl;
if ( site?.DefaultDomainUri != null )
{
    displayUrl = new Uri( site.DefaultDomainUri, pageUrl ).ToString();
}

Before: /giving/scheduleeventpayments (resolves to admin domain)

After: https://www.bayside.church/giving/scheduleeventpayments (resolves to correct site)

The link should also open in a new tab (target="_blank") so admins aren't navigated away from the Pages admin screen.

Files to Modify

1. RockWeb/Blocks/Administration/PageProperties.ascx.cs (~line 315)
2. Rock.Blocks/Administration/PageProperties.cs (~line 335)

Fallback Behavior

If no SiteDomain records are configured for a site, DefaultDomainUri gracefully falls back to the PublicApplicationRoot global attribute — so there's always a reasonable default.

Scope of Change

This only affects the display of the URL in the Page Properties view panel. It does not change routing, page resolution, or any other Rock functionality.