
## Introduction

Working in Sitecore XM Cloud, I often noticed a gap: it can be difficult to quickly identify SEO and accessibility issues on a website page. Things like missing alt text, page titles, or improper heading structures often slip through the cracks. These may seem like small details, but they matter a lot for SEO and accessibility.

To solve this, I built a Marketplace app that plugs directly into XM Cloud and lets you run a quick audit on published pages. The results show up instantly inside the Pages editor.

---

## The Idea Behind the App

The idea was simple. Instead of relying on external tools or waiting for SEO audits later, authors can now check their published pages right inside XM Cloud.

It makes the process faster, removes context switching, and gives immediate insights into metadata and accessibility.

---

## How the App Works

The app is built with Next.js and TypeScript and embedded into Sitecore Pages via the Marketplace. When opened, it fetches the published page’s rendered HTML and checks for:

- Missing alt attributes on images  
- Missing or duplicate meta titles and descriptions  
- Incorrect heading structure  

The results are displayed in a clean panel inside Pages.

![image](/images/post/xmcma-1.png)
---

## Creating and Configuring the App in Sitecore XM Cloud

Here’s the exact process I followed to create and configure the app:

1. **Build the app locally**

```bash
git clone https://github.com/mgnventures/xmc-page-seo-audit-app.git
cd xmc-page-seo-audit-app
npm install
npm run dev
```
The app runs on `http://localhost:3000`.

2. **Deploy the app**  
Push it to Vercel, Netlify, or Azure.  


3. **Register the app in Sitecore XM Cloud**  
- Go to Sitecore Cloud Portal.  
- Navigate to **Cloud Portal → Developer Studio → Create App**.  

![image](/images/post/xmcma-2.png)



- Fill in details:  
  - Name  
  - App icon (from your repo’s public folder)  
  - App URL (your deployed endpoint)  
  - Select **Pages Context Panel** as the extension point  

  ![image](/images/post/xmcma-3.png)

  ![image](/images/post/xmcma-4.png)

- Save the configuration.

4. **Install the app in XM Cloud**  
- Open Sitecore Prtal.  
- Go to the My Apps tab.  
- Search for your app and click **Install**.  

![image](/images/post/xmcma-5.png)

- The app now appears as a panel inside Pages.



---

## Real Use Cases

- A content author can check if their published landing page has proper alt text.  
- A marketer can confirm that the page has a correct title and description.  
- A developer can extend the app with custom rules for their project.  

The biggest win is that you can run these checks on the live published page and see results immediately in XM Cloud.

---

## Getting Started Guide

For anyone who wants to try this app:

```bash
git clone https://github.com/mgnventures/xmc-page-seo-audit-app.git
```

Then follow the steps above to register and configure the app in XM Cloud.

---

## Reflections and Future Potential

Building this app showed me how easy it is to extend XM Cloud with custom utilities. The Marketplace is still new, and even small apps like this can add real value for authors and marketers.

Next, I would like to refine the audit rules and improve how results are displayed. I also hope other developers fork the project on GitHub and help make it more stable and useful:

👉 [GitHub Repo – xmc-page-seo-audit-app](https://github.com/mgnventures/xmc-page-seo-audit-app)

In the end, this app is about more than code—it’s about contributing something practical to the Sitecore community.


SEO Audit - Sitecore XM Cloud Marketplace App


Content migration projects are notoriously painful Excel files flying around email threads, editors losing track of versions, and developers drowning in manual imports. I recently implemented a workflow that **keeps Excel in Sitecore Media Library, transforms it to JSON with Next.js, and imports directly into Sitecore via PowerShell**. No temp files, no duplication, just clean automation.

## The Challenge

* Content teams live in **Excel**.
* Developers prefer structured formats like **JSON**.
* Sitecore needs clean, validated data to create content items at scale.

Traditional approaches meant exporting JSON files, juggling temp folders, and scripting one-off transformations. I wanted a system that was **repeatable, auditable, and fully API-driven**.

---

## The Architecture

1. **Excel in Sitecore Media Library**  → Editors upload workbooks as media items.
2. **GraphQL Query**  → Resolve the media item URL via Sitecore GraphQL.
3. **Next.js API (with `xlsx`)**  → Download, parse, normalize headers, return JSON.
4. **PowerShell + SPE**  → Call API, validate, and upsert items into Sitecore.

This creates a seamless **Excel → JSON → Sitecore** pipeline.

---

## Step 1 — GraphQL to Resolve the Media Item

We start by resolving the Excel file stored in the Media Library:

```graphql
query ExcelMedia($id: String!) {
  item(path: $id, language: "en") {
    ... on MediaItem {
      id
      name
      extension
      url: mediaUrl
    }
  }
}
```

This gives us the download URL for the Excel file.

---

## Step 2 — Next.js API: Parse Excel into JSON

The API fetches the media binary, parses it with `xlsx`, and maps it to clean JSON. Features include:

* **Column mapping dictionary** (`Page Title` → `Title`)
* **Validation** (required fields)
* **Duplicate detection** (ExternalId or Title)
* **Dry-run mode**
* **Sheet selection** (`?sheet=LandingPages`)

```ts
import * as XLSX from "xlsx";

const COLUMN_MAP = {
  "title": "Title",
  "page title": "Title",
  "summary": "Summary",
  "body": "Body",
  "content": "Body",
  "category": "Category",
  "external id": "ExternalId",
  "id": "ExternalId"
};

// Normalize + validate rows
type MappedRow = { Title: string; Summary?: string; Body?: string; Category?: string; ExternalId?: string };

function mapRow(raw: Record<string, unknown>): MappedRow {
  const mapped: Partial<MappedRow> = {};
  for (const [k, v] of Object.entries(raw)) {
    const key = String(k).toLowerCase().trim();
    const field = COLUMN_MAP[key];
    if (!field) continue;
    mapped[field] = String(v ?? "");
  }
  mapped.Title = (mapped.Title ?? "Untitled").trim();
  mapped.Category = mapped.Category ?? "General";
  return mapped as MappedRow;
}

export async function GET(req: Request) {
  const url = new URL(req.url);
  const mediaId = url.searchParams.get("mediaId");
  const dryRun = url.searchParams.get("dryRun") === "true";

  // 1. Resolve Media URL via GraphQL (omitted here for brevity)
  // 2. Fetch binary
  // 3. Parse workbook

  const wb = XLSX.read(/* arrayBuffer */, { type: "array" });
  const ws = wb.Sheets[wb.SheetNames[0]];
  const raw = XLSX.utils.sheet_to_json(ws, { defval: "" });

  const mapped = raw.map(mapRow);

  return Response.json({
    dryRun,
    count: mapped.length,
    data: mapped
  });
}
```

---

## Step 3 — PowerShell Importer

The PowerShell script calls the API, validates rows, and upserts into Sitecore. It respects **dry-run mode** and reports **created, updated, skipped, failed**.

```powershell
param(
  [string]$MediaId = "media:/sitecore/media library/Your/Path/content.xlsx",
  [string]$ApiBase = "https://yourapp.com/api/import/parse-excel",
  [switch]$DryRun
)

$endpoint = "$ApiBase?mediaId=$([uri]::EscapeDataString($MediaId))" + ($(if ($DryRun) { "&dryRun=true" } else { "" }))
$response = Invoke-RestMethod -Uri $endpoint -Method Get

$parentPath = "master:/sitecore/content/YourSite/Migrated"
$templateId = "{TEMPLATE-GUID-HERE}"

foreach ($row in $response.data) {
  $title = $row.Title
  $name  = [Sitecore.Data.Items.ItemUtil]::ProposeValidItemName($title)

  # Resolve existing by ExternalId or Title
  $item = $null
  if ($row.ExternalId) { $item = Get-Item "$parentPath/*" | Where-Object { $_["ExternalId"] -eq $row.ExternalId } | Select-Object -First 1 }
  if (-not $item) { $item = Get-Item "$parentPath/*" | Where-Object { $_["Title"] -eq $title } | Select-Object -First 1 }

  if (-not $item) {
    $item = New-Item -Path $parentPath -Name $name -ItemType $templateId
  }

  $item.Editing.BeginEdit()
  try {
    $item["Title"]      = $row.Title
    $item["Summary"]    = $row.Summary
    $item["Body"]       = $row.Body
    $item["Category"]   = $row.Category
    $item["ExternalId"] = $row.ExternalId
  } finally {
    $item.Editing.EndEdit()
  }
}
```

---

## Hardening & Enhancements

* **Dry-run mode** → editors see validation errors without creating items.
* **Row-level error reporting** → API returns `{ rowNumber, messages }` for invalid rows.
* **Duplicate detection** → prevents double imports by checking `ExternalId`/`Title`.
* **Observability** → counts, logs, and metrics pushed to dashboards.
* **Security** → protect API with signed tokens or IP allowlisting.

---

## Why This Works

✅ Editors stay in their comfort zone (Excel in Media Library).

✅ Developers get a stable JSON contract.

✅ PowerShell focuses on item creation, not messy parsing.

✅ Re-runs are safe thanks to upserts + duplicate detection.

This isn’t just about moving content—it’s about building a **reliable migration engine** that’s reusable for future projects.

---

## Final Thought

When migrations are API-driven, versioned, and validated at the edge, you get **repeatability, safety, and speed**. That’s exactly what this Next.js + PowerShell pipeline delivered.

---


From Excel to Sitecore - My Streamlined Migration Workflow via PowerShell


Our team is consistently hitting a wall with next/image component. When a designer hands off a vector graphic, it gets flattened into a static img tag, completely stripping it of its inherent scalability and styling benefits. This isn't just a minor issue; it's a performance bottleneck, a hit to our dynamic styling capabilities, and a constant source of technical debt.

This post will walk through a robust, production-ready solution: a custom Next.js Image Wrapper that not only gracefully handles all media from Sitecore but also intelligently renders SVGs as true inline svg markup.

## Executive Summary

  * **The Problem:** The default `next/image` component treats SVGs as raster images, limiting styling and DOM manipulation. We also need a bulletproof way to handle missing `width`, `height`, and `alt` attributes from Sitecore.
  * **Inline SVG vs. `next/image`:** By rendering SVGs as inline `<svg>` markup, we gain full CSS control (e.g., `currentColor` for theming), enable accessibility hooks, and simplify DOM manipulation. For all other image types, we leverage the power of `next/image` for automatic optimization.
  * **Bulletproof Fallbacks:** Our wrapper component provides sensible defaults for `width` and `height` if they are missing from the Sitecore Media Library, preventing Cumulative Layout Shift (CLS) and ensuring consistent layouts.
  * **Key Outcomes:** This approach leads to superior performance (no extra network requests for styling), enhanced accessibility, and a more maintainable, consistent frontend architecture. It’s about building a predictable and resilient component system.

-----

## The Problem

Sitecore’s Media Library is a fantastic tool for managing digital assets. It provides URLs for images, but when it comes to SVGs, a URL is often not enough. A standard `<img>` tag or `next/image` component treats the SVG file just like a PNG or JPG. We lose:

  * **Styling with CSS:** Can’t use `fill`, `stroke`, or `color` to change the icon's appearance based on state or theme. This is critical for design systems and Dark Mode.
  * **DOM Interaction:** No way to programmatically manipulate the SVG's internal paths or elements with JavaScript.
  * **Accessibility:** The `alt` text is on the wrapper `<img>` tag, but you can’t add rich accessibility attributes like `aria-labelledby` or `role="img"` directly to the `<svg>` itself.
  * **Performance:** The browser makes an extra network request to download the SVG, even if it's a tiny icon, instead of having the markup directly in the DOM.

On top of this, CMS authors often forget or don't know to fill in the `width`, `height`, or `alt` fields for an image, leading to layout shifts and accessibility violations. We need a way to enforce consistency without manual intervention.

-----

## The Solution: Architecture Overview

Our solution is an intelligent wrapper component that sits in front of the standard `next/image`. Its primary job is to inspect the `src` URL and make a critical decision: should this be a flexible, inline `<svg>` or a performant, optimized `<Image>`?

Here’s the decision flow:

```
props (field, width, height)
         └─> isSVG? (check file extension)
         |   └─> is in Experience Editor or Preview mode? -> <NextImage />
         |   └─> else -> fetch SVG content on the server -> render <SVGInline />
         |
         └─> else (e.g., .jpg, .png)
             └─> has all dimensions? -> <NextImage />
             └─> else (missing dimensions)
                 └─> is in Experience Editor? -> render red warning + <NextImage />
                 └─> else -> render empty tag to prevent layout shift
```

This architecture ensures we get the best of both worlds: the power of inline SVGs where we need it and the performance benefits of `next/image` for everything else. The fallback logic for missing dimensions is a critical safety net that prevents layout shifts (CLS) and provides clear feedback to content authors in the editor.

-----

## Code Walkthrough

Let's dissect the code files to see how this all comes together.

### `NextImageExtended.tsx`

This is our main wrapper component. It's the "brain" that makes all the decisions.

**File Name & Role:** `NextImageExtended.tsx`. This component serves as a drop-in replacement for the default Sitecore JSS `NextImage` component. Its primary responsibility is to orchestrate the rendering logic based on the image's properties.

**Key Exports:**

  * `NextImageExtended`: The core component that handles the rendering logic.
  * `NextImageProps`: A TypeScript interface to define the expected props, ensuring type safety.

**Code:**
```tsx
import useIsEditing from '@/hooks/useIsEditing';
import {
  ImageField,
  LayoutServicePageState,
  NextImage,
  useSitecoreContext,
} from '@sitecore-jss/sitecore-jss-nextjs';
import SVGInline from './SVGInline';

type NextImageProps {
  field?: ImageField;
  width?: number;
  height?: number;
}

const NextImageExtended = (props: NextImageProps): JSX.Element => {
  const { sitecoreContext } = useSitecoreContext();
  const isEditing = useIsEditing();
  const isPreview = sitecoreContext.pageState == LayoutServicePageState.Preview;

  if (!!props.width && props.field?.value) {
    props.field.value.width = props.width;
  }
  if (!!props.height && props.field?.value) {
    props.field.value.height = props.height;
  }
  const hasEmptyDimension =
    props?.field?.value?.src !== undefined &&
    (props.field?.value?.width === undefined ||
      props.field?.value?.width === '' ||
      props.field?.value?.height === undefined ||
      props.field?.value?.height == '');

  if (props.field?.value?.src?.includes('.svg') && !(isEditing || isPreview)) {
    let src = props.field?.value?.src;
    src = '/api/fetchSvg?url=${encodeURIComponent(src)}';
    return <SVGInline src={src} />;
  } else if (props.field?.value?.src?.includes('.svg') && hasEmptyDimension) {
    props.field.value.width = 50;
    props.field.value.height = 50;

    return <NextImage {...props} />;
  } else if (hasEmptyDimension) {
    if (isEditing) {
      return (
        <>
          <span style={{ color: 'red' }}>Fill in image dimensions</span>
          <NextImage {...props} />
        </>
      );
    } else {
      return <></>;
    }
  } else {
    return <NextImage {...props} />;
  }
};

export default NextImageExtended;
```


**Why this matters:**

  * **Experience Editor Exemption:** We intentionally *don't* render inline SVGs in the Experience Editor. This is a crucial design choice. The editor often requires a specific `<img>` tag structure to enable its rich-text and image editing capabilities. The `useIsEditing()` and `useSitecoreContext()` hooks are the perfect way to make this distinction, ensuring the authoring experience is not broken.
  
  * **Server-Side Fetching:** The `src` is rewritten to `/api/fetchSvg`. This is a powerful move. By fetching the SVG content on the server side (via a Next.js API route), we can get the raw markup *before* the component is rendered. This is essential for server-side rendering (SSR) and Incremental Static Regeneration (ISR). The `<SVGInline>` component then renders this already-fetched and sanitized markup. This avoids a client-side fetch, improving performance.
  * **Handling Missing Dimensions:** The `hasEmptyDimension` check is our fallback logic.
  * **Preventing CLS:** Setting default dimensions prevents a massive layout shift. `next/image` requires these values to calculate the aspect ratio, which is key to preventing CLS.
  * **Content Author Feedback:** In editing mode, we show a red warning. This isn't just a band-aid; it's a user experience improvement for the content author, teaching them that dimensions are important.
  * **Graceful Degradation:** In production, if dimensions are still missing, we just render an empty `<></>` fragment. This is an opinionated choice: better to render nothing than to cause a massive layout shift or a broken layout.

### `fetchSvg.ts`

This is our Next.js API route. It's a simple, single-purpose utility.

**File Name & Role:** `fetchSvg.ts`. This file defines a **serverless function** that lives in the `/pages/api` directory (or `/app/api` in Next.js 13+). Its sole purpose is to securely fetch the raw content of a given SVG URL.

**Key Exports:**

  * `handler`: The default export that serves as the API route.

**Critical Code Paths:**
```tsx
import { NextApiRequest, NextApiResponse } from 'next';

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  const { url } = req.query;

  if (!url) {
    res.status(400).json({ error: 'Missing URL parameter' });
    return;
  }

  try {
    const response = await fetch(url as string);

    if (!response.ok) {
      res.status(response.status).json({ error: 'Failed to fetch SVG' });
      return;
    }

    const data = await response.text();
    res.setHeader('Content-Type', 'image/svg+xml');
    res.status(200).send(data);
  } catch (error) {
    res.status(500).json({ error: 'Internal Server Error' });
  }
}

```

**Why this matters:**

  * **Security First:** By using an API route as a proxy, we can sanitize the SVG content before it reaches the client. While this code doesn't show it, a real-world implementation should use a library like `dompurify` on the `data` to strip out any malicious `<script>` tags or `on*` attributes. **Never** render raw SVG markup from an untrusted source.
  * **Caching and Optimization:** This API route can be cached by a CDN or Next.js, meaning the SVG content is only fetched from Sitecore once. This is a huge performance win for repeat visits.
  * **Cross-Origin Headers:** This route handles any potential cross-origin (CORS) issues between your Next.js application and the Sitecore Media Library, as it acts as a server-side intermediary.

-----

### Migration Checklist

Ready to adopt this into your project? Here's a quick checklist:

1.  **Create the files:** Add `NextImageExtended.tsx`, `SVGInline.tsx` (a simple component that takes `src` as props and renders the inner HTML), and the `fetchSvg.ts` API route.
2.  **Add Types & Helpers:** Ensure you have the necessary types and the `useIsEditing` hook.
3.  **Update your components:** Find and replace all instances of `<NextImage ... />` with `<NextImageExtended ... />`.
4.  **Sanitize:** Integrate a sanitation library like `dompurify` into the `fetchSvg.ts` route for security.
5.  **Test:** Verify that images and SVGs render correctly in both production and Experience Editor modes. Ensure missing dimensions are handled gracefully.

By following this approach, you can deliver a more performant, accessible, and maintainable frontend experience for your Sitecore solution. It’s about being deliberate with our design choices and creating a component system that is both intelligent and resilient.

Next.js Image Wrapper for Sitecore SVGs


Sitecore recently released Sitecore Stream, a powerful addition to its expanding suite of digital experience solutions. First introduced at last October’s Sitecore Symposium, this new tool is designed to help marketing teams create, manage, and optimize content more efficiently while ensuring brand consistency. As organizations scale their content production and personalization strategies, the demand for solutions that simplify workflows and uphold brand integrity continues to grow.

Let’s dive into how this integration is changing the game for digital marketers.

## Why AI Content Optimization in XM Cloud is a Game-Changer

Creating high-performing, on-brand content at scale has always been a challenge. With Sitecore Stream’s AI integration in XM Cloud, marketers now have:
- **Instant content generation** – AI drafts text for headlines, paragraphs, and CTAs in seconds.
- **Real-time optimization** – Fix grammar, adjust tone, shorten or expand text with a click.
- **Brand-aware AI** – Ensures all content aligns with your brand guidelines (for Stream Premium users).
- **Data-driven decisions** – A/B test AI-optimized content to determine the best-performing version.

No more staring at a blank page—just **faster, smarter content creation.**

## How AI Content Optimization Works in XM Cloud Pages

![image](/images/post/AItranslate.png)

### Generate & Refine Content in Seconds
Inside **XM Cloud's Page Editor**, simply:

1. **Select any text component** (headline, paragraph, CTA)
2. Click **"Optimize Content"** in the right-hand panel
3. Choose an action:
   - **Improve writing** (sharpens clarity & engagement)
   - **Fix spelling & grammar** (instant proofreading)
   - **Make shorter / longer** (condenses or expands text)
   - **Change tone** (adjusts voice for different audiences)
   - **Translate** (supports multiple languages)
   - **Adhere to brand** (applies brand guidelines if a Brand Kit is linked)

### A/B Test AI-Optimized Content
Once you've generated an optimized version, you can:

**Replace the original text** immediately  
**Run an A/B/n test** to see which version performs better  

*Example:*  
- Original: *"Discover our latest product features."*  
- AI-Optimized: *"Unlock the full potential of our newest innovations."*  
- **Test both variants** to see which drives more engagement  

### Personalize Content with AI
In **Personalize mode**, AI helps tailor content for different audience segments. Need a more formal tone for B2B visitors and a friendly one for B2C **Stream adjusts dynamically.**


## Getting Started with AI Optimization in XM Cloud

### Requirements:
- **Sitecore Stream Premium** (for AI content optimization)  
- **New CKEditor rich text editor** enabled in XM Cloud  
- **JSS v22.1+** (for A/B/n testing)  

### Next Steps:
1. **Enable Stream in XM Cloud** (contact Sitecore if not yet activated)  
2. **Link a Brand Kit** (for brand-aware optimizations)  
3. **Start optimizing!** Select any text component and let AI enhance it  

## The Future of AI in Sitecore
This is just the beginning. Expect even deeper AI integrations, such as:

- **Automated personalization** (AI suggesting dynamic content variations)  
- **Predictive content scoring** (AI forecasting engagement before publishing)  
- **Voice & visual brand alignment** (AI ensuring multimedia stays on-brand)

**Note:** The points about future AI integrations in Sitecore are educated predictions based on Current Sitecore Product Direction and Sitecore's Existing AI Capabilities

## Final Thoughts
**Sitecore Stream's AI-powered content optimization in XM Cloud** isn't just a productivity boost—it's a **fundamental shift in how marketers and content creators create and optimize content**. By combining **AI speed**, **brand governance**, and **data-driven testing**, Sitecore is helping teams **work smarter, move faster, and drive better results**.

**Ready to transform your content workflow?**  
👉 *Reach out to Sitecore or your implementation partner to enable Stream in XM Cloud today.* 




AI-Powered Content Creation in XM Cloud with Sitecore Stream


Sitecore's transition to the Front-End Development (FED) First approach represents a significant shift in developing with XM Cloud. This method emphasizes running the head application locally while connecting directly to the XM Cloud Preview Endpoint, streamlining the development process.

## Challenges with Docker-Based Development

Initially, Sitecore developers utilized Docker-based development, which involved simulating XM Cloud's backend services locally. However, this approach presented several challenges:

- **Incomplete Service Simulation**: Not all XM Cloud services could be effectively replicated locally, limiting access to features like Pages, Forms, and Components. 

- **Platform Limitations**: The reliance on .NET Framework necessitated Windows-based containers, restricting development to Windows machines and excluding macOS or Linux users. 

- **Resource Intensiveness**: Running multiple containers demanded high-spec machines, leading to increased hardware requirements and potential performance issues. 

- **Slow Startup Times**: Developers often faced prolonged startup durations as numerous containers initialized, hindering productivity. 

- **Limited Offline Development**: An internet connection remained essential for authentication and content management tasks, even when working locally. 

## Advantages of the FED First Approach

The FED First approach addresses these challenges by allowing developers to run only the head application locally, connecting directly to the XM Cloud Preview Endpoint. This offers several benefits

- **Full Access to Services**: Developers can utilize all XM Cloud backend applications, including Pages, Forms, and Components, without local simulation. 

- **Cross-Platform Compatibility**: By eliminating the need for Windows-specific containers, development becomes feasible on Windows, macOS, and Linux systems. 

- **Reduced Resource Requirements**: With fewer applications running locally, developers can operate effectively on machines with lower specifications. 

- **Faster Startup Times**: Launching the development environment is quicker, as it involves starting only the head application. 

- **Simplified Debugging**: Connecting the local head application to production environments facilitates easier debugging with live data. 

## Considerations with the FED First Approach

While the FED First approach offers numerous advantages, it's important to acknowledge potential drawbacks

- **Dependence on Internet Connectivity**: Continuous access to the XM Cloud Preview Endpoint requires a stable internet connection, which may be a limitation in environments with unreliable connectivity. 

- **Integration Challenges**: Coordinating with existing systems and processes might necessitate additional configuration and testing to ensure compatibility. 

- **Limited Backend Debugging:** While front-end debugging is simplified, debugging issues originating in the XM Cloud backend requires relying on logs and potentially remote debugging tools provided by Sitecore.

* **Initial Data Setup:** Ensuring the XM Cloud environment has the necessary content and configurations for your front-end development might require additional effort upfront.


## Conclusion

Sitecore's FED First approach streamlines the development process by addressing many of the limitations inherent in Docker-based development. By enabling direct connections to XM Cloud services and supporting cross-platform development, it offers a more efficient and flexible workflow. However, developers should consider factors such as internet dependency and potential integration challenges when adopting this approach.

For a practical demonstration of the FED First approach, refer to the following video:

[Front-End First Development in XM Cloud - YouTube](https://www.youtube.com/watch?v=hXPBtMHQMZw)

*Note: The insights presented are based on available information and may evolve with ongoing developments in Sitecore's methodologies.* 

Embracing Sitecore's Front-End Development (FED) First Approach

When working with workflows in Sitecore, clients often request automated notifications to keep track of important state changes. The most common requirement is email alerts.

### The Challenge
Sitecore XM Cloud doesn't include out-of-the-box email notifications for workflow state changes. Since XM Cloud discourages server-side customizations, we need a cloud-native solution.

### The Solution: Webhook Submit Actions
Webhook Submit Actions allow you to trigger HTTP calls when workflow actions occur—without writing server-side code. Here's how to set up email notifications when an item reaches the Approved state.

---

#### Step 1: Add a Webhook Submit Action
1. **Navigate** to your workflow:
   - Go to `/Sitecore/System/Workflows` in the Content Editor
   - Open the **Approved** state

2. **Insert a Webhook Submit Action**:
   - Right-click the state → **Insert** → **Webhook Submit Action**

3. **Configure the Webhook**:
   - **Enabled**: Check to activate
   - **URL**: Your API endpoint (e.g., Next.js/SendGrid email service)
   - **Serialization**: Choose JSON or XML (JSON recommended)

#### Step 2: Set Up Authentication (Optional)
If your API requires auth, create an **Authorization Item** under:
`/sitecore/System/Settings/Webhooks/Authorizations`

Supported auth types:
- `ApiKey`
- `Basic`
- `Digest`
---

##### Example Payload Sent to API
When the workflow triggers, Sitecore sends a JSON payload like this:

<Code language="json">
{`{
  "ActionID": "d6588964-7c88-4650-a2bf-27dff4297d65",
  "ActionName": "Approval",
  "Comments": [{"Key": "Comments", "Value": "Looks perfect!"}],
  "DataItem": {
    "Id": "2e97a681-05ed-4a1c-92b0-87343b1d0e27",
    "Name": "Home",
    "TemplateId": "c6a5d6a9-85a0-4acc-8337-074270364850"
  },
  "PreviousState": {
    "DisplayName": "Draft",
    "StateID": "{A0E3A221-B774-4473-B623-1312FB5645CE}"
  },
  "UserName": "sitecore\\admin",
  "WorkflowName": "Approval Workflow"
}`}
</Code>

#### Step 3: Email API Example (Next.js + SendGrid)

Deploy this Next.js API to handle the webhook and send emails:

<Code language="typescript">
{`// pages/api/workflow/notify.ts
import sgMail from '@sendgrid/mail';
import type { NextApiRequest, NextApiResponse } from 'next';

// Initialize SendGrid
sgMail.setApiKey(process.env.SENDGRID_API_KEY as string);

interface WorkflowPayload {
  ActionID: string;
  ActionName: string;
  Comments: Array<{
    Key: string;
    Value: string;
  }>;
  DataItem: {
    Id: string;
    Name: string;
    TemplateId: string;
  };
  UserName: string;
  WorkflowName: string;
  PreviousState: {
    DisplayName: string;
    StateID: string;
  };
}

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method !== 'POST') {
    return res.status(405).json({ message: 'Method not allowed' });
  }

  try {
    const payload: WorkflowPayload = req.body;

    if (!payload.DataItem || !payload.UserName) {
      return res.status(400).json({ error: 'Invalid payload format' });
    }

    const msg = {
      to: process.env.NOTIFICATION_RECIPIENT || 'admin@yourdomain.com',
      from: process.env.SENDER_EMAIL || 'noreply@yourdomain.com',
      subject: 'Workflow Update: ' + payload.DataItem.Name + ' Approved',
      html:
        '<h2>Workflow Item Approved</h2>' +
        '<p><strong>Content Item:</strong> ' + payload.DataItem.Name + '</p>' +
        '<p><strong>ID:</strong> ' + payload.DataItem.Id + '</p>' +
        '<p><strong>Approved By:</strong> ' + payload.UserName + '</p>' +
        '<p><strong>Workflow:</strong> ' +  payload.WorkflowName + '</p>' +
        '<p><strong>Previous State:</strong> ' + (payload.PreviousState?.DisplayName || 'N/A') + '</p>' +
        '<p><strong>Comments:</strong> ' + (payload.Comments?.[0]?.Value || 'No comments provided') + '</p>' +
        '<p>Please review the item in <a href="' + process.env.SITECORE_APP_URL + '">Sitecore</a>.</p>',
    };

    await sgMail.send(msg);

    return res.status(200).json({
      success: true,
      message: 'Notification sent successfully',
    });
  } catch (error) {
    console.error('Error processing workflow notification:', error);
    return res.status(500).json({
      error: 'Failed to process notification',
      details: error instanceof Error ? error.message : 'Unknown error',
    });
  }
}
`}
</Code>

### Final Thoughts
By combining Webhook Submit Actions with a lightweight API, you can implement workflow emails in XM Cloud while adhering to best practices. Extend this further with:

- Notifications for rejections or draft submissions
- Multi-channel alerts (e.g., Slack + email)

**Pro Tip:** Test your webhook with tools like webhook.site before connecting to email services.

Workflow Email in Sitecore XM Cloud Using Webhook Submit Actions


In today’s digital world, businesses are increasingly leveraging location-based data to enhance user experiences. Whether it’s helping customers find nearby stores or delivering personalized content based on a user’s geographical location, geospatial search plays a pivotal role in providing relevant results. Sitecore's robust search features allow for seamless integration of geospatial capabilities, making it easier than ever to implement geospatial search in your digital solutions.

## What is Geospatial Search?

Geospatial search refers to the ability to filter and retrieve content based on geographical data, such as latitude and longitude. This functionality is essential for industries where proximity is important, such as retail, healthcare, real estate, and logistics. Sitecore’s search engine makes it easy to filter content based on location, offering users results that are directly relevant to their current or specified geographic area.

## How to Implement Geospatial Search in Sitecore

In this section, we’ll walk through how to implement geospatial search using Sitecore's search API.

### Step 1: Indexing Geospatial Data

To get started, we need to create a custom field in Sitecore to store geographical coordinates. In this case, we created a field named `Coordinates` with a `GEO` data type, which can store latitude and longitude values.

![image](/images/post/search-field.png)

Here’s an example of indexing a record for a doctor with their location. In this case, I used Sitecore Search's PUSH source and Postman to push dummy data. The following JSON is the sample input used to feed the PUSH API via Postman:

<Code language="json">
{`{
    "document": {
        "id": "1DrJohnDoe",
        "fields": {
            "name": "Dr. John Doe",
            "description": "Lorem ipsum sit a dor, lorem ipsum sit a dor, lorem ipsum",
            "type": "doctor",
            "coordinates": "40.7127837,-74.0059413"
        }
    }
}`}
</Code>

This JSON document represents a doctor, with the `coordinates` field storing the latitude and longitude of their practice. This geospatial data will later be used to filter search results based on proximity.

### Step 2: Modifying the Search API for Geo Filtering

Once the data is indexed, we need to filter search results based on the user’s location. The following code snippet demonstrates how to modify the Search API SDK to include geospatial filters:

<Code language="tsx">
{`useSearchResults<ArticleModel, InitialState>({
  query: (query): any => {
    const latitude = 40.2404; // User's latitude
    const longitude = -75.1652; // User's longitude
    const radius = '100km'; // Search radius (100 km)
    const sourceId = '000000'; // Source ID of PUSH API

    const request = query.getRequest();
    const geofilter = new FilterGeo('coordinates', radius, latitude, longitude).toJson();
    geofilter['type'] = 'geoDistance';

    // Conditionally add geo filter if coordinates are available
    if (latitude && longitude) {
      request.setSearchFilter(
        new FilterAnd([new FilterEqual('name', 'Dr. John Doe'), geofilter])
      );
    }

    // Conditionally add source ID of PUSH Source
    if (sourceId) {
      request.setSources([sourceId]);
    }
  }
});`}
</Code>


In this code, the `latitude` and `longitude` values represent the location of the user making the search. The `FilterGeo` function is used to filter the search results by geospatial data, with the `geoDistance` filter type ensuring that results are ordered based on proximity.


## Why Geospatial Search is Important

Geospatial search is particularly valuable for businesses that depend on location-specific data. Here are some key reasons why implementing geospatial search can enhance your business:

1. **Proximity-Based Results**: Geospatial search allows users to find nearby services, stores, or content based on their current location, improving the overall user experience.
   
2. **Personalized User Experience**: By integrating location-based filtering, you can provide more relevant search results, ensuring that users find exactly what they need, when they need it.

3. **Better Engagement**: Providing users with content that’s relevant to their location can increase engagement, especially in industries such as retail and healthcare, where local presence is key.

4. **Operational Efficiency**: Geospatial search can streamline business operations by allowing for easy display and management of localized content, improving service delivery.

## Conclusion

Geospatial search is a powerful feature in Sitecore that enhances the user experience by delivering more relevant and localized content. Whether you're working in retail, healthcare, or any other industry that relies on geographic data, implementing geospatial search can make a significant impact on your site's search functionality.

By leveraging Sitecore’s search API and incorporating geo filters into your queries, you can provide users with a more personalized and location-aware experience. As businesses continue to rely on geospatial data, integrating such features into your digital solutions will only become more critical for success.



Unlocking the Power of Geospatial in Sitecore Search


When configuring a Sitecore instance for a production environment, performance optimization is critical to ensure smooth operation under heavy traffic and usage. As a Sitecore developer, I often configure the settings below to enhance performance, particularly for high-demand sites. These settings are designed to manage memory usage, reduce unnecessary resource consumption, and fine-tune how Sitecore handles tasks like caching, analytics, and content management. By adjusting cache sizes, disabling certain features, and refining other key configurations, we can ensure that Sitecore performs efficiently while balancing resource utilization.

This configuration can be utilized to improve the performance of Sitecore across various environments, ensuring that production instances are set up to deliver optimal results.



<Code language="xml">
{`<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/" xmlns:env="http://www.sitecore.net/xmlconfig/env/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
    <sitecore>

        <databases>
            <database id="web" role:require="ContentDelivery or Standalone">
                <securityEnabled>false</securityEnabled>
                <cacheSizes>
                    <data>1000MB</data>
                    <items>1000MB</items>
                </cacheSizes>
            </database>

            <database id="master" role:require="Standalone or ContentManagement">
                <cacheSizes>
                    <data>1000MB</data>
                    <items>1000MB</items>
                </cacheSizes>
            </database>
        </databases>
        
        <settings>
            <setting name="Analytics.AutoDetectBots" value="true" />
            <setting name="Analytics.Robots.IgnoreRobots" value="true" />
            <setting name="ContentTesting.AutomaticContentTesting.Enabled" value="false" />
            <setting name="Publishing.DeepScanRelatedItems" value="false"/>
            <setting name="Caching.AccessResultCacheSize" value="200MB" />
            <setting name="Counters.Enabled" set:value="false" />
            <setting name="ContentEditor.CheckHasChildrenOnTreeNodes" set:value="false" />
            <setting name="ContentEditor.CheckSecurityOnTreeNodes" set:value="false" />
            <setting name="Pipelines.Profiling.Enabled" set:value="false" />
            <setting name="Analytics.CookieLifetime" set:value="34310"/>

            <setting name="HtmlEditor.RemoveScripts" >
                <patch:attribute name="value">false</patch:attribute>
            </setting>

            <setting name="GeoIp.PerformLookup">
                <patch:attribute name="value" value="false" />
            </setting>
        </settings>
        
        <scheduling>
            <agent type="Sitecore.Tasks.CounterDumpAgent">
                <patch:delete />
            </agent>
            <frequency>02:00:00</frequency>
        </scheduling>
        
        <hooks>
            <hook type="Sitecore.Diagnostics.HealthMonitorHook, Sitecore.Kernel">
                <patch:delete />
            </hook>
            <hook type="Sitecore.Diagnostics.MemoryMonitorHook, Sitecore.Kernel">
                <patch:delete />
            </hook>
        </hooks>
        
    </sitecore>
</configuration>`}
</Code>

## Configuration Breakdown

### Database Settings

- **`<securityEnabled>false</securityEnabled>` in `<database id="web">`**  
  Disables security checks on the `web` database, which can improve performance by bypassing permission evaluations for public content.
  - **Pros**: Increases speed for content retrieval.
  - **Cons**: May pose a risk if sensitive content is mistakenly published.

- **`<cacheSizes>` in `<database id="web">` and `<database id="master">`**  
  Sets cache sizes for data and items on both databases, optimizing retrieval times.
  - **Pros**: Enhances performance by reducing database calls.
  - **Cons**: High memory usage may require monitoring to avoid memory issues.

---

### Sitecore Settings

- **`<setting name="Analytics.AutoDetectBots" value="true" />`**  
  Enables bot detection, filtering bot activity in analytics.
  - **Pros**: Improves analytics accuracy.
  - **Cons**: Could misclassify some legitimate users as bots.

- **`<setting name="Analytics.Robots.IgnoreRobots" value="true" />`**  
  Ignores bot activity in analytics reports.
  - **Pros**: Maintains data integrity by excluding bots.
  - **Cons**: Risk of overlooking user behavior if real users are misclassified as bots.

- **`<setting name="ContentTesting.AutomaticContentTesting.Enabled" value="false" />`**  
  Disables automatic content testing.
  - **Pros**: Reduces resource use by disabling unused features.
  - **Cons**: Limits A/B testing capabilities.

- **`<setting name="Publishing.DeepScanRelatedItems" value="false"/>`**  
  Prevents deep scans of related items during publishing, which can enhance publish speed.
  - **Pros**: Shortens publishing times.
  - **Cons**: Potentially omits related items if dependencies exist.

- **`<setting name="Caching.AccessResultCacheSize" value="200MB" />`**  
  Allocates 200MB to the access result cache, helping cache permission checks.
  - **Pros**: Speeds up access calculations.
  - **Cons**: Higher memory use.

- **`<setting name="Counters.Enabled" set:value="false" />`**  
  Disables Sitecore counters, which track various metrics.
  - **Pros**: Frees up resources, optimizing performance.
  - **Cons**: Reduces ability to monitor performance metrics.

- **`<setting name="ContentEditor.CheckHasChildrenOnTreeNodes" set:value="false" />`**  
  Disables child node checks in the Content Editor, reducing rendering time.
  - **Pros**: Speeds up Content Editor operations.
  - **Cons**: Tree view may lack structure information, which could impact navigation.

- **`<setting name="ContentEditor.CheckSecurityOnTreeNodes" set:value="false" />`**  
  Disables security checks on tree nodes in Content Editor.
  - **Pros**: Enhances performance for content editors.
  - **Cons**: Security risks if sensitive content permissions are ignored.

- **`<setting name="Pipelines.Profiling.Enabled" set:value="false" />`**  
  Disables pipeline profiling, saving resources by not tracking processing performance.
  - **Pros**: Improves response time and reduces load.
  - **Cons**: Limited visibility for pipeline-related debugging.

- **`<setting name="Analytics.CookieLifetime" set:value="34310"/>`**  
  Sets the duration for analytics cookies.
  - **Pros**: Manages user session persistence.
  - **Cons**: Shorter cookie lifetimes may impact tracking consistency.

- **`<setting name="HtmlEditor.RemoveScripts"><patch:attribute name="value">false</patch:attribute></setting>`**  
  Allows scripts to be included in HTML editor content.
  - **Pros**: Supports custom scripting in content.
  - **Cons**: Potential security risks if scripts are not sanitized.

- **`<setting name="GeoIp.PerformLookup"><patch:attribute name="value" value="false" /></setting>`**  
  Disables GeoIP lookup, which can reduce load from location-based lookups.
  - **Pros**: Enhances performance by avoiding extra lookups.
  - **Cons**: Location-based content may be impacted if needed.

---

### Scheduling

- **Counter Dump Agent Deletion**  
  **`<agent type="Sitecore.Tasks.CounterDumpAgent"><patch:delete /></agent>`**  
  Removes the `CounterDumpAgent` to reduce processing overhead.
  - **Pros**: Reduces load by eliminating non-essential monitoring.
  - **Cons**: Reduces insight into counters.

---

### Hooks

- **Health Monitor Hook Deletion**  
  **`<hook type="Sitecore.Diagnostics.HealthMonitorHook, Sitecore.Kernel"><patch:delete /></hook>`**  
  Removes Health Monitor Hook, saving resources.
  - **Pros**: Reduces resource consumption.
  - **Cons**: Misses out on automated health monitoring.

- **Memory Monitor Hook Deletion**  
  **`<hook type="Sitecore.Diagnostics.MemoryMonitorHook, Sitecore.Kernel"><patch:delete /></hook>`**  
  Disables Memory Monitor Hook to avoid memory monitoring overhead.
  - **Pros**: Saves resources.
  - **Cons**: Undetected memory issues could affect performance.

---

Ensure to thoroughly test configurations before production deployment, especially if disabling features essential for monitoring or analytics.

Sitecore Performance Optimization Configuration


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 fromnext image

Next.js Image Wrapper for Sitecore SVGs