URL used in a v2 link not working in v3.3.1 after upgrade


We’re using 3.3.1 and can send just find. We have 2 links. One works great. The second one doesn’t. It still looks like the format, but shorter. For example, the working link looks like:


But the 2nd link is:


So it’s much shorter and gives a 404. Any ideas?


It might have to do with and upgrade from v2. The 2nd link was used in multiple v2 messages, it’s the link to our home page. If I create a new URL, then it works.

Anyone know any way to fix without removing all of our v2 stats?

@atomz4peace Can you use phpmyadmin to look at the linktrack_forward table. Do any rows have an empty value for the uuid field?

Yes, most of them. Undoubtedly the ones from v2. I ran the conversion upon upgrade and had no errors.

All rows should have a uuid value. Are you sure that the url of the problematic link has a uuid?

From the length of the second url it looks like one of the parameters is missing. Can you look at the config table for a row with name xormask? Using that you can manually decode the tid parameter. That is a bit involved so you can copy the XOR value here and I will try to decode.

base64 decode the tid parameter
then xor with the xormask config value repeated 20 times

that should give a result like this

H|36 characters|36 characters|36 characters

but one of the 36 character strings is missing.

Most do not have a UUID, so I’m sure that’s it. I see the lines in the upgrade.php where it loops and adds the uuid. This must not have succeeded when I ran the upgrade. Unfortunately, it did not throw an error.

Is there a way to just run that 4 line loop to populate the uuid without re-doing everything?

I see the uuid is a custom generator. Would things still work if I just made it simple and used the mysql uuid function like this:

update phplist_linktrack_forward set uuid = uuid() where id = <I have about 20 of them in a loop>

Does it need to use the same format as the phplist generator? Not sure how to write a quick php script to get the db connections and all the includes.

Thank you for your help!

@atomz4peace The mysql UUID() function seems to generate the same format of uuid as phplist, so running a query to populate empty fields should be ok

update phplist_linktrack_forward set uuid = UUID() where uuid = ''

Thanks @duncanc. The URL looks like the right length now, but still gives a 404. Any other ideas? I’ll probably just have to make new URLs. But in case we can figure it out, our URL values are:



@atomz4peace That change won’t fix the links in existing campaigns, only in new campaigns. I don’t think that it is possible to fix the existing links.

To confirm this, compose a new campaign that includes the existing url, then send a test email to see whether the link then works.

i ran into the same problem with version 3.6.7.
The problem was, that i installed PHPList in a subdomain. This subdomain wasn’t resolved in the sendmail.script. It just pointed to the root-folder of the domain, where (of course) script lt.php wasn’t found.

To solve this i added in script sendmaillib.php in every line with “lt.php” the subdomain (i. e. from “$newlink = sprintf(’<a %shref=”%s://%s/lt.php?tid=%s" %s>%s’, $links[1][$i]," to “$newlink = sprintf(’<a %shref=”%s://subdomain.%s/lt.php?tid=%s" %s>%s’, $links[1][$i],"), so the complete link was send in the mailings.

I’m not sure about the complete impact of having added the subdomain to every line. But sending a test-mail and clicking on the picture with the link worked.

Maybe this workaround helps some users. At least until a solution is found to add a subdomain initially.