Variable names in e-mail templates after 3.4 update

Software Support
,
1

Greetings,

after the site admin responsible for my journal updated OJS to 3.4, some variable names in e-mail templates seem to no longer resolve. That is, the variable name instead of the replacement text is printed in e-mails that are sent to authors and reviewers.

For example, this happened for $contextName in the template “Discussion (Review)” and for $editorialContactSignature in “Resubmit for Review”.

Is there a way to systematically find non-resolving variables? I’d like to solve these issues before my authors and reviewers stumble upon them if possible. Is there something I can ask my site admin to do, like an automated migration tool for old variable names?

Thank you very much for your help!

What application are you using?
OJS 3.4

2

Hi @kopf,

Yes, email variables/templates changed significantly with 3.4. You can see some more detailed info on that here: https://docs.pkp.sfu.ca/learning-ojs/en/about-ojs#whats-new

One piece that might be particularly relevant, given what you’ve noted is that:

Each email comes with a glossary of available variables that can be inserted using the ‘Insert Content’ button. The values of variables, such as the author’s name, can be previewed before the email is sent.

This way you should be able to easily identify variables that can be used.

Not that I know of. Variables are very much dependent on the particular email template being used,.

This thread, although a bit dated, does explain this to some degree: Email variables list - OJS 3 - #6 by astevens

But unfortunately, there is no master list of variables, to my knowledge.

-Roger
PKP Team

4

Dear Roger,

thank you very much for your quick reply!

There are a couple of questions I have about the updating process:

  • Will the default templates be automatically updated to have the new variable names with each OJS update? I worry this might become an issue in the future.
  • Will the default templates be automatically updated if they have been modified by the user, e.g., by adding a custom remark?
  • Is there a different way to see which variables are available in which template, e.g. from the source code? I would be fine with looking at some PHP code but I am not sure that I can find the position of these settings in the OJS code

Your help is very much appreciated!
Felix

5

Hi @kopf,

Good questions. I don’t know the answers to these questions, but I’m paging @asmecher who might be able to better answer this.

-Roger
PKP Team

6

Hi @kopf,

The default email templates are installed when the journal is created; if there is a need to rename a variable, then the upgrade process will take care of it.

To take the example of $editorialContactSignature: In 3.3.0 and older, this variable used to appear in ISSUE_PUBLISH_NOTIFY, SUBMISSION_ACK_NOT_USER, REVIEW_REQUEST, REVIEW_REQUEST_SUBSEQUENT, and maybe a dozen other email templates that are used in the editorial workflow.

With the 3.3.0-x to 3.4.0-x upgrade it’s renamed to $signature instead (in lib/pkp/classes/migration/upgrade/v3_4_0/I7264_UpdateEmailTemplates.php, if you’re curious). This works both on default template text and customized email text, but only for email templates that are in the list.

We can’t systematically identify non-resolving variables during upgrade because they might be implemented e.g. by plugins. It might be possible to log non-resolving variables to the error log upon sending, if that would be helpful.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
7

Thank you @asmecher!

In I7264_UpdateEmailTemplates.php I see $editorialContactSignature begin replaced in some templates, but not in “Resubmit for Review” it seems:

'EDITOR_DECISION_RESUBMIT' => [
    'authorName' => 'authors',
    'contextName' => 'contextName',
    'submissionUrl' => 'authorSubmissionUrl',
],

Could this be the reason why $editorialContactSignature is still in the “Resubmit for Review” template and does not resolve now?

9

Hi @kopf,

Looking at the default body text for that email for OJS 3.3.0-x, the {$editorialContactSignature} variable was never used in the default text, so the code to rename the variables on upgrade wasn’t written to expect it there.

Regards,
Alec Smecher
Public Knowledge Project Team