Release notes for Episerver updates

AdminConfigTestSettings caches current settings and never reads again on load balanced machines. This is evident in the Current getter method. There is no need to cache this and whenever Current is read we should just get it from the DynamicDataStore

There is a BOM character created in ABT Script after customer added the AB Testing module into their project. It causes a redundant white line in the site footer, for some customer it adds a white bar on the top of the page.

See MAR-1326 for more details.

Currently we are newing up an instance of TestingContextHelper in the TestManager. We should be getting a service registration of this item.

ConfigurationMonitor resets the load balanced environments at startup causing the rest of the lb machines to toggle the state of ab which then triggers another reset from each lb node, sending another message out to the machines causing another reset message, and so on.

Additionally this configuration monitor is setup to poll every 500msec. There is no reason we need to poll so often. Change to 1 minute

Also added app setting configuration values to override defaults:
EPiServer:Marketing:Testing:TestMonitorSeconds
EPiServer:Marketing:Testing:ConfigurationMonitorSeconds

Redundant ServiceLocator.GetInstance<> calls caused high allocations to load services.

Related to MAR-1302

Problem:

When a user is not a member of one of the default roles (such as CMSAdmin or CMSEditor), the user cannot access or edit an AB Test Controllers. You can now specify a comma-separated list of one or more custom roles to provide access to the AB Test Controllers.

Solution:

1. Add a comma separated list of roles to the app keys. For example:

   <add key="EPiServer:Marketing:Testing:Roles" value="Content_Admins" />

2. Create a new mapped virtual role section. For example:

   <virtualRoles addClaims="true">

   <providers>

   ...

   <add name="LocalAdmins"

   type="EPiServer.Security.MappedRole, EPiServer.Framework"

   roles="SWE_Admins"

   mode="Any" />

   </providers>

3. Add users to those roles so they can access the UI editor again.

Steps to reproduce

1. Create an Alloy site.
2. Install ab testing.
3. Navigate to edit cms pages.
4. Select start.
5. Edit the "Alloy plan" block in the bottom left of the screen.
6. Replace the Alloy plan image with another of your choosing.
7. Click publish / Ab Test changes. The image you see in the challenger should be the image you just replaced.
8. Click cancel.
9. Replace the image with a new image.
10. Publish / Ab Test changes.

Expected:
The image in the challenger spot should be the one used in step 9.

Actual:
The image is the one shown in step 6.

Workaround:
Click revert changes and use the image you wanted to use in step 9

Customers and support have asked for a way to disable AB test processing without uninstalling the NuGet package and re-deploying the application.

Solution
A check box is added to the configuration page. It enables or disables all AB testing processing.
When enabled:

• All normal A/B testing resumes.

When disabled:

• On the Publish Menu, "AB Test changes" option should not be displayed.
• All A/B testing processing (creating views and conversions) is disabled.
• Users can still stop a test or pick a winner.
• Scheduled tests are marked as running at the scheduled time. However, no processing will occur.
• There should be no impact on page load performance.
• On details and pick a winner views, a message indicates that A/B feature is disabled.

The Enabled/Disabled configuration value is preserved and respected after updates and restarts of the web application.
The default state is enabled (that is, AB testing will be enabled by default), including upon upgrade.

Currently, when AB testing is installed, we listen for LoadedContent and LoadedChildren, so we can swap views out for running tests. This hook exists even if there are no active tests. This activity affects performance.

It’s caused by the IsInSystemFolder method of the TestingContextHelper class.

public bool IsInSystemFolder()
    {
bool flag = true;
if (this._contextHelper.HasCurrentContext())
        flag = this._contextHelper.RequestedUrl().ToLower().Contains(this._episerverHelper.GetRootPath().ToLower());
return flag;
    }

If you notice the blue underlines above, you’ll see that this method is called within a RaiseContentEvent repeatedly within an individual request. The number of calls to this method is dependent on the volume of content being loaded, consequently.

This method calls RequestedUrl() and performs a ToLower() method on the resulting string. It does the same for GetRootPath().
You can see on the right side of perf view that these result in a large amount of memory being allocated because the multiplier is called per piece of content being loaded.
Overall, this one method is allocating 146MB of memory to Gen 0 within a 130 second timeframe. Based on an average of 3 pieces of content being loaded, we could reduce this one method’s allocations by 2/3 (or 97MB in 130 seconds) by simply storing the lowered string value within the _contextHelper and episerver helper. If there were 100 pieces of content being loaded, the reduction would be 99/100ths, and so on.