Sitecore getting started to advanced

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...