There has been a strange problem - [NAME] placeholder is not substituted with corresponding attribute, instead it shows as [NAME] in the sent emails.
The other placeholders work as expected - [LAST NAME] for example. Substitution with [NAME%%sometext] returns “sometext”.
Clicking on the question mark above the message shows that the attribute is there and spelling is correct. Name attribute isn’t empty. I’ve tried merging the attribute with another, suspecting database corruption, didn’t help. All the database checks work normally. PHPlist version 3.0.12
Are you SURE your attribute is NAME. IF you have [LAST NAME] then [FIRST NAME] is the obvious one. Go to: Config > Configure Attributes to check.
Add a screenshot if you can.
Also, go to subscribers > search and find the test account you are using. Be sure that there is an entry for the attribute.
Sorry this sounds dull, I work with attributes a lot, they are annoying and tricky - I have spent days on problems like this often. Every single time the cause was something like this (except once when the attribute name was too long)
So that particular subscriber either doesn’t have a value for NAME or it is empty. In that case phplist doesn’t replace just the placeholder on its own, [NAME].
I’ve checked all the obvious reasons several times, everything is as it should. I’ve changed the attribute name to FIRST NAME, tried that as well to no avail, copied the placeholder from the question mark, etc. etc. The attribute is not empty, tried on multiple accounts with different Name values.
The only possible reason left is a bug in PHPlist or in database - think along these lines.
“Search subscriber” show the correct value in NAME as well, PHPList just doesn’t use it when emails are sent.
Well, this is an unusual bug and I can’t replicate it. You can fill out a bug report by following the instructions on phpList.org > Community > Development - but take your time over the report, document everything really well, because this problem is going to be caused by something quite specific I think.
If you have time to investigate the database content it might help to understand what is happening, but not necessarily why it has happened.
The table user_attribute has one row for each attribute that you have defined. So there should be a row whose ‘name’ column has the value ‘Name’ or whatever you have now renamed the attribute to.
The table user_user_attribute has the values for each subscriber for each attribute.
So you can use the ‘id’ column of the user_attribute row to look at the attribute values for each subscriber. From your problem description I guess that there won’t be any but by looking at the data you might be able to see what has happened.
Also/or, the devs happy to offer paid support on this (from phplist.com) if you just want us to fix it for you. Just let me know if you want to do that.
We’ve got the attribute from the beginning, but didn’t have to use it until recently. After trying some things to make it work, I’ve renamed it, then merged it with another - nothing helped.
Ok, well, I suggest you pay the developers for help. You can do so here: https://phplist.com/installservice and link to this thread in comments. It should be about an hours for for them, they will send you a quote.
This is a really odd problem which is not reproducible so far, so while you could simply make a bug report, I don’t think it will get you what you need quick enough. It’s fairly usual for installs of your scale to seek paid support from time to time.