Various problems while upgrading from 3.0.10 to 3.2.2

ℹ️ Support
1

Hi there,
I finally decided to upgrade to latest version (3.2.2) on monday.
And I encountered some problems, most of them are not solved :frowning:

Here is the steps i followed :

  • DB backup

  • /list backup
    I then decided to clean up DB linktracks (it was over a Gb, with messages from 2012).
    I had there a first problem : the table crashed (and is still marked so)

    #144 - Table ‘./reseauid2010/Z_phplist_linktrack’ is marked as crashed and last (automatic?) repair failed

It appeared that my DB backup crashed as well - yep, thats bad luck, and no way to get it back for now.
Anyway, since its “only” linktracks, and since I had a mailing to send today, it let it that way for now.

But still, first problem is a crashed down linktrack table, and I cant fix it.

So, after that DB crash, I installed the new version. No major problems, I restored my config file, everything seemed to work properly.

I prepared my mailing (its in french, with damn characters…), did the classic tests, and found out that the mail subject went from

[communiqué] Eduquer au climat, une nécessité

to

=?UTF-8?Q?[communiqu=C3=A9]_Eduquer_au_climat, _une_n=C3=A9cessit=C3=A9?=

This showed up in the test mail, I tried various things, and it kept doing the same, as long as the text is longer than (put a number here, i didnt find out).
i.e. a subject “Une nécessité” will pass w/o a problem, but a longer phrase with that word in it will cause the bug.

I finally made it shorter, test email was perfect, but my campaign was screwed.

So my second problem is that I cant put accented letters in the subject if its longer than roughly 40 chars

Finally, I put it all in upper case (yeah, its ugly, but it solves the accents problem for now), and I encountered my 3rd problem of the day :smile: :

After putting my message in the queue, I “processed the queue”. In the previous version, I had something like a counter telling me it was sending by blocks of 20 (I have a mutual OVH host, its a pain), and that it was waiting 20 seconds to send the next block.
I dont have anything like that anymore, I just see the phpList logo turning around. After 5 minutes, I had a doubt. I stopped the process, and I found myself on the login page. When I logged back in, my message was still in the queue, with only 60 users processed. I reprocessed the queue, and same deal. It ends up by logging me off, and when i get back in, I only have the next 60 users processed.
Since I only had 600 users this morning, I did this 10 times, and well, it worked. But on January, I gotta send wishes to 10’000 users, and trust me, I really dont feel like doing it manually :smiley:

So, problem #3 : when processing, it only sends 60 messages then logs me out. I have to log back in, reprocess the queue, etc.

Any help would be appreciated. I tried to find some help on the forum here, and on google, but many links send to the old forums, and I cant really find anything adapted to my situation.

Thanks a lot

2

@ReseauID The linktrack table is no longer used. When you upgraded from 2.10.x you should have run a process to convert click statistics. That process would have emptied the linktrack table so I guess that you have not run it.
Depending on how long ago that was, and that the table is marked as crashed, you may be able to just empty it, after fixing the crash problem through phpmyadmin.

Using your subject - [communiqué] Eduquer au climat, une nécessité - in a campaign, it is shown correctly when displayed in Thunderbird.
The value that you appear to see is the Subject header within the email but the escape sequences should be converted back to accented characters.

Pasted image700×71 13 KB

What are you using to display your email when the subject is shown like that?

The approach used by phplist when sending through the browser now limits the time to one minute. You might need to modify your batch settings to take that into account.
But a better approach, especially for large lists, is to use a cron job, which does not have that restriction and it generally more reliable.

3

Thanks @duncanc for those answers.
Indeed, I remember that I once had a “convert stats” thingy, that never worked. I still had it before the crash, with over 2 millions data to be converted (but it didnt work, and to be honnest, I never really looked up to solve that problem).
I’ll try to find more documentation about that point, and remove the unused tables. This concerns all the “linktrack_xxx” tables?

For the subject, you are damn right, the problem only appeared in Mail (Mac OS X 10.10), and thats why some tests yesterday evening went fine, since I did it from home on thunderbird and gmail… I was too tired to make the good conclusions.
Sadly, it doesnt help me for the Mac OS X problem, and 10% of my users are on Mac. But at least, its only a small part of my audience.

Finally, I know I should set up a cron job, but as I said, I’m hosted on mutual OVH server, and as far as I know, it’s a pain to set up anything like that (or at least, it used to be).

4

The only sensible way of converting millions of linktrack records is with a cron job, so you might just have to give-up on having old statistics. phplist 2.10 uses the linktrack and linktrack_userclick tables. The linktrack_forward, linktrack_ml and linktrack_uml_click are used by the current phplist so you should not touch those.

5

If it is not possible to run a cron job then you could use the remote queue processing from phplist hosted, see system:remote_processing [phpList Resources]