Phplist and PHP7

ℹ️ Support
#1

Does anyone have test phlist with php7

#2

I haven’t tested with php7 but would expect there to be some problems with magic quotes, and possibly other previously deprecated functions.
Even if phplist is updated to work with php7, some of the other packages that it uses, such as phpmailer, CKEditor, might not be ready.

It is probably best if you raise this, and post any of your own results, on the developers mailing list https://lists.sourceforge.net/lists/listinfo/phplist-developers

1 Like
#3

Thanks duncanc.
So i’ll test and hive my feedback,
If any woy test also to hesitate to feed.

#4

After test no problem!

1 Like
#5

I run phplist 3.2.4 under PHP 5.6 which worked pretty well.
Today I updated my webserver to PHP 7.0.4 as Joomla 3.5 was published yesterday which is compatible to PHP 7 now.
Without any other changes, phplist doesn’t work anymore. I get displayed a blank page: http://news.mediaventa.de/admin/?page=home

Best regards
Roland

#6

@michiel and @samtuke might wonna read this thread

a
x

#7

the Travis CI checks pass on PHP7, https://travis-ci.org/phpList/phplist3

That does a basic install of phpList. But I’ll see if I can get this going on a VM or something.

1 Like
#8

Hi michiel,
I rechecked my server. it is a shared hosting server of the company Strato, which is well known in Germany.
In my Strato user profile I can switch between PHP versions 5.3 / 5.5 / 5.6 / 7.0
If I go back to 5.6, phplist works fine again.

I tried to get some output in PHP 7 but there is still a blank page.
This is the content of php.ini:
display_errors = on
display_startup_errors = on
error_reporting = E_ALL
zlib.output_compression = On

This is the content of .htaccess:

mod_gzip_on Yes

DirectoryIndex index.php
<FilesMatch “.(php|inc)$”>
Order allow,deny
deny from all

<FilesMatch “(index.php|dl.php|ut.php|lt.php|download.php|connector.php|info.php)$”>
Order allow,deny
allow from all

Best regards
Roland

#9

I installed a local VM with PHP7

PHP Version 7.0.4-1~dotdeb+8.1

phpList works fine. Maybe you have something in your config file that is clashing?

#10

I had the same issue and resolved it via php.ini trickery. This made everything work (substitute your own paths):

[PATH=/usr/local/www/phplist]
open_basedir = /usr/local/www/phplist:/usr/local/bin

#11

Thanks for this php.ini configuration.
I created a php.ini file in my phplist directory with following content:

[PHP]
[PATH=/mnt/webm/c1/93/53299493/htdocs/phplist]
open_basedir = “/mnt/webm/c1/93/53299493/htdocs/phplist/”

It doesn’t solve the problem. I still get a blank webpage on PHP 7.0.5
Running phpinfo() shows an empty value for open_basedir, which means, the parameter doesn’t get loaded.
Switching y server to PHP 5.6.20 phplist works.
I assume that there is no error in my config.php

I wait for new versions of phplist or updates for PHP 7. In the meantime I switch my server to PHP 5.6 when using phplist. Not very elegant but a practical workaround.

#12

php.ini does not belong in the phplist directory. It’s usually located somewhere in /etc or /usr/local/etc, depending on your OS. If you’re running Apache, you can try to trick it with .htaccess (create it under /mnt/webm/c1/93/53299493/htdocs/phplist/), which should contain the line

php_value open_basedir “/mnt/webm/c1/93/53299493/htdocs/phplist/”

If you are not running Apache, you can try renaming the php.ini as .user.ini (yes, it’s a dot before user). Some (but not all) installations of PHP (starting with 5.3.0) pick it up. The service provider, however, may have changed that behaviour. I have limited experience with virtual hosts so I cannot really comment on how things are set up at Strato, and my knowledge of German is limited to ‘ich habe Sauerkraut in meiner Lederhosen’ so I cannot really decipher the relevant portions of their website that well. Anyhow, if you can make PHP pick up that value, it should be smooth sailing with 7.0.

1 Like
CKEditor isn't loaded anymore after switching to PHP 7.0
#13

Hello,
I also have problems with php 7, same kind of yours: a blank page.

What I found by my side (site hosted by One.com) is that the problem come from including ‘HTTP/Request.php’ in admin/init.php. There is now an error thrown with php 7: “Parse error: syntax error, unexpected ‘new’ (T_NEW) in /usr/share/php/HTTP/Request.php on line 412”.
That never happened with php < 7.0

Beside this, class_exists(‘HTTP_Request’) gives ‘false’.

So my questions are: as we know that PEAR::HTTP_Request is quite old, is it really necessary to use this ? What should happen if ‘HTTP/Request.php’ is not included ?

Thanks for your help.

#14

Usually phplist does not use HTTP_Request. I suspect that it is being included because curl is not available. Check your php configuration to see whether that is the case. If it is then install or enable the curl extension.

#15

Thanks duncanc for your anwer.

curl is available and enabled by One.com, indeed.
The fact is that the test on availability of curl is done after checking http_request in init.php:

//@@TODO finish this, as it is more involved than just renaming the class
//@include_once "HTTP/Request2.php";
if (0 && class_exists('HTTP_Request2'))
{$GLOBALS['has_pear_http_request'] = 2;}
    else {
@include_once 'HTTP/Request.php';
$GLOBALS['has_pear_http_request'] = class_exists('HTTP_Request');
}
$GLOBALS['has_curl'] = function_exists('curl_init');
$GLOBALS['can_fetchUrl'] = $GLOBALS['has_pear_http_request'] || $GLOBALS['has_curl'];

Here, class_exists(‘HTTP_Request2’) returns ‘false’, so HTTP/Request.php is included and gives an error (since php 7) and class_exists(‘HTTP_Request’) is ‘false’, also.

Fortunately, function_exists(‘curl_init’) returns ‘true’.

So I’ll comment out the (for my case) useless lines. This will solve my problem.

Can this be considered as a “bug” to be corrected for future releases and improve compatibility with php 7 ?

#16

@smilo227 Yes there is a bug somewhere. As HTTP_Request is not compatible with PHP7, should that be changed or should phplist make a special case?

You could raise this as an issue on Mantis the bug tracking system, https://mantis.phplist.org/view_all_bug_page.php but you will need to register first.

#17

Thanks a lot, that solved the problem for me too! Before adding the line I also saw only a blank page.

For anyone else having the same problem: In order to be able to upload attachments again I also had to add the temporary directory “/tmp” to the directive since it’s outside of the path of my phpList installation (the temporary directory is defined in /phplist/config/config.php).

So in my case the line looks like this:

php_value open_basedir “/www/htdocs/[my_user_account]/lists3/:/tmp/”

#18

Here’s my result with PHP 3.2.5 on a Plesk 12.5 Centos VPS, with existing PHP: 5.4.45 as Apache Module.

I used Plesk to install PHP 7.0.16 (without replacement of the old version).

When I chose to use PHP 7.0.16, my PhpList has this problem:

  • Login page seems to works normally
  • After successful login, I land on ?page=home as usual.
  • If I click anything else, I am kicked out to the login page again. http://example.com/lists/admin/?page=logout&err=1
  • The login page still works normally, but I can only get to home.
#19

This issue seems to go back even to phpList ver 2.10.12.

Upgrading from php 5.4 to php 5.6 broke 2.10.12 (blank page).

The culprit, as above but different file (admin/lib.php line around line 114) is loading HTTP_Request .

@include_once "HTTP/Request.php";  //DISABLE for ver 5.6 php

Disabling above line and amending below to FALSE allows to run. ver 3.x onwards I think codes for cURL instead.

For operational/archival purposes needed access to the old phpList after updating to php 5.6 (Apache)

# $GLOBALS['has_pear_http_request'] = class_exists('HTTP_Request'); //disable for php 5.6

$GLOBALS['has_pear_http_request'] = FALSE; // enable for php5.6