Links changed several releases back, primarily for security reasons, but also to allow for much longer source URLs to be stored. You cannot switch this off unfortunately, unless you disable link tracking entirely. I agree they are now very long for plain text.
It would be possible to use a link shortener (eg a local one on the same server) to reduce the link length, at the cost of increasing page load time marginally. You could propose that as a feature request on mantis. Fewer and fewer subscribers seem to use text emails however, so this feels like a shrinking use case.
I’ll look into a link shortener, thanks for the tip (something else to figure out )
re text mails:
I have a bounce rule for “over quota” mailboxes that I then
manually set to text after 2 consecutive bounces (be nice to add custom rules/macros/workflows to handle this kinda case, out of office etc … and why does a CSV import have to include a reset to HTML ?) the next bounce (as text) the address is deleted (manually )
Anyways thanks again … I really enjoy and am grateful for this software despite my observations above.
OK it will probably be a while before I get back here, but for anyone else with this problem I looked at poir and yourls, both look pretty good especially yourls, will probably come in useful later BUT I couldn’t see any functionality in the PHPlist API to access the link values so…
I am now following this link http://www.sean-o.com/blog/index.php/2009/08/11/tutorial-how-to-create-your-own-url-shortener/
and gonna TRY and hack the functionality into the core files…
this will keep me busy for a bit, if/once done I will try to get back here with my results.
Well this was interesting, I get the logic of calculating/storing the clicked links only rather than storing ALL the links/URLS in the database, this would get unwieldy fast, which is where the link shortener would go even if it was only working on the text only mails.
I understand this happened a while back, can anyone put a date on it or better yet point me to the discussions as I am now curious as to what logic etc ideas were debated.
Most URLs are stored unchanged in the linktrack_forward table.
Those URLs that include a uid parameter, such as to the phplist preferences page or unsubscribe page, have that parameter removed before storing so that there is only one URL for the preferences page instead of one for each subscriber. The uid parameter is added by phplist when the link is clicked.
The tid parameter identifies the subscriber, the campaign, and the original URL
I’m not sure that URL shortening is going to work well because that parameter will be different for each subscriber for each URL in the campaign. It looks like the number of combinations will quickly become extremely large.
Yep, thanks duncanc, thats the same conclusion I came, to even if it’s only 1 CTA link/URL (not sure what the diff is) and only for the text mails then pruned after campaign end it will still become unwieldy.
Anyways it was interesting having a look see whats going on there.
Is there anywhere I can find a discussion around the change in link format as I am curious as to what other considerations were debated/explored/mentioned.
The click tracking mechanism was changed in release 3.3.0 https://www.phplist.org/newslist/phplist-3-3-0-release-notes/
So far as I remember the reason was the possibility of someone getting access to other’s personal data (such as the preferences page) by using brute-force to test possible variations of campaign id, user id and link id. I don’t remember any public discussion about the changes or alternatives.