Content configuration implies defining (figure 1):
- a mapping between template and profile (which profile should be used with the template);
- whether to make a record in mailing history;
- whether to track if a customer opened the email;
- whether to track if a customer followed a link from the email to the store;
- if the template is enabled.
Figure 1. Templates configuration
There are 3 configuration levels (from more specific to more general): template level, language level, store level. To resolve configuration they are searched from more specific level to more general up to the first enabled setting. For example, let’s take template ‘Admin’ and ‘Log’ setting (recording emailing history). The setting is disabled at template and language levels but enabled at the store level (figure 2). In this case, ‘Log’ setting will be resolved to ‘enabled’ since it enabled at store level. If you disable this configuration on all the levels – it will be resolved to ‘disabled’ and there will be no records in ‘History’ table for ‘Admin’ template.
Figure 2. Settings priority
Resolving profile mapping is a bit more complicated since the extension takes into consideration mapping defined at ‘Content’ tab. The algorithm is following: firstly is checked a language level mapping on ‘Content’ tab (figure 3), then a store level mapping on ‘Content’ tab (figure 4). ‘Default’ mapping means no mapping. If no mapping is detected, then normal setting resolution takes place as described above.
Figure 3. Content tab. Language level profile mapping
Figure 4. Content tab. Store level profile mapping
The last thing to mention is template fallback system. When the extension resolves template, it starts with the longest possible ‘template hook’. For example, let’s take the email, which is sent to a customer when order status changes to ‘Canceled’. This email will be resolved to the template ‘Customer – Order status: Canceled’ (figure 5).
Figure 5. Content tab
Action hook for this template will be: ‘customer.order.update.7’. So the extension will start with ‘customer.order.update.7’ and will check if there is a template with such action hook and if this template is enabled. If there is no template or the template is disabled, the extension will discard rightmost part of the template hook (up to the first period) and will try that new template hook (‘customer.order.update’), and so on till template will be found.
The template hierarchy is following (more general templates are at the top):
|1||Default. Action hook: ‘*’. Is not shown in templates’ action hook structure|
|2||Admin. Action hook: ‘dashboard’||Customer. Action hook: ‘customer’||Affiliate. Action hook: ‘affiliate’||Newsletter. Action hook: ‘newsletter’|
|3||Dashboard emails (sent to admin)||Customer emails (sent to customers)||Affiliate emails (sent to affiliates)||Newsletter emails|
Figure 6. Templates hierarchy
So fallback stack for template ‘Customer – Order status: Canceled’ will be following: ‘Customer – Order status: Canceled’ (‘customer.order.update.7’) > ‘Customer – Order update’ (‘customer.order.update’) > ‘Customer’ (‘customer’) > ‘Default’ (‘*’). There is no template with action hook ‘customer.order’. As was mentioned earlier, if there is no template with specific action hook or if this template is disabled (figure 7) then the next template from a fallback stack will be taken until template can be resolved. If all the templates in a fallback stack are disabled it will be as if the extension itself is disabled and OpenCart email will be sent.
Figure 7. Disabling template
For the most cases, all configuration you need to do is to map profile on the store level (figure 8).
Figure 8. Store level profile mapping
Without explicit mapping, all the templates will be mapped to ‘Extended’ profile. In order to check current mapping open some tab except for ‘Profile’, open preview window and select a specific template – in the preview window, you’ll see the current mapping (figure 9).
Figure 9. Profile mapping preview