Do PHP DEPRECATED messages bother you?

[horst]

If you want, you can filter them out and focus more on your essentials.

But first things first.
There is a whole list of different PHP errors, warnings and hints (notices).

Spoiler

;
; Error Level Constants:
; E_ALL             - All errors and warnings (includes E_STRICT as of PHP 5.4.0)
; E_ERROR           - fatal run-time errors
; E_RECOVERABLE_ERROR  - almost fatal run-time errors
; E_WARNING         - run-time warnings (non-fatal errors)
; E_PARSE           - compile-time parse errors
; E_NOTICE          - run-time notices (these are warnings which often result
;                     from a bug in your code, but it's possible that it was
;                     intentional (e.g., using an uninitialized variable and
;                     relying on the fact it is automatically initialized to an
;                     empty string)
; E_STRICT          - run-time notices, enable to have PHP suggest changes
;                     to your code which will ensure the best interoperability
;                     and forward compatibility of your code
; E_CORE_ERROR      - fatal errors that occur during PHP's initial startup
; E_CORE_WARNING    - warnings (non-fatal errors) that occur during PHP's
;                     initial startup
; E_COMPILE_ERROR   - fatal compile-time errors
; E_COMPILE_WARNING - compile-time warnings (non-fatal errors)
; E_USER_ERROR      - user-generated error message
; E_USER_WARNING    - user-generated warning message
; E_USER_NOTICE     - user-generated notice message
; E_DEPRECATED      - warn about code that will not work in future versions
;                     of PHP
; E_USER_DEPRECATED - user-generated deprecation warnings
;

 

The one we are interested in is E_DEPRECATED. These messages indicate that a used PHP function somewhere in the code is no longer supported in a future, i.e. higher PHP version, not the actual used one.

Example: The days (February 2022) I have changed my developer machine to use the latest PHP version 8.1.2.

• The last PHP 7.4+ is still supported for 9 months from today on,
• PHP 8.0 still for 1 year + 9months,
• PHP 8.1 for 2 years+ 9 months,
• and all other PHP 8+ versions each plus one more year.

So the point is clear now, right? It will be year(s) before PHP 9 is on the schedule. ? 

Currently in v8.1.2, depending on what code I run, I get notices that certain PHP functions will no longer be available starting with PHP 9. (PHP 9! see above). So currently these functions are safe and supported functions, as in past versions as well as in all further PHP 8+ versions(!). No matter how many additional PHP 8+ versions there will be.

ProcessWire by default allows us to suppress ALL output, or show ALL output, by the boolean configuration variable "$config->debug". This is good and right, because on a production site you should always suppress all those outputs.

On a developer machine it usually shouldn't bother you if there are also E_DEPRECATED hints included. But if it does, you can filter them out as follows, for example.

In your site/config.php you can define a own error handler function and load / bind it on your developer machine only.
As a proof of concept or simple example, I added the following function to my site/config.php

/** OWN ERROR HANDLER FOR DEPRECATION NOTES **********************************************/

    function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) {
        if(!isset($GLOBALS['DEPRECATION_WARNINGS_BAG'])) {
            $GLOBALS['DEPRECATION_WARNINGS_BAG'] = [];
        }
        if(!is_array($GLOBALS['DEPRECATION_WARNINGS_BAG'])) {
            $GLOBALS['DEPRECATION_WARNINGS_BAG'] = [];
        }
        $GLOBALS['DEPRECATION_WARNINGS_BAG'][] = [$errfile, $errline, $errstr];
        return true; // true | false  = suppress further processing
    }

/** OWN ERROR HANDLER FOR DEPRECATION NOTES **********************************************/

With the following call, also located in my developer machines site/config.php file, I bind it to all raising E_DEPRECATED warnings ONLY! So we are sure and free from all other types of errors, warnings, hints, etc.

    // preceed the callback function name with the PW namespace, 
    // and define the error types that should passed to the function
    set_error_handler('ProcessWire\myLocalDevDeprecationErrorHandler', E_DEPRECATED);

(read more on php.net)

Now you will not see any of the deprecated notices any more, cluttering your screen. Neither in the front end nor in the backend. But they are all collected in our bag. ?

A simple loop in the site/templates/admin.php, before the controller.php is called, can display any of it, maybe to the superusers only, for example:

<?php namespace ProcessWire;

    // IF WE HAVE CACHED PHP DEPRECATION WARNINGS, SHOW THEM IN THE ADMIN, FOR SUPERUSERS ONLY
    if(isset($GLOBALS['DEPRECATION_WARNINGS_BAG']) && is_array($GLOBALS['DEPRECATION_WARNINGS_BAG'])
        && 0 < count($GLOBALS['DEPRECATION_WARNINGS_BAG'])
        && $user->isSuperuser()) {
        foreach($GLOBALS['DEPRECATION_WARNINGS_BAG'] as $deprecatedMessageItem) {
            $deprecatedMessageItemMSG = "PHP DEPRECATED (v". PHP_VERSION .") = \n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;";
            $deprecatedMessageItemMSG .= "{$deprecatedMessageItem[0]} : [{$deprecatedMessageItem[1]}]\n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;";
            $deprecatedMessageItemMSG .= "{$deprecatedMessageItem[2]}";
            $this->message($deprecatedMessageItemMSG);
        }
    }

    require($config->paths->adminTemplates . 'controller.php');

 

If you want to show them on the front end to, it belongs to how you have organized your output strategy. I use a delayed output with _init.php and _main.php, where I have a special function for adding all kind of debug messages, that gets displayed on the end of the site, after the footer. Simply adding the whole collected array is enough for my information:

    if(isset($GLOBALS['DEPRECATION_WARNINGS_BAG']) && is_array($GLOBALS['DEPRECATION_WARNINGS_BAG']) && 0 < count($GLOBALS['DEPRECATION_WARNINGS_BAG'])) {
        mvdr(['DEPRECATED ('. PHP_VERSION .')' => $GLOBALS['DEPRECATION_WARNINGS_BAG']]);  // add it to the debug output region var
    }

 

The outputs in admin then may look like this

 

Or the very basic info for me on front end

 

[szabesz]

Thanks Horst! The thing is, Tracy Debugger does deal with all "errors" for us, so it might be a better idea to ask @adrian to take special care of deprecated (and maybe warning) messages so that they do not show up in Tracy's debug bar as "errors", highlighted with red labels.

Maybe Tracy could maintain two "bags", I mean sets of php error messages for us, one for low level of importance and one for high level of importance, and each set could show up in the debug bar under its own "label". High level of importance errors should be red as currently, while the low level of importance "errors" could be under a green label. On the Tracy settings page we could configure what goes where, and a sensible default would be set for us, of course.

So whenever I see some "green error" messages in Tracy and its log, I know that currently there is nothing urgent to check out, but if I want to, all the messages are there for me to examine.

[horst]

That sounds good. And I think it should not be much work (hopefully) for @adrian to incorporate that. It needs just a separation of different PHP error and warning types through dedicated error_handler function(s). I think everything that belongs to the group of "best practices and deprecations" could go into the green bag, where as all other stays in the red one. ?

 

[szabesz]

7 minutes ago, horst said:

I think it should not be much work (hopefully) for @adrian to incorporate that.

Well, since there is no "just a five minute task" – even though our clients often firmly believe in such a thing –, I have not yet wanted to turn this idea into a feature request but I would be happy to hear Adrien's reply.

The last time I checked what PHP error level constants exist there were fewer than currently, so as the language evolves, these constants evolve too. Which means there are differences between PHP versions in this regards as well, so dealing with error level constant differences might mean some extra effort on Adrian's part, I guess.

[horst]

8 minutes ago, szabesz said:

– even though our clients often firmly believe in such a thing –

Outch! ?

EDIT: but, but, - uhm, - but I enclosed a "(hopefully)" already, ...

Edited February 18, 2022 by horst

[szabesz]

@horst I did not mean your "request" belongs to that category but I was probaly not that clear about that, sorry....

Edited February 18, 2022 by szabesz
typo

[adrian]

I'm honestly not sure how I feel about this, but that's another story :)

The feature that you're asking for probably belongs in the Tracy core, so it might be best to request it over here: https://github.com/nette/tracy/issues

That said, I have hacked together something (fairly quickly, but definitely not 5 minutes). Try the attached - currently only works for direct loading of frontend pages - ie it doesn't work in the admin or via AJAX. The errors panel gets recolored if the only errors in it are deprecations.

Sorry, I don't have anymore time to spend on this at the moment, especially given that I think it belongs in the Tracy core.

TracyDebugger.module.php

[szabesz]

Thanks Adrian, I was really just brainstorming here but will surely test what you've done.

Do you have any idea whether the Nette devs like filing feature request as "issues" or not?

[adrian]

1 minute ago, szabesz said:

Do you have any idea whether the Nette devs like filing feature request as "issues" or not?

[szabesz]

I see :) looks like I do not dare touching certain buttons :)

[Ivan Gretsky]

1 hour ago, szabesz said:

I see ? looks like I do not dare touching certain buttons ?

If you end up making this feature request I'll surely give it a thumbs up. I am so used to this "errors" count in the Tracy bar I do not even look at them anymore.

 

On 2/17/2022 at 10:39 PM, horst said:

 

 

How are you doing, @horst! I reeeealy like that color indication and LOCAL label. Could you share how you achieve that? I would use it on every site of mine.

[szabesz]

15 minutes ago, Ivan Gretsky said:

If you end up making this feature request I'll surely give it a thumbs up. I am so used to this "errors" count in the Tracy bar I do not even look at them anymore.

I will first check what Adrian shared, next, I will gather my thoughts and share them with you guys so that I can present something convincing...

[szabesz]

10 minutes ago, szabesz said:

I will first check what Adrian shared, next, I will gather my thoughts and share them with you guys so that I can present something convincing...

Ok, I've tested it, deprecated is colored green, looks great.

I just do not know what to ask the Nette devs for. My limited knowledge of Tracy Debugger is restricted to Adrian's module, which is configurable extensively while core Tarcy does not seem to be configurable at all: https://tracy.nette.org/en/guide However, the idea is that Adrian's module should provide settings for separating "low level of importance" and "high level of importance" (what should these be called, btw?).

So what should be the feature request to the Nette devs in the first place?

[horst]

1 hour ago, Ivan Gretsky said:

that color indication and LOCAL label. Could you share how you achieve that?

https://github.com/BitPoet/AdminDevModeColors

The best is the configuration through the site/config.php !! ? 

[horst]

1 hour ago, Ivan Gretsky said:

I would use it on every site of mine.

I do so! ?

[adrian]

1 hour ago, szabesz said:

So what should be the feature request to the Nette devs in the first place?

Well, they already have this option:

Debugger::$strictMode = true; // display all errors
Debugger::$strictMode = E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED; // all errors except deprecated notices

but that only controls what happens in strict mode. I don't know if you want to have something similar for non-strict mode and ignore deprecations completely, or if you do really want to have the error panel tab change color, or separate panels. I think I would suggest the color change because I think it's pretty important to continue to get regular warnings about deprecations, because before you know, you've upgraded PHP and now that function is no longer available and you have real errors, but having an extra panel is just unneeded space.

 

[wbmnfktr]

Kind of heckling here, yet...

I didn't even know anything about this in that depth... therefore... just a THANK YOU for this insight.