
In this blog post, we will explore a common requirement in Sitecore Headless SXA, exposing site-specific settings and global data to the front end when working with a JSS headless site.

## Problem Statement

When building headless JSS sites, you often need to expose certain site settings or global configuration data from the Sitecore SXA Settings node to the front-end. However, the out-of-the-box Sitecore Layout Service primarily focuses on delivering route details (placeholders, data sources, fields, etc.), which may not fully cover the broader configuration needs.

In such cases, using GraphQL to query site-specific settings and integrating the results into the page-props is a reliable approach.

### The Solution

To address this requirement, we can extend the Sitecore page-props to include site-specific settings. The approach involves:

1. Extending the `SitecorePageProps` type to include site settings.
2. Creating a GraphQL service to query and fetch the settings items.
3. Adding a new plugin to the page-props-factory to populate the site settings into the props for every page.

Let's walk through the implementation step-by-step.

## Implementation Steps

### Step 1: Extend the `SitecorePageProps` Type

The first step is to extend the `SitecorePageProps` type to include a new property for site settings. We modify the `src/types/props/page-props.ts` file and add a new variable:

<Code language="typescript">
{`export type SitecorePageProps = {
  site: SiteInfo;
  locale: string;
  dictionary: DictionaryPhrases;
  componentProps: ComponentPropsCollection;
  notFound: boolean;
  layoutData: LayoutServiceData;
  headLinks: HTMLLink[];
  SiteConfigurations: SiteSettingFields;
};`}
</Code>

Here, we introduce a new property called `SiteConfigurations` of type `SiteSettingFields`, which will hold the site settings data.

### Step 2: Create a GraphQL Service to Fetch Settings

Next, we create a service to handle GraphQL queries and fetch the settings fields. We’ll create a new file called `settings-service.ts` inside `src/lib/page-props-factory/services`.

<Code language="jsx">
{`import { GraphQLClient } from '@sitecore-jss/sitecore-jss';
import { debug, GraphQLLayoutService, GraphQLLayoutServiceConfig, LayoutServiceData } from '@sitecore-jss/sitecore-jss-nextjs';

export class GraphQLSettingsService extends GraphQLLayoutService {
  private myGraphQLClient: GraphQLClient;

  constructor(public serviceConfig: GraphQLLayoutServiceConfig) {
    super(serviceConfig);
    this.myGraphQLClient = this.getGraphQLClient();
  }

  public async fetchSettings(siteName: string, language: string): Promise<LayoutServiceData> {
    const query = this.getQuery(siteName, language);
    
    const data = await this.myGraphQLClient.request<{
      sitesettings: {
        item: {
          contentRoot: {
            children: SiteSettingFields;
          };
        };
      };
    }>(query);

    return data.item.rendered;
  }

  private getQuery(siteName: string, language: string) {
    return \`query {
      sitesettings: layout(site: "\${siteName}", routePath: "/", language: "\${language}") {
        item {
          contentRoot: parent {
            children(includeTemplateIDs: "{54BC031B-293F-46F6-8F98-CB4A9B37BDE2}") {
              results {
                sampleField: field(name: "sampleField") {
                  jsonValue
                }
              }
            }
          }
        }
      }
    }\`;
  }
}`}
</Code>

In this example:

- We use the `GraphQLClient` to execute a query against the Sitecore GraphQL endpoint.
- The query retrieves the children of the settings node, filtering by template ID (`{54BC031B-293F-46F6-8F98-CB4A9B37BDE2}`) and selecting the relevant fields.
- The `sampleField` is an example field from the settings that we want to expose.

This service is designed to fetch the site settings from the settings node, specifically tailored for each site.

### Step 3: Add a New Plugin to the Page-Props Factory

Now, we integrate the site settings into our page-props using a custom plugin. We create a file called `get-settings.ts` inside `src/lib/page-props-factory/plugins`:

<Code language="typescript">
{`import { GetStaticPropsContext, GetServerSidePropsContext } from 'next';
import config from 'temp/config';
import { Plugin } from '..';
import { GraphQLSettingsService } from '../services/settings-service';
import { SitecorePageProps } from 'lib/page-props';
import clientFactory from 'lib/graphql-client-factory';

class GetSiteSettingsPlugin implements Plugin {
  private settingsRequestClient: GraphQLSettingsService;

  constructor() {
    const siteName = config.sitecoreSiteName;
    this.settingsRequestClient = new GraphQLSettingsService({
      siteName,
      clientFactory,
      retries: (process.env.GRAPH_QL_SERVICE_RETRIES && parseInt(process.env.GRAPH_QL_SERVICE_RETRIES, 10)) as number,
    });
  }

  order = 2;

  async exec(props: SitecorePageProps, context: GetServerSidePropsContext | GetStaticPropsContext) {
    const siteSettings = await this.settingsRequestClient.fetchSettings(
      props?.site?.name,
      props.locale
    );

    if (siteSettings != null && props != null) {
      props.SiteConfigurations = siteSettings ?? {};
    }

    return props;
  }
}

export const getSiteSettingsPlugin = new GetSiteSettingsPlugin();`}
</Code>

### Plugin Explanation

- **Order Property**: The `order = 2` ensures that this plugin runs after the core plugins (e.g., `normal-mode` and `preview-mode`). This is crucial because it allows us to populate the settings data before any layout data is processed.

- **Settings Fetching**: We call the `fetchSettings` method to retrieve the settings data based on the site name and locale. The resulting data is stored in the `SiteConfigurations` property within `props`, making it accessible across the application.

### Optimization Considerations

Since this GraphQL query runs on every page render, caching the results is recommended to avoid redundant requests and improve performance. Implementing caching at either the service or plugin level can significantly optimize the solution.

## Conclusion

This approach gives you a clean and extensible way to expose site settings from the SXA settings node to your Next.js frontend. By integrating GraphQL queries into the page-props factory and leveraging custom plugins, we can make site configurations accessible across every page in the application.

Feel free to enhance this solution further with caching strategies or by extending the settings to include more complex data structures. Happy coding!

Exposing Site Settings from the Settings item in a Headless JSS Next.js Application


Recently, while working with a Sitecore 10.4 deployment in an Azure environment, we encountered an interesting challenge: handling Sitecore Content Management (CM) and IdentityServer (SI) behind a proxy/CDN setup using Azure Application Gateway. The DNS configuration was managed at the Application Gateway level. Here’s how we resolved the issue.

### The Setup

In this scenario, the public URLs were routed through Azure Application Gateway before reaching the internal Sitecore servers:

- **User Request (CM):** `https://cm.cdn.xyz.com`  → Azure Application Gateway → `https://cm.xyz.com` (internal CM URL)

However, this setup presented some issues, as Sitecore’s out-of-the-box configuration isn’t fully equipped to handle such complex routing seamlessly.

### Issue

**Misalignment in URLs:** The login redirects and callbacks during authentication often landed on the internal URLs (`https://cm.xyz.com`) rather than staying within the proxy URLs (`https://cm.cdn.xyz.com`), and hence produces invalid request error.

![image](/images/post/sc-si-auth-error.png)

### The Three-Step Solution

To resolve these issues, a three-step solution was implemented:


#### 1. **Install the "Application Gateway Host Rewrite" Extension**

The first step is to ensure that the host headers are correctly rewritten so that Sitecore picks up the appropriate URLs. We installed the **Application Gateway Host Rewrite** extension on the CM App Service. This extension allows the Azure Application Gateway to rewrite the host headers for incoming requests, ensuring that IdentityServer4 picks up the correct host (`https://cm.cdn.xyz.com`), even after the requests have passed through the gateway.


#### 2. **Update Sitecore Identity Server confguration**

The next step involves updating the Sitecore Identity Server configurations to allow communication from all relevant domains.

1. Open the `\Config\production\Sitecore.IdentityServer.Host.xml` file in the Sitecore Identity Server site root.
2. Locate the `<AllowedCorsOrigins>` tag and update it to include all the necessary domains that need to communicate with IdentityServer. Separate each domain using the `|` symbol.

For example, in an Azure QA environment with both CM and CD app services, the configuration might look like this:

<Code language="xml">
{`<AllowedCorsOrigins>
  <AllowedCorsOriginsGroup1>https://cm.xyz.com|https://cm.cdn.xyz.com</AllowedCorsOriginsGroup1>
</AllowedCorsOrigins>`}
</Code>

#### 3. **Add a Rewrite Rule in CM’s `web.config`**

Lastly, we added a rewrite rule in the `web.config` of the Content Management instance to handle URL rewrites correctly for outbound responses. Here’s the rule that was applied:

<Code language="xml">
{`<system.webServer>
  <rewrite>
    <outboundRules>
      <rule name="HttpToHttpsOutbound" preCondition="IsRedirect">
        <match serverVariable="RESPONSE_Location" pattern="^http://cm.xyz.com/(.*)" />
        <action type="Rewrite" value="https://cm.cdn.xyz.com/{R:1}" />
      </rule>
      <preConditions>
        <preCondition name="IsRedirect">
          <add input="{RESPONSE_STATUS}" pattern="3\d\d" />
        </preCondition>
      </preConditions>
    </outboundRules>
  </rewrite>
</system.webServer>`}
</Code>

This rule ensures that any HTTP redirect responses are transformed to use the correct HTTPS endpoint (`https://cm.cdn.xyz.com`) and that the responses maintain consistency with the proxied URL.

### Wrapping Up

By leveraging the **Application Gateway Host Rewrite** extension and carefully configuring rewrite rules, we were able to seamlessly integrate Sitecore CM and IdentityServer in a complex proxy/CDN environment. These adjustments allowed the client’s Sitecore environment to maintain consistent URLs throughout the authentication flow, improving the user experience and eliminating issues caused by internal vs. external URL mismatches.

This setup highlights the importance of understanding how Sitecore’s configurations interact with reverse proxies and CDNs, especially when dealing with environments hosted in Azure.

Handling Sitecore CM and IdentityServer Behind a Proxy or CDN in an Azure Environment


In the composable world of modern Sitecore solutions, integrating search appliances like Coveo with digital asset management tools such as Sitecore Content Hub is common practice. One typical use case involves building Coveo search sources to index content stored in Sitecore Content Hub. These indexes can then be used to create rich front-end search experiences.


### Use Case: Indexing Approved PDFs with Public URLs

In this post, we explore a scenario where we needed to index only approved PDF documents from Content Hub that have public URLs. We leveraged the Scroll API to retrieve and process a large number of results efficiently.

#### Using the Scroll API

The Scroll API is a powerful tool for retrieving extensive results from a single query without the limitations of traditional pagination. Unlike standard queries, it does not support the `skip` parameter and relies on retrieving the next page through the resource link. This allows continuous paging until no more results are available.

Here’s the Scroll API query we used:

```http
GET /api/entities/scroll?query=Definition.Name=='M.Asset' AND Parent('AssetMediaToAsset').id==1057 AND Parent('FinalLifeCycleStatusToAsset').id==544&sort=createdOn&order=Asc
```

This query retrieves assets defined as `'M.Asset'` and filters them to those associated with specific media and lifecycle status IDs.

#### Filtering for Approved PDFs

To further refine our results to only include approved PDF assets, we used the following filters:

- **PDF Assets**: `Parent('AssetMediaToAsset').id==1057`
- **Approved Assets**: `Parent('FinalLifeCycleStatusToAsset')==544`

Adding these filters to our query ensured that only approved PDF assets were returned. Although these IDs are typically standard across all Content Hub instances, it's important to verify them in your own Content Hub instance before using them in queries. You can locate the asset media type IDs under Taxonomy Management within Content Hub.

#### Retrieving Public URLs of an Asset

To include the public URLs of the PDFs in the index, we had to call additional APIs. For each asset returned by the Scroll API, we used the following endpoint to get all API URLs of the public links:

```http
GET /api/entities/{assetId}/relations/AssetToPublicLink
```

The response provides the actual API links needed to obtain the public URL. Here’s an example response:

```json
{
    "children": [
        {"href": "/api/entities/303872"},
        {"href": "/api/entities/235003"}
    ],
    "inherits_security": true,
    "self": {"href": "/api/entities/31999/relations/AssetToPublicLink"}
}
```



We then called each API link to retrieve the public URL.

### Indexing Data into Coveo Using Push APIs

#### Step 1: Create the File Container

1. **Obtain Access Token**: Ensure it has `Privileges / Organization / Organization = View`.

2. **Gather Information**:
   - **OrganizationId**: Found in your Coveo Platform.
   - **useVirtualHostedStyleUrl**: Set to `true`.

3. **Create File Container**:
   - **POST Request**:
     ```http
     POST https://api.cloud.coveo.com/push/v1/organizations/<OrganizationId>/files?useVirtualHostedStyleUrl=true
     Content-Type: application/json
     Accept: application/json
     Authorization: Bearer <AccessToken>
     ```
   - **Response**: Contains `uploadUri`, `fileId`, `requiredHeaders`.

#### Step 2: Upload Data to File Container

1. **Prepare JSON Data**: Structure your data using the `addOrUpdate` array.
   ```json
   {
       "addOrUpdate": [
           {
               "m_title": "Example Title",
               "m_overview": "Description",
               "documentId": "http://example.com",
               "data": "Content",
               "fileExtension": ".txt"
           }
       ]
   }
   ```

2. **Upload Data**:
   - **PUT Request**:
     ```http
     PUT <uploadUri - From Step 1>
     Content-Type: application/octet-stream
     x-amz-server-side-encryption: AES256
     ```
   - **Body**: Your JSON data.

#### Step 3: Push File Container to Push Source

1. **Push Data**:
   - **PUT Request**:
     ```http
     PUT https://api.cloud.coveo.com/push/v1/organizations/<OrganizationId>/sources/<SourceId>/documents/batch?fileId=<fileId>
     Content-Type: application/json
     Authorization: Bearer <AccessToken>
     ```

2. **Response**: Should be `null` with a `202 Accepted` status if successful.



### Pseudo Implementation

With the necessary data gathered, we could proceed to index the content into Coveo. Below is a sample implementation in C#:

<Code language="c#">
{`public void Process(string apiUrl, bool recursive = true)
{
    // Calling scroll API, and parse the API response into relevant model
    var contentHubItems = GetContentHubAssets(apiUrl);

    // Process each item in contentHubItems  
    foreach (var item in contentHubItems)
    {
        try
        {
            // Get Public link of the content hub Item
            var publicLink = GetAssetPublicLink(item.assetToPublicLink);
            
            // Parse content hub item required information to coveo model
            List<CoveoItem> coveoItemsModel = new List<CoveoItem>();
            CoveoItem coveoObject = GetCoveoObject(publicLink, item);
            coveoItemsModel.Add(coveoObject);
        }
        catch (Exception ex)
        {
            // Log Error
        }
    }

    // Try to push items to Coveo
    if (coveoItemsModel.Count > 0)
    {
        var coveoIPushModel = new CoveoItemsModel
        {
            addOrUpdate = coveoItemsModel
        };
        
        var containerInfo = CoveoHelper.CreateFileContainer();
        CoveoHelper.UploadConetntsToContainer(containerInfo.uploadUri, containerInfo.requiredHeaders.XAmzServerSideEncryption, coveoIPushModel);
        CoveoHelper.PushContainerToSource(containerInfo.fileId, containerInfo.requiredHeaders.XAmzServerSideEncryption);
    }

    // Recursively process next page if recursive flag is true
    if (recursive && contentHubItems.next != null && !string.IsNullOrEmpty(contentHubItems.next.href))
    {
        Process(contentHubItems.next.href);
    }
}`}
</Code>

### Conclusion

By leveraging the Scroll API and additional API calls for public URLs, we were able to effectively index approved PDF documents from Sitecore Content Hub into Coveo. This approach ensures that only the necessary and approved assets are indexed, optimizing the search experience.

Feel free to use and adapt this approach for your own Sitecore Content hub and Coveo integrations. 

Indexing Sitecore Content Hub Assets in Coveo: A Practical Guide


The Sitecore Search SDK Starter Kit provides a powerful foundation for developers to build robust and user-friendly search functionalities into their websites. This open-source project offers a significant advantage by streamlining the integration of Sitecore Search with React based applications. Recently, I have made few enhancements to the forked GitHub repository (https://github.com/Sitecore/Sitecore-Search-JS-SDK-Starter-Kit) that aim to improve the overall search experience for end users and provide developers with a more efficient development workflow.


### Modular Component Architecture for Improved Maintainability and Reusability
A core aspect of the enhancements involves restructuring the codebase to utilize separate components for facets, pagination, sorting, and search results. This shift towards a modular component architecture offers several advantages:

![image](/images/post/starter-kit-enhancements/modular-approach.png)

#### Enhanced Maintainability:

Separating components fosters a well-organized codebase. This improves code readability and understanding, making it easier for developers to maintain and extend the functionalities in the future.

#### Increased Reusability:

Individual components can be reused across different parts of your application. This promotes code consistency and reduces development time by eliminating the need to rewrite code for similar functionalities.

### Facet Refinement

Finding the exact product or information can be challenging, especially when dealing with a vast number of facets. To address this, I've introduced "show more" and "show less" functionality for facets. This allows users to control the number of facets displayed at once, preventing them from feeling overwhelmed by an excessive number of options. Additionally, facet filtering has been implemented, enabling users to refine their search results with greater precision.

![image](/images/post/starter-kit-enhancements/facets-improvement.png)


This following component, FacetList, renders a list of facet values with filtering capabilities and a show more/show less feature. It receives props such as selectedFacetsToRender, facet, and facetsnumbertoshow, and dynamically filters the facet values based on user input. The component allows users to toggle the visibility of facet values and efficiently manage large lists by displaying only a subset at a time.

<Code language="tsx">
{`import { CheckIcon } from '@radix-ui/react-icons';
import type { SearchResponseFacet } from '@sitecore-search/react';
import { AccordionFacets } from '@sitecore-search/ui';
import { useEffect, useState } from 'react';
import type { SelectedFacets } from '../Facets';
import { AccordionFacetsStyled } from '../styled';
export interface FacetListType {
  facet: SearchResponseFacet;
  selectedFacetsToRender: SelectedFacets[];
  facetsnumbertoshow: number;
}

export const FacetList = ({ selectedFacetsToRender, facet, facetsnumbertoshow }: FacetListType) => {
  const isSelected = (facetID: string, facetValue: string) => {
    return (
      selectedFacetsToRender.filter(
        (x) => x.id === facetID && x.values.map((q) => q.id).includes(facetValue)
      ).length > 0
    );
  };

  const minNumberOfItemsToShow = facetsnumbertoshow ?? 5;
  const totalItems = facet.value.length;
  const [keyword, setKeyword] = useState('');
  const [filteredItems, setFilteredItems] = useState(facet.value);
  const [numberOfItemsToShow, setNumberOfItemsToShow] = useState(minNumberOfItemsToShow);

  useEffect(() => {
    // This will be called whenever parentProp changes (i.e., when the parent component rerenders)
    setFilteredItems(facet.value);
  }, [facet.value]);

  const handleInputChange = (event: { target: { value: string } }) => {
    const inputKeyword = event.target.value.toLowerCase();
    setKeyword(inputKeyword);

    // Filter the array based on the input keyword
    const updatedItems = facet.value.filter((item) =>
      item.text.toLowerCase().includes(inputKeyword)
    );
    setFilteredItems(updatedItems);
  };

  const handleShowMore = () => {
    setNumberOfItemsToShow((prevVisibleItems) => prevVisibleItems + minNumberOfItemsToShow);
  };

  const handleShowLess = () => {
    setNumberOfItemsToShow((prevVisibleItems) =>
      Math.max(prevVisibleItems - minNumberOfItemsToShow, minNumberOfItemsToShow)
    );
  };

  return (
    <>
      <AccordionFacetsStyled.Facet facetId={facet.name} key={facet.name}>
        <AccordionFacets.Content>
          <div className="input_wrap">
            <input
              name={facet.name}
              placeholder="Type to filter..."
              id={facet.name}
              type="text"
              value={keyword}
              onChange={handleInputChange}
            />
          </div>
          <AccordionFacetsStyled.ValueList>
            {filteredItems.slice(0, numberOfItemsToShow).map((v, index) => (
              ...
            ))}
          </AccordionFacetsStyled.ValueList>

          {filteredItems.length > minNumberOfItemsToShow && (
            <div className="retractable-actions">
              {numberOfItemsToShow < totalItems && (
                <a href="#" className="retractable-toggle"
                  onClick={(e) => {
                    e.preventDefault();
                    handleShowMore();
                  }} > Show More{' '}
                </a>
              )}
              <br />
              {numberOfItemsToShow > minNumberOfItemsToShow && (
                <a href="#" className="retractable-toggle"
                  onClick={(e) => {
                    e.preventDefault();
                    handleShowLess();
                  }} > {' '} Show Less
                </a>
              )}
            </div>
          )}
        </AccordionFacets.Content>
      </AccordionFacetsStyled.Facet>
    </>
  );
};

export default FacetList;`}
</Code>

### Sharable Search Queries

Imagine collaborating with colleagues on research or revisiting a complex search later. The implemented mechanism to append facet selections and page numbers to the query string makes this a reality. Users can now generate URLs that include preselected facets and specific pages, Simply revisit the shared URL, and your desired search criteria are instantly applied.

![image](/images/post/starter-kit-enhancements/searh-query.png)

Following is the function responsible to generate query string and append in Query string, called when any facet value is clicked.

This TypeScript function, manages the modification of facet-related search parameters in a URL query string. It parses the current query parameters, updates facet values based on user actions (such as selecting or deselecting options), and generates an updated URL with the modified parameters, ultimately navigating to the new URL

<Code language="tsx">
{`const updateFacetsSearchParams = (params: any, remove = false) => {
    const queryParams = new URLSearchParams(location.search);
    const searchParamsObject = paramsToObject(queryParams.entries()) as any;
    let values = searchParamsObject[params.facetId]?.split(',') ?? [];
    values = values.filter((n: any) => n);
    if (remove || params.checked === false) {
      const index = values.indexOf(params.facetValueId);
      if (index > -1) {
        values.splice(index, 1);
      }
    } else {
      values.push(params.facetValueId);
    }
    if (values.length <= 0) {
      delete searchParamsObject[params.facetId];
    }
    delete searchParamsObject.page;
    searchParamsObject[params.facetId] = removeDuplicates(values).join(',');
    const updatedRelativeUrl = generateQueryString('/search', searchParamsObject);
    navigate(updatedRelativeUrl);
  };`}

</Code>

### Open-Source Contribution and Continued Development

All of the enhancements mentioned above are included in a pull request submitted to the forked GitHub repository: https://github.com/mgnventures/Sitecore-Search-TS-SDK-Starter-Kit/pull/1 . This pull request provides a detailed overview of the changes and facilitates the integration of these improvements into the forked Sitecore Search SDK Starter Kit.

I believe these enhancements will significantly improve the Sitecore Search SDK Starter Kit, providing developers with a more efficient development experience and empowering users with a more intuitive and productive search experience. If you're interested in learning more or contributing to this project, feel free to visit the GitHub repository.


Sitecore Search SDK Starter Kit: Enhanced User Experience


In this blog post, I'll walk you through the process of smoothly leveraging the Search SDK Starter Kit into a Sitecore Next.js solution.

## Prerequisites
Before proceeding, ensure the following prerequisites are met:

- A Sitecore search account with initial configuration set up on Customer Engagement Console (CEC).
- Sitecore headless Next.js solution running on your local environment.
- Installation of necessary packages:

<Code language="jsx">
{`npm install --save @sitecore-search/react
npm install --save @sitecore-search/ui
npm install --save styled-components`}
</Code>

### Configuration Steps

#### 1. Create Source in CEC

Follow the steps outlined in the [official documentation](https://doc.sitecore.com/search/en/users/search-user-guide/configuring-a-source.html) to create a source in CEC.

#### 2. Configure Suggestions Blocks

Ensure that suggestions blocks have a field named `title_context_aware`. Refer to the [documentation](https://doc.sitecore.com/search/en/users/search-user-guide/create-auto-complete-functionality-using-suggestions-blocks.html) for configuration details.

#### 3. Setup Sorting Options

Configure sorting options to include `featured_desc` and `featured_asc` criteria as per the [documentation](https://doc.sitecore.com/search/en/users/search-user-guide/walkthrough--adding-the-option-to-sort-by-top-views.html).

#### 4. Preconfigured Widgets

Ensure that the following widgets are created beforehand:
- Search Results Page
- Search Results
- Preview Search

### Code Leveraging Steps

1. Download or clone the Sitecore Search SDK Starter Kit repository.
2. Copy the following folders from the starter kit's `src` folder to your Sitecore Next.js solution's `src` folder:
   - Contexts
   - Data
   - Hocs
   - Hooks
   - Themes

![image](/images/post/starter-kit/sk-1.jpg)

3. Create a new folder named `widgets` in your solution and copy the `PreviewSearch` and `SearchResults` folder along with `Utils.tsx` file from the starter kit.

![image](/images/post/starter-kit/sk-2.jpg)

4. We might face formatting issue in our copied tsx files, for this we can update `.prettierrc` file to handle formatting issues, set the `endOfLine` value to `auto`

![image](/images/post/starter-kit/sk-3.jpg)

5. Create environment variables in the `.env` file:
   
<Code language="dotenv">
{`NEXT_PUBLIC_SEARCH_CUSTOMER_KEY=<customer-key>
NEXT_PUBLIC_SEARCH_API_KEY=<api-key>
NEXT_PUBLIC_SEARCH_ENV=prod`}
</Code>

6. Update the `_app.tsx` file to integrate the widget provider.

Add necessary imports.

<Code language='tsx'>
{`import { LanguageContext } from 'src/contexts/languageContext';
import useLanguage from 'src/hooks/useLanguage';`}
</Code>

add following const in within the main function.
<Code language='tsx'>
{`const { language, setLanguage } = useLanguage();`}
</Code>


Wrap language context and widget provider with `<I18nProvider />` and Supply environment variables for customer key and API key, final outcome should look like as shown in the screenshot below:

<Code language="jsx">
{`<LanguageContext.Provider value={{ language, setLanguage }}> 
  <WidgetsProvider 
    env={process.env.NEXT_PUBLIC_SEARCH_ENV as Environment} 
    customerKey={process.env.NEXT_PUBLIC_SEARCH_CUSTOMER_KEY} 
    apiKey={process.env.NEXT_PUBLIC_SEARCH_API_KEY} 
    publicSuffix={true}>
      <I18nProvider lngDict={dictionary} locale={pageProps.locale}> </I18nProvider> 
  </WidgetsProvider> 
</LanguageContext.Provider>`}
</Code>


7. Replace references to `react-router-dom` with `@sitecore-jss/sitecore-jss-nextjs` in `Styled.ts` file under `SearchResults` widget folder.

8. Replace `useNavigate` import from `react-router-dom` with `next/router` and fix all references accordingly, whereever it is being used.

9. Create a Search rendering in Sitecore and implement it in your Next.js solution.
   - Create a `Search.tsx` file under `components/search` folder.
   - Call the Search results widget in the `Search.tsx` file.
   - Wrap the export with `withPageTracking` hoc, this will enable tracking user analytics.
   - Example implementation:

<Code language="jsx">
{`import withPageTracking from 'src/hocs/withPageTracking';
import SearchResults from 'src/widgets/SearchResults';

const Search = (): JSX.Element => {
  return <SearchResults key={'search'} rfkId="rfkid_7" defaultKeyphrase={''} />;
};

export default withPageTracking(Search);`}
</Code>

Now, you're ready to drop the search component on any page from the Experience Editor and enjoy the final outcome if the source and facets are configured properly in the CEC portal.

![image](/images/post/starter-kit/sk-5.jpg)

## Conclusion

By following these steps, you can seamlessly leverage the Sitecore Search SDK Starter Kit into your Sitecore Next.js solution. With proper configuration and implementation, you can enhance search functionality and improve user experience, and update the styling of search components as per the site theme.






Leveraging Sitecore Search SDK Starter Kit into Your Sitecore Next.js Solution [Part 2]


Moving to a new Coveo Cloud organization can be a strategic step for your business. But what about the customizations and data you've built up in your dev or QA organization? This post will guide you through the process of migrating changes between Coveo cloud organizations.

### Understanding the Need for Migration
- Collaboration between developers and system administrators often involves experimentation and configuration changes.
- As deployments grow, efficient migration between Coveo organizations becomes crucial for consistency.
- Replicating production settings for new development iterations requires a streamlined migration process.


### Migrating Your Configuration with Resource Snapshots
Coveo's Resource Snapshot feature allows you to take control of your migration. With snapshots, you can copy the configuration of various resources, including:

- Query pipelines
- Indexing pipeline extensions
- Hosted search pages
- Coveo Machine Learning models

This lets you quickly set up your new organization with the same functionality as your dev or qa oraganizations.

### Important Considerations for Snapshots

While snapshots are a powerful tool, it's important to understand their limitations:

- Not all resource types are currently supported.
- Coveo does not offer an automated process to migrate organization data (such as user data).
- The snapshot can only copy the top 1,000 query suggestions from your old organization.
- Data like Usage Analytics cannot be migrated.

### Professional Services: A Seamless Migration Option

For a more comprehensive migration experience, consider leveraging Coveo Professional Services. Coveo team can handle the entire process, ensuring a smooth transition with minimal disruption.

#### Creating a Snapshot
- Begin by creating a snapshot of resources in the source organization to capture the current configurations.

![image](/images/post/coveo-create-snapshot.png)

- Choose to include dependencies automatically to ensure all necessary resources are captured.
- Provide a descriptive name for easy identification and proceed to export the snapshot.

![image](/images/post/coveo-add-resources-to-snapshot.png)

#### Exporting and Applying the Snapshot
- Export the created snapshot to the destination Coveo organization.
- Switch to the destination organization and apply the snapshot.
- Validate the snapshot to ensure all prerequisites are met and review any detected errors.
- Address errors before proceeding with the snapshot application.

#### Under the Hood: Snapshot Creation and Application
- A snapshot consists of a JSON file listing included resources and configurations.
- Coveo matches resource names in the snapshot with IDs in the destination organization to determine actions.
- This matching process ensures consistency and accuracy during snapshot application, preventing conflicts.

### Conclusion
Efficiently migrating changes between cloud organizations in Coveo for Sitecore is essential for maintaining consistency and streamlining development workflows. By following these step-by-step instructions, organizations can replicate configurations across environments with ease, reducing manual effort and minimizing the risk of errors. 

> For further information and detailed guidance on managing resource snapshots, refer to the official Coveo documentation. Additionally, Coveo representatives are available to assist with specific inquiries and support ongoing optimization efforts.

Coveo for Sitecore - Guide to Migrate Changes Between Cloud Organizations


In today's web development landscape, delivering efficient and intuitive search functionality is crucial to provide an enhanced user experience for your visitors. With the advent of Sitecore Search, developers now have a powerful tool at their disposal to seamlessly integrate robust search capabilities into their Next.js applications.

Sitecore Search offers a comprehensive platform that allows you to incorporate predictive and personalized search experiences for your visitors. By leveraging the capabilities of Sitecore Search, you can request and retrieve data such as search results, facets, suggestions, and more, empowering you to build a highly tailored and relevant search experience.


### Understanding the React SDK

#### What is the React SDK?

The React SDK from Sitecore Search is tailor-made for developers in the React ecosystem, including Next.js. It simplifies the integration of Sitecore Search into web apps, enriching the user experience with advanced search features. Developers can quickly enhance their applications with predictive search, personalized results, and more, thanks to the streamlined capabilities of the React SDK.

#### Key Components of the React SDK

The React SDK comprises two npm packages:

1. **React Package**: This package forms the foundation of the SDK, providing core functionality.

2. **UI Package**: Housing a plethora of UI components, the UI package equips developers with various composable to construct diverse user experiences seamlessly.

### Getting Started with the React SDK

#### Installation and Configuration

To start utilizing the React SDK, we need to follow these fundamental steps:

1. Install the two required npm packages: React Package and UI Package.
<Code language="jsx">
{`npm install --save @sitecore-search/react
npm install --save @sitecore-search/ui	`}
</Code>
2. Wrap the React application with the Widget Provider component, furnishing the SDK with essential functionality, usually in Next JS application _app.tsx file is the root of the application.

<Code language="jsx">
{`<WidgetsProvider
			env={process.env.NEXT_PUBLIC_SEARCH_ENV as any}
			customerKey={process.env.NEXT_PUBLIC_SEARCH_CUSTOMER_KEY}
			apiKey={process.env.NEXT_PUBLIC_SEARCH_API_KEY}
			publicSuffix={true}>
	<Component  {...rest}  />
</WidgetsProvider> `}
</Code>
3. Configure the Search Config object to establish the connection between the application and the designated search instance. It's recommended to store sensitive information, such as API keys, in environment variables for security purposes.

<Code language="JSX">
{`NEXT_PUBLIC_SEARCH_CUSTOMER_KEY=<customer-key>
NEXT_PUBLIC_SEARCH_API_KEY=<api-key>
NEXT_PUBLIC_SEARCH_ENV=prod`}
</Code>
### Building Search Functionality with the React SDK

#### Creating Search Components

Once the SDK is integrated into the React application, we can start building out search functionality, in order to communicate with Sitecore Search API we will use query hooks available in the JS SDK package, for search results we will be using  **useSearchResults** query hook, this hook is used request and retrieve data for search results widgets. page, keyphrase, selectedFacets, itemsPerPage, and sortType.

Following is the basic example of its utilization:

<Code language="jsx">
{`import type { SearchResultsInitialState, SearchResultsStoreState, SearchResultsWidgetQuery } from '@sitecore-search/react';
import { WidgetDataType, useSearchResults, useSearchResultsSelectedFacets, widget } from '@sitecore-search/react';

type ArticleModel = {
  id: string;
  type?: string;
  title?: string;
  name?: string;
  subtitle?: string;
  url?: string;
  description?: string;
  content_text?: string;
  image_url?: string;
  source_id?: string;
};

type ArticleSearchResultsProps = {
  defaultSortType?: SearchResultsStoreState['sortType'];
  defaultPage?: SearchResultsStoreState['page'];
  defaultItemsPerPage?: SearchResultsStoreState['itemsPerPage'];
  defaultKeyphrase?: SearchResultsStoreState['keyphrase'];
};

type InitialState = SearchResultsInitialState<'itemsPerPage' | 'keyphrase' | 'page' | 'sortType'>;

export const SearchResultsComponent = ({
  defaultSortType = 'date_desc',
  defaultPage = 1,
  defaultKeyphrase = '',
  defaultItemsPerPage = 10,
}: ArticleSearchResultsProps) => {
  const {
    widgetRef,
    actions: {
      onResultsPerPageChange,
      onPageNumberChange,
      onItemClick,
      onFilterClick,
      onSortChange,
      onFacetClick,
      onClearFilters,
    },
    state: { sortType, page, itemsPerPage },
    queryResult: {
      isLoading,
      isFetching,
      data: {
        total_item: totalItems = 0,
        sort: { choices: sortChoices = [] } = {},
        facet: facets = [],
        content: articles = [],
      } = {},
    },
  } = useSearchResults<ArticleModel, InitialState>({
    query: (query:SearchResultsWidgetQuery) => query,
    state: {
      sortType: defaultSortType,
      page: defaultPage,
      itemsPerPage: defaultItemsPerPage,
      keyphrase: defaultKeyphrase,
    },
  });
  const totalPages = Math.ceil(totalItems / itemsPerPage);
  const selectedSortIndex = sortChoices.findIndex((s:any) => s.name === sortType);
  const selectedFacetsFromApi = useSearchResultsSelectedFacets();
  if (isLoading) {
    return ( <div> ... </div> );
  }
  return ( <div ref={widgetRef}> ... </div> );
};

const SearchResultsStyledWidget = widget(SearchResultsComponent, WidgetDataType.SEARCH_RESULTS, 'content');

export default SearchResultsStyledWidget;
`}
</Code>

in the above code line #69 is where our UI will be placed to create search experience like the implementation of facets, search results, pagination, we will disuss this in the next parts of the blog.

It is important to Convert a UI component into a widget component before adding it to pages or use.

>To convert a component into a widget component, pass the UI component to the  `widget`

### Utilizing Supporting Resources

#### Documentation and Sample Repositories

Sitecore Search offers a comprehensive suite of resources to help developers in their journey to develop search experience:

1. Detailed SDK documentation and a Storybook instance for exploring UI components.

https://developers.sitecorecloud.io/search-sdk/react/latest/storybook/index.html?path=/story/introduction-introduction--page

2. Sample repositories, including a starter kit and the Developer Portal repository, provide practical examples and insights.

https://github.com/Sitecore/Sitecore-Search-JS-SDK-Starter-Kit

### Conclusion

Incorporating Sitecore Search into React applications empowers developers to deliver enhanced search experiences, thereby elevating user satisfaction and engagement. By leveraging the React SDK and its accompanying resources, developers can streamline the implementation process and unlock the full potential of search functionality within their applications.


In the next blog post, I'll show you how to use the Sitecore Search SDK Starter Kit from [GitHub repo](https://github.com/Sitecore/Sitecore-Search-JS-SDK-Starter-Kit) to our Sitecore Next.js solution. Stay tuned for simple steps to create a great search experience!

Sitecore Search SDK Integration [Part 1]


SharePoint On-Premises remains a cornerstone of many organizations' collaboration and content management strategies. Among its key features are WebParts, which allow users to customize SharePoint sites with various functionalities. However, managing WebParts in SharePoint On-Premises environments can be complex, especially across multiple farms or servers. Fortunately, PowerShell offers a robust set of tools to streamline the process. In this blog post, we'll explore how PowerShell can simplify the installation, updating, and uninstallation of SharePoint On-Premises WebParts, empowering administrators to efficiently manage their SharePoint deployments.

Installing SharePoint On-Premises WebParts with PowerShell:
Automating the installation of SharePoint On-Premises WebParts using PowerShell can significantly reduce administrative overhead. Below is a PowerShell script for installing a WebPart in a SharePoint On-Premises environment:

<Code language="PowerShell">
{`Add-SPSolution "C:\Path\To\WebPart\File.wsp"
Install-SPSolution -Identity WebPartName.wsp –WebApplication <web application url> -GACDeployment
`}
</Code>

This script adds the solution file containing the WebPart to the SharePoint farm's solution store and deploys it globally across the farm.

Updating SharePoint On-Premises WebParts with PowerShell:
Keeping SharePoint On-Premises WebParts up-to-date is essential for maintaining security and functionality. PowerShell can automate the process of updating WebParts across SharePoint farms. Here's a PowerShell script to update a SharePoint On-Premises WebPart:

<Code language="PowerShell">
{`Update-SPSolution -Identity WebPartName.wsp -LiteralPath "C:\Path\To\Updated\WebPart\File.wsp" -GACDeployment
`}
</Code>

This script updates the existing solution with the new version of the WebPart file.

Uninstalling SharePoint On-Premises WebParts with PowerShell:
When SharePoint On-Premises WebParts are no longer needed, removing them is crucial to maintain system cleanliness and performance. PowerShell offers a straightforward approach to uninstalling SharePoint WebParts. Here's a PowerShell script to uninstall a SharePoint On-Premises WebPart:

<Code language="PowerShell">
{`Uninstall-SPSolution -Identity WebPartName.wsp 
Remove-SPSolution -Identity WebPartName.wsp 
`}
</Code>

This script uninstalls the solution containing the WebPart from the SharePoint farm and removes it from the solution store.

Conclusion:
PowerShell is a powerful tool for managing SharePoint On-Premises WebParts, enabling administrators to automate the installation, updating, and uninstallation processes. By leveraging PowerShell scripts tailored to their specific needs, administrators can streamline WebPart management tasks, saving time and reducing the risk of errors. Whether deploying new WebParts, applying updates, or removing obsolete components, PowerShell provides a flexible and efficient solution for SharePoint On-Premises WebPart management.

Showing posts fromnextjs

Exposing Site Settings from the Settings item in a Headless JSS Next.js Application