Smarty 5 incompatibility in jcalendar.tpl: unknown modifier uniqid when creating new mandate (CiviCRM 6.2)

[vasyugan]

ChatGPT helped me with formulating this issue report, so I am not nearly as smart as it sounds...

I'm running CiviCRM 6.2 on Ubuntu 20.04 with PHP 8.1 and on Debian Bookworm with PHP 8.2 and encountered a Smarty 5 compatibility issue when attempting to create a new SEPA mandate via the CiviSEPA extension.

When I try to create a mandate for a contact, I get the following error:

Smarty\CompilerException: "Syntax error in template "file:CRM/common/jcalendar.tpl" on line 41 
"{assign var='displayDate' value=$elementId|cat:"_display"|cat:"_$string"|uniqid}" 
unknown modifier 'uniqid'"

This happens because uniqid is being used as a Smarty modifier, but Smarty 5 doesn't recognize it by default, and it hasn't been registered as a custom plugin. This breaks rendering of the form used to create SEPA mandates.

Environment:

• CiviCRM 6.2
• org.project60.sepa (latest as of May 2025)
• PHP 8.1/8.2
• Standalone installation, Also WordPress Plugin

Suggestion:
To fix this, either:

• Replace the use of |uniqid with a method that conforms to Smarty 5 syntax, e.g. generate uniqid() in PHP and pass it to the template
• Or refactor the line in jcalendar.tpl like this (pseudocode):

{assign var="uniqid" value=$php.uniqid()}
{assign var='displayDate' value=$elementId|cat:"_display"|cat:"_$string"|cat:$uniqid}

But ideally, remove usage of unsupported Smarty modifiers entirely for forward compatibility with Smarty 5.

Let me know if you'd like me to test a patch. Thanks for maintaining this excellent extension!

[eileenmcnaughton]

Just noting that jcalendar.tpl has been heavily deprecated for more than 5 years (& soft deprecated for much longer) & is due to be removed from core at some point so probably best not to refactor it - I think the replacement is to add datefields code with

addDatePickerRange() - e.g this is how we converted similar core forms in 2019 civicrm/civicrm-core#15709

[eileenmcnaughton]

It looks like there is already a patch for this #736

[vasyugan]

It looks like there is already a patch for this #736

Indeed. I manually applied the patch and it seems to fix this issue. Wouldn't it be great to have an official release with it?

[peth-systopia]

That sure would be great, but there seems to be an open question about potential problems introduced by the patch. So it's not ready to merge yet, but we will try to sort it out asap.

[vasyugan]

That sure would be great, but there seems to be an open question about potential problems introduced by the patch. So it's not ready to merge yet, but we will try to sort it out asap.

Thanks for your response. Unfortunately, the extension seems to be incompatible with the current release in more ways than one, e.g. under Administer/CiviContribut/Payment processors, when I try to create a new payment processor, SEPA is not offered as an option. Unfortunately, no error is shown in the logfile. So I do not know how to create a useful issue report. Maybe doing so is redundant, if you plan to release a version that overall restores compatibility with the current stable version.

[peth-systopia]

The payment processor functionality has been moved to a separate extension, https://github.com/Project60/org.project60.sepapp. Any issues concerning that functionality should be created there.

[vasyugan]

The payment processor functionality has been moved to a separate extension, https://github.com/Project60/org.project60.sepapp. Any issues concerning that functionality should be created there.

Thanks! I'm really struggling to get the components to work together. Can I somewhere find a list which versions work with which, that is mainly, which version of CiviCRM I should install to have the extensions required in Europe, such as SEPA, CiviBanking and Twingle work? Right now, I see it failing at every turn.

(Sorry, I know that I am abusing this comment system here, which has a different purpose)