Sitecore getting started to advanced

In part 1 , we looked at the old way of storing form data on a Sitecore contact. A developer creates a custom facet, a model builder, a JSON file, config files, and a submit action, and deploys all of it. When the marketer wants one more field, the whole cycle starts again. You can read this part on its own. Here, we do the same job with the Generic Personalization module, also called the codeless schema module. Sitecore released it to solve exactly this problem. We will install it, build a " dine preference"  form, check the data on the contact, and personalize the home page. Codeless schema module: The module saves form answers on the contact with no custom facet code. It works because it has one facet, called  FacetAreas , and the shape of that facet never changes.   Contact area: Inside  FacetAreas , the data is grouped into areas. An area is a named group, and its name is the name of the form. For example, a form called "Dine Preference" creates the area ...

Recently, we received a requirement from the client that their marketing team can promote the marketing campaign whenever they need to, on the fly; they can create forms, and they wanted to build a personalization rule on that data and show different pages and components to different visitors. And all of this should happen without a developer and without a new release each time. They wanted all the information the user selected from the campaign form to be stored as user preferences in the xDB contact database, so that the marketer can see details of the user and personalize the content for them. A simple example is a booking form with a "Dine preferences" field. A visitor picks Pasta. The next time that visitor comes, the home page shows a pasta offer. The marketer did all of it alone. This is a two-part post. In this part, we will see how this normally works with a custom facet, and why it is hard. In part 2 , we will see how the Generic Personalization module (also calle...

In the previous article , we installed the ARR module in IIS and discussed the mistakes I made during the initial implementation. In this article, we'll look at the IIS rules and the pipeline code used to make the reverse proxy work correctly. <!--Home page--> <rule name="ProxyHomepageContent" stopProcessing="true"> <match url="^/?$" negate="false" ignoreCase="true"/> <serverVariables> <set name="HTTP_HOST" value="ss104cd.dev.local" /> </serverVariables> <action type="Rewrite" url="https://ss104cd.dev.local/en" appendQueryString="true" /> </rule> <!--EN--> <rule name="languagecoderuleEN" stopProcessing="true"> <match url="^en/?$" /> <serverVariables> <set name="HTTP_HOST" value="ss104cd.dev.local" ...

In my previous post , we covered how to install the ARR (Application Request Routing) module in IIS to set up a reverse proxy. Before configuring the reverse proxy, there's one important thing to consider: we're not just proxying the homepage URL, but also the static assets used on the homepage, such as: CSS JS images  While implementing this reverse proxy, I ran into a number of issues when a language code was present in the domain for the homepage. Let me walk through the issues I faced so this can be helpful to others. Our new Sitecore 10.4 instance has two language versions, en and ar, so I created IIS rules to handle this as shown below. However, no redirect happened from the old site to the new Sitecore site for the homepage. I first focused on getting the reverse proxy working without a language code in the URL, as shown below for the homepage.     The reverse proxy wasn't working; I still got the old site's homepage when loading the domain. I traced this to t...

Recently, we had a situation where we needed to migrate a project from an older Sitecore version, 8.1, to Sitecore 10.4. We had already started development when, after some time, the client decided it was important for at least the homepage to go live on the new Sitecore 10.4 instance, while the rest of the pages would continue to be served from the old Sitecore instance — all under the same domain. Technically, this meant running two Sitecore instances in parallel: the client would continue content authoring on their existing old Sitecore instance, while development continued on the new Sitecore 10.4 instance. This approach would allow the client to run their marketing campaign for the new site without waiting for the full migration to complete. After considering a few different approaches, we concluded that a reverse proxy would solve the problem — serving the homepage from Sitecore 10.4 and the rest of the pages from the old Sitecore instance. Let's look at how this can be achi...

Sitecore turns 25 this year, and I feel like I have grown up alongside it. I started working with Sitecore nearly 14 to 15 years ago, back at version 6.6 . As a .NET developer, picking up Sitecore MVC was easy from the start. The initial learning was not complex at all, which made it simple to keep going and build on what I already knew. That momentum carried me further than I expected. Over the years, I worked across the full Sitecore stack. MVC, JSS, CDP, Personalize, Content Hub, Sitecore Connect, Sitecore AI , and the Marketplace. Each product helped me understand digital experience better, not just technically but strategically. Working with some of the biggest brands in the UAE showed me what digital experience really looks like in real life. Sitecore was at the heart of every solution I delivered. Speaking at events like SUGCON Bangalore, running webinars and seminars, and sharing Sitecore also shaped who I am professionally in ways I did not expect. Sitecore also shaped who I ...

In the previous article , we explored the Agent API and learned how to generate a token and make API calls. In this article, we will dive deeper into one of the important capabilities of the Agent API: Jobs . Now that we understand how to authenticate and interact with the Agent API, let’s consider a practical scenario. Imagine that some content has been added or updated in a connected Sitecore instance , and those changes unexpectedly cause an issue on the website. In such situations, the natural solution is to roll back the changes . Typically, the usual approach is to navigate to the Sitecore Content Editor , locate the affected item, and manually restore the previous content. This works well if we have a backup of the earlier content . However, if no backup exists, reverting the changes becomes more complicated. We may need to inspect item versions, review previous changes, or use other manual recovery approaches , which can be both time-consuming and error-prone. This is wher...