Resolving deprecation warnings

Sometimes you see a lot of the following warnings in your Flarum installation:

NOTICE: PHP message: PHP Deprecated:

This is happening because your webserver is not configured properly for production use.

There are two solutions:

Server side

Your server should be configured for production use, this is not the case. PHP can be configured in the php.ini to ignore deprecation (and other) warnings by setting the value like so:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

This is the recommendation for production environments. You will probably have to edit the php.ini for the webserver (apache/nginx) and for cli as well to fully make the deprecation warnings go away.

Flarum side

Edit your extend.php and add the following before the return [:

error_reporting(E_ALL & ~E_DEPRECATED & ~E_STRICT);

In both cases it is possible that the changes aren't impacting your website immediately. Sometimes you will need to restart your webserver. How to do that depends on the webserver used (apache versus nginx).

what would be the issue if i decided to use both of these (editing my php.ini and extend.php)? or would it have no effect

    wylzn using the second method might fail if the server disallows setting the ini value from php. Though that shouldn't happen on most hosting environments.
    Using both merely enforces the value from two angles.

        luceos i run my own server so i can fix about any issue; if it works ill have both cause why not 🤷

          3 months later

          So, I get this is how to turn off the pesky warnings - and I absolutely agree that in production one should not be showing errors to users - it leaks a lot of info used to bad actors...

          However, the fundamental worry I have is that the errors when installing with PHP 8.3 for deprecation in the code mean that Flarum code is using outdated / deprecated functions and such... and that an update to PHP in the future where such deprecated features get obsoleted it is going to break.

          So isn't the best path forward for Flarum to be updated to get rid of the deprecated calls / replace them with the newer function calls that replace them?

            DigitalSorceress So isn't the best path forward for Flarum to be updated to get rid of the deprecated calls / replace them with the newer function calls that replace them?

            Flarum 2.0 is based on a newer Laravel version, that will resolve these warnings entirely. Regardless of that, deprecation warnings are still not meant to be shown in production, even if you want to push this responsibility to us; in the end it's your responsibility to use a hosting environment that is safe, secure and well managed.

              DigitalSorceress However, the fundamental worry I have is that the errors when installing with PHP 8.3 for deprecation in the code mean that Flarum code is using outdated / deprecated functions and such... and that an update to PHP in the future where such deprecated features get obsoleted it is going to break.

              That's a fair worry to have. But let me explain how we deal with deprecation warnings and why you see them in the latest 1.x versions.

              1.x supports PHP versions from 7.3 to 8.4, which is a wide range. For those using PHP 7.3 and 7.4 (and possibly 8.0) they do not see these deprecation warnings which were only introduced in PHP versions 8.1+.

              These deprecation warnings that remain, remain because code changes to address them would break the code with older PHP versions (7.3 for example). And we do not wish to make a breaking change in the 1.x line, of requiring higher PHP versions as a minimum, especially not for this reason.

              Flarum 2.0 which is still in beta, addresses these deprecation warnings by updating the code. Because in 2.0 we can safely update the minimum PHP requirement to 8.2 as it is a major upgrade.

              This is why we ask users to ignore these warnings. They are but warnings, addressed to developers, and we know how to handle them accordingly.