Closed DavidVogel-NC closed 2 years ago
I'd suggest you look directly at the db to make sure it's stored as%userfirstname%
and not &userfirstname&
- maybe somethings encoding the parameters on saving? - but that's still a bit weird because I wouldn't expect it to happen to "all" your re-engagements at the same time..
Let us know if you work it out!
I installed the Plugin yesterday on my Moodle 3.9.12+ (Build: 20220121).
Same result here: variables are not replaced!
I'd like to follow your hin and check how they are stored in the DB. Problem is, I don't know where to look... 🤷♂️
Same issue for me, upgraded to 3.6.3 of Reengagement on Moodle Moodle 3.11.6+ (Build: 20220405) and same thing happens. Checked the html code and it is definitely %userfirstname% not &userfirstname&
@danmarsden thanks for the quick response. I thought of the possible encoding issue and checked in the db first thing. The strings are saved with literal % characters, not encoded.
For those wanting to check the encoding, go to mdl_tool_customlang (updating the table prefix if needed for your install) and search for a substring from the generic Reengagement notification email, "This is a reminder notification from course". See the query below:
SELECT * FROM mdl_tool_customlang WHERE master LIKE '%This is a reminder notification from course%'
You should get at least three matches. The master field will show the placeholder values, and you can also check the componentid value on those matches, then search the table for that ID to get all the strings for this module.
Encoding isn't an issue in our case. The text below is directly copied from mdl_tool_customlang for stringid emailcontentthirdpartydefaultvalue:
This is a reminder notification from course %courseshortname%, regarding user %userfirstname% %userlastname%.
As I said, I haven't updated either Moodle or this plugin in several weeks, and it suddenly broke a few days ago. These are the only changes I can think of which might have contributed:
In case it's relevant, our system config is: Ubuntu 20.04.3 PHP 7.4.28 MySQL 8.0.28 Table collation utf8mb4_unicode_ci
Based on posts above by Stefan and Gareth, I'm thinking this is a broader issue beyond something weird with our specific site config.
I suspect this was caused by #113 - we'll look into it here.
I've just pushed a fix into github here for the 3.9, 3.11, and 4.0 branches - if someone could please test with the latest code and come back and let me know here I'll publish a new release to the moodle.org plugins db.
thanks for the report!
Just updated from 3.11 branch with the latest code and the %placeholder% items are now showing as expected. Thanks for the quick fix on this.
great thanks for that -I'll bump versions and release in the plugins db shortly.
@danmarsden Sorry for the slow response. I had to wait on my client to confirm if the fix worked on production. Like Gareth above, your fix worked for us on the 3.9 branch, with Moodle 3.10.
About five days ago, all the Reengagement emails started being sent with the %placeholder% items still in place. For example:
We're using Moodle 3.10 with your MOODLE_39_STABLE branch installed, and have not made any recent updates to our system. The notification emails have not been changed, and the place holders were working perfectly up until a few days ago. The place holders are remaining in place both for emails going to participants and the "third party recipient" emails.
Obviously something changed, and I'm wondering if possibly there was a package update on the server which changed something which somehow affected the place holder substitution, but I found the reengagement_template_variables function in lib.php where the place holders are replaced and I don't see anything which looks vulnerable to that sort of package update.
Any suggestions for what might be causing this issue? Thank you for any help you can provide.