Doing so will ensure all of us that the right person is
being matched to the right account within Stripe. You will be taken back to your account on
netlify to log in, and you will be connected to Stripe where you will be able to securely change
your personal information.
Again, that link is {{ .ConfirmationURL }}
It is reading it from the correct location, because I’m receiving the email when I test signing up. But the Confirmation link is not resolving to a valid link. Here’s what it looks like when it’s delivered:
So…I gave this a shot. Unfortunately I’m not sure how to resolve the nomenclature. If I just want a confirmation link (i.e. click the link, returns to my site logged in), this syntax doesn’t work. I am trying this in Gmail but not sure that should matter.
When I just use href="{{ .SiteURL }}/#confirmation_token={{ .Token }}", I get the following:
Why would it be delivering through Mandrill? Isn’t that a MailChimp property? Is Netlify using MailChimp for deliverability?
Anyhow - I’m still a bit confused as to why the default template would work and a custom one wouldn’t. I don’t think it would be my mail reader, as the link resolution should happen at the Netlify server, shouldn’t it?
Yes, by default, we use Mandrill to send out emails. We’ve used them since before they were part of Mailchimp. .
And you are correct that the link should be resolved on our side. I checked the deployed HTML file and it looks like the link is coming through as: <a href="">HERE</a> and <a href="/#confirmation_token=">Confirm your mail</a>.
Can you confirm that this HTML is not being processed by your build? It should be placed in a folder where it can be placed in your build folder after the build process is done without any changes to the file. Normally it would be named ‘static’ or ‘public’.
I updated the email so that I could see all of the variables:
Here’s a screenshot of my _site and development folder structure. As you can see here - the template is in src/email and ntl build generates the template in email/confirmation/index.html.
This didn’t surprise me that much because I would think this would need to be resolved by the identity application on the server. If that’s a mistake, then there’s something incorrect in my setup possibly. Do I have to include a library in the email template code in order to get a proper generated template?
Here is how this looks when I actually try it (generated at the server):
You mentioned that you are generating the HTML file. Can you clarify what is happening to your templates during that process? I see the placeholders being removed by your build process. I recommend that you don’t generate or process your templates in any way and instead, just copy your template as-is to your build directory. Let me know if that helps.
Yeah I was going to say - building your site ideally shouldn’t play with that file at all. On my Gatsby-based identity sites (for example) the identity templates sit as fully static html files in the ./static/ folder - Gatsby never touches them. From my understanding, Identity reaches out to your site at the time of needing to send the email then hydrates the HTML with the liquid values and sends it. So the ‘time of needing to send the email’ is inevitably long after your build process - it’s when the user signs up. If your template tags aren’t in the file by then, no dice.
Alternatively, if you do need build the template files (to inject CSS or some other reasons) you would need to make sure that your SSG ignores the liquid injection tokens entirely so they don’t change during the build.
Sorry - that was semantics when I said that the HTML template is getting built. I am not generating it at all. The file - confirmation.html - is created and placed in the email directory as shown in the screenshot above. BUT - if I can’t do any html in the template - how would I possibly style the template so it doesn’t look like a form of spam?
I’m going to remove the HTML and see if that resolves my dilemma, but I don’t think I did much more than <h1>, <h2>, <p>, <div>, and <a href=>. Are those out of bounds as well?
Netlify Identity / Hosting doesn’t impose any restrictions on writing your Identity templates with HTML other than what @tomrutgers mentioned - the template itself needs to be a partial template of what would be already inside <body> tags - you shouldn’t make your own. This is just the difference of having a template that says:
<head>
</head>
<body>
<h1>Thanks!</h1>
</body>
and a template that’s just
<h1>thanks!</h1>
– You want the latter.
That said, if your SSG is parsing that file or processing that file in any way (which would be implied by you saying that you ran ntl build and the markup changed), that needs to be disabled.
Given that it appears that you’re using Eleventy, I would recommend creating a ./static/ folder (not nested inside of ./src/) and putting your confirmation.html inside of that, then using Eleventy’s Passthrough File Copy by adding
eleventyConfig.addPassthroughCopy("static")
to your config. That should ensure that your confirmation template is not getting parsed by the SSG.
Not necessarily, and I certainly won’t claim to be an Eleventy wiz but the goal it to have the SSG copy the untouched file over to the publish directory. As a general point of direction, those sorts of things tend to live outside of the project’s ./src/ directory (to help illustrate that it’s outside of the scope of the build tool, Eleventy in this case), but if you prefer it inside and can setup Eleventy to not process that file using the pass-through, by all means!
.
but the goal it to have the SSG copy the untouched file over to the publish directory. As a general point of direction, those sorts of things tend to live outside of the project’s