I’ll give some background below, but the subject pretty much sums it up. I want to use the [USERID] placeholder in a campaign, within a link, but what comes through is apparently a hash of the ID rather than the ID itself. I saw one other post here about this hashed value, but nobody replied.
Is there a way to get the plain ID rather than a hash of it?
If this is not by design, I’d be happy to try to develop and submit a fix for it, I’m just a little uncertain about the process and could use a little encouragement/guidance. (Lots of coding experience but far too little experience contributing to projects like phpList.)
Background: I’m a fiction writer and use phpList to keep in touch with readers. Since I write in multiple genres, and since some of my messages are genre-specific, I have a user attribute defined for “preferred genre” so I can segment as appropriate. This has been haphazard at best, with me assigning it based on the first book they downloaded (I do a lot of list building by giving away free books), and occasionally presenting that data to subscribers and asking them to let me know if it’s not right. I want to add a click-to-pick feature in my onboarding email, so people can choose their favorite genre directly. I need a more efficient way to connect those link clicks with subscribers than manually viewing the stats in phpList, so I need the ID to handle it in code (or at least semi-automatically).
@Crenel84 The [USERID] placeholder is replaced the by the uniqid field from the phplist_user_user table. You can use that to lookup a subscriber, either on the Search subscribers page or in your own code.
This is the same value used in the URLs to the preferences and unsubscribe pages.
The phplist documentation tends to use the term UID (unique id) instead of identifying the database field directly.
I just looked at the database, and despite what the name implies the uniqid field is not set to be unique in the database. If that is a hash of another field (like the actual ID which is the primary key) and there’s a collision, a search could bring up the wrong subscriber. That’s a bit worrisome regarding the use of that field for the unsubscribe function.
Maybe I’m barking up the wrong tree with my approach to this goal, or the goal overall. I wanted a low-friction way for people to optionally share incrementally more info about their preferences, but it’s not looking feasible (or at least can’t be scaled up well) the way I had in mind. Well, unless I trust the not-unique field to be unique.
@Crenel84 The field should be unique for each subscriber. It is not a hash of another field but a randomly generated value.
The index idx_phplist_user_user_uniqid isn’t defined as being unique, but it could be. You can change the index in phpmyadmin to be unique if you want to ensure that a non unique value is never entered.
You do not want to make public the id column of the user table. If someone knows that their id is 1234, that leaks information that subscribers with ids of 1 - 1233 probably exist, and ids with higher sequential numbers probably exist too. Someone knowing their unique id leaks no information about other subscribers.
Agreed about the problem of making the actual ID visible, due to the +/- exploration that someone might do. I was narrowly (and inappropriately) only focused on my own current goal.
After thinking about this more, I realized I’m already unintentionally relying on the uniqid being unique, in multiple ways. It wouldn’t be a functional change if I codify that further. Still, I’d rather be certain that it really is unique - for what I have in mind and for the unsubscribe function (I wouldn’t want someone to try to unsubscribe and still get messages from me).
You have much more experience with phpList, so your crystal ball has a clearer view than mine, lol. If I change that index to be unique, do you think it’s likely that a future update might override my database change? (Totally understand if you don’t want to answer that, haha…) If it’s a change that’s likely to stick, I’d like to change my database accordingly.