An exception is thrown when updating dynamic module fields on multilingual Sitefinity projects with configurations stored in the database

Jul 20, 2016
Knowledge

Title

URL Name

An-exception-is-thrown-when-updating-dynamic-module-fields-on-multilingual-Sitefinity-projects-with-configurations-stored-in-the-database

Article Number

000186981

Environment

Product: Sitefinity Version: 5.x, 6.x, 7.0, 7.1, 7.2 OS: All supported OS versions Database: Microsoft SQL Server 2012 SP2

Question/Problem Description

Exception is thrown when updating field of modules created with the Module Builder in a Multilingual Sitefinity project using configurations in database.

Invalid attribute "languageSource" for element "Telerik.Sitefinity.Web.UI.ContentUI.Views.Backend.Master.Config.DynamicMarkupGeneratorElement".

The exception prevents the site from starting once it is thrown.

Steps to Reproduce

Clarifying Information

Sitefinity projects meeting all of the below criteria will experience the problem:

More than one frontend language enabled (Multilingual)
Configurations initially stored on the FileSystem (default setting) and at some point set to store their configurations in database (e.g. deployed to Windows Azure)
Had some of their dynamic modules created while the configurations were stored on the FileSystem and the project was configured with more than one frontend language (Multilingual). Changes to the fields of these modules once the configuration storage has moved to Database will result in the stated exception.

Error Message

Invalid attribute "languageSource" for element "Telerik.Sitefinity.Web.UI.ContentUI.Views.Backend.Master.Config.DynamicMarkupGeneratorElement".

Defect Number

http://feedback.telerik.com/Project/153/Feedback/Details/131159-dynamic-modules-cannot-be-edited-after-moving-the-configuration-to-the-database-i

Enhancement Number

Cause

The issue is caused by a bug in Sitefinity.

Resolution

The bug is fixed in Sitefinity 7.3.5600.0. Upgrade to this version or later for the bug fix.

Workaround

1. Remove the offending entry in DynamicModulesConfig.config

After changing your project configuration files storage to be Database (Move configurations to database: http://docs.sitefinity.com/administration-turn-on-database-storage-for-configuration-files) Sitefinity starts writing any changes to the corresponding configuration files in the sf_xml_config_items table of the database. Before the discussed exception is thrown an offending element is written in the DynamicModulesConfig.config file, and it should be cleared. To remove the offending entry please:

- Perform a full backup of the database.

- Execute the below SQL script against the database:

update [dbo].[sf_xml_config_items]

set dta = replace(

dta ,

'<generatorSettings languageSource="Frontend" itemsInGroupCount="6" groupTag="div" itemTag="div" />',

''

)

where path = 'DynamicModulesConfig.config'

2. Merge the FileSystem portion of DynamicModulesConfig.config with the one stored in the database

Once the steps outlined in 1. are performed, the project will be running fine until modification is done to one of the dynamic module fields. To fix this, merge the DynamicModuleConfig.config contents present on the FileSystem with the ones stored in the database. Do this with our Config API:

var manager = ConfigManager.GetManager();

manager.Provider.SuppressSecurityChecks = true;

//Start with DB storage mode, then dynamically switch to FileSystem, so only the FileSystem configuration is read

var field = typeof(XmlConfigProvider).GetFields(BindingFlags.Instance | BindingFlags.NonPublic).Where(f => f.Name == "storageMode").FirstOrDefault();

field.SetValue(manager.Provider, ConfigStorageMode.FileSystem);

//Load the DynamicModulesConfig

var section = manager.GetSection("DynamicModulesConfig", null, null);

//Load its views

var contentViewConfig = section as IContentViewConfig;

if (contentViewConfig != null)

{

foreach (var control in contentViewConfig.ContentViewControls.Values)

{

//Note: Do not remove this section - it ensures lazy view configs are loaded!!!

foreach (var view in control.ViewsConfig.Values)

{ }

}

//Set StorageMode to be Database so we can persist everythign in the DB

field.SetValue(manager.Provider, ConfigStorageMode.Database);

//Rename the existing DynamicModulesConfig.config to DynamicModulesConfig.config.old - this way Sitefinity is "tricked" to write everything in the DB

var configStorageFolder = HostingEnvironment.MapPath(Config.SectionHandler.Settings.StorageFolder);

string oldFilePath = string.Concat(configStorageFolder, section.GetType().Name, configFileExtension); // Full path of old file

string newFilePath = string.Concat(oldFilePath, renamedConfigFileExtension); // Full path of new file

if (File.Exists(oldFilePath))

{

if (File.Exists(newFilePath))

File.Delete(newFilePath);

File.Move(oldFilePath, newFilePath);

}

manager.SaveSection(section);

manager.Provider.SuppressSecurityChecks = false;

For your convenience a small ASP.NET WebForm that automates this task is attached.

- Include the attached MoveConfigurationToDatabase in your project,

- build it, and navigate to it in the browser

- when the page loads just press the "Move Configuration" button.

Alternatively the MoveConfigurationToDatabaseInlineCSharp WebForm can be used. It has the same functionality, but the code-behind logic has been moved inline in the markup, thus allowing to simply upload it to the Sitefinity application and run it, without building the solution.

The module's fields can now be modified without problems.

Notes

Keyword Phrase

Last Modified Date

7/20/2016 2:14 PM

An exception is thrown when updating dynamic module fields on multilingual Sitefinity projects with configurations stored in the database

Files(1)

Was this article helpful?

Was this article helpful?

An exception is thrown when updating dynamic module fields on multilingual Sitefinity projects with configurations stored in the database

Information

Related Articles