Email template variables in OJS 3.5

[sarahfr]

Hello,

We’ve recently upgraded a sandbox journal from OJS 3.3 to 3.5. Through testing, we’ve noticed that a few variables don’t populate in some of the email templates (i.e. email text includes the variable name itself rather than the text that should replace it).

This issue can be replicated by working through an editorial process corresponding to one of the affected templates (e.g. declining a submission pre-review) and viewing the sent email in the activity log:

Here is a list of the affected variables and templates:

{$contextName}

Affected Templates:

• Sent to Review

• User Invited to Role Notification

• Submission Declined (Pre-Review)

• Revisions Requested

• Reviewer Commented Notify Editors

• orcidCollectAuthorId

• orcidRequestAuthorAuthorization

{$editorialContactName}

Affected Templates:

• Reviewer Commented Notify Editors

{$editorialContactSignature}

Affected Templates:

• Submission Confirmation

{$principalContactSignature}

Affected Templates:

• orcidCollectAuthorId

• orcidRequestAuthorAuthorization

{$recommendation}

Affected Templates:

• Reviewer Commented Notify Editors

{$passwordResetURL}

Affected Templates:

• Review Reminder (Automated)

• Review Response Overdue (Automated)

{$authorName}

Affected Templates:

• orcidCollectAuthorId

• orcidRequestAuthorAuthorization

{$articleTitle}

Affected Templates:

• orcidRequestAuthorAuthorization

{$filename}

• Does not populate in the activity log (not in any email templates):

We’ve seen some similar issues already documented in the GitHub (e.g. with the {$contextAcronym} variable), so apologies if any/all of these instances are duplicates. If there’s any way to fix this issue (other than manually changing the variables), we would love to hear about it!

Thank you!

[grierb]

Hello and welcome to the community with your first post @sarahfr . This is a great list. I will bring it to the team and see if we can’t find a more robust approach to fixing all of them. As you have noticed we have a few of those covered as issues to be fixed in upcoming patches (see below).

{$contextAcronym} - #10962

{$filename} - #11997

{$reviewAssignment} - #10045

[SAJS09]

Hi @sarahfr and @grierb, we just upgraded to 3.5 and are experiencing these same issues, have you perhaps managed to find a solution or workaround in the meantime? Thank you.

[grierb]

@SAJS09 What version did you upgrade to for 3.5? Was it the recent release 3.5.0-4? I noticed that 2 out of 3 of the tickets I linked have not been completed.

[ojs_daip]

Hi, we updated to version 3.5.0.4, and we have the same problems, the email templates don’t load.
Any Solution??

[grierb]

I may have interpreted the steps incorrectly. How are you adding the variables? Is it when the email workflow comes up and you select Insert Content or are you editing the template and adding these variables?

Are they accurately being rendered in the email but not in the activity log?

When I tried to Insert Content for example, {$contextName} it automatically converted the variable into a string in the email preview.

Also, some variables might not be able to be rendered correctly until they can gather information about the Journal context. They will remain unrendered in the activity log.

I Couldn’t reproduce the following on 3.5.0-4. Either by first editing the template and then going through email process or first going through email process and using Insert Content option:
for {$contextName}

• Submission Declined (Pre-Review)

• User Invited to Role Notification

• Reviewer Commented Notify Editors

• Sent to Review

I did notice that these variables might no longer exist and you may have to fix your templates to remove them. I couldn’t check them all but here are some I checked. If you are experiencing the same problem on 3.5.0-4 then the templates must be loading but the variables aren’t rendering? I think they don’t exist and are being interpreted as text.

for {$editorialContactName} ← this variable doesn’t exist

Affected Templates:

• Reviewer Commented Notify Editors

{$editorialContactSignature} ← this variable doesn’t exist

Affected Templates:

• Submission Confirmation

{$principalContactSignature} ← this variable doesn’t exist

Affected Templates:

• orcidCollectAuthorId

• orcidRequestAuthorAuthorization

[sarahfr]

What you describe in the second part of your response is consistent with what we’re seeing. Some variables in the default OJS 3.5 templates do not exist and as such are interpreted as text. They do not render in the activity log or in sent emails. When I click “Insert Content,” none of the variables listed in my above post are included in the list of variables that can be inserted.

There are a few variables that work in some templates but not in others. These are:

• {$recommendation}, which works in the Recommendation Made template, but does not work in the Article Review Completed Template.
• {$authorName}, which only does not work in the ORCID templates (orcidCollectAuthorId and orcidRequestAuthorAuthorization).
• {$articleTitle}, which only does not work in the orcidRequestAuthorAuthorization template.

The easiest way to fix this issue is to replace the unrecognized variable with a functioning variable, using the “Insert Content” button to edit the template. When a variable works in some templates but not others, I only replace it in the affected templates. Here is how I have been replacing the variables:

{$contextName} (original variable) → {$journalName} (fixed variable)

{$editorialContactName} → {$contactName}

{$editorialContactSignature} → {$journalSignature}

{$principalContactSignature} → {$journalSignature}

{$recommendation} → {$reviewRecommendation}

{$passwordResetUrl} → {$passwordLostUrl}

{$authorName} → {$authors}

{$articleTitle} → {$submissionTitle}

{$filename} → {$submissionID}

These variables must be replaced after upgrading to 3.5, because the changed variable names typically aren’t recognized in 3.3, and the ones that break in 3.5 work in 3.3. (For instance, {$contextName} works in 3.3 and {$journalName} does not, but the opposite is true in 3.5.)

So far, we’ve upgraded two sandboxes and one production journal to 3.5. While changing the variable names manually works, it would be wonderful to have a more permanent fix!

[grierb]

@sarahfr Thanks for the list. I found this ticket as well : Deprecated email template variables require migration · Issue #9158 · pkp/pkp-lib · GitHub

Not sure when it would be released as it would require a migration.

[sarahfr]

@grierb Thanks for pointing out the ticket, I’ll keep an eye on it.

One correction to my reply - the correct replacement for {$authorName} is:

{$authorName} → {$recipientName}

[grierb]

Thanks for the update @sarahfr. I linked this post as reference in the migration ticket.

So to mitigate the problem (for others) it appears that those email template variables will have to be manually updated until a proper migration can be implemented. After it is implemented it should resolve those other tickets I mentioned.