m_config

  • Module: core

Zotonic has two places where a site’s configuration is kept:

  • the site’s config file (accessible through m_site)
  • the site’s config database table. Entries in the config table overrule any module settings from the config file.

Note

Configuration keys are only accessible from templates using {{ m.config }} for users with administrator rights. To access other configs, use or add specific models.

All m_config keys can be thought of as tuples {Module, Key, Value}, where Value is a complex value that can have a text value but also any other properties. Only configuration with text values can be edited in admin.

The config model table has different access methods. Below are examples of what is possible and how to access the configuration.

Fetch the value of a config key

Example, fetching the config key value of mod_emailer.from_email:

{{ m.config.mod_emailer.email_from.value }}

Or, from Erlang:

m_config:get_value(mod_emailer, email_from, Context).

Where m.config.mod_emailer.email_from returns a property list which is much like:

[
    {id,5},
    {module,<<"mod_emailer">>},
    {key,<<"email_from">>},
    {value,<<"no-reply@example.com">>},
    {props,undefined},
    {created,{{2009,11,7},{20,48,27}}},
    {modified,{{2009,11,7},{20,48,27}}}
]

If the database does not contain a mod_email.email_from configuration parameter, Zotonic falls back to the site config file and tries to find the parameter there.

When the config key would have any extra value (besides the value property) then they would be visible as extra properties and the property “props” would not have been present.

When the configuration comes from the site config then the id property is not present.

Fetching all configurations of a module

This only returns configurations from the config table; configuration keys from the site config are not mixed in. This might change in the futurr:

{% for key, value in m.config.mod_emailer %}

{% endfor %}

Fetching all configurations

This only returns configurations from the config table. Configurations from the site config are not mixed in. This might change in the future:

{% for mod,keys in m.config %}
    {% for key,value in keys %}

    {% endfor %}
{% endfor %}

Listening for config changes

m_config uses z_notifier to broadcast events when values are changed or deleted:

#m_config_update{module=Module, key=Key, value=Value}

for “complex” property value updates/inserts a slighly different notification is used:

#m_config_update_prop{module=Module, key=Key, prop=Prop, value=Value}

For config key deletes, the #m_config_update{} record is broadcast with undefined for the value:

#m_config_update{module=Module, key=Key, value=undefined}