home.social

#xm-cloud โ€” Public Fediverse posts

Live and recent posts from across the Fediverse tagged #xm-cloud, aggregated by home.social.

fetched live
  1. Insights with Vishal Khera @insightswithvishalkhera.wordpress.com@insightswithvishalkhera.wordpress.com ยท

    SITECORE EXPERIENCE EDGE 429 RATE LIMITS: Patterns That Actually Work in Production

    INTRODUCTION

    Across the projects Iโ€™ve worked on, this little log line shows up sooner or later on almost every XM Cloud build:

     HTTP 429 Too Many Requests  X-Rate-Limit-Limit: 80 

    Experience Edge ships with a fair-use guardrail of 80 uncached requests per second per tenant โ€” a deliberate design choice that keeps multi-tenant Edge fast for everyone. Apps that respect this guardrail run beautifully. Apps that donโ€™t can see ISR revalidations queue up and Vercel logs grow noisy during traffic surges. The good news: the patterns to stay well under it are well-established.

    This blog is the playbook I give every team when they hit this. Five patterns that actually work, with the exact code and configuration needed to ship them. Every pattern below is verified against the Sitecore Accelerate Cookbook and the official Experience Edge documentation.

    The Bit Most Teams Miss

    The Sitecore docs explain the 80 req/sec number plainly. What they donโ€™t tell you is how that number actually behaves in real projects, which is what trips teams up. Three things Iโ€™ve learned to remind every team I work with:

    • It is per tenant, not per page or per user. So a single popular page can soak the whole budget.
    • It only counts uncached requests. The whole game is making sure as many of yours as possible are cached.
    • The window resets every second. That means a burst of 200 calls in one second is far worse than 200 calls spread over five seconds. Steady throughput beats bursty traffic on this platform every time.

    Where my clients have hit this in practice:

    • A popular page revalidates during a traffic surge, taking 50+ concurrent GraphQL calls with it.
    • Wildcard routes (product details, article pages) fan out at build or during ISR.
    • A sitemap with 10,000 URLs tries to refresh all at once.

    With that context, here are the patterns.

    Pattern 1: Start With SSG, Not SSR

    If I have time for one conversation with a team about Edge cost, this is it. SSR is the single biggest reason teams burn through their request budget. Every request hits Edge afresh, no matter how identical the page output. SSG flips the script: render once, serve from cache until revalidation fires.

    If your XM Cloud Next.js app is still using getServerSideProps or unconfigured route handlers, move to SSG first. Everything else in this playbook compounds on top of it.

     // Content SDK - App Router SSG with revalidation  // app/[[...path]]/page.tsx  import { sitecoreClient } from 'lib/sitecore-client';   export const revalidate = 3600;   export async function generateStaticParams() {    const sitemap = await sitecoreClient.getSiteMap();    return sitemap.map((entry) => ({      path: entry.path.split('/').filter(Boolean),    }));  }   export default async function Page({ params }) {    const route = await sitecoreClient.getRouteData({      path: '/' + (params.path?.join('/') ?? ''),      language: 'en',    });    return ;  } 

    Gotcha: generateStaticParams called against a 10k-entry sitemap at build time is itself a burst of Edge calls. Run your first build against a limited sitemap in a preview deployment before flipping production.

    Pattern 2: Consolidate Queries with GraphQL Aliases

    Walk through your component tree and count the GraphQL fetches a single page makes. On most projects I audit, the answer is somewhere between five and twelve, just for the chrome (header, footer, nav, search, meta, breadcrumbs). Each of those counts as a separate request against your budget.

    GraphQL aliases let you merge them into a single request. This pattern is in the Sitecore Accelerate Cookbook for a reason.

    Before โ€“ five queries, five requests:

     query GetHeader($path: String!) { item(path: $path) { ... } }  query GetFooter($path: String!) { item(path: $path) { ... } }  query GetNav($path: String!)    { item(path: $path) { ... } }  query GetSearch($path: String!) { item(path: $path) { ... } }  query GetMeta($path: String!)   { item(path: $path) { ... } } 

    After โ€“ one query with aliases, one request:

     query GetPageGlobals(    $headerPath: String!    $footerPath: String!    $navPath: String!    $searchPath: String!    $metaPath: String!  ) {    header:  item(path: $headerPath)  { ...HeaderFields }    footer:  item(path: $footerPath)  { ...FooterFields }    nav:     item(path: $navPath)     { ...NavFields }    search:  item(path: $searchPath)  { ...SearchFields }    meta:    item(path: $metaPath)    { ...MetaFields }  }   fragment HeaderFields on Item { id name fields { name value } }  fragment FooterFields on Item { id name fields { name value } } 

    Five separate fetches become one fetch. On a 50-component page, this alone can reduce your Edge calls by 70-80%.

    Pattern 3: Use Vercel Data Cache with fetch + revalidate + Tags

    If I had to pick the one pattern that has saved my projects the most Edge calls, this is it. Vercelโ€™s Data Cache sits between your app and Experience Edge by default when you deploy XM Cloud there. The opportunity is what most teams miss: with the right revalidate and tags on every fetch, the same GraphQL call gets served from cache across thousands of page renders. You go from โ€œevery request hits Edgeโ€ to โ€œthe first request hits Edge, the next 9,999 donโ€™t.โ€

     // lib/fetch-edge.ts - wrap raw Edge calls through this helper.  // For most data fetching in Content SDK apps, prefer the built-in  // SitecoreClient methods (getRouteData, getSiteMap, etc.) since they  // handle auth, retries, and caching for you.  export async function fetchEdge(args) {    const res = await fetch(process.env.SITECORE_EDGE_URL, {      method: 'POST',      headers: {        'content-type': 'application/json',        // sc_apikey expects your Edge Delivery API key, not the Context ID.        'sc_apikey': process.env.SITECORE_EDGE_API_KEY,      },      body: JSON.stringify({ query: args.query, variables: args.variables }),      next: {        revalidate: args.revalidate ?? 3600,        tags: args.tags ?? [],      },    });    if (!res.ok) throw new Error('Edge error ' + res.status);    const json = await res.json();    return json.data;  } 

    Heads up: sc_apikey and the Content SDK CONTEXT_ID are two different auth mechanisms. The context ID is how the SDK finds your Edge environment and resolves credentials internally. The sc_apikey is the explicit Delivery API key you generate yourself. Keep them separate in your env vars.

    Usage โ€“ tag fetches so you can invalidate them surgically:

     const nav = await fetchEdge({    query: NAV_QUERY,    variables: { path: '/sitecore/content/site/navigation' },    revalidate: 86400,    tags: ['nav', 'globals'],  });   const news = await fetchEdge({    query: NEWS_QUERY,    revalidate: 300,    tags: ['news'],  }); 

    Now every component that needs navigation hits the cache on subsequent renders. Your Edge call count drops dramatically.

    Pattern 4: Revalidate Tags on Publish via Webhook

    Now we hit the question every editor will ask within a week of go-live: if I cache navigation for 24 hours, why arenโ€™t my published changes showing up?

    Answer: hook the Sitecore publish event to a Next.js revalidation route. This is one of the under-appreciated parts of XM Cloudโ€™s webhook system. You can react to publishes, items being saved, almost anything.

     // app/api/revalidate/route.ts  import { revalidateTag } from 'next/cache';  import { NextResponse } from 'next/server';   export async function POST(request) {    const secret = request.headers.get('x-revalidate-secret');    if (secret !== process.env.REVALIDATE_SECRET) {      return NextResponse.json({ ok: false }, { status: 401 });    }    let body;    try { body = await request.json(); }    catch { return NextResponse.json({ ok: false }, { status: 400 }); }    const tags = mapPayloadToTags(body);    for (const tag of tags) revalidateTag(tag);    return NextResponse.json({ ok: true, tags });  }   function mapPayloadToTags(payload) {    return ['globals'];  } 

    Create a Webhook Event Handler in Sitecore at /sitecore/system/Settings/Webhooks/ pointing at /api/revalidate. When content publishes, the webhook fires, the matching tags invalidate, and the next visitor gets fresh content without you paying the Edge bill for everyone else.

    Heads up: Set the secret header on both sides or your endpoint becomes a public cache-buster. I have seen this in production.

    Pattern 5: Tune the Retry Strategy in sitecore.config.ts

    Even with all the caching above, some requests will miss. Content SDK gives you a clean way to handle that gracefully. The older GRAPH_QL_SERVICE_RETRIES environment variable from JSS days is gone, replaced by a config-based retry strategy that lives in sitecore.config.ts. I prefer this because itโ€™s versioned with the code, not buried in environment variables nobody reviews.

    Simple form โ€“ just a retry count:

     // sitecore.config.ts  import { defineConfig } from '@sitecore-content-sdk/nextjs/config';   export default defineConfig({    api: {      edge: {        contextId: process.env.CONTEXT_ID,        edgeUrl: process.env.SITECORE_EDGE_URL,      },    },    retries: 3,    defaultSite: 'my-site',    defaultLanguage: 'en',  }); 

    Advanced form โ€“ custom status codes and back-off factor:

     // sitecore.config.ts  import { defineConfig } from '@sitecore-content-sdk/nextjs/config';  import { DefaultRetryStrategy } from '@sitecore-content-sdk/core';   export default defineConfig({    api: {      edge: {        contextId: process.env.CONTEXT_ID,        edgeUrl: process.env.SITECORE_EDGE_URL,      },    },    retryStrategy: new DefaultRetryStrategy({      statusCodes: [429, 502, 503, 504],      factor: 2,    }),    defaultSite: 'my-site',    defaultLanguage: 'en',  }); 

    A three-retry exponential strategy recovers from transient 429s in the vast majority of cases. Anything more than 3 retries is usually a sign you should be fixing cache patterns, not backing off harder.

    Pattern 6: Wildcard Pages for High-Fanout Routes

    This one is a content-modelling decision more than a code one, and itโ€™s where Iโ€™ve seen teams gain the most ground without writing a line of new code. For routes with thousands of URLs that all share the same layout (product detail, article, knowledge base), use a wildcard page. The layout response caches against the wildcard item once, and every concrete URL reuses that cached layout.

    • Wildcard layout calls: cached against the wildcard item, free after the first hit
    • Concrete item data: still fetched per URL, but at the datasource level, not the full layout

    The net effect is that a site with 10,000 product pages uses roughly the same Edge budget as a site with 100.

    Pitfalls I See on Almost Every Project

    Pitfall 1: Forgetting to Tag Fetches

    I have lost count of how many code reviews Iโ€™ve done where the fetchEdge helper is in place but every call has an empty tags array. Then a publish event comes in and the team has two bad options: nuke the entire cache (slow, costly) or let stale content sit for hours. Neither is good.

    The fix: Tag every fetch. Even [โ€˜globalโ€™] on a catch-all is better than nothing.

    Pitfall 2: Using the Same TTL for Everything

    I see this on roughly half the projects I audit: a single revalidate: 3600 everywhere. News content goes stale. The home page churns refreshes for content that hasnโ€™t actually changed. Both costs are paid for the same TTL.

    The fix: Match TTL to actual publishing cadence per content type. Nav: 24 hours. News: 5 minutes. Marketing copy: 1 hour.

    Pitfall 3: Not Monitoring 429 Response Rates

    The earliest signal that you are approaching the guardrail is 429 responses in your logs. Telemetry catches this well before users do. The X-Rate-Limit-Limit: 80 header confirms the limit on every response, so you can wire it into a dashboard from day one.

    The fix: Instrument your Edge fetch wrapper to count responses by status code. Log every 429 with timestamp, route, and query name. Set a dashboard alert on any sustained 429 rate above zero in the last 15 minutes.

    Pitfall 4: Treating revalidate as a Magic Number

    When I ask a team why they chose revalidate: 3600, the honest answer is usually โ€œthatโ€™s what the starter had.โ€ Thatโ€™s not a decision, itโ€™s a default. Each data type deserves a TTL chosen on the basis of how fresh it actually needs to feel and how expensive a cache miss is.

    The fix: Document the TTL decision per content type in your README or sitecore.config.ts comments. Review it every quarter as publishing cadence changes.

    Key Takeaways

    โœ“ The fair-use guardrail is 80 uncached GraphQL requests per second per tenant. Know this number and design for it from day one.

    โœ“ SSG first. SSR hits Edge on every request. SSG + revalidation is the default for a reason.

    โœ“ Consolidate queries with GraphQL aliases. Five queries become one. Do this everywhere it makes sense.

    โœ“ Vercel Data Cache is your best friend. Wrap every Edge call through a fetchEdge helper with revalidate and tags, or use the Content SDK built-ins where you can.

    โœ“ Invalidate via webhook on publish, not by shortening TTL. Longer TTLs + on-publish invalidation beats short TTLs every time.

    โœ“ Use DefaultRetryStrategy with exponential back-off. Three retries covers most transient 429s. More than that means your cache strategy needs work.

    โœ“ Wildcard pages for high-fanout routes. 10,000 product pages can share one layout cache entry.

    โœ“ Instrument 429 rate monitoring. Count and alert on 429 responses in your Edge fetch wrapper so you catch issues before users do.

    A 429 in production is rarely an Experience Edge problem. It is almost always a caching-strategy problem.

    #saas #sitecore #SitecoreXMCloud #xmCloud
  2. The #Sitecore Content SDK v1.0.0 has been released with its new #XMCloud starter kit. I wrote an extensive article on the new SDK, the differences with #JSS, what is new for developers, pros/cons, and resources.
    getfishtank.com/insights/farew
    #headless #nextjs #angular

  3. ๐Ÿ“ขJust Blogged: #Sitecore 10.4 Headless SXA #Docker #Containers ๐Ÿณ: Run MVC & Next.js side-by-side with XM0/XP1 topologies, Sitecore Identity Server 8.0. Perfect for #XMCloud migration

    ๐Ÿ”—Blog: tinyurl.com/headless-sxa

    #CMS #SitecoreMVP #SUGCON #SitecoreAI #SitecoreSYM #MVPBuzz

  4. ๐Ÿƒโ€โ™€๏ธโ€โžก๏ธRun #Sitecore MVC + Headless on XP!
    โœ… Coexist #MVC & #Nextjs
    โœ… Fetch content via Layout Service/ #GraphQL
    โœ… Prep for #XMCloud with Edge GraphQL

    ๐Ÿ”— Learn more: tinyurl.com/AKTechBites10

    #HeadlessCMS #SitecoreMVP #SUGCON #AvanadeDoWhatMatters #XMCloud #SitecoreSYM #MVPBuzz

  5. ๐Ÿ“ฃ ๐—๐˜‚๐˜€๐˜ ๐—•๐—น๐—ผ๐—ด๐—ด๐—ฒ๐—ฑ: ๐—”๐˜‚๐˜๐—ผ๐—บ๐—ฎ๐˜๐—ฒ Sitecore ๐—ซ๐—  ๐—–๐—น๐—ผ๐˜‚๐—ฑ ๐˜ž๐˜ฆ๐˜ฃ๐˜ฉ๐˜ฐ๐˜ฐ๐˜ฌ๐˜ด ๐—ฅ๐—ฒ๐—ด๐—ถ๐˜€๐˜๐—ฟ๐—ฎ๐˜๐—ถ๐—ผ๐—ป with ๐—”๐˜‡๐˜‚๐—ฟ๐—ฒ & ๐—ฃ๐—ผ๐˜„๐—ฒ๐—ฟ๐—ฆ๐—ต๐—ฒ๐—น๐—น!No more manual token refreshes. โฑ๏ธ๐Ÿ’ก

    ๐Ÿ”— Full guide: tinyurl.com/xmc-devops

    #Sitecore #SitecoreMVP #SUG #SUGCON #SitecoreSYM #XMCloud #Azure #DevOps #PowerShell #Webhooks #Martech #Automation #AvanadeDoWhatMatters

  6. ๐Ÿ“ฃ ๐—๐˜‚๐˜€๐˜ ๐—•๐—น๐—ผ๐—ด๐—ด๐—ฒ๐—ฑ: ๐˜š๐˜ถ๐˜ฑ๐˜ฆ๐˜ณ๐˜ค๐˜ฉ๐˜ข๐˜ณ๐˜จ๐˜ฆ Sitecore ๐—ซ๐—  ๐—–๐—น๐—ผ๐˜‚๐—ฑ with #๐—”๐˜‡๐˜‚๐—ฟ๐—ฒ ๐—™๐˜‚๐—ป๐—ฐ๐˜๐—ถ๐—ผ๐—ป๐˜€ & Real-Time #๐—ฆ๐—ถ๐˜๐—ฒ๐—ฐ๐—ผ๐—ฟ๐—ฒ ๐—ฆ๐—ฒ๐—ฎ๐—ฟ๐—ฐ๐—ต ๐˜œ๐˜ฑ๐˜ฅ๐˜ข๐˜ต๐˜ฆ๐˜ด!
    .
    .
    ๐Ÿ”— Learn how: tinyurl.com/sitecore-search-up
    .
    .
    .
    #SitecoreMVP #LearnSitecore #SitecoreLearning #XMCloud #MVPBuzz

  7. โœ… Checkout my 8th tech bites ๐Ÿ‘‰ Handling User Data in Sitecore XM Cloud ๐Ÿ’ฅ๐Ÿš€๐Ÿ‘‰ tinyurl.com/AKTechBites8

    ๐Ÿ” Secure API keys
    ๐Ÿ”„ Replace MVC controllers w/ API routes

    #Sitecore #SitecoreMVP #SitecoreCommunity #LearnSitecore #AKTechBites #hashnode #xmcloud #sugcon #GenAI #dotnet #javascript #Nextjs #headless #headlesscms #ReactJS #API #git

  8. ๐Ÿ“ฃ Just Blogged:๐ŸŽฏ Master ๐— ๐˜‚๐—น๐˜๐—ถ-๐—–๐—ผ๐—ฑ๐—ฒ๐—ฏ๐—ฎ๐˜€๐—ฒ ๐——๐—ฒ๐˜ƒ๐—ฒ๐—น๐—ผ๐—ฝ๐—บ๐—ฒ๐—ป๐˜ in #๐—ซ๐— ๐—–๐—น๐—ผ๐˜‚๐—ฑ ๐Ÿš€

    Struggling with multiple #๐—ฆ๐—ถ๐˜๐—ฒ๐—ฐ๐—ผ๐—ฟ๐—ฒ websites in ๐—น๐—ผ๐—ฐ๐—ฎ๐—น ๐—ฑ๐—ฒ๐˜ƒ? My new guide shows you how to:

    โœ… ๐— ๐—ฎ๐—ป๐—ฎ๐—ด๐—ฒ ๐—ฑ๐—ถ๐—ณ๐—ณ๐—ฒ๐—ฟ๐—ฒ๐—ป๐˜ ๐—ฐ๐—ผ๐—ฑ๐—ฒ๐—ฏ๐—ฎ๐˜€๐—ฒ๐˜€
    โœ… ๐—”๐˜‚๐˜๐—ผ๐—บ๐—ฎ๐˜๐—ฒ ๐—ฒ๐—ป๐˜ƒ ๐˜€๐—ฒ๐˜๐˜‚๐—ฝ ๐˜„๐—ถ๐˜๐—ต ๐—ฃ๐—ผ๐˜„๐—ฒ๐—ฟ๐—ฆ๐—ต๐—ฒ๐—น๐—น
    โœ… ๐—ฆ๐˜„๐—ถ๐˜๐—ฐ๐—ต ๐—ฝ๐—ฟ๐—ผ๐—ท๐—ฒ๐—ฐ๐˜๐˜€ ๐˜„๐—ถ๐˜๐—ต ๐—ผ๐—ป๐—ฒ ๐—ฐ๐—ผ๐—บ๐—บ๐—ฎ๐—ป๐—ฑ

    ๐Ÿ”— ๐—™๐˜‚๐—น๐—น ๐—ด๐˜‚๐—ถ๐—ฑ๐—ฒ: enlightenwithamit.hashnode.dev
    #๐—ฆ๐—ถ๐˜๐—ฒ๐—ฐ๐—ผ๐—ฟ๐—ฒ #๐—›๐—ฒ๐—ฎ๐—ฑ๐—น๐—ฒ๐˜€๐˜€๐—–๐— ๐—ฆ #๐——๐—ผ๐—ฐ๐—ธ๐—ฒ๐—ฟ #๐—ช๐—ฒ๐—ฏ๐——๐—ฒ๐˜ƒ๐—ฒ๐—น๐—ผ๐—ฝ๐—บ๐—ฒ๐—ป๐˜ #๐—๐—ฆ๐—ฆ #๐——๐—ฒ๐˜ƒ๐—ฒ๐—น๐—ผ๐—ฝ๐—ฒ๐—ฟ๐—ง๐—ถ๐—ฝ๐˜€ #๐—ฆ๐—ถ๐˜๐—ฒ๐—ฐ๐—ผ๐—ฟ๐—ฒ๐— ๐—ฉ๐—ฃ #๐—Ÿ๐—ฒ๐—ฎ๐—ฟ๐—ป๐—ฆ๐—ถ๐˜๐—ฒ๐—ฐ๐—ผ๐—ฟ๐—ฒ #๐—ฆ๐—ถ๐˜๐—ฒ๐—ฐ๐—ผ๐—ฟ๐—ฒ๐—Ÿ๐—ฒ๐—ฎ๐—ฟ๐—ป๐—ถ๐—ป๐—ด #๐—”๐˜ƒ๐—ฎ๐—ป๐—ฎ๐—ฑ๐—ฒ #๐— ๐—ถ๐—ฐ๐—ฟ๐—ผ๐˜€๐—ผ๐—ณ๐˜ #๐— ๐—ฉ๐—ฃ #๐— ๐—ฉ๐—ฃ๐—•๐˜‚๐˜‡๐˜‡ #๐—ฆ๐—จ๐—š๐—–๐—ข๐—ก #๐—ต๐—ฎ๐˜€๐—ต๐—ป๐—ผ๐—ฑ๐—ฒ

  9. CVE-2025-29927, a Next.js critical vulnerability was disclosed on Friday March 21st 2025. You hear about it everywhere recently. You are a Sitecore customer using Next.js for your website(s) and you need to know what to do now. Discover if you are affected and how to protect your websites in this article.

    getfishtank.com/insights/nextj

    #sitecore #nextjs #cve #headless #jss #sitecorejss #sitecorexmcloud #xmcloud

  10. In my latest article, I explore how personalisation works in Sitecore XM Cloud. What's inside:

    ๐Ÿงฉ Step-by-step data flow (lots of gifs!)
    ๐ŸŽ๏ธ Differences between SSR and SSG
    ๐Ÿ˜บ Role of the cat in the diagram

    linkedin.com/pulse/how-persona

    #sitecore #sitecorecommunity #xmcloud #personalization

  11. ๐ŸŽ‰ Exciting News! ๐ŸŽ‰ Iโ€™m thrilled to share that Iโ€™ve successfully passed the #Sitecore #CDP Certification (2024)! ๐ŸŒŸ

    credly.com/badges/3cc6df74-090
    .

    .

    .

    ๐Ÿ™Œ A huge shout-out to my current organization (Avanade Avanade UK & Ireland) for their unwavering support and encouragement throughout this journey. Their commitment to professional growth has been invaluable! ๐Ÿš€

    #SitecoreCommunity #SitecoreMVP #SUGCON #LearnSitecore #msbuild #Sitecorefriends #SitecoreFamily #LearnToCode #XMCloud #DotNet #Azure

  12. I am very happy to introduce my latest project: @Sitecore XM Cloud Extensions. A browser extension that improves #Sitecore #XMCloud user experience.
    jflh.ca/2023-11-21-introducing

  13. Did you want to deploy Unicorn serialization to XM Cloud? ๐Ÿฆ„ I did some playing around on this PoC so that you don't have to!

    ๐Ÿค”Is it possible to deploy Unicorn serialization to XM Cloud? (Yes)

    ๐Ÿ’ก What are the steps that make it work? (a little dirty...)

    โš  REMEMBER: Sitecore doesn't officially support this method, so make sure you know the risks.

    ๐Ÿ™(Please read the article to learn about how and why)

    #Sitecore #XMCloud

    jasonstcyr.com/2023/11/15/depl

  14. With all of the focus I've spent on migration this last while, it was a no-brainer that I would be interested in reading this post by Jack Spektor on #Sitecore #XMCloud migration estimates! There are no numbers in here, but good call out with 9 things to pay attention to when determining complexity of your move:

    jackspektor.medium.com/estimat

  15. Technological #SitecoreLunch today! Discussed:

    ๐Ÿ” VPNs
    ๐Ÿšซ Adblockers
    ๐ŸชŸ #Windows11
    ๐Ÿ“บ Binge watching
    โšก Thunderbolt ports
    โ›… #Sitecore #XMCloud
    ๐Ÿ’ป Laptop performance
    ๐Ÿ‘Ž #MicrosoftEdge hate
    ๐Ÿฅ“ Full English breakfast
    ๐Ÿ—ฟ Composable vs. monolith
    ๐Ÿ“ #SitecoreForms alternatives
    ๐Ÿ“ง Adding + to #Gmail addresses
    ๐Ÿ’ณ Disposable credit card numbers

    See you same time next week! ๐Ÿฅช๐Ÿฅ—

  16. Join the #SitecoreCommunity tomorrow at 12:15 p.m. ET for this week's #SitecoreLunch. Chat #Sitecore, #XMCloud, and more! ๐Ÿ…๐Ÿฅ™

    โฒ๏ธ when: tomorrow, 12:15 p.m. ET
    ๐Ÿ–ฅ๏ธ where: details in #Sitecore Slack #general channel
    ๐Ÿ• join #Sitecore Slack: sitecore.chat

  17. Headless #SitecoreLunch today! Discussed:

    ๐Ÿ‘น #RegEx demons
    ๐Ÿงผ I don't use SOAP
    ๐Ÿ” #SitecoreDiscover
    ๐Ÿงฉ #Composable search options
    ๐Ÿš€ Deploying solution to #XMCloud
    ๐ŸŒค๏ธ Running #Sitecore #XMCloud locally
    โš™๏ธ Configuration search sources and indexers
    ๐ŸŽญ Experience Editor and client-side components

    See you same time next week! ๐Ÿฅช๐Ÿฅ—

  18. Anthropomorphic #SitecoreLunch today! Discussed:

    ๐Ÿ’ฟ CD-ROMs
    ๐Ÿ’ #BonziBuddy
    ๐ŸŽฏ Board games
    ๐Ÿค– AI integrations
    ๐Ÿฎ #Zoom avatars
    ๐Ÿ“ Writers on strike
    ๐Ÿคณ #Sitecore TikToks
    ๐Ÿš• Black cabs in London
    ๐Ÿ’พ Don't copy that floppy
    ๐Ÿ“Ž #Clippy for a new generation
    ๐ŸŽ‚ Happy 30th birthday, Internet!
    ๐ŸŽ† #SitecoreDX Boston next week
    ๐ŸŒก๏ธ Temperature/tone settings in AI
    ๐Ÿ“จ #SitecoreSend and #SitecoreCDP
    โ›… #Sitecore #XMCloud local installation

    See you same time next week! ๐Ÿฅช๐Ÿฅ—

  19. Human-generated #SitecoreLunch today! Discussed:

    ๐Ÿท Paris
    ๐Ÿง  IntelliSense
    ๐Ÿšช #Azure Front Door
    ๐ŸŒถ๏ธ C# 12 new features
    ๐ŸŒ GeoIP analytics rules
    ๐Ÿค– #ChatGPT's bad code
    ๐Ÿฅณ Upcoming #Sitecore events
    ๐Ÿงช #Sitecore testing tools in Chrome
    โ›… New #Sitecore #XMCloud features

    See you same time next week! ๐Ÿฅช๐Ÿฅ—

  20. I wrote the final piece in my blog series covering the migration of the #Sitecore #MVP site to #XMCloud. I'm closing it out by talking about Secure Site Pages.

    robearlam.com/blog/migrating-t