[make:user] Legacy <= 5.3 & Doctrine Cleanup#1107
Conversation
jrushlow
force-pushed
the
fix/doctrine-legacy
branch
2 times, most recently
from
3d38390 to
ddc814e
Compare
| "composer/semver": "^3.0", | ||
| "doctrine/doctrine-bundle": "^2.4", | ||
| "doctrine/orm": "^2.3", | ||
| "doctrine/orm": "^2.10.0", |
There was a problem hiding this comment.
potentially controversial.. need to double check dependency dependencies to ensure this is possible... Reasoning being the bump to 10 / conflict w/ <2.9 is primarily related to the new exception classes introduced in 2.10 that will become interfaces in 3.0..
There was a problem hiding this comment.
My initial thought is: it's ok. ORM 2.10 was released Oct 3rd, 2021. Maker now requires Symfony 5.4, which was released at the end of November 2021. So, if you have 5.4, you've been upgrading already. And bumping to 2.10 is a minor release bump.
jrushlow
force-pushed
the
fix/doctrine-legacy
branch
from
230942e to
c095088
Compare
jrushlow
changed the title
jrushlow
added
Status: Needs Review
| $newData = $this->manipulator->getData(); | ||
| if ('password_hashers' === $keyName && isset($newData['security']['encoders'])) { | ||
| // fallback to "encoders" if the user already defined encoder config | ||
| $this->updatePasswordHashers($userConfig, $userClass, 'encoders'); | ||
|
|
There was a problem hiding this comment.
Re for situations where a user still has security.encoders set - we could do any of:
A) Throw an exception e.g. "MakerBundle does not support password encoders.."
B) Remove the existing security.encoders and continue with setting security.password_hashers
The problem with the latter is we dont have a way to tell the user that we're removing the existing encoders.. I suppose we could start linking make:user's IO to SecurityConfigUpdater or something to make this "async" but that just feels like a headache w/ not alot of gain.
If we just throw an exception, what action do we tell the user to take to correct the problem?
There was a problem hiding this comment.
If encoders is set, let's throw a clear exception that explains to change to password_hashers.
There was a problem hiding this comment.
sounds like a plan
jrushlow
force-pushed
the
fix/doctrine-legacy
branch
from
57fb893 to
bce7788
Compare
weaverryan
left a comment
weaverryan
left a comment
There was a problem hiding this comment.
Very complex, nice work! Minor comments
src/DependencyInjection/CompilerPass/SetDoctrineManagerRegistryClassPass.php
Outdated
Show resolved
Hide resolved
| $newData = $this->manipulator->getData(); | ||
| if ('password_hashers' === $keyName && isset($newData['security']['encoders'])) { | ||
| // fallback to "encoders" if the user already defined encoder config | ||
| $this->updatePasswordHashers($userConfig, $userClass, 'encoders'); | ||
|
|
There was a problem hiding this comment.
If encoders is set, let's throw a clear exception that explains to change to password_hashers.
jrushlow
force-pushed
the
fix/doctrine-legacy
branch
from
bce7788 to
616806d
Compare
jrushlow
added
Status: Needs Work
weaverryan
force-pushed
the
fix/doctrine-legacy
branch
from
004a131 to
e0c5f2b
Compare
|
HUGE work - thanks Jesse! |
2 participants
TemplateComponentGenerator::generateUseStatements()can now handle use statements with aliases.Add
doctrine/ormconflict w/<2.10drop legacy Symfony <
5.4Doctrine && User conditionalsremove legacy
UserBuildertestsfixes make:user & password_hashers: skip password_hashers update if possible #990
Depends on [make:auth] drop guard support and legacy code cleanup #1104