Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

handle mustache curly braces #28

Closed
luposky opened this issue Apr 5, 2016 · 12 comments
Closed

handle mustache curly braces #28

luposky opened this issue Apr 5, 2016 · 12 comments
Assignees
Labels
Milestone

Comments

@luposky
Copy link

luposky commented Apr 5, 2016

I use foundation-emails / inky to generate email templates. These templates have {{tags}} inside and are filled with mustache data before sending it.

In inky template I have this line:
<button href="{{buttonUrl}}">{{buttonText}}</button>

but compiling with inky completely drop my {{tags}}:
<table class="button text-center"><tr><td><table><tr><td></td></tr></table></td></tr></table>

desidered result:
<table class="button text-center"><tr><td><table><tr><td><a href="{{buttonUrl}}">{{buttonText}}</a></td></tr></table></td></tr></table>

Best regards,
Luca

@iberflow
Copy link

I've got a similar problem. Laravel's Blade syntax uses curly braces, so when trying to use:
{{ "{{ trans('emails.account.invitation.text') }}" }} I get an empty string.

@iberflow
Copy link

So I've figured out that panini uses handlebars. So far I got to:
\{{ route('settings.account.invite.confirm', [$token, $id]) }}
which produces:
{{ route(&apos;settings.account.invite.confirm&apos;, [$token, $id]) }}

haven't found a way to disable html entity encoding.

@McJay
Copy link

McJay commented Apr 29, 2016

I have similar case where I would need to use curly braces and disable html entity encoding case by case or globally if not possible to just escape the enities. Anyone have way to handle this situation?

@rafibomb
Copy link
Member

There is PR that is a work in progress to stop the character encoding #37

This should solve you use case. It would be awesome to add this test case to this page https://github.com/zurb/foundation-emails/blob/develop/test/visual/pages/inliner-bugs.html so when it's fixed there can be some regression testing - thanks!

@rafibomb
Copy link
Member

rafibomb commented Jun 8, 2016

Maybe some kind of <raw> tag to wrap content that should be ignored. Perhaps <ignore>?

@rafibomb rafibomb added this to the 2.2.0 milestone Jun 10, 2016
@rafibomb
Copy link
Member

This looks like a great one to get into 2.2.

We're thinking a <raw> tag might be good because a lot of JS and handlebars syntaxes use this. Is anyone able to take a stab at this one?

@rafibomb
Copy link
Member

This is in 2.2.1!

@diomededavid
Copy link

diomededavid commented Sep 15, 2016

Raw does not work when wrapping less than and greater than like so: <raw><<Text here>></raw>.Would doing a decode function work?

@anthonybrebion
Copy link

anthonybrebion commented Feb 2, 2017

Hi,

I'm trying to use the raw tag to not process a template variable used by our ESP but it doesn't seem to work as expected.

Ex: {{unsubscribe_link}} doesn't output anything
and if I use a one of the Custom data set at the top of my page, it outputs it. (ex: {{subject}})

Edit: I get it. I need to use {{{{raw}}}}... {{{{/raw}}}} instead

@twistedpixel
Copy link

As pointed out by @diomededavid does not work with greater-than and less-than so php tags still get mangled. Is there a way round this? Is it a known issue? In my opinion, it should ignore absolutely everything between the tags without exception so I'm not sure if this is intended behavior.

@diomededavid
Copy link

@twistedpixel One way you could work around it is to replace your <, and > with < and gt; tags. You can add a find/replace gulpscript/function after the inliner fuction in your gulp script to find replace for < and gt; tags and probably colons, you will have to encode some tags in your html to bypass the inliner.

@twistedpixel
Copy link

Yep, that's what I'm currently doing but it just feels dirty. It ruins object attributes too ($var->att) and will likely affect other things I haven't come across yet so it's not particularly reliable.

I'm curious: is it intended or a bug? If intended, I might just have it run through Smarty or Blade, avoiding PHP tags with the inliner altogether. Feels cleaner, if not overkill.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants