Dealing with One Sitecore Search Sandbox and Multiple XM Cloud Environments

19 March, 2025

Sitecore, Sitecore Search, XM Cloud

Managing a single non-prod Sitecore Search Sandbox alongside two non-prod XM Cloud environments can be frustrating, especially when you need separate configurations for each environment. Ideally, each environment would have its own sandbox, but that’s not always the case. And creating separate widgets for each environment? That’s just not practical.

The challenge? It becomes difficult to test when your search result listings show data from both UAT and QA environments, making it hard to validate environment-specific configurations properly.

Luckily, there’s a solution—Site Context Variables. By leveraging these variables, you can dynamically adjust configurations based on the environment, streamlining the process without the headache of managing multiple widgets manually. Let’s dive into how Site Context Variables can make your setup more efficient and manageable.

The Challenge: News Listing in a Shared Sandbox

In Sitecore Search, when you want to display a listing component—such as a news listing that pulls all article detail pages—you typically need to create a widget in Sitecore Search. This widget is responsible for querying and displaying the relevant content on your site.

However, when working with a shared Sitecore Search sandbox across multiple non-prod environments (UAT and QA), things get tricky. Since both environments use the same search index, the listing component can retrieve mixed data from both environments. This makes it difficult to validate environment-specific configurations, as search results may include articles from both UAT and QA instead of just the intended environment.

A Smarter Approach: Using Site Context Variables

To solve this, we can leverage Site Context Variables in Sitecore Search. These allow us to dynamically adjust search queries based on the environment, ensuring that the news listing only displays data relevant to the current site environment.

Here’s how it works:

  1. Define a Site Context Variable that identifies the environment (e.g., uat or qa).
  2. Modify your search query to filter results based on this variable.
  3. Ensure each environment passes the correct context value, so UAT retrieves only UAT data, and QA retrieves only QA data.

By implementing this approach, you avoid data mixing between environments and maintain accurate, environment-specific search results, making testing and validation much smoother.

Defining the Site Context Variable

To ensure that your search results only display data from the correct environment, you need to define a Site Context Variable in Sitecore Search. Here’s how you can do it:

  1. Go to Administration in Sitecore Search.
  2. Navigate to Domain Settings > Attributes.
  3. Click Create a New Attribute and name it Environment.
  4. Scroll down to the Properties section.
  5. Ensure the checkbox for “Available for Site Context” is selected.

By doing this, you make the Environment attribute available as a Site Context Variable, allowing you to dynamically control search queries based on the active environment (UAT or QA).

Modifying Your Search Query to Use Site Context

Now that we’ve defined the Environment attribute as a Site Context Variable, we need to apply it to our search queries to ensure they only retrieve results from the correct environment.

Here’s how to do it:

  1. Open your widget in Sitecore Search.
  2. Navigate to the Rules section.
  3. Click Add Rule.
  4. In the left tabs, select Context.
  5. Under Context, choose Site Context and then click Add Context Rule.
  6. Select the Environment attribute.
  7. Choose the “is” condition.
  8. In the value field, enter the appropriate environment, e.g., UAT.
  9. Finally click on save

Filtering Out Unwanted Content with a Blacklist Rule

Now that we’ve added a Site Context Rule for the Environment, we need to ensure that only content belonging to the selected environment is displayed. To do this, we can apply a Blacklist Rule to exclude content from other environments.

Steps to Add a Blacklist Rule:

  1. In the same rule where Environment = “uat” is applied:
  2. Click the Strategy tab.
  3. Choose Blacklist Rules.
  4. Click on + Add Attribute.
  5. Select the content_source attribute (this must be previously populated in the corresponding source, meaning we may need a separate source for UAT content and another for QA content).
  6. Choose the “is not” condition.
  7. Enter uat as the value.
  8. Finally Publish your changes

You will see a summary like this:

Important Note: If you need to do same on all widgets you can move the rules to a Global Widget as Follows

Passing the Correct Context Variable in Your Next.js Application

To ensure that each environment correctly passes the Site Context Variable, we need to set up an environment variable in our Next.js application.

1. Define the Environment Variable

In your .env.local file, add:

NEXT_PUBLIC_SEARCH_ENVIRONMENT=uat


This variable will dynamically specify which environment the search requests should be associated with.

2. Set the Context in Your React Application

If you wrap your application in a React Context, such as a SearchProvider component, you need to ensure the correct environment is passed when instantiating the WidgetsProvider.

In the same component where WidgetsProvider is being called, add the following code:

const context = PageController.getContext();
context.setPage({
  ...context.getPage(),
  custom: {
    ...context.getPage()?.custom,
    environment: process.env.NEXT_PUBLIC_SEARCH_ENVIRONMENT,
  },
});

A Word on context.setPage()
Using context.setPage() to inject the environment variable was a bit tricky. The documentation doesn’t explicitly clarify how Site Context Variables are being mapped on the Sitecore Search side. This made it more difficult to understand how to pass context from the frontend to ensure the correct filtering based on the environment.
For reference, you can check the documentation here: Sitecore Search JS SDK for React Context.
How This Works
  • PageController.getContext() retrieves the current search context.
    • 


  • context.setPage() updates the context, injecting the environment value from the Next.js environment variable.
    • 


  • Now, whenever a search request is made, Sitecore Search will receive the correct environment variable (uat or qa), ensuring that only the relevant content is retrieved.
This ensures that UAT and QA environments remain separate, avoiding data mix-ups in search results.
Behind the scenes it pass the context variable under context params as follows:
Conclusion
Managing a shared Sitecore Search sandbox across multiple non-prod environments, like UAT and QA, can pose significant challenges—especially when you need to ensure that search results are environment-specific. However, with the right approach, you can streamline the process and avoid mixing data between environments.
By defining Site Context Variables and utilizing Blacklist Rules, you can effectively filter content based on the active environment, ensuring that each environment retrieves only the relevant data. Additionally, integrating environment variables within your Next.js application and properly configuring the context.setPage() function allows you to dynamically set and pass the environment context to Sitecore Search, making it possible to tailor search results to each specific environment.
While implementing these steps can be tricky, especially when the documentation doesn’t offer clear guidance on how Site Context Variables are mapped on the Sitecore side, this solution provides a clean and efficient way to manage your search results across environments.
By following this approach, you can ensure accurate testing, prevent data contamination, and streamline the process of working with Sitecore Search in multi-environment setups. Happy coding! 🚀
								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
Troubleshooting React Issues When Transitioning Between Pages


			
		    
		    

					
31 January, 2025


			    

									
NextJs, Sitecore, XM Cloud

								
		    


		
 

		
			


				
We’ve encountered a peculiar issue where some components break when navigating between pages using a link. This article will walk you through the problem and its solution, particularly when reading properties from the context page instead of the data source item.
The Issue
If your component works fine when loading a page directly via the URL but encounters null issues when accessing it through a link, this guide will help you troubleshoot the problem.
Before diving into the sample case, it’s important to understand that transitioning between pages happens on the client side, similar to how a Single Page Application (SPA) behaves.

Sample Case
Consider a scenario where Page A contains a list of links, and clicking on one of these links navigates to Page B. Page B includes a component that reads fields from the Context Page.
However, after clicking the link to navigate to Page B, the page breaks due to a null error. But why?


Debugging the Issue
All fields on Page B are required, so a null value was unexpected. To investigate, I attached a debugger and found that the Navigation Title still referred to Page A instead of Page B.


Root Cause Analysis
Reviewing the code, I noticed that the component was being called from the origin page (Page A), meaning field.careerListingSource was undefined because it didn’t exist in that context.


The Solution
The fix was straightforward: add a null check on the property, considering the scenario where that field doesn’t exist on the origin page.
After implementing this change, the page loaded successfully because:
  1. First Load: The CareerList component was initially loaded in the origin page (Page A), but the execution was handled gracefully even if the component wasn’t presented.
    2. 


  2. Second Execution: The CareerList component was loaded correctly in the target page (Page B), as expected.
Conclusion
When working with components that rely on fields from the Context Page, remember that your component might be rendered on a page where those fields don’t exist. Adding proper null checks or fallback values will prevent your component from breaking during transitions.
I hope this article saves you time troubleshooting similar issues!
Relevant Documentation:
Routing: Linking and Navigating
								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
Optimize API Calls for a Page with Multiple Components


			
		    
		    

					
13 July, 2024


			    

									
Sitecore, XM Cloud

								
		    


		
 

		
			


				
Introduction


When working with a Product Page, it’s common for data to reside outside of Sitecore. In such cases, the CMS may only hold a reference ID to the actual data stored in another system. A typical page is composed of numerous components, and using getStaticProps for each component can result in multiple API calls, leading to inefficiency.


Solution


To address this issue, you can use a Page Props Factory Plugin. This plugin allows you to manage data fetching more efficiently by centralizing API calls.


Step-by-Step Guide


Create a New File


Navigate to /lib/page-props-factory/plugins and create a new file named product-props.ts.


Step 2: Add the Following Code



class ProductPropsPlugin implements Plugin {
  private productService: ProductService;

  order = 4;

  constructor() {
    this.productService = new ProductService();
  }

  async exec(props: SitecorePageProps) {
    if (!props.layoutData.sitecore.route) return props;
    if (props.layoutData.sitecore.route.templateId != PRODUCT_DETAIL_PAGE
      return props;

    const route = props.layoutData.sitecore.route;
    const productIdField = route.fields?.productId as Field<string>;
    if (productIdField.value === '') return props;
   
    const productResponse = await this.productService.getProduct(
      productIdField.value as string
    );

    const componentProps = props.componentProps as { [key: string]: unknown };
    componentProps['productData'] = productIdField.data.product;

    const errors = Object.keys(props.componentProps)
      .map((id) => {
        const component = props.componentProps[id] as ComponentPropsError;

        return component.error
          ? `\nUnable to get component props for ${component.componentName} (${id}): ${component.error}`
          : '';
      })
      .join('');

    if (errors.length) {
      throw new Error(errors);
    }

    return props;
  }
}

export const productPropsPlugin = new ProductPropsPlugin();




Step 3: Use the Property in Your Component


Finally, you can add the following code in your component to get the property:


const productData = useComponentProps<Product>('productData') as Product;



Conclusion


By implementing a Page Props Factory Plugin, you can optimize API calls for a page with multiple components. This approach reduces redundancy and improves performance by centralizing data fetching, making your application more efficient and maintainable.


								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
XM Cloud – Docker container troubleshooting


			
		    
		    

					
19 June, 2024


			    

									
Sitecore, XM Cloud

								
		    


		
 

		
			


				
Are you trying to up your docker instance and you noticed the following error, “curl: (6) Could not resolve host: nodejs.org”
There is an easy solution, how to fix this issue.
  1. Go To Docker Desktop -> Settings -> Docker Engine
    2. 


  2. Add
{
  "dns": [
    "8.8.8.8"
  ],
 ....
}



DNS Record will help to your Docker to resolve the nodejs.org.
I hope that you find helpful this post.
								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
Passing Attributes between Components within Placeholders in XM Cloud [NextJS]


			
		    
		    

					
26 March, 2024


			    

									
NextJs, Sitecore, XM Cloud

								
		    


		
 

		
			


				
Hey there! Have you ever found yourself scratching your head, wondering how to smoothly pass attributes from one component to another nestled inside Sitecore Placeholders? I recently delved into this topic, exploring the documentation provided by Sitecore (check it out here).


Despite diving into the docs, I couldn’t find a straightforward way to achieve this task. But fear not! I stumbled upon a hidden gem within the placeholder — the modifyComponentProps function.


 /**
     * Modify final props of component (before render) provided by rendering data.
     * Can be used in case when you need to insert additional data into the component.
     * @param {ComponentProps} componentProps component props to be modified
     * @returns {ComponentProps} modified or initial props
     */
 modifyComponentProps?: (componentProps: ComponentProps) => ComponentProps;



Excitedly, I decided to give it a whirl. However, to my dismay, it seemed like nothing happened, at least not with JSS v21.6.0.


After some pondering, I speculated that the ComponentPropsFactory might be overriding modifyComponentProps. But lo and behold, I found the information tucked away in ComponentPropsContext. And thus, a solution was born — a function to help you effortlessly achieve your goal.


All you need to do is install the following library:


npm i @constellation4sitecore/foundation-enhancers



Let me walk you through an example. Say you want to send properties to a child component inserted into a Placeholder.


const MyComponent = ({ fields, params, rendering }: MyComponentProps) => {
    // Invoke the magic
  useModifyChildrenProps(rendering, {
    myProp1: fields.myProp1,
    myProp2: 'hello world!',
  });

  return (
    <Placeholder
      name={`my-chindren-modules-${params.DynamicPlaceholderId}`}
      rendering={rendering}
    />
  );
};



And in your Children Component, you can effortlessly retrieve all the passed data.


type ChildComponentProps = {
    fields: Fields,
    // Add prop types here
    myProp1: Field<string>
    myProp2: string
}
const ChildComponent = ({ myProp1, myProp2 }: ChildComponentProps) => (
  <>
    <Text field={myProp1} />
    <span>{myProp2}</span>
  </>
);



This nifty solution has made passing data to all children a breeze. I hope you find this information as helpful as I did!


Common use cases:


    

  • You have a Tab component and need to send the active ID to children.
    • 

  • You need to re-render some props on specific breakpoints in the children component (e.g., mobile, desktop), and the parent component holds the information.
    • 



If you’re curious to dive deeper into this functionality and perhaps even contribute, you’re in luck! The function we discussed is part of an open-source project called Constellation 4 Sitecore. You can find the source code and contribute your ideas and improvements on Check it on Github!. We welcome collaboration from developers of all levels of expertise. Let’s join forces and make this tool even more powerful together! 🚀


Special thanks to Josue Jaramillo for invaluable assistance in troubleshooting the issue!


								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
XM Cloud Next.js Practices for a Smooth Development


			
		    
		    

					
15 June, 2023


			    

									
Sitecore, XM Cloud

								
		    


		
 

		
			


				
Working with Next.js application in XM Cloud, In this article I want to summarized what I learn until now.
Reserve fields only for Sitecore Fields
I do consider a good practice to reserve fields field only for Sitecore fields like the following example:
type ContentBlockProps = ComponentProps & {
  // Reserve fields for Sitecore Props
  fields: {
    heading: Field<string>;
    content: Field<string>;
  };
};



The reason that I consider a good practices is because in scenarios that you need to build a custom logic in getStaticProps, I feel that content fields are mixed with logic fields.
type ContentBlockProps = ComponentProps & {
  fields: {
    heading: Field<string>;
    content: Field<string>;
    myProp: MyType // prop not related with content
  };
};

export const getStaticProps: GetStaticComponentProps = async () => {
  const myCustomProp = await myLogic();
  return { fields: {
      myProp: myCustomProp 
   }
  };
};



So consider moving myprops out of fields.


type ContentBlockProps = ComponentProps & {
fields: {
    heading: Field<string>;
    content: Field<string>;
  };
 myProp: MyType // prop not related with content
};



When working with Variations try to reuse component
Per some investigations for name convention it’s a best practice to use PascalCase, however I need to find a way how to differenciate a React Componet vs a Sitecore Component.
So I suggest the following practice (maybe some day this becomes a best practice), anyway I’m open to feedback.
For example consider this scenario:
Simple Masthead with 3 Variations, Default, Color A, Color B.
So I starared to create a component with UI{ComponentName} so this means that this is a React Component that I can reuse it without necessary being a Sitecore Component.
const UISimpleMasthead = ({
 fields,
 variationParams}
}: SimpleMastheadProps): JSX.Element => 
(<>
Markup Here
</>);




Then I can declare the variations with the same approach


const UIDefault = (props: SimpleMastheadProps): JSX.Element => (
  <UISimpleMasthead {...props} variationParams={{ cssStyle: 'default' }} />
);
const UIColorA = (props: SimpleMastheadProps): JSX.Element => (
  <UISimpleMasthead {...props} variationParams={{ cssStyle: 'color-a' }} />
);
const UIColorB = (props: SimpleMastheadProps): JSX.Element => (
  <UISimpleMasthead {...props} variationParams={{ cssStyle: 'color-b' }} />
);



Finally export Sitecore Components / Variations as follows:


export const Default = withDatasourceRendering()<SimpleMastheadProps>(UIDefault);
export const ColorA = withDatasourceRendering()<SimpleMastheadProps>(UIColorA);
export const ColorB = withDatasourceRendering()<SimpleMastheadProps>(UIColorB);



With this approach I can reuse the markup and define the variations using props.
Also this could be used if you are working UI Components so you can Prefix your UI Components to understand that this is a UI and without prefix you know that this is a Sitecore Component. 
I’ll continue writing more tips or suggestions to improve your developer experience. Happy coding!
								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
Notes from a .Net Developer working with XM Cloud.


			
		    
		    

					
14 June, 2023


			    

									
Sitecore, Sitecore JSS, XM Cloud

								
		    


		
 

		
			


				
XM Cloud is a comprehensive Software-as-a-Service (SaaS) product designed to provide organizations with a powerful platform for managing their digital experiences. As a developer, you can start learning easily by fork the following project https://github.com/sitecorelabs/xmcloud-foundation-head.
To set up XM Cloud, please follow the instructions provided in the README file. One of the commands you need to run is the init command, which will generate keys for secure HTTPS connections. After running this command, you may notice that changes have been made to your .env file.
Please refer to the README file for detailed instructions on how to run the init command and this update your .env variables accordingly. 
To complete the setup process, execute the up.ps1 script. This script will download the necessary files and create local Docker containers for XM Cloud. Running the script will ensure that all the required components are set up correctly and ready for use.
I’m taking by .NET developer persepective, venturing into the world of XM Cloud, there are a few key things you’ll need to learn and familiarize yourself with:
  • Be familiar with React Lifecycle. Understanding the React component lifecycle is essential for working with XM Cloud, as it is built on React and Next.js.
    • 


  • TypeScript: TypeScript is a statically-typed superset of JavaScript, and it’s beneficial to learn its syntax and features. W3Schools offers documentation and tutorials for TypeScript, providing a comprehensive resource to get you up to speed with the fundamentals. 
    • 


  • Next.js Documentation: Next.js is the framework used in XM Cloud, and familiarizing yourself with its documentation is crucial. The Next.js documentation provides detailed information on concepts, features, and best practices for building applications with Next.js.
    • 


  • Sitecore Documentation: Sitecore, the company behind XM Cloud, provides valuable documentation and resources to help you ramp up on their platform.
By focusing on these resources, you’ll gain a solid foundation for working with XM Cloud.
Here are some observations and key points to keep in mind while working with Next.js and XM Cloud:
  • In the context of Sitecore MVC (Model-View-Controller), you typically use “Controller Rendering” to render dynamic content on web pages. Similarly, in Next.js, you can achieve similar functionality using “Server-Side Rendering (SSR)” or “Static Site Generation (SSG)” techniques by using a “Json Rendering” Template in Sitecore.
    • 


  • If you have been using TDS for Sitecore development, you can leverage Sitecore Serialization for Visual Studio as an alternative. It offers similar functionality to TDS, allowing you to manage Sitecore items using serialization. Sitecore Serialization for Visual Studio integrates with Visual Studio IDE and provides a user-friendly interface for working with serialized items.
    • 


  • Alternatively, you can use Sitecore Serialization from the command line, which offers a similar experience to Unicorn. Sitecore CLI integrates with Sitecore Serialization and provides commands for serialization tasks, allowing you to automate item serialization operations from the command line.
    • 


  • In traditional .NET Framework, the logic for retrieving data and preparing it for rendering is typically handled in controllers. However, in Next.js, you can achieve similar functionality by utilizing the getStaticProps function. 
    • 


  • In Next.js, the term “model” is not commonly used as a specific concept. Instead, the focus is on React components and the data passed to these components as props. The props represent the data and behavior that are passed from a parent component to its child component. By defining the expected props fields, you establish a contract for the data that should be passed to the component.
    • 


  • The view is represented by the React components that define the structure and rendering logic of the user interface. These components are responsible for rendering data, managing local state, and defining the appearance and behavior of the UI elements.
    • 


  • In the Sitecore .NET framework, Sitecore.Context.Item is used to access the current item being processed. In contrast, in Next.js with Sitecore implementation, the equivalent would be accessing the route information through layoutData.sitecore.route. or sitecoreContext.route
Based on my learning experience, I’ve been working with Richard Cabral (developer of constellation4sitecore for .NET MVC Solution) in a framework that eliminates the complexities often associated with integrating Next.js and Sitecore (SXA), providing you with a smooth development experience.
This framework is in beta version and consist in the following features:
  • @constellation4sitecore/foundation-labels: It is an alternative of dictionaries, this helps you to consolidate all translatable texts for a component in one place.
    • 


  • @constellation4sitecore/foundation-data: This package helps you to access item information easily for example: getItem(itemId), derivedFrom(itemId, ‘BASE TEMPLATE ID’), getTemplateInfo(itemId) which perform graphql queries for you.
    • 


  • @constellation4sitecore/foundation-mapper: Foundation mapper contains helpers for maping fields based on Graphql structure to a props fields structure. 
    • 


  • @constellation4sitecore/feature-navigation: A set of templates to easily build a navigation using Next.js. More examples comming up.
In the coming weeks, I will be posting more detailed documentation and helpful samples on how to effectively use our project. These resources will serve as valuable references for developers who are interested in leveraging our work. So, stay tuned for updates and get ready to dive into the exciting world of our project. Happy coding and exploring the possibilities it offers! If you have any questions or need assistance, please don’t hesitate to reach out.
								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
Enable FEaaS Components in XM Cloud


			
		    
		    

					
10 April, 2023


			    

									
Sitecore, XM Cloud

								
		    


		
 

		
			


				
Sitecore Components are designed to be modular, reusable, and customizable, allowing users to create websites quickly and easily by combining and configuring these components in different ways.
If you are trying Sitecore Components in early access and you started your xm cloud project before Sitecore Components, early access were released and when you try to add a component in your xm cloud site. You see an error that said: “The component cannot be dropped into this placeholder”. It is necessary that you update your solution from https://github.com/sitecorelabs/xmcloud-foundation-head
If you are starting a new project you can skip this quick tutorial, because FEaaSWrapper already exists into the starter kit.
Step 1: Verify that FEaaSWrapper.tsx exists under components folder
The easy way to fetch this files is to pull the latest from xmcloud-foundation-head (master) branch.
Otherwise, create a new file FEaaSWrapper.ts and copy the content with
https://github.com/sitecorelabs/xmcloud-foundation-head/blob/main/src/sxastarter/src/components/FEaaSWrapper.tsx
import { FEaaSComponent, FEaaSComponentProps } from '@sitecore-jss/sitecore-jss-nextjs';
import React from 'react';

export const Default = (props: FEaaSComponentProps): JSX.Element => {
  const styles = `component feaas ${props.params?.styles}`.trimEnd();
  const id = props.params?.RenderingIdentifier;

  return (
    <div className={styles} id={id ? id : undefined}>
      <div className="component-content">
        <FEaaSComponent {...props} />
      </div>
    </div>
  );
};




Step 2: Verify that you have FEaaS Available Renderings item
As I mentioned if your solution does not have FEaaS out-of-the-box it is probably that your solution is out-to-date.
To fix this you can right-click and add Available Renderings item and name it “FEaaS”
Finally all you need to do is add FEaaS Wrapper component as Available Rendering which is located in the following path: /sitecore/layout/Renderings/Foundation/JSS Experience Accelerator/FEaaS/FEaaS Wrapper
Right now if you go back to Sitecore Pages and try to add FEaaS Componet you are able to do it.
								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
Troubleshooting: XDB Certificates on CD Server


			
		    
		    

					
7 December, 2022


			    

									
Sitecore

								
		    


		
 

		
			


				
It is very common that at some point your certificates expires and you need to renew your certificates. A common issues that I saw in projects is the following error:
The certificate was not found. Store: My, Location: LocalMachine, FindType: FindByThumbprint, FindValue: [YOUR-Thumprint-Value-Here], InvalidAllowed: False.
Source: Sitecore.Xdb.Common.Web



If you have a CM in one Server and CD server in another server. It is probably that you forgot to install the xconnect certificate in CD server.


You can run the following commands to validate if you have correctly installed the certificate for each server.


On CM Server run


Get-ChildItem  -Path Cert:\LocalMachine\MY | Where-Object {$_.Thumbprint -Match "[YOUR-Thumprint-Value-Here]"}



If you see a result then you can conclude that certificate is installed on CM server assuming that connect is installed in the same server.


Then you can check the same on CD server:


Get-ChildItem  -Path Cert:\LocalMachine\MY | Where-Object {$_.Thumbprint -Match "[YOUR-Thumprint-Value-Here]"}



If you noticed that you get no results, then you need to perform the following steps:


    

  1. Open Manage computer certificates in CM server.
    2. 

  2. Go to Personal -> find the certificate that match your thumprint.
    3. 

  3. Export Certificate
    4. 



4. Move the file to the CD server
5. Install Certificate on Local Machine in Personal folder.
6. Grant Read access to the application app pool.
7. Recycle application pool and check your logs again.
Note: Be sure that thumbprint matches in CD server you can check the file ConnectionStrings.config to confirm that thumbprint is same as you certificate installed.
I hope that helps you to troubleshooting your certificates issues.
								

							

						
			Read more			
						


		
	
 
		



 
                                            
                            


		


	


		


			
			    
[Workaround] XM Cloud: Error building sample Next.js app


			
		    
		    

					
29 November, 2022


			    

									
Sitecore, Sitecore JSS, XM Cloud

								
		    


		
 

		
			


				
I started an XM Cloud project using Next.js as Rendering Host. I added some Graphql code, but when I want to run jss build I got an error similar to the next one. https://sitecore.stackexchange.com/questions/33141/error-during-build-of-sample-next-js-app
./src/components/graphql/GraphQL-ConnectedDemo.dynamic.tsx:114:72
Type error: Argument of type 'TypedDocumentNode<ConnectedDemoQueryQuery, Exact<{ datasource: string; contextItem: string; language: string; }>>' is not assignable to parameter of type 'string | DocumentNode'.
  Type 'TypedDocumentNode<ConnectedDemoQueryQuery, Exact<{ datasource: string; contextItem: string; language: string; }>>' is not assignable to type 'DocumentNode'.
    Types of property 'kind' are incompatible.
      Type '"Document"' is not assignable to type 'Kind.DOCUMENT'.



Environment


    

  • @sitecore-jss/sitecore-jss-nextjs: "^21.0.0"
    • 

  • @sitecore-jss/sitecore-jss-cli: "^21.0.0"
    • 

  • XM Cloud
    • 



After some research I found a workaround. I know this is not the best solution. But if someone else know how to fix this issue please, feel free to leave a comment.


Workaround


In order to stop the type error, I wrap the Graphql call into a js file.
index.js


 export async function myFunctionToExecuteQuery
{
.... some code here
 const result = await graphQLClient.request(MyQueryDocument, {
    myParam: myParam,
  });

return result;
}



Then I added an index.d.ts to declare the types.


export declare async function myFunctionToExecuteQuery<TResult>(
  myParam: string
): Promise<TResult| null>;




With that workaround I can still declare the query result type, and also run jss build without any error.


As I mentioned, this is not the best solution, but I can build the Next.js application successfully.


								

							

						
			Read more