Fixed E-Mail templater is missing params
- Thread starter Kirby
- Start date
Sure 
Being able to access to app object gives a lot of flexibility, for example we could get
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):
Obviously this could be done via an Add-on, but being able to just use template code simplifies things in some cases.
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.
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.
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.
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.
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:
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:
Change log:
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