Skip to main content

Community Public Pages Feature Context

Source: .agents/references/features/community-public-pages.md

Content​

Community Public Pages Feature Context

Purpose​

Community public pages are the visitor/member-facing surfaces for a community. They include the community home/profile, product listing, feed, events, courses, challenges, files, forms, memberships, and zero-link pages under dynamic community routes. These pages need to preserve SEO, static rendering behavior, member/non-member visibility rules, and checkout/product CTA behavior.

User-Facing Workflows​

  • Visitors land on src/pages/[communityLink]/index.page.js, home.page.js, community.page.js, or product/event/feed child routes and browse public content.
  • Members see member-specific CTAs, welcome/splash states, feed access, enrolled product state, membership details, and chat/community access cards.
  • Non-members see join/buy/apply CTAs, public descriptions, product cards, and upsell content.
  • Community pages must handle inactive/missing communities, preview states, product availability, and localized copy without editing generated locale files unnecessarily.
  • Every active community exposes cached /{communityLink}/robots.txt and /{communityLink}/sitemap.xml; active custom domains expose the same files at the host root.
  • Public pages are mobile-heavy. Keep CTAs, carousels, filters, and modals ergonomic on narrow viewports and avoid stretching controls unless the design explicitly does so.

Key Entrypoints​

  • Routes:
    • src/pages/[communityLink]/index.page.js
    • src/pages/[communityLink]/home.page.js
    • src/pages/[communityLink]/community.page.js
    • src/pages/[communityLink]/products.page.js
    • src/pages/[communityLink]/events/[eventSlug]/index.page.js
    • src/pages/[communityLink]/feed/[postSlug].page.js
    • src/pages/[communityLink]/courses/[courseSlug].page.tsx
    • src/pages/[communityLink]/challenges/[challengeSlug]/index.page.js
    • src/pages/[communityLink]/forms/[formSlug].page.tsx
    • src/pages/[communityLink]/zerolink/[zeroLinkSlug].page.js
    • src/pages/api/business-seo/[communityLink]/robots.page.ts
    • src/pages/api/business-seo/[communityLink]/sitemap.page.ts
  • Components:
    • src/components/features/CommunityPage/
    • src/components/features/CommunityPage/components/home/
    • src/components/features/CommunityPage/components/allProducts/
    • src/components/features/CommunityPage/components/common/
    • src/features/CommunityProductPage/
    • src/features/EventPublicPage/
    • src/features/ResourcePage/
    • src/features/ZeroLinksContent/
  • Hooks:
    • src/hooks/useCommunityData.js
    • src/hooks/useCommonPublicPageData.js
    • src/hooks/useActiveCommunity.js
    • src/hooks/useCommunityPricingData.js
    • src/hooks/useStartCta.js
    • src/hooks/useUserRoleInCommunity.ts
  • Services:
    • src/services/communitiesService.js
    • src/services/communitiesService/types.ts
    • src/services/unifiedProduct/unifiedProductServices.ts
    • src/services/community/businessSeoService.ts
    • src/services/commonService.js
  • Utilities:
    • src/utility/communityHelpers.js
    • src/utility/communityUtils.ts
    • src/utility/routesHelper.ts
    • src/utility/pageTypes.js

Data Flow and Service Boundaries​

  • Dynamic community routes usually derive communityLink and product/entity slugs from Next.js route params. Inspect route-level data fetching before changing client hooks.
  • Public route families are also exposed to AI agents through the read-only public page catalog (public/.well-known/public-pages.json, public/public-pages.md, and public/public-pages/llms.txt). Keep those docs aligned with public community, feed, offer, membership, zero-link, inactive, and physical-product variant routes when route families change.
  • Public pages mix static/server props, service calls, SWR-style helpers, and client-only widgets. Do not assume all data is fetched client-side.
  • Public event client refreshes must preserve valid static event data when a successful response omits eventInfo; incomplete refresh payloads must not clear the rendered event state.
  • Product cards often use unified product data. Check src/components/features/CommunityPage/components/allProducts/ and src/services/unifiedProduct/ before changing labels, pricing, enrollment, or CTA logic.
  • Business sitemap generation resolves the active landing page, honors its indexable setting, and consumes every page from the public member unified-products endpoint with pageSize=100. It validates every page before publishing, deduplicates canonical URLs, skips unsupported product types, and refuses to publish more than 50,000 URLs.
  • Business SEO responses prefer the configured whiteLabelledDomain; otherwise they use the Nas.com community path. Successful robots and sitemap responses use a 100-second shared-cache lifetime with one-hour stale-while-revalidate. Missing, invalid, oversized, and upstream-error responses are not cached.
  • Lead forms are part of public unified product discovery: hasLeadForms/lead form counts should make the public Products tab and home product sections visible, while an otherwise empty community with no products, posts, or non-owner members can hide landing tabs and the home empty state.
  • Member-specific UI often depends on active community, user role, membership, pending approval, and product enrollment state. Keep those checks close to the rendering component when it already has the needed hook data.
  • Analytics are spread across utilities and feature-specific helpers. Preserve existing event names and action IDs unless the task explicitly changes tracking.

Conventions and Gotchas​

  • Use t('english-copy-as-kebab-case') for user-facing strings. Add only focused local English keys if required by the current repo rule.
  • Public routes are SEO-sensitive. Preserve meta tag helpers, static props, canonical URLs, and JSON-LD when touching page shells.
  • Nas.com keeps its existing root public/robots.txt and CDN-backed /sitemap.xml. Root robots/sitemap requests still pass through middleware so custom domains can rewrite them to the matching community; nested Nas.com robots files are informational because crawler directives are authoritative only at a host root.
  • Custom-domain root robots/sitemap rewrites must pass the domain-resolved slug through the internal x-business-seo-community-link request header; Next can match the rewritten dynamic Pages API route without populating its communityLink query parameter and strips rewrite query parameters.
  • Public pages for communities with an active custom domain must emit absolute custom-domain canonical, Open Graph, Twitter, and JSON-LD URLs during server rendering. Do not derive these URLs solely from window.location, which is unavailable during prerendering.
  • Preserve semantic landmarks in public page shells: one primary main, with header, nav, and footer supplied by the shared layout; route content should use labelled section regions and repeated product cards should use article without changing their visual classes.
  • Public page AI discovery must stay read-only. Page-context and MCP resources may describe visible public pages, but must not imply checkout/payment internals, member-only content, private feed/chat, learner lists, submissions, hidden pricing, seller/admin APIs, OAuth, API keys, webhooks, or MCP write tools.
  • Private/member-only route families such as /{communityLink}/courses/{courseSlug}/view, /{communityLink}/digital-files/{digitalFileSlug}/view, and /{communityLink}/products/{productSlug}/view are blocked from public page context.
  • Avoid unnecessary useEffect; derive view state from loaded community/product/member data when possible.
  • Do not use raw <img> for content images when existing code uses Next image wrappers or sizing helpers.
  • Keep card/button widths faithful to Figma or existing UI. Do not add flex-1 or w-full to CTA rows unless the design shows full-width behavior.
  • For conditional Tailwind classes, use classnames imported as classNames.
  • Treat slugs and query params as untrusted input. Validate/guard before using them in service calls or redirects.
  • ZeroLink checkout entry from a custom-domain public page must resolve the relative NAS-only /checkout-global destination through resolveNavigationHref before hard navigation. Preserve the current forced navigation and affiliate query construction while avoiding a custom-host checkout hop.
  • Legacy community social links may store their value in url or link without username. Public social link clicks must use the stored-field fallback and skip navigation when every value is empty.
  • .agents/rules/clean-react.mdc
  • .agents/rules/direct-translation-and-component-files.mdc
  • .agents/rules/no-direct-locale-additions.mdc
  • .agents/rules/no-try-catch-service-api.mdc
  • .agents/rules/web-security.mdc
  • .agents/references/coding-standard/useeffect-guidance.md
  • .agents/references/coding-standard/figma-guidance.md for Figma-driven UI work

Useful Graph Queries and Fallback Searches​

Use the terms below with search_graph/search_code, then run trace_path on central page-context, membership, or product-card symbols. Run these shell searches only as documented fallbacks.

rtk rg "communityLink|activeCommunity|membership|UnifiedProduct|hasLeadForms|getPublicPageVisibilityConfig" src/pages/[communityLink] src/components/features/CommunityPage src/hooks src/services
rtk rg "ProductCard|StartCta|WelcomeToCommunity|PendingCommMembership|leadForms" src/components/features/CommunityPage src/features
rtk rg "public-pages|page-context|nas-page://|getPublicRouteFamilyContext|REGISTERED_PUBLIC_PAGE_CONTEXTS" public src/services/agentDiscovery src/pages/api src/utility
rtk find src/components/features/CommunityPage -maxdepth 4 -type f

Update Triggers​

Update this reference when route names, community membership checks, unified product card behavior, public page data loading, public tab/empty-state visibility, public page catalog entries, route-family page-context behavior, per-community robots/sitemap behavior, or community-specific CTA rules change.