In multisite setup, the error pages in XMC are not rendered for each site.

[isyedakhtar]

Description

In (headless) SXA, we can define the error pages either on the Sitegrouping or Settings item itself. XM Foundation repo code is pulling the layout from edge for those error pages and renders them. For example in getStaticProps of 404.tsx
export const getStaticProps: GetStaticProps = async (context) => { const site = siteResolver.getByName(config.jssAppName); const errorPagesService = new GraphQLErrorPagesService({ endpoint: config.graphQLEndpoint, apiKey: config.sitecoreApiKey, siteName: site.name, language: context.locale || config.defaultLanguage, }); }
When getting the site information, we are using config.jssAppName. It works well for a single website hosted. If we are using the multisite plugin and have a single project, every site would render the error pages defined for the website that has a presence in config.jssAppName i.e. package.json app name.

Can someone suggest, what's the best way of tackling this. I thought to resolve it by removing the getStaticProps and use the Sitecore context within the main function. That could be a quick resolution but no SSG for a static page.

Additional information

I couldn't find a way to create a discussion under the repo https://github.com/sitecorelabs/xmcloud-foundation-head so thought to start a thread here.

[illiakovalenko]

@isyedakhtar Hey, I think it's possible to create an issue ticket there: https://github.com/sitecorelabs/xmcloud-foundation-head-dev/issues
But here it's fine.
I can suggest you take a look at site plugin. It extracts a real requested site, you can use this code and do the same in getStaticProps and use the value

export const getStaticProps: GetStaticProps = async (context) => {
  const path =
      context.params === undefined
        ? '/'
        : Array.isArray(context.params.path)
        ? context.params.path.join('/')
        : context.params.path ?? '/';

  // Get site name (from path)
  const siteData = getSiteRewriteData(path, config.jssAppName);

  // Resolve site by name
  const site = siteResolver.getByName(siteData.siteName);

  const errorPagesService = new GraphQLErrorPagesService({
    endpoint: config.graphQLEndpoint,
    apiKey: config.sitecoreApiKey,
    siteName: site.name,
    language: context.locale || config.defaultLanguage,
  });
  let resultErrorPages: ErrorPages | null = null;

  if (!process.env.DISABLE_SSG_FETCH) {
    try {
      resultErrorPages = await errorPagesService.fetchErrorPages();
    } catch (error) {
      console.log('Error occurred while fetching error pages');
      console.log(error);
    }
  }

  return {
    props: {
      headLinks: [],
      layoutData: resultErrorPages?.notFoundPage?.rendered || null,
    },
  };
};

[isyedakhtar]

Hi @illiakovalenko that site plugin and the code you shared has the same problem. They are using config.jssAppName to fetch the site information. In multisite setup, the config.jssAppName will not work as it will only be pointing to one of the sites. Which means, for all the sites, we are serving 404 page of the site config.jssAppName

[illiakovalenko]

@isyedakhtar Hi. Nope, getSiteRewriteData(path, config.jssAppName); - here is config.jssAppName is a fallback value, you will get siteName from the rewrite path

[isyedakhtar]

@illiakovalenko The page is generated statically. getStaticProps is called only once for all the sites in a multisite environment. When I tried this change, I see that it is generating static pages for each site. In my case there two sites 'basic' and 'skaters'. It generates static pages for both basic/404 and then skaters/404. However, because the SiteData is only being created once and it points to Skater site, both error pages are taken from skater site content.

[art-alexeyenko]

However, because the SiteData is only being created once and it points to Skater site, both error pages are taken from skater site content.

@isyedakhtar can you share your implementation for 404.tsx? 404 page will be generated for both sites, and getStaticProps should execute for both, with different site names. Can you verify if that's the case on your end?

[isyedakhtar]

@art-alexeyenko The 404 is statically generated for both sites as the page is part of the XM content home/404. When there is 404 error, the 404.tsx is executed from the next code which then calls the getStaticProps inside it. At this point, the getStaticProps doesn't know the context site. I tried using getSiteRewriteData as @illiakovalenko mentioned above, but the context.params always returns undefined. This
makes it fallback to the jssAppName.

[illiakovalenko]

@matkovskyi Can you, please, take a look a this issue and consider implementing it if it's possible? Seems like it's a limitation for multisite solutions using ErrorPages, isn't it?

[sc-ruslanmatkovskyi]

@illiakovalenko We have a task for implementing ErrorPages with multisite supporting. But now it isn't technically possible as I know

[ambrauer]

Next.js (Pages Router) only allows static 404/500 error pages, and they are compiled during build time. If you have i18n configured, those locales will be taken into account (and static versions of each language are built). This works because i18n is a built-in feature of Next.js. However, multisite is not and relies on dynamic site resolution and custom rewrite path segments to be used during build time.

This is a known limitation for JSS multisite. The starter code uses your configured default site for the 404/500 page content.
If you need unique 404/500 pages per site, then you can always serve sites using a dedicated rendering host (a single site) using the same codebase.

Note this is not a problem on Next.js App Router (which we will provide support for in the future). Even the official Next.js multi-tenant example did not have multi-tenant error pages until App Router 😉.