zen_mail sends wrong html body in subsequent emails due to global $current_page_base

Hi guys!

Zen Cart 1.5.5, PHP 7.4

Disclaimer: This is not standard Zen Cart code and only encounterable if you're heavily modifying things, so I do not class this as a bug, just a gotcha.

Just to share a moment of painful debugging to help others, I ran into some weirdness in the functions_email.php code where zen_build_html_email_from_template() is used to build the HTML portion of the email. It sets the global $current_page_base variable, which is then re-used in subsequent calls to the function. So if you are calling it from a standalone script to send emails using a different $module (email template) like this:

zen_mail(...some params..., 'default');
.. some other processing
zen_mail(...some params..., 'my_custom_template');

Inside zen_mail it calls zen_build_html_email_from_template($module, $block), which seems to be designed to be executed from a specific Zen Cart page being executed e.g. "shopping_cart" or "product", in which the very common variable $current_page_base would be set up. This doesn't hold up so well when run from your own custom script with a different global context where $current_page_base starts out undefined.

  function zen_build_html_email_from_template($module='default', $content='') {
    global $messageStack, $current_page_base;
    if (NULL == $current_page_base) $current_page_base = $module;
    ... the template file to load from disk is then decided based on $current_page_base

The first time through it will set $current_page_base to the first module you pass, in my example above this is "default".

The second time through it will use "default" again as your email template, despite you passing in a different module name, in my example "my_custom_template".

This is easily avoided by unsetting $current_page_base in the global scope between calls to zen_mail.

zen_mail(...some params..., 'default');
.. some other processing
$current_page_base = null;
zen_mail(...some params..., 'my_custom_template');

Some very confused customers of ours were sent some very weird emails yesterday due to this :)

Cheers
Nick

I've run into the specific situation causing my trouble, outside the scope of my own scripts that leverage the zen_mail function, so I thought I'd ask here for advice.

I have a customer facing page, let's say it's "job_approval" so there's a tpl_job_approval_default.php and modules/job_approval/header_php.php as normal. The submit handler is the same page, so I have code in header_php.php that wants to send emails to our team, and it wants to use a specific email template 'custom_template'.

// in POST handler to job_approval page, modules/job_approval/header_php.php
// At this point, $current_page_base is 'job_approval'
zen_mail('[email protected]', 'Job Team', blah, $module = 'custom_template');

The intention is that the email/email_template_custom_template.html will be used to build the HTML section of the email. But, because $current_page_base is 'job_approval', the email_template_job_approval.html template is used instead.

What's the "official" way to use an email template different to the current page's template? Or, is there not one? Any good suggestions?

In this context, it seems that resetting the global $current_page_base to NULL in order to trick zen_build_html_email_from_template to use a different template isn't a clean thing to do, and for safety's sake one would want to set it back to the old value after sending, i.e.

$old_page_base = $current_page_base;
$current_page_base = null;
zen_mail('[email protected]', 'Job Team', blah, $module = 'custom_template');
$current_page_base = $old_page_base;

Thanks!
Nick

I found this confusing too. This behavior has been changed in the next release; you can see my fix here

https://github.com/zencart/zencart/pull/3713

Thank you swguy! I wish I'd seen that PR when doing my research. It does seem to do what I need, and works around the other bug where I call zen_mail twice from a standalone script with two different email templates.

I hadn't noticed the $block['EMAIL_TEMPLATE_FILENAME'] which seems ugly as it kind of does double duty with the $module parameter passed into the script, but the old logic was rather twisted, frankly.

Cheers!