A little while ago someone asked me if they can automate the addition of watermarks using Sitecore. My normal response here is ‘mumble mumble custom code’ or something along those lines, but I found it a pretty cool idea actually … Continue reading
I was running through the Sitecore Experience Editor the other day, where I wanted to check whether my various patterns would be showed the correct personalized content. The easiest thing to use is the Experience Explorer, which you can get to through the Other button in the Mode chunk.
This will open the Experience Explorer on the left-hand side of the website with the Experience Viewer on the right-hand side. In the Onsite Behavior tab I set the proper scores to match a particular pattern card. After clicking ‘Apply’ I didn’t see any difference until I checked the Onsite Behavior tab in the Experience Viewer.
Easily managed by just clicking ‘Apply’ 2 more times, but a bit annoying. Turns out, there’s a way of going around this: The Analytics.Patterns.MinimalProfileScoreCount setting. By default it won’t show up in your settings so you’ll have to manually add it. After applying this setting the profile personalization will be applied directly after setting the value of Analytics.Patterns.MinimalProfileScoreCount to 1.
Before you change it though, keep in mind that this will not only affect the Experience Explorer, but also the ‘normal’ website – and as such might have adverse effects.
I’ve been working with Commerce Server now for a while, trying to enable it on our dev environment. After the installation process (which might require its own post as well), I figured I’d write something about how to get product definitions, products, category definitions and categories from Commerce Server into Sitecore.
Creating definitions
The Product Definitions and Category Definitions (and I’m guessing Property Definitions also, but I haven’t used custom properties yet) work in a similar way. They can be created in the Commerce Server Catalog and Inventory Schema Manager, using the appropriate view in the Views panel on the bottom left in the screenshot below.
Creating a new definition is reasonably straightforward. Just give the definition a name and optionally a description, and select the properties you’d like that particular definition to use. After this, you’re done! You can now create new products or categories based on that new definition.
Creating products and categories
Creating new categories and products can be done in the Commerce Server Catalog Manager. Right-click where you’d like to add a new category or product, and use the context menu to create a new category or product. Alternatively, you could use the SPEAK app Merchandising Manager, on which I’m sure more blog posts will be coming as well. In the meantime, more on the Merchandising Manager can be found here. When using the Merchandising Manager, you can skip to the section about getting the definitions to Sitecore. When using the Commerce Server Catalog Manager, you can follow the steps below to get create products or categories.
In this screenshot you can see I’m using the MVC demo store (of which you can download the source on the Sitecore Marketplace or the Sitecore package from SDN if you don’t need the source).
Creating a new category and/ or new product will pop up with a wizard which will run through the various steps (Selecting the definition, entering the properties followed by the custom properties, selecting primary and additional categories and then selecting relations for the category or product). This is all very easy to do.
All done, we have our products and categories in Commerce Server.
Now, how do we get this to go into Sitecore? If the product and category definitions already exist in Sitecore, products and categories will be synced automatically, although caching might get in your way sometimes.
Syncing products and categories
If they don’t get synced automatically, and the definitions exist, there’s two options:
Syncing definitions
To make sure your definitions go into SItecore (they will be used as the data templates), you need to go into the Content Editor and click ‘Update Data Templates’ in the Sitecore Commerce tab in the ribbon.
Don’t forget to publish – in fact, when there’s new definitions and new products/ categories I’ve had to to a full republish in some cases- and don’t forget to re-index as well.
SitecoreCop is a cool little feature in Sitecore Rocks, which can check a lot of the Sitecore configurations. It can be executed by connecting to a Sitecore instance using Sitecore Explorer, then right-clicking on a Sitecore Item -> SitecoreCop -> Run SitecoreCop.
By default there are already a whole lot of rules available, from checking whether fields contain Lorem Ipsum text to whether the license is about to expire and from whether media items have actual media attached to them to whether the admin password is still the default – and a whole lot more still.
Even so, if one would want to add their own rules to it, that’s also possible but requires a bit more than just the code (which I didn’t find out until @TheRocksGuy gave me some pointers): The assemblyname has to start with Sitecore.Rocks.Server, so for instance Sitecore.Rocks.Server.CustomRules. Also, the assembly needs to reference Sitecore.Rocks.Server.Core and Sitecore.Rocks.Server.Validation.
The class then needs to be marked with the [Validation] attribute, in which you can specify a rule name and the rule category.
namespace Sitecore.Rocks.Server.CustomRules
{
[Validation("This is a custom rule", "Items")]
public class SomeCustomRule : ItemValidation
{
...
}
}
There are multiple existing Validation types to inherit from, such as ItemValidation or RenderingValidation.
You will then need to implement the CanCheck and Check methods. CanCheck will execute to see if the rule can be executed in the context you’re running it in and the Check method has the actual logic.
...
public bool CanCheck(string contextName, Sitecore.Data.Items.Item item)
{
Assert.ArgumentNotNull(contextName, "contextName");
return contextName == "Site";
}
public void Check(ValidationWriter output)
{
// You'd probably want some logic here to make sure it only flags the problem in the right cases.
output.Write(SeverityLevel.Warning, "Title", "This is the problem", "This is the solution");
}
...
When you then execute SitecoreCop (after making sure your assembly is copied across to the bin folder of your webroot) you might have your problem flagged up:
In my posts about custom FxCop rules I mention creating rules for FxCop. In this post I’ll explain how to add the created rules to Sonarqube.
First of all, the assembly needs to be put on the server somewhere. The location doesn’t really matter too much, as long as it’s accessible for Sonarqube. In my case I just dropped it into the default FxCop Rules folder, which is located by default in C:\Program Files (x86)\Microsoft FxCop 10.0\Rules.
After that, Sonarqube needs to be told about the rules as well. The XML is actually fairly similar to the XML file we create for the FxCop rules in the first place.
<?xml version="1.0" encoding="utf-8" ?>
<rules>
<rule key="Classname">
<name><![CDATA[Name for the rule]]></name>
<configKey><![CDATA[Classname@Location\Of\Assembly\Assemblyname.dll]]></configKey>
<description><![CDATA[Rule description]]></description>
</rule>
</rules>
So, to take the example of the GetItemUsingID rule, the XML could look something like this:
<?xml version="1.0" encoding="utf-8" ?>
<rules>
<rule key="GetItemUsingID">
<name><![CDATA[Enforce calling the GetItem method using an ID]]></name>
<configKey><![CDATA[GetItemUsingID@$(FxCopDir)\Rules\Sitecore.FxCop.dll]]></configKey>
<description><!CDATA[Use GUIDS where possible instead of path / name. This will improve performance as well as prevent code breaking if content is renamed or moved in the content tree.]]></description>
</rule>
</rules>
When the XML has been created it has to be put in the FxCop custom rules field in Sonarqube. You can get to this by going to Sonarqube -> Settings -> Configuration -> .NET FxCop:
Before the rules can be used Sonarqube does have to be restarted. Then we can go into Sonarqube -> Settings -> Quality Profiles. Select the active code profile, and go to the inactive FxCop rules. Select the newly added rules to be active, and we’re all done.
I guess this would also be a good time to mention the source code of the 11 rules I initially created is available on Bitbucket and Sitecore’s marketplace, so feel free to create a fork and add your own rules!
If you just want to use the rules, that’s possible as well, just go to the download page on Bitbucket and download the zipfile. The zipfile contains a dll of the initial release at the moment, although I hope to steadily add new rules to the project.
This is the fourthpost in the Sitecore and FxCop series.
I’ve been working on a bunch of easier to implement rules, which I figured I’d run through here. As always, I’m trying to improve the code, either increasing the performance of the code or making it a little more safe to use.
There’s a couple of categories in which I’ve added rules, and I’ll be creating a post per category, as it’ll be a huge post otherwise.
The categories I added rules in are:
ItemAxes & Database
This is one of the most important areas for performance issues. When we are using the ItemAxes to get all ancestors or descendants that can take a very big performance hit. It is often much better and faster to use Sitecore.ContentSearch (granted, this can only be done using Sitecore 7 and up). The same goes for the SelectItems() with Xpath as well.
So the four rules I put in on the ItemAxes are:
On this blogpost I saw some stats for Lucene and fast query, which is not really a fair comparison I think because fast query will always go straight to the database, I figured I’d get a bit of data together.
Consider the following code:
var index = Sitecore.ContentSearch.ContentSearchManager.GetIndex("sitecore_master_index")
{
using (var context = index.CreateSearchContext())
{
// ContentSearch
Stopwatch sw = new Stopwatch();
sw.Start();
var indexed = context.GetQueryable<Sitecore.ContentSearch.SearchTypes.SearchResultItem>().Where(item => item.Name.Contains("s"));
sw.Stop();
Sitecore.Diagnostics.Log.Info(string.Format("ContentSearch. Elapsed time: {0}. Items found: {1}", sw.Elapsed, indexed.ToList().Count));
}
// Fast query
Stopwatch sw2 = new Stopwatch();
sw2.Start();
var fQuery = Sitecore.Configuration.Factory.GetDatabase("master").SelectItems("fast://*[@@name='%s%']");
sw2.Stop();
Sitecore.Diagnostics.Log.Info(string.Format("Fast query. Elapsed time: {0}. Items found: {1}", sw2.Elapsed, fQuery.Length), this);
// Normal query
Stopwatch sw3 = new Stopwatch();
sw3.Start();
var query = Sitecore.Configuration.Factory.GetDatabase("master").SelectItems("//*[contains(@@name, 's')]");
sw3.Stop();
Sitecore.Diagnostics.Log.Info(string.Format("Normal query. Elapsed time: {0}. Items found: {1}", sw3.Elapsed, query.Length), this);
}
This gave me the following output in my Sitecore log file:
INFO ContentSearch. Elapsed time: 00:00:00:0178173. Items found: 8723 INFO Fast query. Elapsed time: 00:00:05.2718443. Items found: 5194 INFO Normal query. Elapsed time: 00:00:09.7881149. Items found: 4320
Those are some pretty big differences. These results are for just under 13000 items. Of course, it’s still not completely honest because the normal query does need to call the Contains function, which I don’t know the performance implications for…
Another big plus of using ContentSearch is that Linq is a lot easier to read in more complex queries than Xpath / Fast query.
From a custom rule perspective, those four rules are extremely simple to create. Almost all rules I added to my project so far use a lot of the same code – If the corresponding classes get called, flag them as warnings on the page.
Of course, as with all rules, there’s bound to be some exceptions and actual legitimate good uses of these classes. The rules are only there to point out that it might be a good idea to re-think that.
This is the fourthpost in the Sitecore and FxCop series.
I’ve been working on a bunch of easier to implement rules, which I figured I’d run through here. As always, I’m trying to improve the code, either increasing the performance of the code or making it a little more safe to use.
There’s a couple of categories in which I’ve added rules, and I’ll be creating a post per category, as it’ll be a huge post otherwise.
The categories I added rules in are:
Fields
I actually added a couple of field rules. In a previous post I was talking about accessing raw field value properly and getting items from the database with IDs rather than a path.
Now, of course it would also make sense to get the field values based not on the fieldname, but the GUID of the particular fields. This of course has the advantage of getting the correct field always, even when the fieldname changes.
I’ll admit this is a rule I had some difficulty with, although it ended up being very easy.
public override void VisitMethodCall(MethodCall methodCall)
{
base.VisitMethodCall(methodCall);
var memberBinding = methodCall.Callee as MemberBinding;
if (memberBinding != null)
{
var methodCalled = memberBinding.BoundMember as Method;
if (methodCalled != null)
{
if (methodCalled.FullName == "Sitecore.Collections.FieldCollection.get_Item(System.String)")
{
Expression parameter = methodCall.Operands[0];
CheckValue(methodCall, parameter);
}
}
}
}
In which CheckValue just tries to match the value of the parameter with a GUID, using a Regular Expression. The thing I had difficulties with was that I was accessing a FieldCollection, and could not inspect the actual line which was making the call.
Another rule which I think will be particularly useful is one that flags where people are trying to get the value from a CheckboxField – to check whether it’s been checked or not. The utils that come with Sitecore seem to be a little under-used, and one of the things that’s possible with the utils is exactly this: Get the value of a checkbox.
Consider the following code snippet:
namespace SomeNamespace
{
public class SomeClass
{
public void SomeMethod()
{
var item = Sitecore.Context.Database.GetItem("{66EC0398-1E67-4D43-B2EB-ED29E3E8E291}");
if (item != null)
{
CheckboxField field = (CheckboxField)item.Fields["checkbox"];
if (field != null)
{
var isChecked = field.Checked;
}
}
}
public void SomeOtherMethod()
{
var item = Sitecore.Context.Database.GetItem("{66EC0398-1E67-4D43-B2EB-ED29E3E8E291}");
if (item != null)
{
var isChecked = MainUtil.GetBool(item["checkbox", false);
}
}
}
}
Of course, instead of calling the field with its fieldname we should do that with the ID – but for this example it’s a bit easier to read like this.
We don’t have to first get the checkboxfield, then check whether it even exists followed by finally getting the value, we can just call Sitecore’s MainUtil.GetBool, pass in the value we want to convert to bool and the default value. A lot safer and it’s a couple lines shorter which should appeal to us lazy programmers 😉
I figured I’d skip the same FxCop rule code this time, as it’s the same as the examples in the other posts. The method we’re checking for this time is Sitecore.Data.Fields.CheckboxField.get_Checked . If that method is indeed called, flag that as a possible problem.
This is the third post in the Sitecore and FxCop series.
I’ve been working on a bunch of easier to implement rules, which I figured I’d run through here. As always, I’m trying to improve the code, either increasing the performance of the code or making it a little more safe to use.
There’s a couple of categories in which I’ve added rules, and I’ll be creating a post per category, as it’ll be a huge post otherwise.
The categories I added rules in are:
Security
The first new FxCop rule I implemented is to make sure to use the Sitecore.Security.Accounts.UserSwitcher, rather than the Sitecore.SecurityModel.SecurityDisabler.
The SecurityDisabler elevates the users permission (temporarily) to administrator rights, which has the potential to be very dangerous to use and errors to potentially be very costly. An interesting side effect is that anything done with the SecurityDisabler will show up as being done by the sitecore\Anonymous role, messing up the audit trail.
However, if we use a UserSwitcher, we will actually tell the system to do something based on a user, with the access rights of that user. Consider the following code snippet:
namespace SomeNamespace
{
public class SomeClass
{
var home = Sitecore.Context.Database.GetItem("{66EC0398-1E67-4D43-B2EB-ED29E3E8E291}");
using (new Sitecore.SecurityModel.SecurityDisabler())
{
home.Delete();
}
Sitecore.Security.Accounts.User someUser = Sitecore.Security.Accounts.User.FromName(@"sitecore\SomeUser", false);
using (new Sitecore.Security.Accounts.UserSwitcher(someUser))
{
home.Delete();
}
}
}
Assuming we have set up the access for the SomeUser account correctly, the home item will not be deleted with the UserSwitcher, but will be deleted with the SecurityDisabler, because we have effectively disabled all security there. In our case, because the SomeUser account has been set up correctly, an AccessDeniedException will be thrown.
Although this is a trivial example, it does point out the dangers of the SecurityDisabler.
The rule is actually also very easy, and is very similar to the rules described in earlier posts. The biggest difference is that because we’re now looking for a constructor rather than a method that’s been called, we need to override the VisitConstruct method.
public override void VisitConstruct(Construct construct)
{
base.VisitConstruct(construct);
Method method = (Method)((MemberBinding)construct.Constructor).BoundMember;
if (method.FullName.Equals("Sitecore.SecurityModel.SecurityDisabler.#ctor", StringComparison.OrdinalIgnorecase)
{
this.Problems.Add(new Problem(this.GetResolution(method), construct));
}
}
We don’t really care about anything else – if the SecurityDisabler is getting called, we want to add a warning that the UserSwitcher should be used.
This is the second post in the Sitecore and FxCop series. Read the first post here.
The second rule I came up with has to do with how to access raw field values.
Let’s say we want to grab the raw value of the Title field on the current item. There’s two different options we can use:
var fieldValue = Sitecore.Context.Item.Fields["Title"].Value;
Which really isn’t correct – what if there is no Title field? Or what if we have a typo in the fieldname? We’d end up with a NullReferenceException. To get around this we could use:
var field = Sitecore.Context.Item.Fields["Title"];
if (field != null)
{
var fieldValue = field.Value;
}
The other option is:
var fieldValue = Sitecore.Context.Item["Title"];
In this case, if there is no Title field, or if we have a typo in the fieldname, we’d get an empty string.
To be absolutely clear, this is only to get the raw field value. To display it on the front end side of things usually one would use a FieldRenderer instead anyway.
So, the second option is shorter and safer. Seems like a good thing to check for.
In the Rules.xml we need to add the following to our existing <Rules> definitions:
<Rule TypeName="AccessRawFieldValueProperly" Category="Sitecore.BestPractice" CheckId="SC002">
<Name>Get the raw field value properly</Name>
<Description>
Accessing the raw field value through the Field property on the item can throw NullReferenceExceptions when
the fieldname changes, the field doesn't exist or there's a misspelling in the fieldname.
</Description>
<Url />
<Resolution>
Raw field value is accessed by Item.Fields["Fieldname"].Value. Raw field values should be accessed by Item["fieldname"]
</Resolution>
<Email />
<MessageLevel Certainty="70">Error</MessageLevel>
<FixCategories>Breaking</FixCategories>
<Owner />
</Rule>
As always, the TypeName needs to match the name of the class.
internal sealed class AccessRawFieldValueProperly : BaseRule
{
public AccessRawFieldValueProperly() : base("AccesssRawFieldValueProperly")
{
}
public override ProblemCollection Check(Member member)
{
var method = member as Method;
if (method != null)
{
VisitStatements(method.Body.Statements);
}
return this.Problems;
}
public override void VisitMethodCall(MethodCall methodCall)
{
var memberBinding = methodCall.Callee as MemberBinding;
if (memberBinding != null)
{
var methodCalled = memberBinding.BoundMember as Method;
if (methodCalled != null)
{
if (methodCalled.FullName == "Sitecore.Data.Fields.Field.get_Value")
{
Problems.Add(new Problem(GetResolution(), methodCall));
}
}
}
base.VisitMethodCall(methodCall);
}
}
Then, when I have a solution with the following code:
public void SomeMethod()
{
var rawFieldValue1 = Sitecore.Context.Item.Fields["fieldname"].Value;
var rawFieldValue2 = Sitecore.Context.Item["fieldname"];
var field = Sitecore.Context.Fields["fieldname"];
}
I would expect to get one error in FxCop. I still want to be able to grab the actual field of course.
When I have a couple more rules in here I’m thinking about releasing this to the Sitecore Marketplace, so your input is very welcome. Is there any rule you would like to see added?
I’ve been looking to create some FxCop rules for Sitecore development to get easier overviews to check (and possible enforce) using best practices on Sitecore development. This is the first post in a series of Sitecore specific rules, which eventually (when there’s a couple of useful rules) will be released through the Sitecore Marketplace as well.
Creating custom rules for FxCop isn’t that hard, especially with some great resources such as this post. Following that post, there’s a couple of simple steps which boil down to the following:
Create a new class library project. The project will of course require references to the FxCop assemblies, FxCopSdk.dll and Microsoft.Cci.dll.
After that, create a rule definition XML, a BaseRule and a custom Rule which inherits BaseRule. The custom Rule can now contain some code that will show if the code is abiding by the rules or breaking them.
Before I give an example of my custom rules, please note that it’s very important to set the Build Action for the XML file as Embedded Resource, otherwise the error ‘Analysis was not performed; at least one valid rules assembly and one valid target file must be specified’ will be thrown.
Oops…
I would strongly advise having a read through the blog post to get a better understanding what’s going on.
Sitecore rules
I’ve created a baseclass called BaseRule, which is exactly the same as in the blog mentioned earlier so I won’t describe that one. As for the rule I’ll describe here, I want to make sure that the GetItem method is called using a GUID, not a path.
To do this, I’ve created a Rules.xml which looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<Rules>
<Rule TypeName="GetItemUsingID" Category="Sitecore.BestPractice" CheckId="SC0001">
<Name>Enforce calling the GetItem method using ID</Name>
<Description>
Use GUIDs where possible instead of path / name. This will improve performance, as well as prevent any breakage if you move content to a new location in the content tree.
</Description>
<Url />
<Resolution>GetItem is called passing in {0}. GetItem should be called passing in an ID.</Resolution>
<Email />
<MessageLevel Certainty="80">Error</MessageLevel>
<FixCategories>NonBreaking</FixCategories>
<Owner />
</Rule>
</Rules>
A couple clarifications: I’ve put the certainty on 80 for now, since all I’m doing is checking if there’s a string parameter that does not have a GUID. I completely ignore things like queries, empty IDs and the like.
Also, the Resolution message could be a little clearer, pointing out where the GetItem method gets called for instance, but for the purpose of this example it’s clear enough.
namespace Sitecore.FxCop
{
using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;
using Microsoft.FxCop.Sdk;
internal sealed class GetItemUsingID : BaseRule
{
public GetItemUsingID() : base("GetItemUsingID")
{
public override ProblemCollection Check(Member member)
{
Method method = member as Method;
if (method != null)
{
this.Visit(method.Body);
}
return this.Problems;
}
public override void VisitMethodCall(MethodCall call)
{
base.VisitMethodCall(call);
Method targetMethod = (Method)((MemberBinding)call.Callee).BoundMember;
if (targetMethod.DeclaringType.FullName.Equals("Sitecore.Data.Database", StringComparison.Ordinal) && targetMethod.Name.Name.Equals("GetItem", StringComparison.Ordinal))
{
Expression endResponse = call.Operands["0"];
if (endResponse.NodeType = NodeType.Literal)
{
var value = ((Literal)endResponse).Value.ToString();
var match = Regex.IsMatch(value, @"\b[A-F0-9]{8}(?:-[A-F0-9]{4}){3}-[A-F0-9]{12}\b", RegexOptions.IgnoreCase);
if (!match)
{
this.Problems.Add(new Problem(this.GetResolution(value, call))
}
}
}
}
}
}
}
A couple of interesting things here:
So now consider the following code:
var database = Sitecore.Data.Database.GetDatabase("master");
var item1 = database.GetItem("/sitecore/content/home");
var item2 = database.GetItem("{4E7AB8D1-6A39-4C8C-BF5B-816F8105BFFD}");
When I then add my custom rule to be inspected by FxCop, I get the following:
A grand start, although I would still only get one message about GetItem even if I would have multiple instances of calling GetItem with a path in the same method.
Which FxCop rules would you like to have regarding Sitecore best practices?
Sitecore and such 