Update to 3.3.15 success, but PHP errors, my site is gone - RESOLVED

[Fogbow_Foggy]

Here are the errors I'm getting. I will try to edit /vendor/composer yadda yadda to comment out line 576, but does anyone know what is causing this problem? Here are the PHP errors I'm getting:

[phpBB Debug] PHP Warning: in file [ROOT]/vendor/composer/ClassLoader.php on line 576: include([ROOT]/vendor/composer/../s9e/text-formatter/src/Configurator/RendererGenerators/PHP/XPathConvertor/Convertors/BooleanFunctions.php): Failed to open stream: No such file or directory

[phpBB Debug] PHP Warning: in file [ROOT]/vendor/composer/ClassLoader.php on line 576: include(): Failed opening '[ROOT]/vendor/composer/../s9e/text-formatter/src/Configurator/RendererGenerators/PHP/XPathConvertor/Convertors/BooleanFunctions.php' for inclusion (include_path='.:/opt/cpanel/ea-php83/root/usr/share/pear')

[Fogbow_Foggy]

Here are the last few lines of the file ClassLoader.php that's causing the problem, but I don't understand it or what went wrong. Remember, my ACP works fine and says I have updated my site to 3.3.15. But my site has only the PHP errors. When I commented out line 576 (include $file) I got a 500 error for a website. Please, i have users all over the globe who are waiting for us to get back online again.

Code: Select all

        /**
         * Scope isolated include.
         *
         * Prevents access to $this/self from included files.
         *
         * @param  string $file
         * @return void
         */
        self::$includeFile = \Closure::bind(static function($file) {
 576           include $file;
        
        }, null, null);

    }
}

[thecoalman]

That error is telling you the file is missing, Delete vendor folder and re-upload it.

[Fogbow_Foggy]

I deleted my vendor folder and downloaded a fresh copy of 3.3.15.zip. I'll unpack that and upload the vendor folder.

[Fogbow_Foggy]

That apparently did it, my board is back online (thefogbow.com/forum), but I will check everything I can for a while to make sure.

[Fogbow_Foggy]

Perfect. I use FileZilla SFTP, I don't know how it could have missed a file the first time, but whatever, the problem is fixed and I owe you a great deal of thanks, thecoalman. So thanks, and thanks again. This topic is finished.

[Mike-on-Tour]

You need to transfer files with FileZilla using the binary mode otherwise you can get random errors such as the one you experienced.

[invenio]

When using Filezilla in SFTP mode it defaults to binary mode regardless of the settings. With FTP mode you are correct that it should be set to binary mode.

Just commenting as it's unlikely that the root of OP's problem was a Filezilla transfer mode setting as he was using SFTP.

[thecoalman]

You need to transfer files with FileZilla using the binary mode otherwise you can get random errors such as the one you experienced.

It's not some random error, it's specific to the attachments in the file folder because they have no extensions. Every FTP client on the planet defaults to binary when there is no extension except Filezilla. This corrupts a binary file when transferred in ASCII mode, you can safely transfer ASCII files with binary mode.

As side note when using SFTP as the OP indicates there is no option but binary mode.

[LukeWCS]

Every FTP client on the planet defaults to binary when there is no extension except Filezilla.

That was very nicely worded. My thoughts back then, when I became aware of this switch during a support case on phpBB.de, were definitely not politically correct.

If the file format is unknown, leave the file unchanged and transfer it 1:1. Anything else is [self-censorship].

There are other default settings that can cause transfer problems for some users, as we have discovered during several support cases. We have a dedicated article for this. Here is the relevant part translated:

The following are the necessary settings changes:

• Edit > Settings > Transfers > Limit for concurrent downloads: 1
• Edit > Settings > Transfers > Limit for concurrent uploads: 1
• Edit > Settings > Transfers > FTP: FIle types > Default transfer type: Binary

edit: What I forgot to mention: the first two default settings mentioned "can" cause two different problems with a value 0 or >1, which we have observed in several support cases:

• Some files can be transferred empty (0 bytes).
• Some files aren't transferred at all.

[invenio]

The concurrent upload and download of setting to "1" must not be a consistent issue (or server dependent) as I have always done multiple connections with simultaneous downloads/uploads with my hosts and never had an issue.

[LukeWCS]

The concurrent upload and download of setting to "1" must not be a consistent issue (or server dependent)

Yes, that's why I wrote "for some users". Therefore, we generally recommend changing these settings to eliminate or reduce these potential problems.

I have listed the problems that can be caused by the first two settings in my previous post via an edit.