🍽️ The Restaurant of Mistaken Orders: 2025 Year in Review – A Chef's Reflection on Content Operations

Welcome back to the Restaurant of Mistaken Orders, where we've spent another year navigating the ever-evolving kitchen of content operations. As I look back at 2025, I'm reminded of that moment when you realize your "mistaken order" has actually become the signature dish everyone wants.

This year, content operations didn't just mature; it transformed. Let me share what we cooked up, what burned, and what's now on the permanent menu.

The Year AI Agents Left the Kitchen and Joined the Front of House

When I started this blog, AI was the sous chef we were just learning to trust with prep work. In 2025, AI became the maître d', the sommelier, and occasionally, the customer who knew what they wanted before we did.

The Agentic AI Revolution

This wasn't just about ChatGPT writing better metadata descriptions (though it got scary good at that). 2025 was the year of agentic AI. These are autonomous systems that don't just respond to our commands but anticipate needs, make decisions, and execute tasks without constant supervision.

At the Restaurant of Mistaken Orders, we saw this firsthand:

• Metadata agents that automatically enriched Content Hub assets the moment they were uploaded, understanding brand taxonomy without being told
• Workflow orchestration agents that routed content based on context, urgency, and availability, which eliminated manual assignment
• Quality assurance agents that flagged brand inconsistencies, rights management issues, and accessibility problems before assets went live

The data backs this up. According to research from Aprimo and others in the DAM space, 7 out of 10 prospects cited search and findability as their #1 pain point with legacy DAM systems. In 2025, AI agents didn't just improve search; they made it almost telepathic.

But here's what the hype articles missed: The best implementations weren't about replacing humans. They were about amplifying human judgment. The most successful content operations teams used AI agents as sous chefs, not replacements for the head chef.

The Great Convergence: DAM + PIM + Workflow = The Content Operations Kitchen

For years, we've been running separate stations: DAM over here for marketing assets, PIM over there for product content, workflow tools somewhere else entirely. In 2025, the walls finally started coming down.

What Changed: The enterprises I worked with in 2025 stopped asking "Should we buy a DAM or a PIM?" and started asking "How do we orchestrate content across our entire ecosystem?"

This shift was massive. Content operations emerged as a distinct discipline. It's not just a marketing function or an IT project, but a strategic capability with its own leadership, budgets, and career paths.

I have led content operations implementations where:

• Marketing assets from Content Hub fed directly into PIM systems for product launches
• Product data from PIM enriched DAM metadata for better searchability
• Workflow tools orchestrated hand-offs between creative, compliance, legal, and distribution
• Everything talked to everything, and humans could actually find what they needed

The technical term is "content supply chain orchestration." The practical term is "finally being able to find that asset Jenny created three months ago."

React + TypeScript: The New Normal for Content Hub

Remember when Content Hub's transition from Knockout to React felt like ordering in a new language at a foreign restaurant? By the end of 2025, React and TypeScript became the lingua franca of Content Hub customization.

The Journey:

• Q1 2025: Still plenty of confusion. Documentation gaps. Developers asking "Do I really need to learn React for this?"
• Q2 2025: Community catch-up. Tutorials everywhere (including mine). Patterns emerging.
• Q3-Q4 2025: React is just... how we do things now.

The breakthrough wasn't just technical; it was architectural clarity. Once teams understood the component lifecycle, state management, and the Content Hub SDK's React hooks, development velocity increased dramatically.

We went from "this will take 3 weeks to build" to "let me scaffold that this afternoon."

But (and this is important): The best implementations still required understanding the why behind Content Hub's data model. React made building faster; understanding content operations made building right.

The XM Cloud Awakening (and the "Which Sitecore?" Question)

2025 was the year XM Cloud went from "interesting option" to "serious contender." This was especially true for organizations who wanted composable architecture without composable chaos.

But it also created the great existential question for Sitecore practitioners: "Am I a Content Hub person or an XM Cloud person?"

Plot twist: The answer is increasingly "both, plus you need to understand how they integrate."

The most sophisticated implementations I saw in 2025 used:

• XM Cloud for website content management and experience composition
• Content Hub for DAM, creative operations, and multi-channel asset distribution
• Integration layers that made them work together seamlessly

Sitecore's agentic vision started making sense when you saw this orchestration in action. Content Hub became the central repository for approved brand assets, while XM Cloud consumed those assets for web experiences. AI agents managed the sync, versioning, and rights management.

The organizations that figured this out early won 2025.

Personal Milestone: From Developer to Advisor

This year, I made a conscious shift in my own practice. I moved from being the person who builds Content Hub implementations to being the person who architects content operations strategies.

This meant:

• Learning to present to CMOs and CTOs, not just dev teams
• Thinking in business outcomes, not just technical features
• Understanding change management as much as change tracking in Git
• Reading business strategy books instead of just technical documentation

My "Mastering Sitecore Content Hub DAM" book emerged from this shift. It wasn't just a technical manual; it was a bridge between technology capabilities and business needs.

The reception confirmed what I suspected: The market doesn't need more developers who can write React components for Content Hub. It needs architects who can design content operations that actually work for real organizations with real constraints.

What Didn't Go According to Plan (The Burnt Dishes)

Let's be honest about the orders we got wrong:

1. AI Hallucination Reality Check Early in the year, I was bullish on AI doing more autonomous content creation. By mid-year, after seeing several "creative" interpretations of brand guidelines, I learned that guardrails aren't optional. They're essential.

AI agents work brilliantly within well-defined constraints. Give them too much creative freedom, and you get assets that are technically correct but strategically wrong.

2. The Integration Tax Every "seamless integration" took 3x longer than promised. Whether it was connecting Content Hub to PIM systems, syncing with e-commerce platforms, or feeding marketing automation tools, the result was the same: the demo was always smooth, but the implementation was always complex.

The lesson: Budget for integration time realistically. If the vendor says 2 weeks, plan for 6-8.

What's on the Menu for 2026 (Preview)

As we head into 2026, here's what I see coming:

1. Agentic AI Goes Mainstream What we experimented with in 2025 becomes table stakes in 2026. Organizations that don't have AI agents handling metadata, workflow routing, and quality assurance will be noticeably behind.

2. Content Operations as a C-Suite Role We'll see more "Chief Content Officer" and "VP of Content Operations" titles. These won't be rebranded marketing leaders, but strategic roles focused on the entire content supply chain.

3. Composability Clarity The MACH (Microservices, API-first, Cloud-native, Headless) architecture hype will mature into practical patterns. Organizations will stop debating whether to go composable and start understanding how to compose effectively.

4. The Data Foundation Imperative As AI agents become more sophisticated, organizations will realize their data quality is the limiting factor. 2026 will be the year of metadata governance, taxonomy refinement, and content model maturation.

(More detailed predictions in my next post!)

Lessons from the Kitchen: What 2025 Taught Me

Lesson 1: Technical Depth + Strategic Breadth = Career Leverage The most valuable skill in 2025 wasn't knowing React or understanding Content Hub's API. It was being able to translate technical capabilities into business outcomes. Learn the technology deeply. But also learn to speak CEO.

Lesson 2: Community Compounds Every blog post I wrote, every tutorial I shared, every coffee chat I had... they compounded. Opportunities came from people I helped two years ago. Ideas came from conversations I had in Slack channels. Build in public. Help generously. It comes back multiplied.

Lesson 3: AI is a Power Tool, Not a Replacement The best content operations teams used AI to do more of what humans are uniquely good at: strategy, creativity, judgment. The worst tried to replace human judgment with AI and got mediocrity at scale. Use AI to eliminate toil so humans can focus on what matters.

Lesson 4: Integration > Innovation The newest AI model or latest platform feature matters less than how well your systems work together. Boring integration work often creates more value than exciting new capabilities.

Lesson 5: Experience Beats Certification I talked to many hiring managers in 2025. They all said the same thing: "Show me what you've built. Show me problems you've solved. Show me business impact." Certifications are good. Portfolio is better.

Thank You for Dining with Us

To everyone who read this blog, listened to my podcast, used my Chrome extension, asked questions in comments, or reached out for advice: thank you.

The Restaurant of Mistaken Orders exists because the Sitecore Content Hub community needed a place where we could learn from mistakes, share discoveries, and figure out this content operations thing together.

In 2025, we went from "how do I build a React component?" to "how do I architect an enterprise content operations platform?" That's progress.

In 2026, we'll go further. Stay tuned for my predictions post coming next week.

Until then, keep your metadata clean, your workflows sensible, and your AI agents on a leash.

Bon appétit, Roel van Roozendaal Chef de Cuisine, Restaurant of Mistaken Orders

P.S. If you found this valuable, subscribe to my newsletter where I share weekly insights on Content Operations, Sitecore Content Hub, and the intersection of AI and DAM. And if you have a content operations challenge you're wrestling with, reach out... I love a good culinary puzzle.

P.P.S. What was your biggest content operations lesson in 2025? Drop it in the comments. I read every one.

 

Sitecore’s Agentic Tasting Menu

Pull up a chair, ignore the wobble in that table leg, and let me present today’s special: Sitecore’s quietly ambitious move into agentic AI. Think of it as a kitchen refit while the dining room is still full, with a new brigade of robot sous-chefs that never call in sick and only sometimes flambé the tablecloth.

This is a tasting menu, so we’ll move briskly. Aperitif in hand, let’s tour the courses: Agent API, Marketer MCP, AXP (the contextual assistant), Agentic Studio, and a side of Marketplace tapas. Oh, and for dessert, a controversy-free serving of Content Hub vs XM Cloud pairing notes.

Amuse-bouche: Why Agentic matters (and why your AI keeps burning the roux)

Most AI in content ops is a polite intern: it drafts, it suggests, it nods. Agentic AI is the line cook who reads the ticket, fetches the mise en place, plates it, gets sign-off, and sends it. Still with a human pass, still with guardrails, but crucially able to take multi-step actions in your actual systems.

That shift—from predictive to procedural—is the difference between “help me write a blog” and “create a landing page, spin variants, attach the right assets, schedule, and get legal approval.” Sitecore is wiring the kitchen so those agents can legally use the knives.

Course 1: Agent API — “The pass” where orders move

If your content stack is a restaurant, the Agent API is the pass. It’s where structured tickets get picked up and translated into actions without hauling the entire GraphQL pantry into the prompt.

• What it’s for: Let agents create and update content, pull site info, handle localization parameters, and work through predictable steps without bespoke duct tape each time.
• Why it matters: Agents need a simple, LLM-friendly contract to act reliably. The Agent API abstracts complexity so you can automate “create page → populate content → preview → submit for approval → publish” without hand-feeding a 40-step recipe to your model every time.
• Chef’s tip: Treat it like a service layer for orchestration. Keep your prompts thin, your actions robust, and your audits visible.

Course 2: Marketer MCP — Model Context Protocol as your kitchen door

MCP is the swinging door between the LLM brain and your back-of-house systems. It defines the “tools” agents can use, how to call them, with what inputs and outputs, and under which house rules.

• What it’s for: Securely exposing Sitecore capabilities to agent frameworks, so your agent doesn’t try to flambé the staging site on Friday at 4:59 pm.
• Why it matters: Standardized tool contracts make it easier to build complex, multi-step flows that combine internal data, external sources, and Sitecore actions.
• Real talk: MCPs work best when scoped. Think “knife roll,” not “everything drawer.” Smaller, purposeful toolkits produce more reliable agents.

Course 3: AXP — The contextual maître d’

AXP (Agentic Experience Platform) is the assistant that shows up wherever you are and offers contextually relevant actions. Editing a page? It suggests improving copy, generating variants, or pulling insights. In the asset library? It proposes tagging, compliance checks, or localization.

• What it’s for: Meeting marketers and practitioners where they work, not making them climb into six different admin screens.
• Why it matters: Adoption. AI that hides in sidebars dies in sidebars. AXP turns intelligence into immediate, inline actions.

Course 4: Agentic Studio — Build-your-own-brigade

This is the part where Sitecore lets you assemble your own flow agents. Out-of-the-box patterns for sales, insights, and ABM campaigns, plus the ability to compose custom flows: brief intake, data lookups, asset generation, approvals, and go-live steps.

• What it’s for: Repeatable automations that your team can reason about, modify, and approve. Think “recipes,” not black-box magic.
• Why it matters: Scale. If your best ops person can define the happy path and the safety checks once, an agent can run it reliably a hundred times.

Side plate: Marketplace tapas (order two, regret nothing)

Native-feel apps and AI skills that live inside the product. Translation helpers. Bulk editors. Import-export wizards. The rule of thumb: if it feels like a connector, it’s boring; if it changes the day-to-day for a marketer inside Sitecore, it’s delicious.

• What to build: Anything that shortens handoffs and reduces “did we…?” moments. Simulation, rollback, audit trails. If it prints a clean chit at the pass, it’s a hit.

Pairing notes: XM Cloud vs Content Hub

• XM Cloud: Pages, components, personalization, publishing. This is your front-of-house plating, where ABM campaigns and microsites live. Agent API and the first wave of MCPs are strongest here today.
• Content Hub: Assets, metadata, variants, rights, and governance. It’s the pantry and cold line. Expect growing MCP coverage so agents can fetch, tag, validate, and localize without turning your taxonomy into alphabetical soup.

Pro move: Build flows that cross the divide. “Brief-to-campaign” means CH assets plus XM structure, with approvals that keep brand and legal sane.

Chef’s table: What good agentic flows look like

• Clear ticket: outcome, constraints, and a target state. “German variant for Q4 landing page with approved lifestyle imagery, rights valid through Jan 31.”
• Guardrails baked in: required fields, brand kit checks, legal phrases, rights windows, and language switches.
• Human pass: multi-step automations culminating in a review that is fast, not performative.
• Observability: every step logged. When a VP asks “who added the parsley,” you have the receipt.

Pitfalls to avoid (yes, we’ve spilled this soup before)

• Kitchen sink MCPs: overstuffed toolkits that confuse agents and humans alike. Scope by job-to-be-done.
• Prompt spaghetti: burying business rules in prose. Move policy into the action layer where it can be versioned and tested.
• Sidecar UX: agents that live in a modal nobody opens. Surface actions where work already happens.
• Silent failures: if a step fails and nobody hears it, did it even error? Alerts, retries, and graceful degradation are non-negotiable.

Recipes you can serve today

• Migration mise en place: An MCP-powered pipeline that ingests files from S3 or SharePoint, de-duplicates, maps metadata to Content Hub, and runs rights checks before seating the assets.
• Brief-to-plate flow: Take a brand brief, propose copy and components, select assets from CH, generate locales, submit for approvals, and publish to XM. All auditable. No smoke alarm.
• Tag sommelier: An assistant that proposes taxonomy, flags drift, and warns when your sparkling-water tag is being used for still images again.

The bill, please: What this means for teams

• Marketers: More doing, fewer opening tickets. You keep the taste, agents do the chopping.
• Ops: Policies become code. Approvals shift left. Incidents get traceable.
• Devs: You’re building sturdy counters and sharp knives, not bespoke one-off appliances. APIs, MCPs, and simple contracts win.

Final bite

Agentic AI done right isn’t magic. It’s mise en place. Sitecore’s stack, Agent API, MCP, AXP, and Agentic Studio turn prompts into personalized experiences with a human pass and a clean audit trail. It won’t make your copy go viral, but it will make your operation calm, predictable, and faster than the table that ordered after you.

If your current workflow feels like a tasting menu served in random order, it might be time to invite a few well-behaved agents into the kitchen. Just don’t let them near the crème brûlée torch unsupervised.

🚀 From 7 Years at EPAM to Building My Own iOS Navigation App

Yesterday marked the end of an incredible 7-year journey at EPAM Systems. I’ll miss my colleagues, the challenges we solved together, and, of course, our Berlin office at Kurfürstendamm.

The last three months have been nothing short of a rollercoaster. Instead of slowing down and reflecting, I dove headfirst back into something that has always fascinated me: iOS native app development.

This isn’t new territory for me. Back when the App Store first launched, I built and sold several apps, even one called iBiertje, a student-focused app to find the cheapest beer deals. Those were the early days, when even a small app could reach thousands of downloads.

But this time, I wanted to tackle something bigger. A project that combined my passion for mobility, technology, and real-life usability. The result? Urban Rider, the first dedicated navigation app for scooters, mopeds, and brommers.

---

🌍 Why Build a Scooter Navigation App?

If you’ve ever tried using Google Maps or Apple Maps on a scooter, you know the struggle. Standard navigation apps push riders onto highways or major roads, places where scooters simply don’t belong. Setting routes to “bike mode” or “avoid highways” isn’t enough, because avoid still isn’t the same as never.

On top of that, cities like Berlin and Nürnberg are filled with cobblestone streets, which are frustrating on two wheels. Riders want to avoid them, but existing navigation apps don’t give that level of control.

For years, I saw people on Reddit asking for a true scooter navigation app, but no one built it. This summer, after buying my own scooter, I decided to step up and make it happen.

---

💻 From Idea to App Store

What started as a simple experiment quickly grew into the biggest project of my career. I handled everything:

• Design & UX – clean, rider-focused, safe navigation.

• Routing engine – initially tested on Apple Maps but later replaced with a much more accurate solution after 100+ test rides across Berlin.

• Production release – launched on the App Store at €4.99 to validate the market.

Yes, the first versions had rough edges and some negative reviews—but every single issue taught me something valuable. I worked nights and weekends, debugging live on the road with my laptop connected via hotspot. That grind paid off: routing is now rock-solid, rerouting works seamlessly, and version 4.0.0 is almost ready for release.

---

📱 Urban Rider Today

Urban Rider is now a fully-featured scooter and moped navigation app, designed for real riders in real cities:

• 🚦 Scooter-only routes (no highways, no unsafe detours).

• 🛵 Moped-friendly road types, avoiding cobblestones and tricky surfaces.

• 🔄 Fast rerouting that respects your actual driving direction.

• 📍 Multi-stop planning and round-trip support.

• 🌍 Tested on the road by early users across multiple countries.

You can check it out at www.urbanrider.app or download it directly from the App Store with a free 8-day trial.

---

🧑‍💻 A Note on AI & Development

Did I use AI? Yes, but not in the “AI built my app in 2 days” way you sometimes hear about. With 20+ years in development, I use AI for:

• Summarizing API documentation.

• Suggesting alternative approaches.

• Speeding up research.

But complex projects like navigation still require deep architectural thinking, relentless debugging, and hands-on problem solving. AI is a tool, not a co-pilot.

---

🌱 What’s Next?

Building Urban Rider from zero to production in just three months has been the most rewarding challenge of my career. It reminded me how much I love building products that solve real problems.

And now? I’m open to new opportunities—whether as an Engineering Manager, Senior iOS Developer, or something entirely different. Maybe even starting a coffee shop (I make a mean espresso ☕).

If you’re looking for someone who blends technical depth, leadership, and entrepreneurial spirit, let’s connect.

---

👉 Check out Urban Rider – the first navigation app made for scooters and mopeds.
👉 Open to collaborations, leadership roles, or innovative new ventures.

My Order Was "A Simple Script." The API Chef Served a Three-Course Automation.

I had what I thought was a simple order. A straightforward request for the kitchen. "I'd like to automate posting about my new iOS app, Urban Rider, to Reddit. Nothing fancy, just a script that posts to a different, relevant subreddit each day without being a spammy nuisance."

Simple, right?

I sat down at my favorite table here at the Restaurant of Mistaken Orders, the one with the wobbly leg and the IDE open. I thought I knew exactly what I wanted. But the chef, a quirky, undocumented platform called Relay.app, had other plans. What followed was a delightful, maddening, and ultimately illuminating multi-course meal of errors, discoveries, and a final dish that was far more interesting than the one I originally ordered.

First Course: The Appetizer of Confusing Errors

My first order was simple: "I'll have the plain JavaScript, please." I wrote a script to authenticate with the Reddit API.

The waiter (the error log) came back almost immediately. "Sorry, chef says this is a TypeScript-only dish." It was covered in red squiggles complaining about things like Promise<Output>.

"Okay," I said, a little confused. "No problem, I can speak TypeScript. Let me rephrase my order." I carefully rewrote the script with all the proper types. This time, I asked for some standard ingredients: fetch to make the web request, and Buffer to encode my credentials.

The waiter returned, looking apologetic. "About that... we're out of fetch. And Buffer. Actually, we don't have any of the ingredients you'd normally find in a kitchen."

This was a truly mistaken order. I was in a restaurant that had no ingredients. It was like ordering a steak and being told the very concept of "cow" was not supported in this establishment. Every attempt failed. The code couldn't find axios, then it couldn't find http, then it complained about invalid characters in a header that my own tools had corrupted.

The "Aha!" Moment: Reading the Chef's Menu

This is where the magic of this restaurant kicks in. After sending back every dish, I realized my mistake. I was trying to tell the chef how to cook using my own recipe book. I needed to stop and ask: "What's the Chef's Special today?"

I stopped trying to write code. Instead, I looked at the menu the platform provided: the no-code UI steps. The user manual I found (thanks to my helpful AI rubber duck) confirmed it: the Code step was a tiny, limited kitchen, but the Custom HTTP Request step was a full-service Cordon Bleu kitchen, complete with all the tools we needed.

I had ordered a custom meal, but the real solution was the buffet all along.

Second Course: Getting the Recipe Right

Switching to the no-code UI was a game-changer. All the complex authentication logic was suddenly a set of simple fields. But there was one last mistaken order. My request was rejected with a 401 Unauthorized error.

After double-checking everything, we discovered the "secret sauce." The UI didn't have a clear Authentication button. The solution? We had to create the Authorization header manually.

1. Combine the ingredients: We took my app's Client ID and Client Secret.
2. Use a special tool: We used an online Base64 encoder to transform them into a single, secret string.
3. Add the finishing touch: We added the Authorization header with our new encoded string.

Voilà. The API returned a 200 OK. We had successfully authenticated.

Third Course: The Smart Automation Dessert

Now for the fun part. With the connection established, we built the workflow I had wanted from the start.

1. The Daily Special (Choosing a Subreddit) To avoid posting to the same place every day, we added a small JavaScript step. This code acts as our friendly host, seating us at a new table each day. It uses the number of days since 1970 to create a rotating index, ensuring we cycle through our list of 12+ subreddits with plenty of time between visits to the same one.

2. The AI Sous-Chef (Generating the Content) This is where it gets really cool. We added an OpenAI step. But instead of just telling it "write a post," we gave it a detailed recipe (a prompt) to follow:

• Act like a human: "You are a helpful and passionate developer, not a marketer."
• Know your audience: "The target subreddit is [Subreddit Name]. Analyze the name and tailor your tone."
• Focus on one thing: "Pick ONE key problem Urban Rider solves (like avoiding highways) and make that the theme of the post."
• Be engaging: "End with an open-ended question to start a real conversation."

The result was magic. The AI produced a perfect, authentic-sounding post that didn't feel like an ad at all.

3. Plating and Serving (Posting to Reddit) The final step took the output from the AI (title and body), the chosen subreddit, and our auth token, and used another "Custom HTTP Request" to serve the final dish to Reddit.

The Moral of the Story

My visit to the Restaurant of Mistaken Orders was a success. I didn't get the "simple script" I originally ordered. Instead, I was served a sophisticated, multi-course automation that was far more robust and intelligent.

The experience taught me a valuable lesson: sometimes the best solution isn't about forcing a tool to work your way, but about understanding the tools you're given and using them to their full potential. The "Chef's Special" is often better than anything you could have ordered off the menu.

So, what's your favorite "mistaken order" story from a project you've worked on? I'd love to hear it in the comments. And if you're a scooter rider tired of being sent onto the freeway, you know which app to check out.

Day 5: Making it Look Good - Theming and Basic Styling

Day 5, and it's time to make our Sitecore site look less like a collection of boxes and more like a real website! Today, I'm diving into theming and basic styling in SXA.

What I'm Learning Today:

• SXA Themes: The Site's Skin. SXA uses themes to control the visual styling. There are default themes, and I'm learning how to apply them to my site. Themes contain CSS, JavaScript, and other assets. Get an overview of "Themes" within the SXA section of the Sitecore Documentation page: https://doc.sitecore.com/
• Customizing Themes: The default themes are a good starting point, but most projects need customization. I'm looking into how to clone a theme and then modify the CSS and other assets to match a specific design. Search the Sitecore Documentation page for "Customize SXA Theme": https://doc.sitecore.com/
• Scriban: Dynamic Rendering Power. Scriban is a templating language used within rendering variants for more advanced logic when displaying content. It looks like a way to add dynamic behavior to my components without writing full C# code for every little thing. Find information on "Scriban" within the SXA documentation on the Sitecore Documentation page: https://doc.sitecore.com/
• Custom Components (A Glimpse): While SXA has a lot of components, sometimes you need something unique. I'm getting a basic understanding that you can create custom renderings using C# and integrate them into Sitecore. This is more advanced, but good to know for the future. Look for information on "Create a Rendering" on the Sitecore Documentation page: https://doc.sitecore.com/

My Day 5 Takeaways:

• SXA themes provide a structured way to manage the visual styling of a Sitecore site.
• Customizing themes involves working with CSS and other front-end assets within the Sitecore theme structure.
• Scriban looks like a powerful tool for adding dynamic behavior to components directly within the Sitecore UI.
• While SXA offers a lot, Sitecore's extensibility allows for creating fully custom components when needed.

Where to Go From Here:

This 5-day sprint has given me a solid foundation in Sitecore XM and SXA. My next steps are definitely going to be:

• Deeper dive into Scriban and more complex rendering variant scenarios.
• Exploring the world of custom component development.
• Understanding data source configuration and how components get their content.
• Learning about workflows and the content publishing process in Sitecore.
• Engaging with the awesome Sitecore community!

Thanks for joining me on this learning journey! I hope this has been helpful. Remember, the Sitecore Documentation (https://doc.sitecore.com/) is your best friend as you continue to explore.

Other links:

• https://learning.sitecore.com/learn/learning_plan/view/26/sitecore-experience-accelerator-sxa-collection.
• https://portal.sitecorecloud.io
• https://doc.sitecore.com

Happy learning!

#Sitecore #SXA #WebDevelopment #Learning #CMS

Day 4: Giving Content Structure - Data Templates and Architecture

Day 4 is all about understanding how content is organized and structured within Sitecore using data templates. This is the backbone of any good website.

What I'm Learning Today:

• Data Templates: Defining Content Fields. Templates are the blueprints for our content. They define what fields each type of content item will have (e.g., a news article might need a headline, body, image, and author). Learning how to create and configure these is key: Explore the "Working with Templates" section on the Sitecore Documentation page: https://doc.sitecore.com/
• Content Architecture: Planning for the Future. Just creating templates isn't enough. I need to think about how different content types relate to each other and how they'll be organized in the Content Tree. This is all about planning for a maintainable and scalable website. Search the Sitecore Documentation page for "Content Architecture" or "Content Strategy" for more insights: https://doc.sitecore.com/
• Standard Values: Setting the Defaults. Standard values let you pre-populate fields in a template with default content. This saves content authors time and ensures consistency. Learn about "Standard Values" on the Sitecore Documentation page: https://doc.sitecore.com/
• Information Architecture (IA): The User's Journey. While not strictly a Sitecore feature, I'm also thinking about how users will navigate the site and how content will be linked. A well-planned IA is crucial for a good user experience.

My Day 4 Takeaways:

• Data templates are the fundamental building blocks for defining content structure in Sitecore.
• A well-thought-out content architecture is essential for a manageable and scalable website.
• Standard values are a neat way to improve the content authoring experience and maintain consistency.
• Thinking about the user's journey (IA) is just as important as the technical content structure.

Next Steps: Tomorrow, I will shift my focus to the visual layer, exploring SXA themes and how to customize the website's look and feel. I'll also get a basic introduction to Scriban for more advanced rendering customizations.

Follow along: https://learning.sitecore.com/learn/learning_plan/view/26/sitecore-experience-accelerator-sxa-collection.

Day 3: Playing with LEGOs - SXA Components and the Grid

Alright, Day 3 and I'm finally in the Experience Editor, playing with SXA! It feels like building with LEGO, but for websites.

What I'm Learning Today:

• The SXA Toolbox: A Treasure Trove! Wow, there's a whole library of pre-built components I can just drag and drop onto the page. Text, Image, Navigation, Forms, it's all there! This will definitely speed things up. You can find an overview of SXA components on the Sitecore Documentation page: https://doc.sitecore.com/
• The 12-Column Grid: Layout Power! SXA uses a responsive 12-column grid system. It's all about dividing the page into these columns and placing components within them to create different layouts that adapt to various screen sizes. The "Layout" tab in the Experience Editor is where you control this. Learn more about the SXA Grid System on the Sitecore Documentation page: https://doc.sitecore.com/
• Rendering Variants: Component Flexibility. This is a cool concept. Instead of writing code to display a component differently in various situations, rendering variants let you define different HTML structures and data mappings right in the Sitecore UI. Check out the "Rendering Variants" section on the Sitecore Documentation page: https://doc.sitecore.com/
• Partial Designs: Reusable Sections. These are like pre-built chunks of layouts and components (like a header or footer) that you can reuse across multiple pages. Huge time-saver! More info on "Partial Designs" can be found on the Sitecore Documentation page: https://doc.sitecore.com/

My Day 3 Takeaways:

• The SXA Toolbox is packed with useful, ready-to-go components.
• Understanding the grid system is crucial for creating flexible and responsive layouts without writing extensive custom CSS.
• Rendering variants provide a powerful way to customize component presentation without requiring code changes for every minor adjustment.
• Partial designs are going to be my best friend for creating consistent site structures.

Next Steps: Tomorrow, I'm digging into the data side of things – how content is structured using data templates and how it all comes together.

Follow along: https://learning.sitecore.com/learn/learning_plan/view/26/sitecore-experience-accelerator-sxa-collection.

Day 2: Getting My Hands Dirty - Setting Up Shop

 

Day 2 is all about getting a local Sitecore development environment up and running. This can be a bit of a rite of passage for Sitecore developers, so let's see how it goes!

What I'm Learning Today:

• Local Installation (The Traditional Route): I'm going the traditional route for now, using the Sitecore Install Assistant (SIA). It looks like there are prerequisites like .NET Framework, ASP.NET Core Hosting Bundle, and SQL Server. The official installation guide seems pretty comprehensive (and necessary!): Find the installation guide for your specific Sitecore version on the main Sitecore Documentation page: https://doc.sitecore.com/
• Key Tools - Initial Setup:
  • Sitecore CLI: Installed this using the .NET CLI. Seems like it's going to be my go-to for tasks like serializing items and deploying code. Get started with Sitecore CLI on the Sitecore Documentation page: https://doc.sitecore.com/
  • Sitecore for Visual Studio: Just installed this extension in Visual Studio. It adds Sitecore project templates and helps with connecting to my local instance. Look for information on "Sitecore Developer Tools" or "Sitecore for Visual Studio" on the Sitecore Documentation page: https://doc.sitecore.com/
    

My Day 2 Takeaways:

• Setting up a local Sitecore instance can be a bit involved, so following the official documentation closely is key. Patience is definitely a virtue here!
• Sitecore CLI looks like a powerful tool for automating Sitecore tasks.
• The Visual Studio extension appears to make development within my familiar IDE much smoother.

Next Steps: Tomorrow, the fun begins! I'm finally going to start playing with SXA components in the Experience Editor. Let's see what these pre-built goodies can do!

Follow along: https://learning.sitecore.com/learn/learning_plan/view/50/xm-cloud-for-jss-headless-developers.

Move to day 3

Day 1: Hello Sitecore XM & SXA - First Impressions

 

Okay, Day 1. Time to demystify Sitecore XM and SXA. I've heard they're a big deal in the web development world, so let's see what the hype is all about.

What I'm Learning Today:

• Sitecore XM: The Content Powerhouse. From what I gather, Sitecore XM is the core CMS. It's not just a place to store text and images; it's a system for managing the entire lifecycle of web content, featuring workflows and collaboration tools. Think of it as the structured brain behind a website.
• Sitecore SXA: The Developer's Toolkit. SXA is the cool kid on the block for us developers. It's a layer on top of XM that provides a ton of pre-built components, templates, and even themes. The promise? Faster development and more reusability. Sounds like music to my ears!
• Key Concepts - My Initial Grasp:
  • Templates: These are like content blueprints. Imagine defining the fields for a blog post (title, body, author, date). That's what templates do. Explore the "Working with Templates" section on the Sitecore Documentation page: https://doc.sitecore.com/
  • Layouts: The structure of a webpage – where different elements go. Search for "Layouts" on the Sitecore Documentation page: https://doc.sitecore.com/
  • Renderings/Components: Reusable UI bits that display content or add functionality. SXA boasts a big library! Look for "Renderings" or "Components" on the Sitecore Documentation page: https://doc.sitecore.com/
  • Themes: Styling – the look and feel of the site. Find information on "Themes" within the SXA section of the Sitecore Documentation page: https://doc.sitecore.com/
  • Experience Editor: The visual editor for content folks to build pages. Understanding this is key for building components they'll love. Learn about the "Experience Editor" on the Sitecore Documentation page: https://doc.sitecore.com/

My Day 1 Takeaways:

• Sitecore XM is a robust CMS, and SXA is the framework that aims to make our development lives easier.
• The core concepts of templates, layouts, and components appear fundamental to the structure and display of content.
• The Experience Editor is where the content magic happens for non-developers.

Next Steps: Tomorrow, I'm tackling setting up a local development environment. This is crucial for actually getting my hands dirty. Wish me luck!

Follow along: https://learning.sitecore.com/learn/learning_plan/view/51/xm-cloud-for-net-headless-developers.

Move To Day 2 

🍽️ Welcome to Sitecore Content Hub DAM Events! 🍽️ Today’s Special Menu: The Unexpected Events

 

Welcome, dear diners, to a most unique tasting experience! Our chef, Sitecore Content Hub DAM, has prepared a surprise menu where every dish is an “event” you never expected but might just love. Take a seat, enjoy, and let’s dive into the flavors of digital unpredictability. Bon appétit!

Starters

• ENTITY_CREATED
  A Surprise Starter! – A new entity appears, freshly whipped up and served with a dash of spontaneity. Perfect for those who love a little mystery to begin.

• ENTITY_DELETED
  Here One Moment, Gone the Next – A fleeting delicacy, savored briefly before it disappears forever. Was it there at all? Only your memory knows.

• OPTION_LIST_CREATED
  Menu Expansion – A spontaneous assortment of options. Customize your experience with an array of unexpected choices!

• APPLY_AUDIT_QUERY
  Detective’s Delight – A light starter to whet your appetite for insights. Dig deep and uncover the hidden flavors within each byte.

Mains

• ENTITY_SAVED
  The “Safe Bet” Special – This classic comes securely served and saved, ensuring a delightful experience with no risks on the side.

• REFRESH_SEARCH
  New Discoveries – A refreshing take on familiar flavors. Every refresh reveals a new twist, leaving you curious for what’s next.

• REDUX_ERROR
  The Oops Platter – An unexpected, sometimes baffling blend of ingredients that will make you wonder, “Was this supposed to happen?” But hey, it adds a bit of character to the meal!

• END_OF_PAGE_REACHED
  The Final Act – The ultimate course, served right at the end. Perfect for those who believe the best things are worth waiting (and scrolling) for.

Sides

• COMPONENT_COPIED
  Cloning Perfection – A double serving of your favorite side, recreated with precision.

• COMPONENT_PASTED
  Perfect Placement – Just the right addition to complement any meal, carefully placed for balance.

• SELECTION_CHANGED
  New Tastes – A shift in flavors, a pivot in selection. Sides that adapt to your changing preferences with a smile.

Desserts

• ERROR
  The Unplanned Surprise – Not on the menu, but a dish you’ll remember. Mistakes, after all, make for the most memorable bites.

• CLOSE_INLINE_PREVIEW
  Preview’s Last Glimpse – Just a small taste, enough to intrigue before it fades away. Perfect for the curious diner who loves a tease.

• INSERT_IMAGE
  Picture Perfect Finish – A beautiful visual dessert, carefully plated to end your meal with just the right touch of style.

• INSERT_VIDEO
  Action Finale – A lively video dessert, bringing energy and rhythm to the end of your meal. Enjoy the show!

Our dishes may surprise and confound, but that’s the beauty of the experience at Sitecore Content Hub DAM. Thank you for dining with us, where each meal is an adventure and each event is a dish to remember.

Bon appétit!

"Sort by" or "Why Are We Not on the Menu?": A Story of Divs, Dropdowns, and Dropped Expectations

Imagine walking into our world-famous Restaurant of Mistaken Orders, where the charm lies not in what you ordered, but what you end up with. You ask for a refreshing iced tea, and what do you get? Spaghetti Bolognese. You request a slice of cake, and a plate of sushi arrives. The unpredictability is part of the charm. But what if the unpredictability spilled over into technology, where we expect things to work as planned? Welcome to the wild world of “Sort by”—where things aren't quite what they seem, much like the orders at our beloved restaurant.

The Problem: "Sort by" – A Div Masquerading as a Dropdown

At the Restaurant of Mistaken Orders, we love a good surprise. But when it comes to coding, we’d appreciate a little more... predictability. So, let’s talk about the curious case of our Sort by feature, which is acting more like a rogue waiter who just won’t bring you what you asked for.

You see, "Sort by" looks like a button. It sits there in the interface, all smug, waiting for you to click it and organize your assets. But plot twist—it's not a button at all. It's a div! Yes, a div that wants to be a dropdown, but doesn't behave like one. And, as anyone who has worked with React will tell you, a div pretending to be a button is like asking for a Caesar salad and getting a chocolate soufflé. Oddly delightful in some contexts, but entirely unhelpful when you just want your greens.

Reverse Sorting and Refresh Buttons: The True Buttons

While the "Sort by" dropdown is over in its corner doing whatever it is divs do, the “Reverse Sort by” and “Refresh” buttons are behaving like proper restaurant staff. These two are actual buttons! You can click them, interact with them, and they’ll flip your A-Z sort to Z-A like a waiter finally getting your dessert order correct (on the third try, naturally). They do their job. They understand their place in the hierarchy of web components.

But “Sort by”? Nope. That’s our rebellious chef who refuses to make an omelette because "eggs are just too mainstream." And this chef has taken a vow of silence. You can click it all you want, but it just won’t respond.

Why Can’t I Click It?

Now, here’s where things get quirky—just like how, at our restaurant, sometimes the soup shows up without a spoon. Normally, you can attach click events to divs. It's no big deal. But in this case, when you try to attach a click event to the Sort by div, nothing happens. It’s like trying to get a table by waving frantically at the maître d’—completely ignored.

What makes matters worse? The sub-menu from the dropdown is generated on the fly. That means it’s not sitting there in the DOM waiting to be poked and prodded by eager developers like us. No, no, that would be too easy. It’s only created when someone manually interacts with it. Like a ghost menu that only appears when you whisper the secret password.

But Why Do We Even Want to Click It?

Good question! You might be wondering, why all this fuss over clicking something that doesn’t want to be clicked? Well, it’s because we’ve got an AI assistant that needs to help sort the page based on user commands. Someone might say, “Hey, sort my assets by title!” and we want our trusty assistant to do just that. But instead of giving the AI the nice, neat power to sort via the search API, which refuses to cooperate, we’re stuck trying to simulate a click.

It would be as simple as pressing a button—if only that button were an actual button and not a div in disguise.

The Not-So-Tasty Solution

So, what's the workaround? How do we deal with a rogue div that won’t let us simulate a click? Well, my solution was to update the session that contains the sorting information and then refresh the page. You know, like how at our restaurant, if you really want to get what you asked for, you just order something else entirely and hope for the best.

It’s not elegant. It’s like serving soup in a coffee cup—it technically works, but no one’s thrilled about it.

Why Isn't It a Real Dropdown or Button?

The burning question that keeps us up at night (besides “Did I accidentally double-book that reservation?”) is: Why isn’t "Sort by" a real dropdown or button? If it were, life would be simpler, and our AI assistant could gracefully handle sorting duties. But instead, we’re left with this div-shaped puzzle that, like a misplaced order of anchovy ice cream, leaves us scratching our heads.

Would it have been too easy to just use a button? A standard dropdown? Something with a little more... clickability? Perhaps. But at the Restaurant of Mistaken Orders, we know that sometimes things get a little jumbled up. And in this case, “Sort by” is serving us a confusing, featureless div where there should be a nice, interactive button.

The Final Word

In conclusion, working with this quirky div reminds me of dining at our beloved restaurant. You never quite know what you’re going to get, and sometimes, the solution isn’t what you wanted—but it’s what you’ve got to work with. We’ll make do with session updates and page refreshes, but deep down, we’ll always long for a day when “Sort by” is finally a proper button, ready to be clicked at will.

Until then, we’ll just embrace the chaos—both in our code and on our plates. After all, if everything worked perfectly, it just wouldn’t be the Restaurant of Mistaken Orders, now would it?