Should WordPress.PHP.DevelopmentFunctions.error_log_print_r be relaxed a little?

[thomas-price]

Currently, WordPress.PHP.DevelopmentFunctions.error_log_print_r states: print_r() found. Debug code should not normally be used in production.

Should this be modified to allow print_r(), providing the return is true? Example: print_r( $value, true)

Reference: https://github.com/spaze/phpstan-disallowed-calls/blob/main/disallowed-dangerous-calls.neon

[jrfnl]

@thomas-price Could you explain why you think the rule should be relaxed in that case ?

I mean, debug printing is still debug printing, whether printed to screen or returned (and then possibly written to a file or stored in a database), so I think you need to argue your case a little better.

Also: the referenced link adds nothing to this discussion.

[thomas-price]

The following is our use case. I am sure others will have additional use cases.

• print_r( $value ) or print_r( $value, false ) will print the output. This is only appropriate for debug, hence should not be in Production code.
• But in production, there are sometimes 3rd-party API/library return errors that have wide and varied formats All that is needed from these is the error in plain text for reporting. print_r( $value, true ) is a practical way of achieving this, hence should be allowed in Production code.

WordPress.PHP.DevelopmentFunctions.error_log_print_r currently creates a warning based on print_r(). This proposal suggests a warning should be created if print_r( .* ) or print_r( .*,false ), but not print_r( .*,true ).

[jrfnl]

@thomas-price I must still be missing something, but your use case sounds 100% like debugging, which should not be in production code.

If you need to handle errors from 3rd part API/libraries, you need to use error handling, not debug functions.