The classic check to ensure a test is running is that the red dot (see image above) on the optimization tab is shown, if so all was good. Unfortunately, that is not true, as it is possible that the red dot is shown, but in fact the tests for the page are not running. Sitecore are currently fixing this issue.
So how do we know if the test is running or not? You have to check that status window, for example below the test is NOT running, as the status window says “No Tests”. Thanks to Alec Orlov from sitecore for this tip. If the test is running, the status window will contain the estimated number of days for the test to complete, see below.
So what can cause this issue? Well in this case, the customer had started (Deployed) the test from the “Analytics Testing Workflow” see the image below.
It worked for some Sitecore versions and or with a solution specific patch, but it does not work in general. The workflow is in an internal Sitecore workflow, which should not be used. Please follow the official Sitecore documentation, to start your tests.
If you have a test that is not running, a common issue is related to the fact that the test item which is stored under /sitecore/system/Marketing Control Panel/Test Lab is not in the correct workflow state (must be in deployed state) and or is not published.
Every time I have used AD for providing access to Sitecore, the active directory (AD) structure is crazy and recently I had a customer that had over 18000 roles, which made it difficult to assign roles and it killed the performance of the Sitecore client, as each user had at least 500 roles. Therefore Sitecore to evaluate the combination of a lot of roles to determine if they had read access or not. I talked to the department responsible for the AD setup about changing and or creating a folder that only contained the Sitecore related roles, but this was not possible.
Initially I thought I would have to make own LDAP provider which derives from the standard provider, but I discovered this was not necessary as the LDAP module provides the functionality as standard.
Custom Filter provide the ability to filter the roles and or users returned from the AD (see section 4.1 for full documentation).The custom filter uses the standard LDAP query syntax (see MSDN) to specify how the user or roles are filtered.
The following example ensures only roles, which contain Sitecore and or the special operations role; are imported into Sitecore. The Custom
According to Sitecore documentation, both the User and Role provider must have the same CustomFilter, and that is why the (objectCategory=person) is added so all users are also imported regardless of their name.
I hope this blog post will help others using LDAP to control what roles or users are shown within sitecore.
Whilst reviewing a solution I came across the class in the image below, and felt the need for a rant about using regions.
If you need regions, you should consider if the class has more than one RESPONSIBILITYand or is too big! In this case it is responsible for everything and over 1800 lines of code:-(
So a tip, if you need to use the #REGION’s in your code. I would advise you take a few moments and ensure that the class does not have mixed responsibilities. If it does have more than one responsibility you should split it up into a number of smaller classes with a clearly defined responsibility.
I re-factored the class into the following classes:
4 Service classes
13 Model classes.
In fact by the time I had removed all the code from the class I found that it was not required at all 🙂