Is PHP 8.x.x. supported by phpList?

ℹ️ Support
#1

I use phpList for sending mail to the members of my (millers) association.
When I use the PHP-version 7.4.28 everything goes fine.
When I use PHP- version 8.0.17 or 8.1.4 phpList give doesn’t function well.
Two problems under PHP 8.x.x:

  1. when I send mail to 20 email addresses sending breaks off before the end (after 17 for instance).
  2. spaces are added in the text of the mail.
    I give two exemples:
    Text in PHP 7.4.28:
    “dit is veel tekst terug lezend opnieuw gekocht. dit is veel tekst terug lezend opnieuw gekocht. dit is veel tekst terug lezend opnieuw gekocht. dit is veel tekst terug lezend opnieuw gekocht. dit is veel tekst terug lezend opnieuw gekocht.”
    Text in PHP 8.x.x:
    “dit is veel tekst terug lezend opnieuw gekocht. dit is veel tekst teru g lezend opnieuw gekocht. dit is veel tekst terug lezend opnieuw gekoc ht. dit is veel tekst terug lezend opnieuw gekocht. dit is veel t ekst terug lezend opnieuw gekocht. dit is veel tekst terug lezend opni euw gekocht. dit is veel tekst terug lezend opnieuw gekocht.”
    My problem is that PHP 7.2.28 will be no longer supported after November 2022.
    I hope:
    Or, someone can give me a advice which solves this problem
    Or, there will be a version of phpList before November 2022 with a solution for this bug.
    Thanks for reading this and for reactions,
    Fred Prins,
    Dutch miller
#2

@ffprins Which method do you use to process the queue? Through the admin interface or as a cron job?

Have you noticed any problems when using the admin interface to compose campaigns, maintain users etc?

Also, does phplist send through an smtp server or through the php mail function, PHPMAILERHOST in config.php?

Regarding your problem 1), look at the event log page to see any events issued when phplist was processing that campaign. There might be an explanation as why it sent to only 17 subscribers.

Regarding problem 2), look at the html source of the two emails to identify short sequences of where the text is different. When you copy them here use the toolbar code button </> so that it is clearer to see the differences.

#3

Thank you, Duncanc, for your responds.
And thank you for the trace you gave me.
Yes, I use the admin interface, always.
And now I have defined an other smtp.server in the config file,with login, with SSL, with defined port.
After that PHP 8.1.4 works well.
A satisfied Dutch miller,
Fred Prins

#4

@duncanc, problem Aug 18 not solved completely :thinking:.
With your suggestions on Aug 18 the problem of the damaged text was solved; a test mail was well send under PHP 8.x.x
Today I have send a mailing to all the members of my (millers) association. Under PHP 8.x.x no mails were send. Back to PHP-version 7.4.28 and then I succeeded in sending a mailing to the mailing group.
What can be the difference between PHP 7.4.28 and PHP 8.1.4??

#5

Please explain what you mean by this? Look at the Event Log page to see which events phplist logged when you processed the queue.

#6

Thank you @duncanc for your reaction.
I main under PHP 8.x.x no mails are send (that means only the first mail of the mailing list is send and not the others) and under PHP 7.x.x all mails are send.
I give you the Event Log (translated for you, because I am Dutch and the Event Logs are in Dutch too).

  • handling is started
  • one message to handle
  • please don’t close this screen. phpList will handle your order until all messages are send. This can take some time.
  • a report of sending the messages will be send to you by mail
  • handling of message 193
  • looking for members
  • Found: 71 to handle
    And than big silence: nothing has happend after the last 'Found: 71 to handle.
    I cancel transmitting > change the PHP-version of my domain from 8.x.x to 7.x.x and start again sending my message to my members (in half a minute the message is send to all the members).
    Now the Event Log is:
  • handling is started
  • one message to handle
  • please don’t close this screen. phpList will handle your order until all messages are send. This can take some time.
  • a report of sending the messages will be send to you by mail
  • handling of message 193
  • looking for members
  • Found: 70 to handle (now it’s 70, because the first time phpList had send the message to 1 member)
  • 70 of 70 members handled
  • It took 33 seconds to send this message
  • 70 berichten send in 35,50 seconds (7097 messages/hour)
  • Ready with this phase
  • the number of send messages was not big, so the page will be refreshed at once.
    Conclusion: the event log gives no reason for stopping; the event log stops too.
    As I wrote the first time. It is almost a year that I change the PHP-version of my domain (temporary) before sending mails to the members. But in October 2022 PHP 7.x.x will no longer be supported. I am afraid for problems with the website in my domain. So I praying for a phpList update without this problem :pray:t3::pray:t3:
#7

In my post above:
Main = mean

#8

@ffprins It does look like something is failing after sending the first email.
Is there a php error log that you can look at? If you are not sure then raise the problem with your hosting company or system administrator.

You could also try sending using a cron job instead of through the browser. That is the method I use successfully with php 8. See the online manual for an explanation of how to setup a cron job Setting up your Cron | phpList manual

#9

I’m using phpList 3.6.8 and have been using PHP 7.4.x (currently .32). Website uses Drupal 9.4.x which supports PHP 7.4 branch but Status Report recommends upgrading to 8.0 or higher and that 8.1.0 to 8.1.5 have an OPcache bug that can lead to fatal errors with class autoloading which can be avoided by using 8.1.6+. Drupal 10 and 9.5 are scheduled to be released 14 Dec 2022 and will require PHP 8.1.6 or later.

Switching to 8.1.x (currently .11) and going to yourdomain/lists/admin/?p=home or the subscribe pages results in a blank page with nothing in view source. Firefox displays a white screen and Chromium shows: This page isn’t working; yourdomain is currently unable to handle this request.; HTTP ERROR 500 and a Reload button.

Website is a shared hosting account running on Cloud Linux.

#10

@FredK You will need to find the php error log to see what is causing the 500 error. Sometimes there is an error_log file in the lists or lists/admin directory.

#11

I have two installations that are on servers with a different IP address. One has an error_log in /lists from a few days ago relating to undefined variable: table prefix. I switched both to 8.1.11 and just get the blank page with nothing additional in the error_log for the installation that has that file. I looked at the cPanel errors, and it only shows IP addresses trying to access files that don’t exist or don’t have permission to access.

#12

@FredK You can try enabling error reporting by making a change to the admin/index.php file

Add it just before a group of require statements at line 95

// load all required files
error_reporting(-1);
require_once dirname(__FILE__).'/init.php';

phplist works fine with php 8.1.11 on my site, which also has cpanel.

#13

@duncanc, I added: error_reporting(-1); as line 96. No additional errors are in the error_log or is an error_log file created in the installation where it doesn’t exist. Would the configure command from phpinfo be of any help?

I found a similar issue with 3.59 that was reported fixed in 3.61 0020318: PHP 8.0 support (PHPList 3.5.9) ? - phpList Mantis

Also found where you linked to MySQLi: Default error mode set to exceptions - PHP 8.1 • PHP.Watch

#14

@FredK Sorry, can you try adding error reporting one line later

// load all required files
require_once dirname(__FILE__).'/init.php';
error_reporting(-1);

I found that init.php itself turns-off error reporting.

#15

Great! That worked and a new error_log was created in /admin: (I’ve edited /username/… with /path_to/admin)
[14-Oct-2022 23:35:42 UTC] PHP Fatal error: Uncaught Error: Undefined constant “MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT” in /home/path_to/admin/mysqli.inc:23
Stack trace:
#0 /home/path_to/admin/mysqli.inc(148): Sql_Connect()
#1 /home/path_to/admin/mysqli.inc(333): Sql_Query()
#2 /home/path_to/admin/languages.php(35): Sql_Table_exists()
#3 /home/path_to/admin/index.php(104): include_once(’/home/username…’)
#4 {main}
thrown in /home/path_to/admin/mysqli.inc on line 23

I looked at config.php and had:
// force database connection to use SSL
$database_connection_ssl = true;

Changed true to false and it works and I can login again. Thanks for your help! Is it necessary or advised to use SSL to connect to the database?

Reloaded error_log and see this repeated four times:
[14-Oct-2022 23:47:48 UTC] PHP Deprecated: str_replace(): Passing null to parameter #2 ($replace) of type array|string is deprecated in /home/path_to/admin/defaultconfig.php on line 765
[14-Oct-2022 23:47:48 UTC] PHP Deprecated: str_replace(): Passing null to parameter #2 ($replace) of type array|string is deprecated in /home/path_to/admin/defaultconfig.php on line 766
[14-Oct-2022 23:47:48 UTC] PHP Deprecated: str_replace(): Passing null to parameter #2 ($replace) of type array|string is deprecated in /home/path_to/admin/defaultconfig.php on line 765
[14-Oct-2022 23:47:48 UTC] PHP Deprecated: str_replace(): Passing null to parameter #2 ($replace) of type array|string is deprecated in /home/path_to/admin/defaultconfig.php on line 766
[14-Oct-2022 23:47:48 UTC] PHP Deprecated: str_replace(): Passing null to parameter #2 ($replace) of type array|string is deprecated in /home/path_to/admin/defaultconfig.php on line 765
[14-Oct-2022 23:47:48 UTC] PHP Deprecated: Return type of phpList\plugin\Common\DBResultIterator::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/path_to/admin/plugins/Common/DBResultIterator.php on line 41

#16

There is a pull request in this area that was discussed but never resolved Specify MYSQLI_CLIENT_SSL flag when attempting SSL/TLS secured MySQL connections by jjthiessen · Pull Request #834 · phpList/phplist3 · GitHub so I would leave that setting for SSL alone.

The deprecations for null parameter are fixed in the upcoming release of phplist. Deprecation on use of str_replace with php 8.1 · Issue #888 · phpList/phplist3 · GitHub You can remove the last one for DBResultIterator by upgrading Common Plugin on the Manage Plugins page.

#17

Duncan, thank you for your help! :+1: I replaced the Common Plugin on both installations.