Fixed E-Mail templater is missing params

K

Kirby

Well-known member
Affected version
2.2.11
The email templaters is missing various params (like xf, contactUrl, tosUrl, privacyPolicyUrl, homePageUrl, time and timeDetails).

Especially not being able to access $xf.app is a bit of a PITA.

Can those parameters be added?
 
I can see the use case for many of these but can you elaborate on the use case for the app object being available? I don’t have a strong reason to exclude it, just curious.
 
Sure :)

Being able to access to app object gives a lot of flexibility, for example we could get tosUrl even if no dedicated param is available.

Another quite useful use case is to include links to content like threads without hardcoding the title and URL (which would require updating them if the title or URL changes -> manual maintenance overhead):

Code: 
<xf:set var="$thread" value="{{ $xf.app.get('em').find('XF:Thread', 123) }}" />
<a href="{{ link('thread', $thread) }}">{$thread.title}</a>

Obviously this could be done via an Add-on, but being able to just use template code simplifies things in some cases.
 
Fair enough :) I know you know what you're doing in particular, but the power it comes with can also be a liability. Our preference is that things like database queries are avoided inside templates as a rule of thumb, but I understand it's a useful escape hatch.
 
It is incredible useful to be able to call (template valid) public repository methods instead of needing to write a a template listener and inject arguments that way
 
Noted, we can include it.

I'm mostly asking because we might offer more canonical access for common use cases (including the entity manager and repositories) and limit exposure to the entire container in templates at some point in the future. We don't want to be overly restrictive and are happy to accommodate within reason, but some amount of friction is there by design.
 
limit exposure to the entire container in templates at some point in the future
Click to expand...
Totally understandable even though such a change may require more work (for 3rd party Add-ons) then.

My main complaint right now is that the container is available for public and admin templates, but not email - this restriction doesn't make sense to me.

It should either be available for all template types - or none.
 
Last edited:
Yes I agree, it doesn’t make sense to apply the limitation arbitrarily. I just wanted to understand the use cases better for the future.
 
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.3.7).

Change log:
Expand global email template parameters
Click to expand...
There may be a delay before changes are rolled out to the XenForo Community.
 
Code: 
$xf.addOns
$xf.app
$xf.contactUrl
$xf.debug
$xf.designer
$xf.development
$xf.helpPageCount
$xf.homePageUrl
$xf.isRtl
$xf.language
$xf.options
$xf.privacyPolicyUrl
$xf.reactionsActive
$xf.reactions
$xf.simpleCache
$xf.style
$xf.timeDetails
$xf.time
$xf.toUser
$xf.tosUrl
$xf.versionId
$xf.versionVisible
$xf.version
 
Back
Top Bottom