Custom tokens not working in CiviMail

Same issue. Sending an e-mail with custom tokens triggered by a civiRule actually occurs to return an error.

[warning] Deprecated function CRM_Utils_Token::getTokenDetails, use If you hit this in mailing code you should use flexmailer - otherwise use the token processor.
CRM_Core_Error::deprecatedFunctionWarning
CRM_Utils_Token::getTokenDetails
CRM_Pdfapi_Pdf::create
::civicrm_api3_pdf_create
Array
(    [civi.tag] => deprecated
)

this is problematic for us as we use a lot of them and this breaks our processes :-/

Trying to flush cache shows this error: PHP Fatal error: Uncaught Error: Class 'Civi\FlexMailer\Services' not found in /var/www/vhosts/domain.com/httpdocs/sites/all/modules/civicrm/ext/flexmailer/flexmailer.php:103

error related to the extension admin_ui not having been activated.

which points to this function

/**
 * Implements hook_civicrm_container().
 */
function flexmailer_civicrm_container($container) {
  $container->addResource(new \Symfony\Component\Config\Resource\FileResource(__FILE__));
  \Civi\FlexMailer\Services::registerServices($container);
}

@GuillaumeSorel That flush cache error is, I believe, unrelated. Can you try applying this patch and see if it fixes your problem? https://github.com/civicrm/civicrm-core/pull/25379

I'm on 5.58.1 so the patch has already been applied.

added has-pull-request label

As for your primary issue, I don't think that's a core issue, I think it's a PDF API extension issue. Try applying this patch? extensions/pdfapi!41 (merged)? Also note a new version was released yesterday, so apply this patch atop the new version.

removed has-pull-request label

I am not using CiviRule or the PDF API extension, and there are no errors in the error log for the CiviMail issue I submitted. The problem described by @GuillaumeSorel is different, and should be tracked as a separate issue.

@GuillaumeSorel I agree with @marty, your issue is different from this one.

you're right, I got confused. My issue was linked to that one: extensions/pdfapi!41 (merged)

added comp:tokens triaged labels

@marty - For reference, I tried to reproduce by copying the example from the docs and running it a few ways. It worked for me:

Example extension
- With v23.02.1, run civix generate:example
- Copy-paste the example from https://docs.civicrm.org/dev/en/latest/framework/token/#defining-tokens
- Enable the extension
- Code: example-token-ext.tar.gz
Use-case:
- Create a new mailing with the two custom tokens ({profile.viewLink, {profile.viewUrl}). (I actually used the token-dropdown to insert them.)
- "Preview" it in the browser.
- "Send" a test message.
- "Submit" the mailing, run cv api -U admin Job.process_mailing, and check the mail-server.
Environment A:
- CiviCRM 5.58.0 (and then 5.58.1 and 5.59.1)
- PHP 8.1.6
- Drupal 7.94
- MySQL 8.0
- MailHog (SMTP Simulator) 1.0.1
- Apache 2.4
Environment B:
- CiviCRM 5.58.0
- PHP 7.4.29
- Drupal 7.94
- MySQL 5.7
- MailHog 1.0.1
- Apache 2.4

In both those environments, I found that all renderings (Preview/Send/Submit) included the token data.

I'm not sure what the problem could be. Perhaps there's some other variable/extension/setting in play?

Thanks, @totten. The only difference might be that my code is implemented in a custom Drupal module (and WordPress plugin), and not in a CiviCRM extension. Could that be a factor?

@marty That does indeed make a difference! tldr: Try running the background job another way.

In my testing of a D7 module... The "Preview" and "Send test" seem OK regardless. The trouble comes when you submit and then run the background job. It depends on how you fire the background job. Compare:

cv api --level=full -U admin Job.process_mailing            #Bad
cv api --level=cms-full -U admin Job.process_mailing        #OK

The key facts here are that (1) hook_container runs during system bootstrap and (2) these two examples use different bootstrap processes. Loosely speaking:

With --level=full, it loads Civi then Drupal. (Older protocol)
With --level=cms-full, it loads Drupal then Civi. (Newer protocol)

There are many other ways to fire Job.process_mailing, but they generally fall into those same two buckets. I spot-checked a few more.

php bin/cli.php -e Job -a process_mailing -u admin -p XXXX  #Bad; tested
drush cvapi --user=admin Job.process_mailing                #OK; tested
wp civicrm-api ...                                          #OK; untested
curl https://..../civicrm/ajax/rest...                      #OK; untested
curl https://..../extern/rest.php...                        #Bad; untested
curl https://..../bin/cron.php                              #Bad; untested

So I suggest running your background job in some other way.

The issue here is not really specific to CiviMail or tokens, and it's not really worth the effort to fix the old boot protocol. It's more about handling the transition. For example:

More of the cv subcommands should default to --level=cms-full.
APIv3 Explorer should encourage civicrm/ajax/rest instead of extern/rest.php.

Somewhat related: https://github.com/civicrm/cv/pull/145

added has-pull-request label

Reading the above there seems to have been lots of factors in play but it kind fizzled out without clatifying the problem. I'm going to close this as it is not replicable / solvable based on the informaiton here (and it is nearly a year old) but re-open or open an issue with steps to replicate if there is still an issue

closed

Custom tokens not working in CiviMail

Overview

Reproduction steps

Current behaviour

Expected behaviour

Environment information

Child items ...

Activity