phpList Updater: Plugin Update phpList

Hi,
we are using phpList 3.6.14 and wanted to use the automatic updater for upgrading to version 3.6.15.

When clicking on “use the phpList Updater” on the Dashboard, the following page says:

This plugin needs to be configured, see the plugin documentation.

Checking the Updater plugin at Config → Manage plugins
the following is shown for the UpdaterPlugin

  • Name: Updater Plugin*
  • Description: Page to update the phpList code*
  • version: 1.2.1+20230822*
  • Update statusPlugin must be updated manually*
  • More information: Documentation Page*

Checking the linked documentation at
https://resources.phplist.com/plugin/updater
it is written:
You can upgrade the plugin to the latest version through the Plugins page (menu Config > Manage plugins) using the package URL

Unfortuantely, there is no setting at this page available there to set this URL.

But it looks like, the Updater Plugin is already present in the newest version 1.2.1+20230822.

File public_html/lists/config/config.php does not contain variable $updaterConfig.

What are the steps in order to get the Updater Plugin get working?

Thanks in advance
Holger

@howie That is explained at plugin:updater [phpList Resources]

$updaterConfig = [
‘work’ => ‘/my/phplist/updatedir’,
];

Update phpListDownload of Download phplist-3.6.16.zip (phpList) failed

@duncanc Thanks!

The variable

$updaterConfig = [
    'work' => '/my/phplist/updatedir',
];

in config.php and an apache restart made the Updater Plugin to show the button *Download phpList file".

This dir is set to be writable (and executable) by www-data, the apache2 process for serving phpList.

Klicking on the button takes pretty much 60 seconds until the message about a failed download is shown:

Update phpListDownload of Download phplist-3.6.16.zip (phpList) failed

Since a curl call on the machine takes about 3 minutes for downloading the zip file, this problem seems to be a timeout problem.

The timeout for apache2 is set to 300 seconds. So I don’t know, what the problem behind the scene is. Is there an own timeout setting for php or phpList? Maybe, there is a logging available pointing to the right direction? We have pretty much a standard installation of Apache/2.4.52 (Ubuntu) and made very few modifications to phpList (optical).

Thanks again for your help
Holger

@howie You can try setting the php timeout as explained on that same page of the documentation.

But SourceForge is taking an extremely long time to download the phplist zip file, several minutes. I don’t know why that is happening. Yesterday that was happening initially but later I downloaded the zip file in just a few seconds.

@duncanc, thank you. Reading docs to the end is really good sometimes :wink:
anyway, next try reveals, that SourceForge is much faster today and the download is done after a few seconds.

One useful tip.

As I run my own virtual server and have full root admin control over it, I found a way to avoid the slow downloading of the phplist-3.6.16.zip file from sourceforge when using the phplist updater plugin. Instead I download it manually and then place it within the $updaterConfig work directory.

so if my config is

$updaterConfig = [
    'work' => '/my/phplist/updatedir',
];

then at the cli I run

wget https://cyfuture.dl.sourceforge.net/project/phplist/phplist/3.6.16/phplist-3.6.16.zip

then

cp phplist-3.6.16.zip /my/phplist/updatedir

Make sure the permissions are readable with

chown apache:apache /my/phplist/updatedir/phplist-3.6.16.zip 

then when you run the phplist updater plugin it seems to find the phplist-3.6.16.zip in the correct place and run the updater as expected.

Be warned: this process does delete the file /my/phplist/updatedir/phplist-3.6.16.zip so you’ll need to replace it each time you carry out this process.

I hope this helps

@Gerard, thanks for the update. Next time, the download times out, this hint will be a nice workaround.

1 Like

Yes, that is not documented but was to help my own testing to avoid having to download so often. The plugin does download the MD5 file to confirm that the local file is really the same as on SourceForge.

There is an undocumented setting to tell the plugin to keep the zip file

'delete_archive' => false,
1 Like

Excellent and its a canny little addition to the code.

Cheers :beers: