Finding the Base.html

1

Hello together,

in my registration process I have some emails which are based on each other. Therefore i should have a base.html where all of my other files are relating back to. But I can´t find this file in this folder. Based on that I cannot find a macro which is used in one of the other files and which I have to edit. Is there a way to find those files?

Greetings Torben

2

It’s a bit unclear what you are asking about… are you modifying Indico’s code or trying to override templates?

3

I am trying to override templates. Sry if it is unclear.

4

Which ones in particular? Inheritance uses {% extends ... %} in the template, but if you have problems finding the base template it’s easier if you tell us which template you are overriding…

5

I am overriding nearly each template in the registration folder. The last step before the base.html file is the base_registration.html file

6

OK… so base.html is used for all HTML emails indico sends. It’s in indico/web/templates/emails/base.html

7

Okay i got that. But now my problem extends that i can’t see where I edit the “registration.state.title|lower” or is that not possible? I want to have the registration title in german.

8

Ah. So that’s not really related to template overrides nor inheritance. registration.state is an enum member:

class RegistrationState(RichIntEnum):
    __titles__ = [None, L_('Completed'), L_('Pending'), L_('Rejected'), L_('Withdrawn'), L_('Awaiting payment')]
    complete = 1
    pending = 2
    rejected = 3
    withdrawn = 4
    unpaid = 5

So if you want to translate those titles in your overridden templates, you’d need something like this:

{% if registration.state.name == 'complete' %}Abgeschlossen
{%- elif registration.state.name == 'pending' %}In Bearbeitung
{%- endif %}

(with more branches for the other states of course)

1 Like
9

Thank you! I have just one question. Only those things which start with render_ … are macros which can be edited in the html files?

10

Any example? In principle any template blocks ({% block something %}) can be easily overridden; in case of templates that do not use blocks you may be able to override macros or have to replace the whole template (which is a bit risky during upgrades since you may miss changes that were made upstream)

11

One example would be “{% macro render_registration_info() -%}”

12

Ah yes, those are basically like functions in normal programming code. We use them for that purpose, not for overriding. IIRC. Jinja macros are a bit peculiar when template inheritance is involved, so not sure if re-defining a macro in a template override will work well… (just give it a try)

1 Like