Hey, first things first:
APP ID: c8917f89-5771-44ae-88f0-c1ebda658dbb
Templates are at the root of the served zip file.
Other templates work, all except the password reset template.
The content of the html should be the same except some text really. However, I have a suspicion that there’s a semantic / syntax error in the html and Netlify is refusing to use it? (Although it seems to be the same as confirmation/invite template).
I cannot see any errors provided by netlify, the email is sent just without the template. Will probably need staff to analyse the logs below:
Some timestamps for a reset email sent are:
10-02-2021 23:01:54
10-02-2021 22:35:35
10-02-2021 22:13:07
Using the custom SMTP email as setup in the admin ui.
A timestamp of a working Invitiation template being sent is at:
10-02-2021 22:07:58
10-02-2021 18:43:55
Can’t tell what timezone that is in - could you clarify?
Also - just as an FYI - you are entitled to helpdesk support if you want to write in there instead (support@netlify.com). I am thrilled to support you in community, but in case it serves your needs better to be able to say “on site secret.com that I couldn’t say in community, an email to bob@gmail.com which I couldn’t say in community, was wrong…”
Ah! I had previously written it before I edited.
The timezone is GMT United Kingdom.
Sorry for the late reply, I got distracted today. A recent log time is: 12-02-2021 17:13:35
12th feb.
EDIT: here is a timestamp TO my registered Netlify email if that helps! - 12-02-2021 17:16:45
I’m happy to communicate here and keep the results public incase it helps others, however, if you think this case particularly would benefit from email contact I will raise it there instead
@fool Hey, still having this issue. Curiously, I span up another site with the same repo linked and the same templates but none of them work. I do not want to edit the current templates that ARE working to test further as it would affect current users. However, the only difference between the ones that are working (except password reset) and the ones that don’t is the new test site is password protected at site level.
I can see some logs around your send (or I think it was your colleague an4y? Or perhaps you invited that person?) but can’t see anything immediately obvious without knowing those settings.
There are probably people invited quite often by An4y yeah.
Just to confirm:
Live site (Invite template works etc, Not password reset template) - APP ID: c8917f89-5771-44ae-88f0-c1ebda658dbb
I did try a relative URL, I thought it could be an error within the HTML not being logged but the confusion comes from it originally working for invite and confirmation on the live site.
Any questions feel free to message, ill try to reply asap.
Feel free to change settings if required on the test site (03066fe7-6a57-4283-a9f1-3c99a277c257) if you have that access.
templates folder is at the root and the templates are inside, I can open them and view them in the browser from the zipped deploy.
Cheers fool!
PS: If you need external email SMTP details I can contact the support email.
One last question before we file a bug. Feel free to DM me the answer - what was the email address of the user you tried to send a reset event for at the timestamp you mention ( 12-02-2021 17:13:35 GMT )? While our API showed no problems, let me see if it even made it to our mail service. You seem to have deleted this user (there are none remaining that match its ID), so I can’t look it up in our database as I could for one that was still in our system.
(or, you could press the button again now for a different still-remaining user such as yourself!)
Regarding the templates not working on a site with a password, this is a known limitation since the Identity instance will not have access to your templates due to the password requirement. If you remove the password protection, does the recovery.html template start to work?
That said, I’ve not seen any reason why only that one template would not work while others would. When was the last time you made changes to the recovery.html file? How about the ones that work?
These additional details will help us file a better issue. Thanks for your patience.
The issue was not for a password protected site, two templates work on the live site and “recovery” does not. The password protected test site not having any templates working is fine though.
To be clear there is no password protection on the site with the issue.
Right, I didn’t mean to say that the main issue was related to password protection. Only that you mentioned your test site not working as part of your initial description of the issue, so I wanted to address that. Mainly to see if that test site did still experience the same issue with the recovery.html template when the password protection was disabled. This would help to pinpoint where the issue is and whether the issue might be specific to that one site or the recovery.html file itself or if the issue is systemic (which I don’t think we are seeing reports of).
Also, yes, I do know that there is no password protection on the site with the issue but I had asked if you had ever had that feature enabled during the time you added the email template. That said, I was trying to narrow down the scope of what might be going wrong, which I can’t do without you providing the information needed to do so.
Hey, so after ages of playing around, I deployed a plain template with just a header which worked, then also deployed the confirmation.html as a template for recovery.html, which worked.
I ran the doc through scanners for errors and nothing but meta tags or custom fields came back (which I already tried as issues).
Turns out… upon saving for whatever reason, in a few areas (space) was inserted into the text. Now that I have removed them and managed to save with normal spaces it is working…
It seemed that nbsp is allowed in templates, however, I believe the core issue to the failing template is that was inserted like so {{ .Email }} which I guess was making something fail?
Thanks for looking into it. Would still be interesting to know if there is a specific reason behind that. Maybe whatever parses the {{.tags}} breaks because of it but doesnt produce an error log?
<.following>
