Tech tutorials Top Nine for Sitecore 9
By Insight Editor / 14 Dec 2017 , Updated on 21 Aug 2019
By Insight Editor / 14 Dec 2017 , Updated on 21 Aug 2019
At the 2017 Sitecore Symposium, Sitecore announced the release of Sitecore Experience Platform 9. Here’s my list of the top nine features and capabilities that have been included in this new release.
I've had many clients ask me for recommendations on building rich front ends or client applications on top of Sitecore using Angular or React. In the past, my response has always been, It’s definitely possible, but I wouldn't recommend it.” The main reason is because a lot of the great features provided by Sitecore, such as personalization and A/B testing, are closely tied to the Sitecore rendering engine, which runs on the server and isn’t exposed via REST APIs. With the release of Sitecore 9, however, that’s no longer true.
Sitecore has always relied on ASP.NET membership for user authentication into the platform. If you wanted to leverage authentication through other mechanisms, you had to do a lot of custom development to build your own provider on top of the ASP.NET membership model.
Sitecore now supports the ASP.NET Identity model, which allows you to configure your Sitecore environment to allow authentication through various third-party providers. That means you can allow users to log in to Sitecore using Azure Active Directory, Active Directory Federation Services, Microsoft, Google, various social media platforms such as Twitter, Facebook and Instagram, or any other third-party platforms that support OAuth.
Sitecore has released a new service layer called xConnect for interacting with the Sitecore Experience Database (xDB). xConnect provides a single, consistent REST API for searching, reading and writing xDB data. If you want to capture customer interactions from a custom mobile app, xConnect is the way to do it. Do you want to capture information from a point-of-sale system or Internet of Things (IoT) device? xConnect is the way to do that, too.
And you can be guaranteed xConnect is not some half-baked, barely tested API because everything that interacts with xDB must go through xConnect, including all of the foundational Sitecore code. xConnect implements the oData protocol, providing a standards-based API that’s easy to consume.
Also, because of the potentially sensitive nature of some of the customer experience data that’s captured with xDB, xConnect requires Secure Sockets Layer (SSL), along with an explicit certificate-based handshake for any client to connect to it.
Sitecore has revamped the way installs are conducted with the release of the new Sitecore Installation Framework (SIF). This new framework is built on top of Windows PowerShell and provides a completely automated approach to installing and configuring all of your Sitecore instances. This framework will set up the databases, search indexes, Internet Information Services application pool and websites, install SSL certificates and perform all of the necessary Sitecore configuration for you based on the type of installation you’re performing.
All of the configuration is controlled by JSON files that define the various variables and parameters that go into your specific installation (database names, usernames and passwords, certificates, file locations, etc.). This framework is designed to be extended and customized so that customers can incorporate additional capabilities into their own installation process, such as accommodating specific provisioning and security hardening requirements.
One drawback to the new installation approach is that it’s not as easy or user-friendly as the old Sitecore installers (SIM or the Sitecore Windows installation executable). So while this may make things a little less intuitive for smaller organizations, it provides the power and flexibility to ensure consistent, secure and repeatable deployments for large enterprise installations — without a lot of error-prone, manual installation procedures.
Sitecore has redesigned the way system configuration works with Sitecore 9. The first thing you'll notice is that the App_Config\Include folder has no configuration files. There's a new file in the App_Config folder called Layers.config that shows you exactly why.
<layer name="Sitecore" includeFolder="/App_Config/Sitecore/">
<add path="CMS.Core" type="Folder" />
<add path="AntiCSRFModule" type="Folder" />
<add path="PathAnalyzer" type="Folder" />
<layer name="Modules" includeFolder="/App_Config/Modules/" />
<layer name="Custom" includeFolder="/App_Config/Include/" />
<layer name="Environment" includeFolder="/App_Config/Environment/" />
From this, you can see Sitecore has created a new "layering" structure for the various configuration files, and these are loaded in a specific order. First, all of the "core" Sitecore configuration is loaded as part of the Sitecore layer, and these are all maintained in a separate folder. Next, any Sitecore-provided or third-party modules are loaded in the Modules layer with its own corresponding folder. Then, any custom configuration is loaded from the currently empty "Include" folder as part of the Custom layer.
Lastly, any environment-specific configuration gets loaded as part of the Environment layer. This approach makes it much easier to keep out-of-the-box Sitecore configuration files separate from custom configuration. Also, by defining specific folders for each layer, it makes it much easier to prevent one layer from "polluting" another layer with its content, simplifying the process of maintaining, troubleshooting and upgrading the platform. No longer will you have to create folders with a prefix of "z." just to ensure your custom configuration gets loaded prior to the Sitecore configuration.
In addition to the layer-based approach, Sitecore has also introduced the concept of role-based configuration. This allows you to assign a specific server role to individual configuration nodes. For example, you can define configuration settings specifically for content management, content delivery or processing servers without having to go through a lot of time-consuming and error-prone steps of having to enable or disable various configuration files on each of those servers.
You can also define your own custom configuration roles and assign configuration information to those roles as needed. This role-based approach provides a lot of flexibility while also allowing for consistent, reapeatable, automated deployments.
In addition, Sitecore has provided a new admin page (/sitecore/admin/showconfiglayers.aspx) that allows you to view all of the defined configuration layers, the config files included with each layer and the different configuration roles that have been defined, as well as define new roles.
It also provides the ability to select a specific role and preview the resulting configuration that would be generated for that type of server role. This allows you to essentially validate any environment-specific configuration in a single development environment without having to actually deploy your configuration to another server.
One of the biggest annoyances many developers had to deal with when building Sitecore solutions was the behavior of placeholders in the Experience Editor.
Placeholders are basically named content areas on a page that allow a content author to place a piece of content into. However, if two placeholders with the same name appear twice on a page (responsive grid layouts are a good example), the content dropped into one of the placeholders will also appear in the second placeholder.
In the past, developers had to rely on third-party solutions from the Sitecore Marketplace or custom solutions to address this problem. Sitecore has paid attention to the most requested user voice recommendation from the developer community and has included an out-of-the-box dynamic placeholder to address this issue.
There was a lot of excitement around the original release of the Experience Database (xDB) with Sitecore 7.5. However, it presented organizations with a number of challenges. The foremost of those challenges was probably the technical requirement for MongoDB as part of the platform. In addition to the pre-existing SQL Server database requirements, organizations suddenly had to support a second type of database as well.
Although MongoDB offered a free community addition that works well with Sitecore, many organizations found the need to purchase enterprise licenses of the software due to legal or technical requirements that weren't able to be satisfied with the community version. Additionally, many IT organizations didn’t have the knowledge or experience to be able to install, configure and maintain a completely new type of database platform.
With the release of Sitecore 9, MongoDB is no longer a requirement for the platform. As a matter of fact, MongoDB is surprisingly not yet supported with the initial Sitecore 9 release (but will be supported in an upcoming update release, along with CosmosDB). Sitecore now supports using SQL Server 2017 as the database for xDB. This version of SQL Server provides the necessary level of capability for storing JSON structures in a noSQL type of manner that wasn’t previously possible with SQL Server.
Now, organizations can leverage a single set of software and licenses for all databases required for the Sitecore Experience Platform, and can have peace of mind knowing they have the infrastructure and technical capability to be able to support it.
One of the more exciting new capabilities in Sitecore 9 for content authors is the inclusion of a new Forms module. Many of you are familiar with the Web Forms for Marketers (WFFM) module, which was provided with previous Sitecore releases. The new Sitecore Forms module isn’t just a refresh of WFFM; it’s a completely new module designed and developed from the ground up as a replacement for WFFM, which will be deprecated in the future.
The goal of WFFM was to provide a user interface that would allow content authors the ability to create web forms for their site with little to no developer involvement. While WFFM was able to achieve those goals to some degree, the UI was very clunky, and the module seemed to be very error-prone at times and didn’t lend itself well to more advanced data capture scenarios.
The new Sitecore Forms module addresses all of those issues. The module provides a nice, clean user interface with drag-and-drop capabilities for creating forms. The Forms module also provides support for wizards to allow data capture over multiple pages in sequence, something that was never possible with WFFM. Also, this Forms module is included automatically with the Sitecore install, so it’s no longer an add-on module like WFFM was.
If you've used Sitecore for an extended period of time, you've probably experienced the frustration of trying to create an engagement plan or access the Sitecore App Center only to get that annoying message that you can’t access that functionality unless you install and enable Silverlight in your browser. I've had a number of situations where I needed to enable device detection or Geo IP lookup capabilities from the App Store and was unable to do so because I wasn't permitted to install Silverlight on production hardware.