@duncanc Done… nada. Same HTML output. 
@allvoxman sorry but I don’t know. You can try putting echo statements in admin/index.php to try to see whereabouts it is failing.
@duncanc No prob! Tried that. It breaks just here on this “if” clause. It stops echoing after that. See output on the background top left corner of the screenshot.
@allvoxman You can try the same with the file admin/ui/phplist-ui-bootlist/functions.php in the function _topmenu() which is where the output seems to stop.
Did you try php 7 instead of php 8? There are a few changes in phplist 3.6.1 due to php 8.
@duncanc This one’s the culprit on functions.php.
Yeah, I didn’t try php7 with this version. Actually I also suspect php8 may be the problem, but I want to use php8 on this machine. I think I can wait for the next phpList version if this one doesn’t work.
@allvoxman I think that $_GET[‘pi’] won’t exist so that might be the cause. You could try changing that line to
$currentPageCategory = empty($_GET['pi']) ? pageCategory($current_page) : '';@duncanc Thanks! That didn’t have any effect, but commenting the line did the trick. Admin seems to work without it. Any side effect that may arise? Could there be any other, say, less aggressive way to address it?
@allvoxman If I enable error reporting then there is a php warning about the pagecategory() function, with php 7. I can look at that tomorrow. Maybe in php 8 that is treated more seriously but I would have expected your testing to also have reported the warning.
@duncanc Yeah, it’s still enabled and doesn’t show any warning. Sure, let’s continue tomorrow. I’d like to get to the bottom of it, specially if it helps the project.
@allvoxman Can you try removing this line from file admin/ui/phplist-ui-bootlist/mainmenu.php and undoing any other changes you made
$GLOBALS['pagecategories']['develop']['toplink'] = 'tests';@allvoxman That line isn’t where the problem happens but is the cause. It needs to be wrapped in an if statement. I will raise an issue for this.
1 Like
@duncanc I found that the page “processbounces” is also throwing a blank page. Is it related to the same problem or should we do another bug hunt?
@allvoxman You will need to find why errors are not being displayed after enabling error reporting. Otherwise it is too lengthy to try to find where the problem is.
@duncanc OK… Turns out I hadn’t edited the correct php.ini. Now it’s showing all kindsa warnings all over the place (except for “processbounces”, where it goes white blank although there’s some background HTML). So, these are the warnings (paths edited):
Warning: Trying to access array offset on value of type null in /var/www/path/to/my/site/lists/admin/languages.php on line 360
Warning: Trying to access array offset on value of type null in /var/www/path/to/my/site/lists/admin/languages.php on line 358
Warning: Undefined variable $page_title in /var/www/path/to/my/site/lists/admin/ui/phplist-ui-bootlist/functions.php on line 2
@duncanc Oh shoot, there was another error hidden in the processbounces HTML, waaaaaaay down the document (around 10,000 blank lines below), that why I hadn’t seen it first:
Fatal error: Uncaught ValueError: imap_open(): Argument #4 ($flags) must be a bitmask of the OP_* constants, and CL_EXPUNGE in /var/www/path/to/site/lists/admin/processbounces.php:365
Stack trace:
#0 /var/www/path/to/site/lists/admin/processbounces.php(365): imap_open()
#1 /var/www/path/to/site/lists/admin/processbounces.php(494): processPop()
#2 /var/www/path/to/site/lists/admin/index.php(756): include(‘…’)
#3 {main}
thrown in /var/www/path/to/site/lists/admin/processbounces.php on line 365
phpList version 3.6.1
@allvoxman That error message doesn’t make any sense to me. That line of code is using CL_EXPUNGE.
If you can confirm that this works with php 7 then it might show a problem with php 8 or at least the build of php 8.
Your server environment of Ubuntu 20.4 seems to come with php 7.4. How/where did you get php 8?
Confirmed with php 7.4 just now:
From:
ppa:ondrej/php
which is a widely used ppa, I reckon.
@allvoxman I have installed php 8.0 from the same repository and can repeat the problem.
It looks to be a mistake in some new code in the imap extension for php 8 that validates the flags parameter, the fourth parameter. It has what looks to be incorrect validation of CL_EXPUNGE.
If you remove that parameter or use one of the others, such as OP_DEBUG then the imap_open will work.
@michiel Michiel, I think that you were doing some changes for php 8. Are you able to run the processbounces page in that environment?
1 Like
Ah, I haven’t tried that yet. I guess there are a few more PHP8 issues to iron out. I think we need to advice for the time being not to use PHP8, until we squashed all the issues.