Preamble: This may relate to another thread here, but that thread ended up focusing on the Segment plugin, and I don’t think that’s affecting what I’m seeing. When I saw that thread, I looked at my plugins and realized they were terribly outdated, so I updated them (a manual update due to manual original installation). They are all now current, as is phpList.
So… I can access a subscriber’s record and see that they’re getting campaigns. But if I search for that email address via Subscribers -> Search subscribers or via Subscribers -> Advanced search, no record is found. If I try via Subscribers -> Manage subscribers -> Verify subscribers, the address is listed in the “Non existing subscribers” section.
The only consistent way I can access their record is to go to a campaign in which they clicked a link, look at the click stats, and click their address from there. At that point I can confirm that they’re Confirmed and not Blacklisted and that they’ve been receiving recent campaigns.
This doesn’t affect just one subscriber, nor does it affect every subscriber. It only affects a subset, but due to the nature of the problem I don’t know how large that subset is, nor what might differentiate those affected from those unaffected.
I’ve verified the DB structure and I’ve rebuilt the DB indexes, to no apparent effect.
I’m trying to get to a point where I can do some list re-engagement and culling, but I feel like I’m partly blind to my total population of active subscribers.
I checked and can’t see anything like that (e.g., by copying and pasting into Notepad++ with “show all characters” enabled). It also affects dozens of subscribers, and a character problem seems like it would affect relatively few.
Interesting, I didn’t think of trying that. This opened an interesting new door, as it were. I think I’m on the verge of solving this, but I need to think about the results I just saw. I’ll follow up later, hopefully with a coherent and complete analysis. Thanks for the suggestion!
OK, I now understand what was happening, and it had nothing to do with database integrity. It was a result of several factors combined:
Line 1982 in lib.php which reads: $display = str_replace('@', '@​', $display); (the effect of which is to insert an extra not-readily-displayed character into email addresses in certain displays)
My use of copy-and-paste from lists of subscribers within the phpList UI
The ​ character not being shown in Notepad++ while “Show All Characters” is enabled.
If I download data as a CSV, it’s clean and I can use the email addresses for search functions normally. If I copy and paste (which I’m more inclined to do when working with temporary data), I have to find a way to strip the extra character before further use of the email data.
Insertion of that character after / and @ characters is clearly an intended result from the shortenTextDisplay function in lib.php, so I can’t call it a bug. It’s a design decision I disagree with, though, at least to the extent it affects email addresses which are likely to be sources of copy/paste actions.
@Crenel84 Thanks for looking into the problem. I have to admin that it is partly/mostly my fault due to a code change 9 years ago which added that non-displayable character Use zero width space instead of hard space · phpList/phplist3@996c3ce · GitHub . Before that change a real space was inserted, which led to an invalid email address if you copied/pasted it, but at least the space might have been visible.
There is a better way of achieving the aim of letting the browser wrap long email addresses. The <wbr> element does just that. I will look at submitting a pull request for that, but for your purposes you might as well remove/comment-out those lines of code.