Override a module template

Find the active template and its path relative to priv/templates. Create the same relative path in your site or another active module with a higher selection priority.

Copy only the structure you need to change. When the original template offers blocks, extend it using the supported inheritance pattern rather than duplicating a large file. Check tag#overrules for extending the next matching template.

Load the affected page and inspect the selected template again. A successful compile does not prove that your override is used. Test neighboring categories and languages if the original template serves more than one page type.

For example, place this in the same relative template path as the template being overridden:

{% overrules %}
{% block content %}
    {% inherit %}
    <p>{_ Contact us for more information. _}</p>
{% endblock %}

Use a block that exists in the original. {% inherit %} keeps its content; omit it only when replacing that entire block is intentional. This is especially important for admin panels, where copying a small fragment over a large panel can remove controls.

Dependencies, capabilities, and module priority

The main site or module can declare:

-mod_depends([mod_base]).
-mod_prio(500).

Dependencies express requirements for activation. Modules can also declare provided capabilities with -mod_provides; depend on an established capability when your feature requires that service rather than one particular implementation.

Priority determines ordering when modules supply competing resources such as templates. Lower numerical priorities take precedence. Sites commonly use a low priority so their templates override generic module templates.

Do not use priority to hide a missing dependency or duplicate Erlang module name. Check which modules are active, inspect the selected template, and make one intentional override at a time.