Statistics problem in v3.3.1-RC1 : views = clicks

In Statistics Overview I see exactly the same figure in Views and Clicks. I seems the views are not counted at all and just clicks are reported.

@bernard.fruga Ensure that you have user tracking enabled in your config.php file (but that is the default). If you view the source of an email that you have received then there should be an image similar to this

<img src=3D"http://strontian/lis=
ts/ut.php?u=3D302a0f1fb73e11fc1fc889f13453bc58&amp;m=3D85" width=3D"1" heig=
ht=3D"1" border=3D"0" alt=3D"" /> 

That is working for me with 3.3.1-RC1

Thanks for looking into my problem.
Yes, the img was present in the mail:

<img src=3D"
u=3D2079fa8e-8375-4c0b-a9b6-eea193bef522&m=3D322" width=3D"1" height=3D=
“1” border=3D"0" alt=3D"" />

and in the config.php I have (as I also had before the upgrade) the USERTRACK line commented:


Usertrack is used to track views or opens of campaigns. This only works in HTML messages

as it relies on a little image being pulled from the phpList system to update the database

To add it to your campaigns, you need to add [USERTRACK] somewhere.

From version 3 onwards, this is automatically done with the following setting. If you do not

want it, you can switch it off here, by uncommenting the next line


Somehow the views reporting feature got lost on my upgrade from 3.2.7 to (the unfortunate) 3.3.0, and then on the emergency track to 3.3.1-RC1.

This very hour I performed the test sending mail to my own addresses (two different campaignes, one to 2 addresses and another to 3 addresses). I opened all the mails and once clicked onto the link. The results look not good to me:

It seems like one view was reported only.

Shall I downgrade to 3.2.7 and check if the views would be OK again?

And here we’ve got the report from the 3.2.7 campaign. Then it was OK:

(I’ve done no changes in the config between 3.2.7 and 3.3.1, except to, so I presume something went wrong on the way to 3.3.1)

The uniqid column in your user table has been corrupted by the upgrade to either 3.3.0 or 3.3.1. One of the bugs was to update the existing uniqid column instead of populating the new uuid column.

Are you able to restore to a database backup?

I have a similar issue after upgrading to 3.3.0. No views are updated, but access.log shows that they are triggers. How do we fix this?

@ksmets @bernard.fruga Can you look at the phplist_user_user table to see how many subscribers have been affected by this? The uniqid column should contain a 32 character value, but some maybe all seem to have the new UUID value which is something like 2079fa8e-8375-4c0b-a9b6-eea193bef522

There were a few bugs in this area, and possibly only a few subscribers might be affected.

The safest action is to revert to an older version of phplist and the database, then wait until these problems have been resolved.

But then clicks in the campaigns that you have sent using 3.3.0 and 3.3.1 would stop working. You could send the campaign again using the older version of phplist though.

@duncanc ups, I’ve checked the DB and noticed almost all user got “- - - -” format of the uniqid column (just newly registered were OK).
I’ve got my db backup of 3.3.0 and that was already bugged there.
So I’ll keep using 3.3.1 without the views reported.
I hope the next release will fix it, won’t it?

Same here. All users have UUIDs.

I’ve updated to 3.3.1. In a new (test) campaign I see that now the mails are generated with corresponding UUIDs in the tracking image. Although I see in the nginx access logs that the call is successful, the view count isn’t increased. - - [13/Feb/2017:20:33:08 +0100] “GET /lists/ut.php?u=AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE&m=XX HTTP/1.1” 200 178 “-” "Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko Firefox/11.0 (via GoogleImageProxy)

Any idea?

@ksmets, as far as I understood the issue, now the system used Unique IDs instead of UUIDs for the views tracking.
So the proper user record should be like this:

But, the bug caused almost all records to look like that:

The difference in the extra - - - - in the id. That seems to be the cause of yours and mine problems.

@bernard.fruga @ksmets Currently view tracking does not work in the campaigns that you have sent using 3.3.0/3.3.1, and will not work in any new campaigns because of the format of the incorrect uniqid value.

I think that also view tracking of earlier campaigns will not work, although that may not be such a problem.

To have view tracking working properly again the best solution is to restore the database and phplist code to a release earlier than 3.3.0. Then wait a few days to see whether phplist is then stable, and upgrade again. Any campaigns that you have sent using 3.3.0/3.3.1 will be “lost”, but I don’t think that there is a way around that.

If you do not have an old database to restore then there might be a way to manually generate new uniqid values, but that needs a bit more investigation.

Fixed the database, by running the following sql statement:

update phplist_user_user set uniqid=replace(uniqid, ‘-’, ‘’);


@ksmets removing “-” from the bad records seems to be the most straightforward way to go. @duncanc do you see any threat of that way?

@bernard.fruga @ksmets I don’t recommend changing the phplist code to work around the problem.

Firstly you will need to make the same change on all future phplist releases. Second, using the uuid value in the uniqid field is an error, and should be fixed, not worked around. There might be other areas of phplist that depend on the “correct” format.

If you don’t have a database backup then there is a manual process to generate new uniqids with the correct format.

@ksmets @bernard.fruga Sorry, my previous response was to a code change to ut.php that had been proposed. That seems to have disappeared now!

So long as the uniqid is 32 characters then it is of the correct format. You should be ok with the values really being unique because of the way that UUIDs are generated. View tracking in the emails sent with 3.3.0/3.3.1 will still not work but should work in future emails.

1 Like

@duncanc thanks for sharing your view (and yes, @ksmets edited his post, probably after inverting the idea of the mySQL records fixing); guys I do appreciate kind help of both of you; seems the problem is resolved to me :slight_smile: