Common errors when developing an Episerver site

At Zone, we spend a lot of time developing and maintaining large-scale Episerver builds with a team split across the UK, Romania and India. With a large codebase and lots of developers working at the same time, there are some errors we encounter occasionally that can take time a lot of time to identify, but are quick to fix when you know the solution.

Changes to content types are not reflected in the CMS

Problem

If you are using a code-first approach to create and modify pages and blocks, and you notice that changes are not being reflected when you view the content in the CMS, you may have a problem with assembly versions.

You can confirm that you are experiencing this issue by navigating to the Content Type tab in the Admin section of the Episerver CMS. If you select a content type from the left-hand menu, you will see a yellow warning message like this:

Changes in the model for this page type were ignored because its version (1.0.0.0) is lower than version in the database(2.0.0.0)

This can occur after restoring a backup of the CMS database from an environment where semantic versioning (eg GitVersion) is being used, to an environment not using any versioning – such as a local development environment.

Episerver stores the current version of an assembly in the database when syncing changes to the model. If the site is loaded with a version of the assembly lower than the one stored in the database, it will not update the model to avoid overwriting the most recent update with older changes.

Solution

You can fix this by running a short SQL script in the database to reset the version of the assemblies to correct version.

UPDATE [dbo].[tblContentType]
SET [ModelType] = REPLACE(ModelType, ', Version=2.0.0.0,', ', Version=1.0.0.0,')
WHERE ModelType like '%, Version=2.0.0.0,%'

You should replace 2.0.0.0 with the version that is incorrectly set in the database, and 1.0.0.0 with the version in the assembly info.

Website pages are loading slower than usual in a development environment

Problem

When loading a website that uses Episerver Find, pages suddenly take a lot longer to load. When checking the Episerver logs, you may find errors like this:

EPiServer.Find.ServiceException: The remote server returned an error: (401) Unauthorized.

We have experienced this when developing locally - where we may be using an Episerver Find demo licence. Since the demo licence only lasts for 30 days, you will see this error when the licence expires if you are calling Find during page load. It is a bit more obvious if your website crashes and you see a Yellow Screen of Death (YSOD), but if you are handling errors in a more graceful way, it may be harder to identify the cause.

Solution

Generate a new demo licence at https://find.episerver.com/ and update the search index in your Web.config.

YSOD for all pages

Problem

Loading the site or CMS shows the .NET YSOD with an error message like the following:

ERROR EPiServer.Framework.Initialization.InitializationEngine: Initialize action failed for 'Initialize on class EPiServer.Initialization.Internal.ModelSyncInitialization, EPiServer, Version=11.10.1.0, Culture=neutral, PublicKeyToken=8fe83dea738b45b7'

The DELETE statement conflicted with the REFERENCE constraint "FK_tblContent_tblContentType". The conflict occurred in database "myCmsDatabase", table "dbo.tblContent", column 'fkContentTypeID'.

This error, or similar sounding errors, can occur for a number of reasons. Lots of causes and solutions are discussed in the Episerver forums: https://world.episerver.com/Search?searchQuery=statement+conflicted&from=151704

The error is triggered from SQL Server when a command to delete a row of data conflicts with a constraint on one of the columns in the database table.

In this case, it seems to occur during the model sync as Episerver initialises after a page or block type has been deleted from code. I have not been able to identify the exact conditions that lead to this error in Episerver but I have seen it happen several times after deleting a page type and deploying the code to another environment.  

If you check the tblContent table in the Episerver database, you may find you have orphaned rows that are flagged as Deleted but are not present in the Recycle Bin of the CMS.

Solution

1. Empty the Recycle Bin in the CMS
2. Run a SQL query to check if there are still any rows remaining in the database that are set as Deleted:
   

   SELECT * 
   FROM [tblContent]
   WHERE Deleted = 1

3. If there are rows returned by the query after emptying the recycle bin, delete the rows from the table:
   

   DELETE 
   FROM [tblContent]
   WHERE Deleted = 1​

The site should now load as normal.

Front-end assets redirect to the login page

Problem

We have experienced this error when a developer is setting up a new machine or a new project. The issue happens when loading the website – front assets such as CSS or JavaScript fail to load and if you attempt to load the assets directly you are taken to the Episerver login page.

Logging into the CMS will allow the assets to be loaded, but this issue is caused by misconfigured Windows security permissions for assets folders for IUSR or IIS_IUSRS.

Solution

Right-click on the root folder of the website, select Properties and the Security tab.

Ensure that IUSR and IIS_IUSRS have at least read access to the root folder and subfolders (IIS_IUSRS requires write access to the blobs folder).

The assets should load correctly once these permissions are configured.