Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@dereuromark
Copy link
Member

@dereuromark dereuromark commented Sep 1, 2025

Do we want to fix up #17921 during 5.* ?
If so, would this be a correct approach to it? I dont think so, but I am not sure how to tackle this.

So for, this PR seems to

  • Fixes data corruption issues with encryption/decryption
  • Allows proper separation of display vs persistence logic
  • Maintains full backward compatibility

@dereuromark dereuromark added this to the 5.3.0 milestone Sep 1, 2025
@ADmad
Copy link
Member

ADmad commented Sep 1, 2025

I am not in favor of this unnecessary complication when using virtual getters/accessors avoids this problem.

@dereuromark
Copy link
Member Author

Do we have an alternative approach/fix?

@LordSimal
Copy link
Contributor

I am also in the boat of "this feels wrong" but I haven't had the time to think about this for more than a few minutes.

Comment on lines +1859 to +1861
if ($forPersistence) {
return $value;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be a simpler design (or simpler application code) if this branch was a separate method? The opt-in flow becomes simpler as you have to create a method. It is also simpler to read as there are two separate methods which should reduce branching in application code.

protected function _getPasswordForPersistence(?string $value)
{
    return $value;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants