Consistent errors during installation - does anyone else get these?

[BrendonKoz]

This is likely caused by my development setup using Docker and shared drives (slow read access), but I'm just wondering if anyone else is seeing these (warnings) at the end of (or during) installation, or if it's just me.

Oh, this is the current DEV version of PW: 3.0.241, though I've been seeing these errors as far back as I can remember.

[wbmnfktr]

Nothing like. Not even similar in the last couple of months. Even when installing it into an Nginx environment.

And the worst part... not even a clue where to look.

Is there more in the logs of either PW or Apache or Docker?

Just installed a 3.0.241 (fresh download) a couple of minutes ago without issues (PHP 8.2, MariaDB 10.4 via DDEV).

[poljpocket]

Yes, this happens to me with every fresh install when using PHP 8.0+, at least since version 210.

There seems to be no culprits and I am just ignoring this as it is only the installer which produces these.

I got used to it ??

[wbmnfktr]

1 hour ago, poljpocket said:

Yes, this happens to me with every fresh install when using PHP 8.0+, at least since version 210.

So... at this point you, @BrendonKoz, and others should post all details about their setups to find the issue.

Those warnings might not have an impact, BUT they are a very bad look when trying/installing ProcessWire for the very first time.

For my current DEV-setups:

• latest DDEV (Host: Ubuntu 23.10, not virtual)
• PHP 8.2
• MariaDB 10.4
• Apache FPM
• InnoDB, utf8mb4
• Latest successful ProcessWire version: 3.0.241

For my current PROD-setups:

• PHP 7-4 to 8.2
• MySQL v. ??? on webgo, and whatever on Hostinger
• Apache - not sure how it runs there (webgo, Hostinger)
• InnoDB, utf8mb4 and a lot of MyISAM with utf8 and utf8mb4
• ProcessWire from 3.0.165 to 3.0.241

[bernhard]

DDEV + PHP8.1/2/3: No warnings.

[BrendonKoz]

Development Environment

Host OS: Windows 11
devilbox (predefined docker config, so a DDEV competitor) using shared drives between host and guest
PHP: 8.2.1
Apache: 2.4.54
MySQL 8.0.32
ProcessWire (recalled as tested) from 3.0.229-3.0.241

I truly do believe it's due to my test environment (which also seems to cause a Tracy error when using the console) causing race conditions, and primarily because of the shared drives. I'll try to spin up a test on our host just to verify that though and report back.

[BitPoet]

The first thing I'd look for would be whether there's an auto_prepend_file entry in php.ini.

[BrendonKoz]

Production (shared) Server (Host: Dreamhost):

Completely fresh install of the DEV version (v3.0.241)

Host OS: Ubuntu Jellyfish v22.04
PHP: 8.2.18 w/Zend Opcache v8.2.18 running as CGI/FastCGI
MySQL: 8.0.28 running on Ubuntu 20.04
Apache: 2.4.52 running a custom (unpublished, by the host) mod_security

There are no logs generated in the asssets/logs folder aside from modules.txt and system-updater.txt, and both were informational, none contained actual errors.

Here are the errors captured from the server's errors.log file, which unfortunately are unlikely to be too terribly helpful, beyond what the image itself shows:

Quote

[Wed Aug 21 11:07:46.151282 2024] [fcgid:warn] [pid 1988300:tid 140497328444992] [remote 24.97.137.114:62166] mod_fcgid: stderr: PHP Warning:  ini_set(): Session ini settings cannot be changed after headers have already been sent in /home/sspl/go.sspl.org/wire/core/Session.php on line 287, referer: https://go.sspl.org/install.php
[Wed Aug 21 11:07:46.151322 2024] [fcgid:warn] [pid 1988300:tid 140497328444992] [remote 24.97.137.114:62166] mod_fcgid: stderr: PHP Warning:  session_name(): Session name cannot be changed after headers have already been sent in /home/sspl/go.sspl.org/wire/core/Session.php on line 291, referer: https://go.sspl.org/install.php
[Wed Aug 21 11:07:46.151325 2024] [fcgid:warn] [pid 1988300:tid 140497328444992] [remote 24.97.137.114:62166] mod_fcgid: stderr: PHP Warning:  ini_set(): Session ini settings cannot be changed after headers have already been sent in /home/sspl/go.sspl.org/wire/core/Session.php on line 297, referer: https://go.sspl.org/install.php
[Wed Aug 21 11:07:46.151328 2024] [fcgid:warn] [pid 1988300:tid 140497328444992] [remote 24.97.137.114:62166] mod_fcgid: stderr: PHP Warning:  ini_set(): Session ini settings cannot be changed after headers have already been sent in /home/sspl/go.sspl.org/wire/core/Session.php on line 298, referer: https://go.sspl.org/install.php
[Wed Aug 21 11:07:46.151331 2024] [fcgid:warn] [pid 1988300:tid 140497328444992] [remote 24.97.137.114:62166] mod_fcgid: stderr: PHP Warning:  ini_set(): Session ini settings cannot be changed after headers have already been sent in /home/sspl/go.sspl.org/wire/core/Session.php on line 299, referer: https://go.sspl.org/install.php
[Wed Aug 21 11:07:46.151336 2024] [fcgid:warn] [pid 1988300:tid 140497328444992] [remote 24.97.137.114:62166] mod_fcgid: stderr: PHP Warning:  ini_set(): Session ini settings cannot be changed after headers have already been sent in /home/sspl/go.sspl.org/wire/core/Session.php on line 300, referer: https://go.sspl.org/install.php
[Wed Aug 21 11:07:46.151339 2024] [fcgid:warn] [pid 1988300:tid 140497328444992] [remote 24.97.137.114:62166] mod_fcgid: stderr: PHP Warning:  ini_set(): Session ini settings cannot be changed after headers have already been sent in /home/sspl/go.sspl.org/wire/core/Session.php on line 312, referer: https://go.sspl.org/install.php

PHP.ini file:

Quote

;;; DreamHost-generated php.ini for PHP 82

allow_call_time_pass_reference = 0
asp_tags = 0
date.timezone = "America/Los_Angeles"
display_errors = 0
engine = 1
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
expose_php = 0
magic_quotes_gpc = 0
mail.add_x_header = 1
max_execution_time = "-1"
max_input_vars = 3000
memory_limit = "128M"
output_buffering = 0
post_max_size = "512M"
realpath_cache_size = "128k"
realpath_cache_ttl = 300
register_argc_argv = 0
register_globals = 0
register_long_arrays = 0
safe_mode = 0
sendmail_path = "/usr/sbin/sendmail -t -i"
session.bug_compat_42 = 0
session.gc_divisor = 1000
session.hash_bits_per_character = 6
session.save_path = "/tmp"
short_open_tag = 1
upload_max_filesize = "512M"
opcache.memory_consumption = 32
opcache.interned_strings_buffer = 2
opcache.max_accelerated_files = 3907
opcache.fast_shutdown = 0
opcache.use_cwd = 1
opcache.file_cache = ""
opcache.enable_cli = 0
pcre.jit = 0

;;; Extensions

extension = bcmath.so
extension = bz2.so
extension = calendar.so
extension = ctype.so
extension = curl.so
extension = dom.so
extension = exif.so
extension = fileinfo.so
extension = ftp.so
extension = gd.so
extension = gettext.so
extension = iconv.so
extension = imap.so
extension = mysqli.so
extension = openssl.so
extension = pcntl.so
extension = pdo_mysql.so
extension = phar.so
extension = posix.so
extension = pspell.so
extension = session.so
extension = simplexml.so
extension = soap.so
extension = sockets.so
extension = tokenizer.so
extension = xml.so
extension = xmlreader.so
extension = xmlwriter.so
extension = xsl.so
extension = zip.so
extension = zlib.so
log_errors = on

;;; BELOW ARE THE CONTENTS OF php.ini.local
;;; VALUES BELOW WILL OVERRIDE ANY SET ABOVE!

[wbmnfktr]

How do you put the files on the server - FTP, SFTP, Rsync, Samba share or so?

Do the access rights (read/write) of those files look ok?
Is the session folder writeable?

[BrendonKoz]

For the production server, I SSH'd in and used wget from the PW download/core URL of the zip file. I then unzip'd, and rm'd the zip file. `mv` the files from the processwire-dev (including the dot-files) so that everything was in root, and then ran the installer. The access rights of the files look ok: 775 for folder, 664 for files (600 for session files). The session folder is writeable.

[bernhard]

I don't think that this is very helpful, but maybe someone sees something helpful in this AI help, so I'll share it:

Quote

The errors you're seeing are related to session handling in ProcessWire. The main issue is that the script is trying to modify session settings after headers have already been sent. To resolve this, you need to ensure that no output is sent before session-related operations are performed.

Here are some suggestions to address these errors:

1. Enable output buffering: Add the following line to your php.ini file:

```ini
output_buffering = 4096
```

This will buffer the output and allow session modifications before sending headers.

2. Increase the memory limit: Your current setting is 128M, which might not be enough for ProcessWire. Try increasing it:

```ini
memory_limit = "256M"
```

3. Enable error reporting during development: Change these lines in your php.ini:

```ini
display_errors = 1
error_reporting = E_ALL
```

This will help you see any other errors that might be occurring.

4. Ensure that there are no whitespace or PHP short open tags at the beginning of your PHP files, especially those that handle sessions.

5. Check your ProcessWire configuration: Make sure that the `$config->sessionAllow` setting in your `/site/config.php` file is set to true before any output is sent.

6. Update your ProcessWire installation: If you're using an older version, consider updating to the latest stable release, as this issue might have been addressed in newer versions.

After making these changes, restart your web server and try the installation process again. If you're still encountering issues, you may need to review the ProcessWire installation files, particularly `/wire/core/Session.php`, to see if there are any output statements before the session handling code.

 

[poljpocket]

As I mentioned, this happens to me every time. Well, I thought about how I'm installing PW usually: To start a new project and what do always enable for in-development projects? I enable debug mode.

So, I am still testing around a bit, but using my docker image (https://hub.docker.com/r/poljpocket/processwire) the errors only are output if I enable debug mode, leaving debug mode disabled I get no warnings.

[poljpocket]

I made some progress. With debug mode enabled, I tried to just go with what the error messages were saying. Seemingly, headers are being sent before the last ini_set calls were made. So I restructured the install.php a bit and moved the PW initialization in step 5 of the installer in front of the install-head.php include:

No more warnings even with debug mode on. @ryan I think this might be worty of a PR? Would you like one?

Edited August 22 by poljpocket

[poljpocket]

Here is the updated install.php file for you guys to test out if you want: processwire/install.php at fix/installer-warnings-session · poljpocket/processwire (github.com)

[Jan Romero]

19 hours ago, BrendonKoz said:

output_buffering = 0

I don’t pretend to have a good understanding of this stuff, but does the PW installer perhaps rely on output buffering to modify headers after starting the response body? Do the errors go away when you set this to 4096?

Edit: I see this is exactly what the AI said. ignore me

Edited August 22 by Jan Romero

[BrendonKoz]

6 hours ago, poljpocket said:

As I mentioned, this happens to me every time. Well, I thought about how I'm installing PW usually: To start a new project and what do always enable for in-development projects? I enable debug mode.

Good catch! I never thought about that, but yes, I always enable that upon first installation too, and disable it as needed.

5 hours ago, Jan Romero said:

I don’t pretend to have a good understanding of this stuff, but does the PW installer perhaps rely on output buffering to modify headers after starting the response body? Do the errors go away when you set this to 4096?

Another good catch because, honestly, I never really look at the host's customizations. If I want something different, I used to have to compile and configure PHP myself, so I aim not to have to do that. That said, PHP's output buffering functions (ex: ob_start()) are usually used when dealing with session handling, and I just presumed Ryan was using them. Perhaps not.

I'll have to try @poljpocket's install.php file and see, quickly, if it fixes things (easier than searching the entirety of the codebase for ob_start calls and if/how they're used!).

[BrendonKoz]

Success. ?

[BrendonKoz]

6 hours ago, poljpocket said:

I think this might be worthy of a PR?

Yes, please.

[poljpocket]

Done: restructure install.php to do away with warnings by poljpocket · Pull Request #300 · processwire/processwire (github.com)