Fatal error: Your phpList version is older than two years

I am using 3.3.1 because it works best for me, but today when I try to access my install it says “Fatal error: Your phpList version is older than two years. Please upgrade before continuing.” Is there a way around this without upgrading?

1 Like

Ditto on this.

This is a good idea badly implemented. I’ve been testing v3.3.9 for a few weeks as it sports some new stuff (mainly the upgrade feature) and I need to see how it behaves in our production environment.

1 Like

Same here.
I don’t have time to upgrade now. I have to send out a time sensitive newsletter immediately.

Has anyone found a work around. How are we to upgrade if we cant do proper comparisons and testing. Last time We tryied updating it broke our system. This shutdown stopped a mail blast right in the middle of it.

Same here too. Backed up, installed upgrade and still getting “Fatal error: Your phpList version is older than two years. Please upgrade before continuing.”

I have 30 installs of phplist 3.3.1 down due to this problem. :frowning: The new versions just aren’t the same as good old reliable 3.3.1

Hi everyone who is using version 3.3.1 or older,
a workaround would be removing this check https://github.com/phpList/phplist3/blob/3a3e9eaf5796353b67e94535a9e20de8ceb489e3/public_html/lists/admin/index.php#L529-L534 from the code.


Thanks for the workaround. At a loss why anyone would do this. Did anyone get a heads up that this was coming?

I just got this too.
I overwrote the lists directory with 3.3.9, overwrote the new config.php with my backed-up config.php.
But now database upgrade isn’t returning from blank screen.
I have waited over 30mins, and cleared the value in maintenancemode in the config mysql table. I have done this twice. I still cannot get database upgrade to be successful.

I am willing to start from scratch (bringing along just my 100+k subscribers), is there a easy way to do this?


Thanks! Since we’re all on version 3.3.1, the line numbers are actually 493-499. Here’s the commit for when this was added: https://github.com/phpList/phplist3/commit/d4ee3cf63170d471e937f86b6a3053c31333f450

1 Like

@kaon I wouldn’t suggest using v3.3.9 software if your database upgrade fails.

1 Like

Hi All, let’s group together the information into a single post that should give most people the answers they’re looking for.


Sorry that this has caused significant disruption. The version check was introduced two years ago and not everyone in the core contributors team were aware of it. Advance notice should have been provided to you so as to avoid a shock. Sorry that it wasn’t.


Running old versions of phpList is very bad idea. For security and legal reasons alone, running a version older than 2 years will cause you headaches over time. Those headaches are bad for users, administrators, and the reputation of the project. They also mean this support community spends time on issues that were previously fixed, or cannot be reproduced by support-providers.

In some specific cases it is hard or impossible to upgrade phpList. For my perspective those cases are invitations to address the underlying causes, not expose your users, servers, and legal entities to avoidable risks.


You can disable the message and the corresponding check by deleting these lines from your admin/index.php file. Note that the code, not the line numbers, should be checked, because the line numbers are different in different versions of phpList:

    if (defined('RELEASEDATE') && ((time() - RELEASEDATE) / 31536000) > 2) {
    Fatal_Error(s('Your phpList version is older than two years. Please %supgrade phpList</a> before continuing.</br>
        Visit <a href="https://www.phplist.org/users/" title="'.s('Get some help').'">the support site</a> if you need some help.'
        ,'<a href="https://www.phplist.com/download?utm_source=pl'.VERSION.'&amp;utm_medium=outdated-download-forced&amp;utm_campaign=phpList" title="'.s('Download the latest version').'" target="_blank">'));


An alternative way of handling this version cut off point will be worked on and find it’s way into a future release, probably next month.

Thanks for your attention; I’ll mark this post as the solution to this thread.


Thanks for the response and clarification! I hope this means something (anything, almost) besides a fatal error. I understand that there are security risks to using software that is out of date, but 2 years is an arbitrary time limit, and ultimately I want to make the final decision on whether or not I’m OK with the risks.

Is this the best place to continue the discussion, or is there another place where the team will be discussing alternative methods that I can watch to see how this evolves?

Other projects handle this easily by requesting that you provide your version number when asking for support.

I don’t think the amount of time is as important as keeping up to date with security patches. What were some security fixes that were added after version 3.3.1 that I should be aware of?

It is actually the admin/index.php file that has to be edited, not init.php

1 Like

Yes this thread is a good centralised location

The version number is requested in the issue tracker, but not in the forum. Either way, supporting and discussing old and potentially insecure versions is not something that should be encouraged.

Please see the release notes of each particular release for details.

Suggestion: instead of commeting out code in admin/index.php

change the RELEASEDATE in admin/init.php to something in the future

define("RELEASEDATE", "2486989511");

Same difference, maybe.

1 Like

I did that. That’s why I specifically asked. I went through the release notes of every version 3.3.2 through 3.3.9, and searched for the word “security” but found none, except for 3.3.3 which specifically mentions “This is not a security-related release.

I don’t mean to be confrontational, but the fact is that if no security improvements have been made in any of the newer releases, then logically version 3.3.1 is just as secure than version 3.3.9. It has absolutely nothing to do with 2 years or any other arbitrary amount of time.

I mean seriously, have there been any security updates in the past 2 years? I can’t find them.

The version check which causes the error is not about a single release or a single security fix. It is about staying regularly up to date for the reasons mentioned above.

Sometimes releases include fixes related to security or legislation. It is in everybody’s interest to adopt those updates in a timely manner. Recent improvements such as the Automatic Updater reflect efforts to make this as easy as possible. That is a better use of project resources in my view than maintaining additional changelogs and expiry notifications for specific releases, particularly as phpList is now released monthly.

Nevertheless the error was not well handled and we’ll take steps to avoid such a surprise occurring again.