Deprecated function: hash(): Passing null to parameter

Like that or do we want something less gracious?

The last submitted patch, 2: monitoring-depricated_hash_null-3355384-2.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

The last submitted patch, 4: monitoring-depricated_hash_null-3355384-4.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

@Primsi - Your patch did infact get rid of my errors, however when I looked over the code. And I think this line does a comparison checking the users password against an empty string. And I think with your orginal patch that will always evaluate as true, where as a NULL !== ''.
https://git.drupalcode.org/issue/monitoring-3355384/-/blob/c0cf78aef5023...

So I specifically am keeping NULL as the password on the GitLab Branch see
https://git.drupalcode.org/issue/monitoring-3355384/-/commit/c0cf78aef50...

Was not able to get unit test running locally, so just offering this branch as an alternative. I can run it a while on my site to test it.

I have fixed this Deprecated function: hash(): Passing null to parameter in attached above patch5.

@NicholasS I think it should work fine, It's using the Null coalescing operator, so it should be equal to

isset($user->getPassword()) ? $user->getPassword() : '';

Or am I missing something?

@Primsi so after more detailed testing your Patch #4 is actually correct, I was thinking it was needed to preserve the users original NULL password, but coaxing it into an empty string, which then is hashed actually is what is needed for the monitoring module to NOT trigger the "Password Changed" event.

So actually, seems like $expected_users data comes from the key_value table (learning this module still). So actually my MR approach would compare just fine if you "reset" the user monitoring data. It then compares the current NULL against the previous users NULL.

Pros of not mutating/coalescing a users NULL password into an empty string is the "Expected Values" for users are more accurate, in the sense of if you wanted to make a sensor to monitor NULL and a separate for passwords '' you could. By coalescing you can't differentiate them.

On the other hand seems what this module was doing already was coalescing nulls into empty stings, and hashing those strings so I guess Patch #4 keeps things the same without user needing to repopulate the expected users key_values.

Tested that on another of our websites and it got rid of the deprecation notice.

The last submitted patch, 9: Deprecated-function-hash-Passing-null-3355384-patch5.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Berdir → closed merge request !6

Merged #4.

Automatically closed - issue fixed for 2 weeks with no activity.