A fluent wrapper for the TagBuilder class can make it much easier to work with the dynamic placeholders introduced in Sitecore 9.
In this post, we will take a closer look at the Initialize-CSSite commandlet and how it might behave differently if you are installing a custom site or if you are trying to start from scratch.
In the last post we covered the installation of the Commerce Engine. In this post we will wrap up the Commerce installation with a few final steps.
In the last post, we covered the site initialization process. In this post we will go over the installation of the Commerce Engine.
In the last post, I covered how to install the core components of Sitecore Commerce 8.2.1. This post will cover the installation of the reference storefront.
I was recently tasked with installing Sitecore Commerce 8.2.1 for a client. It was one of the more frustrating experiences I can remember. The instructions provided in the Deployment Guide are written for a local development environment with a local database server. The DevOps Guide has more detailed listings of accounts and permissions, but it provides very little instruction on how to use that information in the context of an installation. Some parts of the DevOps Guide also seemed to be out of date when I initially went through this. Fortunately, the instructions have been getting regular updates. This series attempts to provide better instructions for installing Sitecore Commerce in an existing development or test environment where the database is on a separate server.
Sitecore has a button on the developer tab that allows you to re-index just a portion of the content tree. This can be handy to avoid a full index rebuild when you have a large content tree or if you are debugging custom indexing funtionality likc computed fields. Unfortunately, the button causes the the subtree to be re-indexed for all indexes. A few MVPs were recently tweeting about how it would be nice to have the option to select a particular index. I just happened to have written a Sitecore PowerShell Extenstions context menu script to do this recently. Continue reading
In this post we will wrap up the Forgot Password functionality that we have been working on by adding a bit of personalization to our Forgot Password page that will show a different form if the user has successfully verified their email address. Continue reading
In the previous post we set up a form and email to verify the user’s email address before we allow them to reset their password. This post will show how to update the user’s state in response to the click-through from the verification email.
Continue reading
In the last post we started creating Forgot Password functionality. We created goals and an engagement plan to define the logic behind the user flow. In this post we will start working on the frontend. Continue reading