Text link lenghts

Hi,
I am upgrading from 3.2.4 after sending many successful campaigns :slight_smile: and am currently testing 3.4.3 I’ve noticed than in the older version the links in the text version look like this

http://…/lists/lt.php?id=bBhVVUQCBlRPUw

while the newer version are like this

http://…/lists/lt.php?tid=NW/nMkfqnZiAVc4m8s8itulJHVxCE74ZvvaGZNtICN7z1WxVqUCNZr/CE/wLg6BI

which to my eyes looks more likely to put people off clicking it.

Is this just the way it is or is there a setting somewhere to shorten or neaten this link.

Thanks in Advance
Gareth

Hi Gareth, happy to hear that!

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.

Thanks Samtuk,
I kinda suspected that, it’s a pity as I have quite a few text only subscribers and those URLS do look kinda scary.

Anyways thanks again for letting me know.

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.

Hey Samtuke,
I’ll look into a link shortener, thanks for the tip (something else to figure out :wink: )
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 :frowning: )

Anyways thanks again … I really enjoy and am grateful for this software despite my observations above.

Gareth

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.

edit:
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.

All the best
Gareth

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

https://mysite.com/lists/lt.php?tid=4nW/SWkVcDuBmXsxJv3KBrTj+O72snjTqamq/t5ZhP5jE+IjI8AqH7K1VHfD8TWl

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.

Thanks again
Gareth

The click tracking mechanism was changed in release 3.3.0 phpList 3.3.0 Released: Major update with new user interface | Open Source newsletter software | phpList.org
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.