The Control Panel node contains advanced setting for various apps and features in Dynamicweb - see below for a short description of each setting.
Using the Language Management settings, you can change or customize several aspects of working with language layers.
With the first Language Management settings (Figure 2.1), you can:
- Deactivate new paragraphs/pages on language layers, when created on the master website. They must then be manually activated on each language layer
This is useful if you do not want to publish paragraphs/pages on a language layer before they have been translated
- Allow paragraph/page operations on language layers to create and work with paragraphs/pages on language layers in the standard manner
Note: If you want to rearrange your content later, keep in mind that structural changes made on a language layer are not reflected on either the master page or any other language layers
- Allow the creation of global paragraphs from a language layer
With the other settings (Figure 2.2), you can customize if and how changes made to a master paragraph should be automatically copied to language layers:
- Copy master changes to language versions if values are the same (pages)/(paragraphs). All changes made to the properties of a master page/paragraph will automatically be copied to any language versions of that same page/paragraph if and only if their values are already identical
- Pages example: If you change the Title value on a master page from "Frontpage" to "MyCompany", then only the language versions of the page that also has "Frontpage" as Title value will be changed
- Paragraphs note: If the content of a language version paragraph differs in any way from its master (markup language included depending on the Compare paragraphs as text setting), it will not be altered by changes made to the master
- Compare paragraphs as text to ignore any markup language when comparing master and language version paragraphs for the purpose of the above setting
Finally, with the last settings (Figure 2.3), you can:
- Use website name in dropdowns instead of the website culture name
- Choose to make the published/unpublished state on language versions independent of the master version
With the Maps settings (Figure 3.1), you can:
- Enter your default Google API credentials, which are needed if you exceed the Google-imposed limit on API requests (these are overriden if new credentials are entered on a Maps app)
- Run batch updates of the location information for users and user groups – this will cause the app to reload location information. You will be presented with a list of users alongside information on whether or not their location has been updated or not
Read about the setting in this article.
The Users section contains settings relevant for a number of functions related to user management.
Custom user fields
On some solutions you may need to use custom fields, e.g. when importing users from other systems, where critical information is not matched by one of the regular user fields in Dynamicweb.
With the Custom fields and Custom address fields settings (Figure 6.1), you can create and edit custom (address) fields.
To do so, click Edit custom (address) fields in the list of settings, to bring up the custom fields view (Figure 6.2).
From here, you can add new custom fields by specifying a name, a system name and a type.
With the upload settings (Figure 7.1), you can select between having a global custom files folder for upload or having one for each user.
You can also customize the location of the Extranet secure folder (Figure 7.2).
To ensure that the files in the secure folder are protected, your server must be configured to disallow direct download. Contact your hosting company for further information. If you are hosting your own solution, simply disable the read permission on the secure folder in your IIS.
New permission model
With the Permissions settings, you can choose to use the new pemission model here. Changing this setting will force a logoff.
Extranet login and cookie settings
With the Extranet login limitations settings (Figure 9.1), you can set a limit on the number of failed attempts allowed – and customize how the system should treat failed login attempts.
You can also customize, for how long (in days) a login cookie should be valid (Figure 9.2).
Password security settings
With the Password security settings, you can control the password security settings for both extranet users and backend administration users. Apart from the scope of the settings, the options (Figure 10.1) are are identical to each other.
- Check the Encrypt checkbox to enable encryption by default – in combination with the extranet app, and user initiated profile creation, this means that your users will not have to worry about their password security. If checked, you can select your preferred hashing algorithm
- Set a password expiration interval, from 30 days to a year
- Specify the number of new passwords which must be used before an old password can be used again
- Select the minimum required password complexity level
- Specify the minimum number of characters a password should contain
- Encrypt all existing users (irreversible)
On solutions with multiple websites, you may want to include a shopID when logging users in to the solution (Figure 11.1). This allows for e.g. 2 different user records with the same email logging into 2 different websites.
Be advised, that you need the Multishop Advanced module for this integration to be possible, and that each shop needs to belong to its own website – or the system will not be able to figure out which user to login.
Remember to select a default shop in the Ecommerce settings set in Website properties (Apps > Websites > Edit website > Ecommerce). When using e.g recover password include a <input type="hidden" value"shopX"> in the template to help select the proper user instance.
With the Impersonation settings (Figure 12.1), you can switch between impersonation modes.
You can choose between the following:
- Only tag orders with impersonating user enables the Only orders mode and tags orders placed using impersonation with "(Current User) on behalf of (Impersonated User)"
- Replace current user with impersonated user enables the Full impersonation mode and allows the current user to act (e.g. place orders or make forum posts) directly for the impersonated user
When the Full impersonation mode is selected, you can check Use impersonator for permissions. This means that when user A impersonates user B, permissions, e.g. access to a page, will be based on user A. Things like prices will still be based on user B.
You can read more about the different impersonation modes and how to set up impersonation in this article.
Smart search settings
The Smart search setting (Figure 13.1) lets you control how often your smart searched should be recalculated.
From the File Manager settings, you have access to a number of advanced configuration options (Figure 14.1) for the file manager.
With the settings, you can:
- Activate one or more of the renaming options for uploaded files
- Limit (or extend) the max subfolder count – the default is a maximum of 500 subfolders
- Create system meta fields applied to all files in the file manager – read about meta fields here
With External Authentication, you can integrate with social media platforms, and allow users to log in or create an account using e.g. their Google, Twitter or Facebook accounts.
You can read more about External Authentication and the advanced settings in this article.
The Item settings unsurprisingly contain settings related to items (Figure 16.1).
The Google Fonts API Key settings lets you enter an API key for Google Fonts, which is used to pull combinations of font names and font weights in the Google Font item type.
The Synchronize settings let you control how item types are synchronized between two copies of a solution, running on the same instance of the database:
- "Files" means that every developer will have a local copy of the item type definitions. It is XML files placed in \Files\System\Items. Consider 2 devs sharing the same database but they have local copies of /files. If dev1 makes a change to an item type on his machine, then the schema on the database gets updated with this new field. Now dev2 goes and do stuff on the solution, but since he does not have the new schema, but the old one, the field gets deleted again. And this will eventually cause the total loss of data.
- "Database" and syncronisation means that all those XML files with itemtypes gets moved into the database in the table ItemTypeDefinitions - so when one developer makes a change, it will go into the database, and developer 2 will get the same schema right away.
- "All" is a combination, which means that DW gives you a local copy of the XML file from the database and adds the changes you make to the database so it gets synced to dev2.
All solutions must be set to the same synchronization settings for everything to work as intended.