Database changes for version 3.0.12?

Is there a changelog file or a readme file that documents the changes between the various versions of phpList 3.0.X?


Yes you can see that here:

It’s not always very detailed… you can also see more detailed/user-friendly notes at, for example and

Hi Anna, unfortunately I don’t think these pages are much help with what I am looking for. I am trying to find out what the changes were in the database structure between versions 3.0.8 and version 3.0.12. When we updated, we got the message that our database would be updated as well because it was not compatible with 3.0.12. We have since run into some issues and we are considering rolling back to 3.0.8 as part of our diagnosis of the problem. However, we don’t want to lose the data we have accumulated, like unsubscribes (!) if we decide to do that.

This may now need to be moved to a different thread since it getting into a discussion of a specific problem.


Ok, I have asked on the developers mailing list, hopefully someone will get back to us :smile:

The file admin/upgrade.php contains the database changes for each release. If I am interpreting it correctly then there weren’t any changes between releases 3.0.8 and 3.0.12. In fact, there don’t appear to be any database changes since release 2.11.7, so I might not be.

Hi Duncan, any idea why the update installation process would have warned that the database required upgrading? Is it a legacy message from prior install code? FYI, the email distribution process started breaking down a couple of weeks after installing the plugin mod. However, it is now breaking down when we run phplist with and without the mod, so I’m hoping that it is not related. Thanks.

I’d like to add here that I have used version 3.05 and 3.0.12 on the same database. Each time I log into the system, the web page wants to ‘updated’ the database to match the web front end version. I have gone forward, and backwards in ‘updating’ and everything seems to work ok.

I DONOT RECOMMEND going backwards in revisions, but it did work for me.

Just upgraded from 3.0.5 and turned on the function of unsubscribing requires password by adding the following 2 lines to my config.php:


However, it was not working. Does anyone else has the same problem with me ???

After a quick review of index.php
I found the following condition cannot be true:

$login_required =
      (ASKFORPASSWORD && $userpassword && $_GET["p"] == "preferences") ||
      (ASKFORPASSWORD && UNSUBSCRIBE_REQUIRES_PASSWORD && $userpassword && $_GET["p"] == "unsubscribe");

Because $userpassword is always empty!!! THE USER DOES HAVE PASSWORD!!
I think something maybe wrong in the following code (index.php: ln91 ~ ln97)

 if (isset($_GET["email"])) {
    $req = Sql_Fetch_Row_Query(sprintf('select subscribepage,id,password,email from %s where email = "%s"',
    $id = $req[0];
    $userid = $req[1];
    $userpassword = $req[2];
    $emailcheck = $req[3];

In my scenario, there won’t be an email string contained in URL when unsubscribing. Therefore, $_GET[“email”] is always empty.

To fix the problem and minimize the impact, I added the following code to index.php after line 108:

  } elseif (isset($_GET['p']) && ($_GET['p'] == 'unsubscribe')) {
    if (isset($_POST["email"])) {
      $req = Sql_Fetch_Row_Query(sprintf('select subscribepage,id,password,email from %s where email = "%s"',
      $id = $req[0];
      $userid = $req[1];
      $userpassword = $req[2];
      $emailcheck = $req[3];

Yeah… I just changed $_GET[“email”] to $_POST[“email”]

I don’t like to modify the code manually at all. I am aware that all the changes will be lost during next upgrade.
However, I just couldn’t find out what’s wrong. Is that a bug? Anyone else can confirm that???

Hi, lead developer says can you make a bug report for this. Directions are on developers home page at

Thanks :slight_smile:

Sure! I will try to do that…

1 Like