Apologies for the late contribution, I was OoO. Unfortunately, I haven't worked with Email Templates in a long time (but I'm glad Jive finally added the unsubscribe feature). In general, the syntax is EXTREMELY volatile, so definitely be extra careful. Usually, what I would do is download Freemarker Tools in Eclipse or something and test the template locally using dummy data where I could synthesize...especially if the template was hard to grok. This may have a nasty setup cost associated with it....but its the only way to simulate the template rendering on-demand. I would agree with Engineering, that <#if> / conditional statements are usually the culprit when there is a discrepancy between preview and live results. If you can attach a remote debugger to your instance, that also helps so you can get a feel for the actual data flowing through the render sequence.
One other tip....would be to take all the variables that you are including in your snippet...and outside of the <if> structure, simply output them....using Freemarker's default operand such as:
unsubscribeLink!"No Value" ... in Preview mode this should generate the data being passed through and perhaps that will shed some of the light?
Hope that helps.
This is a known bug expected to be fixed in 2016.1. Here is the explanation from the engineer:
The includeUnsubscribeLink variable is created and exposed when the EmailConfiguration is instantiated. However, the Digest uses its own configuration interface called DigestEmailConfiguration which, until I fixed the bug, did not have this unsubscribe link included so the variable you're trying to use never exists. This means that "#if (includeUnsubscribelink)" will always return false for the new digest email until my bug fix is released in 2016.1.
Furthermore, the unsubscribe links get generated with a unique token after confirming that includeUnsubscribeLink is true, which means that unsubscribelink?has_content would also return false because it doesn't exist.
I would bet that this is working in his preview and test emails because our application uses the default EmailConfiguration for those tests, but the actual Digest is using its own DigestEmailConfiguration.