Describe the Bug
Bug Description
Problem
In a Next.js multisite JSS implementation with separate catch-all route directories (pages/_site_njord-store/[[...path]].tsx and pages/_site_njord-2/[[...path.tsx]] ), the JSS application fails to select the correct site during static site generation and server-side rendering.
Root Cause
The issue originates from how the site.ts plugin resolves the site name:
-
Site Plugin Logic: The SitePlugin extracts the path from context.params.path and uses it to determine which site should handle the request:
const path = Array.isArray(context.params.path)
? context.params.path.join('/')
: (context.params.path ?? '/');
const siteData = getSiteRewriteData(path, this.config.sitecoreSiteName);
props.site = siteResolver.getByName(siteData.siteName);
-
The Problem: When catch-all routes are nested within _site_${app-name} folders, the context.params.path does not include the _site_${app-name} prefix because:
- The folder name (
_site_njord-store or _site_njord-2) is part of the Next.js routing structure, not a route parameter
- Next.js only captures the
[[...path]] segments as context.params.path
- For example, visiting
/products/headsets results in params.path = ['products', 'headsets'], without any site identifier
-
Site Resolution Failure: Without the site identifier in the path, getSiteRewriteData() cannot determine which site configuration to use.
Solution
My band-aif fix is to modify the getStaticProps functions in each catch-all route to prepend the site identifier to the path before the plugin processes it:
const NJORD_STORE_SITE_NAME= '_site_njord-store';
// Fixes the JSS multisite site selection for nested catch all routes
export const fixMultisiteContext = (context: GetStaticPropsContext, siteToInject: string) => {
if (context?.params?.path === undefined) {
context.params = { ...(context.params || {}), path: [] };
}
(context?.params?.path as string[]).unshift(siteToInject);
};
export const getStaticProps = (context: GetStaticPropsContext) => {
fixMultisiteContext(context, NJORD_STORE_SITE_NAME);
(... regular static props code continues)
};
To Reproduce
Steps to Reproduce
- Set up multisite JSS Next.js application with separate catch-all route folders.
- Navigate to any route under second (non-default) site
Observe the issue:
- Check props.site value - it is default site
- GraphQL Client fetches with defualt site
Expected Behavior
- props.site is selecting proper site
- graphQL client fetches with proper site
Possible Fix
I do believe site.ts should receive better data to select the app properly, not only based on the context path
Provide environment information
- Sitecore Version: Sitecore.NET 10.4.1 (rev. 012149)
- JSS Version: 22.9.1
- Browser Name and version: Edge / Chrome latest
- Operating System and version (desktop or mobile): Windows 11
Describe the Bug
Bug Description
Problem
In a Next.js multisite JSS implementation with separate catch-all route directories (
pages/_site_njord-store/[[...path]].tsxandpages/_site_njord-2/[[...path.tsx]]), the JSS application fails to select the correct site during static site generation and server-side rendering.Root Cause
The issue originates from how the
site.tsplugin resolves the site name:Site Plugin Logic: The
SitePluginextracts the path fromcontext.params.pathand uses it to determine which site should handle the request:The Problem: When catch-all routes are nested within
_site_${app-name}folders, thecontext.params.pathdoes not include the_site_${app-name}prefix because:_site_njord-storeor_site_njord-2) is part of the Next.js routing structure, not a route parameter[[...path]]segments ascontext.params.path/products/headsetsresults inparams.path = ['products', 'headsets'], without any site identifierSite Resolution Failure: Without the site identifier in the path,
getSiteRewriteData()cannot determine which site configuration to use.Solution
My band-aif fix is to modify the
getStaticPropsfunctions in each catch-all route to prepend the site identifier to the path before the plugin processes it:To Reproduce
Steps to Reproduce
Observe the issue:
Expected Behavior
Possible Fix
I do believe site.ts should receive better data to select the app properly, not only based on the context path
Provide environment information