Let's share the knowledge

Performance of application is one of the important business KPI (Key Performance Indicators) which heavily contributes to the success of business.There are ways to improve the performance of the website like performing optimization, resources upgrade and etc.

Apart from traditional approaches to improve the performance, there is a lot of buzz and talk going on for AMP (Accelerated Mobile Pages- powered by Google ) these days.

As per wikipedia– “The Accelerated Mobile Pages Project (AMP) is an open-source website publishing technology designed to improve the performance of web content and advertisements. The AMP Project led by Google is a competitor to Facebook’s Instant Articles,[1] and includes several other large search, social and web publishing platforms around the world.”

As part of this blog post– I would like to discuss if AMP can be leveraged for Sitecore applications, advantages and disadvantages and what are some key points to be considered before we plan to integrate AMP with Sitecore.

Advantages of AMP:

Speed and Performance-AMP provides a great user experience across many platforms

Do we need separate layout or can be managed with same default layout.

Though we know AMP is a performance booster, but it’s worth to check above points and do a analysis to understand the Integration.

Apart from just AMPiying your website another important factor is to analyze and understand what pages should be migrated to AMP like:

Home page

Landing pages and other top performing pages which contribute to the overall business.

Also, when when AMP should be served?- when user is trying to search contents from Google- via organic search(this is default behavior) or when user hit your page directly is a point of discussion and depends on business requirements, Let’s discuss above points as part of my next post on AMP.

Case Studies:

Here are some case studies are available and can be used as reference to understand it better.

I am very excited about AMP and it’s integration with Sitecore, i am pretty sure you guys are too?. I hope this give you a starting point and makes you think about AMP and how it can be leveraged with Sitecore.

When we work with Multisite solution where in the same Sitecore instance we have different sites for different regions/country, or when we go with several micro sites configuration based on Master site, there are scenarios when we have to create new item(s) based on specific template(s) on all the sites that has been created as part of the instance.

There is absolutely no issue when we are dealing with few sites and pages, but how about when we have more sites? and what if we have to create more than one item under each site?

As a solution we can go to each site node and create the expected items manually, but this approach is going to take good amount of time to complete the full process.

Solution:

Instead we can leverage Sitecore PowerShell Extensions (SPE) to perform this activity, this is much fast and one of the best approach to complete this operation.

For example– If we want to add two items based on two different templates on the same Sitecore Instance, you can use the following script for that and this will get the job done.
Get-Item master: -Query "/sitecore/content//*[@@templatename='Home Page']" | ForEach-Object {
$newpath= $_.FullPath
$item = New-Item $newpath -Name TestArticle -type "/sitecore/templates/User Defined/Sandbox/Article"
$item = New-Item $newpath -Name FAQ -type "/sitecore/templates/User Defined/Sandbox/FAQ"
}

In the above example what i have done is:

Querying all the home nodes under /sitecore/content – based on “Home Page” template.

Taking each home item as context and running “New-Item” SPE command to create an item based on template passed.

As we are running two commands, two items will get created under each site.

Thanks to Michael West and Adam Najmanowicz for this great module.

Hope this is helpful and can save someone’s time who is trying to do something similar.

The scope of this blog post is to give an idea about personalization in Sitecore, why it’s required and steps to create and configure personalization for the components, this is for beginners who are trying to understand the concept and how it can be implemented.

Personalization enables you to deliver targeted content to your visitors. For example, you can implement rules that show personalized content to visitors based on their browsing behavior and their accumulated profile values.
This is really important as you don’t want to show something to users which really doesn’t makes any sense to them.

As an example- For an e-Commerce application as an business you want to show relevant information to users to get most of the conversions, this depends on number of factors, some of them includes:

User behavior

Location

Goals users have triggered.

Anonymous Vs Logged in users

Based on Subscription

Showing different banner images.

Sitecore XP lets you choose from several personalization approaches:

Rules-based personalization: You define the conditions under which content is delivered to a customer. For example, you can set rules based on the IP address or physical location of your visitors, the keywords they use to reach your site, their mobile device, or the goals that they achieve on your website to determine the content that is displayed.

Adaptive personalization- Use visitor profiles and pattern-card matching to dynamically adapt the content shown to visitors in real time. You can set adaptive personalization rules in Sitecore XP’s Rules Set Editor.

Historical personalization: You can set rules that personalize content based on a contact’s historical or past behavior, rather than their actions from the current session (after all, context is what comes before and after the present).

Test and then personalize: With Sitecore XP, you can use A/B and multivariate testing to assess your content and use the test results to optimize for conversion rates against your site’s goals. You can also use testing to assess which type of content works best with certain segments of your visitors.

Journey-based personalization: Design user journeys with Sitecore XP using advanced business logic, and use them to help assess where your customers are in their journey with your brand. Then you can use triggers to advance them through their journeys in context of how far along they are.

There are several out of the box categories which we can use to personalize the components, which includes:

Campaigns

Channels

Date

Device

Fields

GeoIP

Tracking

Visit and etc.

Personalizing the Component:

In order to personalize the component we have to make sure that the component which you are targeting to personalize should support datasource, this would help us in assigning different contents based on different criteria set.

Here are the steps to configure personalization for specific component(s):

Select the component that you want to personalize, you can select the component either from presentation or from Experience editor.

Select the component and click on Personalize button.

Click on the “New Condition” button and add the rule which you want to add based on the requirement.

Click on Edit button and add the rule.

As an example- i am adding the rule which is based on field name compares to specific value.

We can also define the default or fallback component datasource, if none of the conditions matches the default will be used.

Once the configurations are done on the component, we can see an indicator in the presentation which shows that personalization has been applied to the specific rendering/component.

We can personalize the component from experience editor as well.

Now based on the condition which is added on the component, related content will be rendered else the default content will be displayed.

Custom Personalization:

There are certain scenarios where out of the box personalization which are available are not enough to handle the business scenarios, in those cases we have to think about creating custom personalization rules.

We need to create a class that inherits from Sitecore.Rules.Context and implement the Execute() method,and this is where all the business rule exits for the custom rule. We will be covering in a separate blog post about how to create custom personalization rule and applying it on the renderings.

Facets are used to group and classify content items, it’s used to aggregate the count of terms in a field to help a user filter their search more and more to get to the specific results they are after.

As per the documentation of SOLR, facets are described as “… the arrangement of search results into categories based on indexed terms…”. faceting makes it really easy for the end users to look and explore for something which they are looking for. An example can be amazon.com which provides faceted navigation based on the selected keyword, which facilitates users to do look into specific category and narrowing down their results.

Lucene and SOLR both provides support for Facets using ContentSearch API,which means you write facets one and that can be re-used for other search engines as well.
Using ContentSearch API we can use FacetOn() method on the IQueryable<T> instance to set what to facet on, and then call GetFactes() method to get the list of results.

The second parameter to FacetOn() method is optional, it’s a min count and if we provide the min count, it means it’s going to return facets that is greater then equal >= to the value which has been set there.

Default field type in SOLR is tokenized which means it will split the string value in your index, and if the facet field value has space on it, it will be considered as two facets, as a workaround we should create a new computed untokenized index field and use that field instead.

In this blog post I’ll be doing a introduction of the ContentSearch API found in Sitecore followed with a basic search example.
There are several articles which are available, but i will show a very simple working example of it.

ContentSearch API:

ContentSearch API acts like an abstraction over the low level details of search technologies like Lucene or Solr. Sitecore provides an API that can be used to work with Lucene or SOLR, there might be some changes between the two, but those will be just configuration changes.

Same code can be leveraged for Lucene or SOLR, this also helps and provides flexibility during Sitecore upgrade or switching the search providers, you will end up making configuration changes to match the version and you will be all set.

Once we have the index we can get other index details out of it, and can also perform operations like rebuilding of the index if required.

Get the search context:

This is more of opening a connection to search index, once we have the index available, next step is to create search context which allows us to perform search queries and operations against the selected index.
We create the search context using CreateSearchContext() method.

It is quite obvious that we have to create computed fields in Sitecore, to process some of the information well before it get indexed, and not processing it while requesting for the data.

There are chances when you don’t find any value to be added to you computed field, in those cases we can return either null or String.Empty().

Returning null basically tells that there is nothing to be indexed, and it won’t take any space in your index, but when we return string.Empty() , it actually creates an entry in index with no value.

Returning String.Empty() is helpful when you want to validate something based on empty string, but most of the case it is not worth.

Also, consider a case when you are dealing with several thousands Sitecore items, and if you are going to return String.Empty() for few thousands also, it will just get indexed that takes up space in you index.

We should carefully think about this, if there is a need to return String.Empty() we should do the same, but if not we should always try to return null.

There are several instances when you make updates to your Sitecore.config file, changes can include:

Adding new pipelines and processors for any custom feature implementation.

Updating/overriding the default values for some of the setting values like cache sizes and etc.

Adding new Sitedefination for your Sitecore instances.

So, to make any of the updates mentioned above, we have to perform following task(s):

Code changes (class file updates) and/or

Configuration file(s) changes (this is to make sure we register the changes in Sitecore)

Once you are done with you class and config changes, we need to register the changes in Sitecore, this is required so that Sitecore can identify the changes you made, and the functionality works as expected.

There are two approaches for registering the custom updates in Sitecore:

By adding/updating the config changes directly in Sitecore.config file (not recommended) or

Creating a patch file (with extension .config) which includes all the changes required, and placing file under App_Config/Include folder, we can create separate sub folders as well.

Both the approaches works fine as expected, but there is an issue with approach 1.

How would you handle the updates in Sitecore.config file when you are planning for an upgrade later?, provided that you made several changes to Sitecore.config file, it may results issues after the upgrade.(think about it carefully before making changes directly to default Sitecore.config file)

How about if we think about creating a patch file, and putting all our changes there?, and this works well even if you are going for an upgrade at later stage, as you are not adding/updating anything on default Sitecore.config file directly, all the custom changes are coming as part of your patch file(s), This also helps in easy maintenance and troubleshooting.

Patch files are merged with Sitecore.config in alphabetical order. This means configuration in a patch file named a.config will appear before configuration in a patch file named b.config.

If the same configuration is found in multiple patch files, the configuration from the last patch file processed is the configuration that is used.

We can create as many patch files as we want, it all depends on the feature/requirement(s) and the way you want to organize your configuration files in your solution.

For example – you can create separate patch file for any Import functionality we have in the system, and this includes all the settings that needs to be added for specific one, also, there can exists separate patch file which includes custom indexes if exists any?

Note: Patching only works on the Sitecore configuration section, no other file or section can be patched with this.

Place in solution where patch files are placed, i.e under “App_Config/Include” folder

This will set the default database for your website to master, this helps in testing the application without publising changes to web db
(Make sure to revert it back once you are done- and never make this change in QA/Production)

How to see the result after Patching?

Now, how we can see the file which includes all the patches which we have applied, there is no physical .config file which can be used, In order to see the final result, please use this URL

Security is one of the very important considerations for any website.Today I want to share on how to make sure we keep site’s security in mind while implementing the solution, security is equally important as your build.

Following are few points which contribute in website security:

Change the administrator password :

Sitecore recommends that we create a new administrator account, with a unique name, and delete the out-of-the-box administrator account.

Before you deploy your Sitecore installation, you must change the administrator password to a strong password.

Changing the password prevents unauthorized users from using the default password to access the admin account.

In one of the Sitecore application i worked, we had to sync large amount of data from XML, XML had several thousands of records, there was also a business rule in place which used to check certain conditions/fields before it can be inserted as item in Sitecore.

We performed several tests in local environment, before that utility can be executed in QA and other high end environment, but in this process, we have to go back and delete all existing imported items several times.

This was a time consuming process, as deleting several thousand items in Sitecore, can make your Sitecore instance slow, so, we used Sitecore Serialization to delete the items in bulk.

“The Sitecore serialization functionality is designed to help teams of developers thatwork on the same Sitecore solution to synchronize database changes between theirindividual development environments, but is also valuable when a single developerworks on a solution.”

“Serialization allows you to serialize an entire Sitecore database or a series of items ina database to text files. You can then use these text files to transfer this database orseries of items to another database or Sitecore solution.”

This is particularly helpful when we use Sitecore Item buckets to structure all our content items.

Serialization option can be enabled from “Developer” ribbon.

In this example, I have created a folder called “Generic Items” and added few items under it.