BoldMinded

All add-ons currently require PHP 7.4 or greater.

On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.

Please read about the changes to BoldMinded add-on licensing.

Ticket: Error message “FilesystemDriver.php:38”

Status Resolved
Add-on / Version Speedy 1.9.0
Severity
EE Version EE7.4.11

Harold Kuiper

Jul 15, 2024

We had the following error: file_exitst(): Argument #1 ($filename) must not contain any null bytes FilesystemDriver.php:38 Our question: has this been resolved or is this new to you? Best regards, Harold

#1

BoldMinded (Brian)

Hi, Harold. If you’re using 1.9 this could likely be fixed in 1.9.2, you should upgrade and see if the error still exists, and if so please share the full stack trace so I can see what is calling that function. Thanks.

#2

Harold Kuiper

Thanks Brian, We can can close this ticket. Best regards, Harold

#3

Harold Kuiper

Hi Brian, We got the same message again (from our client): file_exitst(): Argument #1 ($filename) must not contain any null bytes FilesystemDriver.php:38 The hard thing in general here is that we can’t open Speedy if this occurs and we can only clear the cache through SSH. And we can’t ask the client for the ‘full stack trace’. Anything what we can do to help you further? Best regards, Harold

#4

BoldMinded (Brian)

Comment has been marked private.

#5

BoldMinded (Brian)

The issue with not having the stack trace is I don’t know what is causing the problem or why. Instead all I can do is blindly prevent the error message, but the real issue might be somewhere else and could be more problematic. If you’re able to turn up EE’s debugging you should be able to see the error the same way the client is. Having the stack trace would be very helpful.

#6

Harold Kuiper

Hi Brian,

Thanks for the quick turnaround and provided build! We’ve installed it right away, and hopefully this will give us some time to get to the bottom of this error and ensure the client doesn’t see it anymore.

We understand that not having the stack trace makes this hard to debug. Unfortunately, this error occurs in the production environment and not in staging/development. Is there a way to get the stack trace in one of the log files produced? We could turn on the debugger in production as well, but this would also mean we have to wait for the client to encounter the error again, right? Then we would go to that specific entry/error (in production) to get the stack trace, correct? This is not something we want to do currently, as the client is becoming rather frustrated by this error. This platform is continuously being used, and an error in the publishing mechanism means no work can be done by a large group of people. We would love to fix this issue in silence, if possible.

Thanks for your help!

Best regards, Wiebe.

Login to reply