When you define a configuration key at the same level of the configuration cascade in multiple CloudCannon Configuration Files, CloudCannon will preferentially use configuration from the last file in the import order.
CloudCannon uses the localeCompare() Javascript function when importing definitions for object keys in the main Configuration File and other Configuration Files referenced by a *_from_glob key. Any inline configuration in your Configuration File is used first, followed by the imported configuration from other files in alphabetical Unicode order.
Unicode order respects upper and lowercase letters, punctuation, locale-specific rules for special characters, and accented letters, ensuring proper ordering for international filenames.
Multiple configurations for an array key#
When you define multiple values for an array configuration key (e.g., _structures.*.values), CloudCannon will not overwrite any array item with another. Instead, array items referenced in another Configuration File using a *_from_glob key are appended to arrays defined in your main Configuration File. The order of array items in the array will follow the import order (i.e., inline configuration first, followed by configuration from other files in Unicode order).
_structures:
staff:
style: modal
values_from_glob:
- /.cloudcannon/boardMember.cloudcannon.structure_value.yml
values:
- label: Employee
value:
name:
title:
profile_picture:
- label: Manager
value:
name:
title:
profile_picture:
url:
The main Configuration File references another Configuration File, board_member.cloudcannon.structure_value.yml, using _structures.staff.values_from_glob.
In the main Configuration File, there are two array items in _structures.staff.values, "Employee" and "Manager".
{
"_structures": {
"staff": {
"style": "modal",
"values_from_glob": [
"/.cloudcannon/boardMember.cloudcannon.structure_value.yml"
],
"values": [
{
"label": "Employee",
"value": {
"name": null,
"title": null,
"profile_picture": null
}
},
{
"label": "Manager",
"value": {
"name": null,
"title": null,
"profile_picture": null,
"url": null
}
}
]
}
}
}The main Configuration File references another Configuration File, board_member.cloudcannon.structure_value.yml, using _structures.staff.values_from_glob.
In the main Configuration File, there are two array items in _structures.staff.values, "Employee" and "Manager".
label: Board
value:
name:
title:
profile_picture:
url:
description:
In boardMember.cloudcannon.structure-value.yml, there is one array item, "Board". CloudCannon will append this value after the inline values defined in the main Configuration File as the boardMember.cloudcannon.structure-value.yml file is last in the import order (inline values are always first).
{
"label": "Board",
"value": {
"name": null,
"title": null,
"profile_picture": null,
"url": null,
"description": null
}
}In boardMember.cloudcannon.structure-value.yml, there is one array item, "Board". CloudCannon will append this value after the inline values defined in the main Configuration File as the boardMember.cloudcannon.structure-value.yml file is last in the import order (inline values are always first).
Multiple configurations for an object key#
When you define multiple values for an object configuration key (e.g., _inputs, collection_config), CloudCannon will preferentially use the configuration of the from the last file in the import order (i.e., inline configuration first, followed by configuration from other files in Unicode order).
This means, when you define conflicting object keys inline in your main Configuration File and in another Configuration File referenced by a *_from_glob key, CloudCannon will preferentially use the configuration defined outside of the main Configuration File.
_inputs_from_glob:
- /.cloudcannon/contact_address.cloudcannon.inputs.yml
_inputs:
contact_address:
type: url
options:
hide_link_to_address: true
The main Configuration File references another Configuration File, contact_address.cloudcannon.inputs.yml, using _inputs_from_glob.
The main Configuration File defines the contact_address Input inline. CloudCannon will not use this configuration as it is first in the import order.
{
"_inputs_from_glob": [
"/.cloudcannon/contact_address.cloudcannon.inputs.yml"
],
"_inputs": {
"contact_address": {
"type": "url",
"options": {
"hide_link_to_address": true
}
}
}
}The main Configuration File references another Configuration File, contact_address.cloudcannon.inputs.yml, using _inputs_from_glob.
The main Configuration File defines the contact_address Input inline. CloudCannon will not use this configuration as it is first in the import order.
_inputs:
contact_address:
type: url
options:
hide_link_to_address: false
The contact_address.cloudcannon.inputs.yml file also defines the contact_address Input inline. CloudCannon will use this configuration as it is last in the import order.
{
"_inputs": {
"contact_address": {
"type": "url",
"options": {
"hide_link_to_address": false
}
}
}
}The contact_address.cloudcannon.inputs.yml file also defines the contact_address Input inline. CloudCannon will use this configuration as it is last in the import order.
Additionally, if you define a conflicting object key in multiple Configuration Files referenced by a *_from_glob key, CloudCannon will preferentially use the configuration defined in files later in the import order. The order of files in your *_from_glob array does not affect import order.
collections_config_from_glob:
- /.cloudcannon/posts.cloudcannon.collections.yml
- /.cloudcannon/blog.cloudcannon.collections.yml
The main Configuration File references two Configuration Files using collections_config_from_glob, posts.cloudcannon.structures.yml and blog.cloudcannon.structures.yml. However, both these Configuration Files define the same Collection, content.
{
"collections_config_from_glob": [
"/.cloudcannon/posts.cloudcannon.collections.yml",
"/.cloudcannon/blog.cloudcannon.collections.yml"
]
}The main Configuration File references two Configuration Files using collections_config_from_glob, posts.cloudcannon.structures.yml and blog.cloudcannon.structures.yml. However, both these Configuration Files define the same Collection, content.
content:
path: content
icon: wysiwyg
The posts.cloudcannon.structures.yml defines the content Collection. CloudCannon will use this configuration as it is last in the import order (posts is after blog in Unicode order).
{
"content": {
"path": "content",
"icon": "wysiwyg"
}
}The posts.cloudcannon.structures.yml defines the content Collection. CloudCannon will use this configuration as it is last in the import order (posts is after blog in Unicode order).
content:
path: content
icon: post_add
The blog.cloudcannon.structures.yml also defines the content Collection. CloudCannon will not use this configuration as it is first in the import order (posts is after blog in Unicode order).
{
"content": {
"path": "content",
"icon": "post_add"
}
}The blog.cloudcannon.structures.yml also defines the content Collection. CloudCannon will not use this configuration as it is first in the import order (posts is after blog in Unicode order).