[postponed] feat: rename UserAuthenticationController to RestAuthenticationController (11.4 breaking)#356
Conversation
…ller (11.4 breaking) Drupal\user\Controller\UserAuthenticationController is deprecated in drupal:11.4.0 and removed in drupal:12.0.0; use Drupal\rest\Controller\RestAuthenticationController instead. The replacement controller was added to the rest module in the same commit as the deprecation (drupal-core c0e71efe93, 11.x only) and does not exist on any older minor, so the structural use/extends/::class rewrite would fatal on Drupal < 11.4 and cannot be BC-wrapped. The rest module must also be enabled at runtime. It therefore goes in the opt-in DRUPAL_114_BREAKING set as a RenameClassRector entry, alongside the existing menu_link_content migrate-process renames. Route name strings (user.login.http -> rest.login, etc.) are not rewritten and must be updated manually; this is documented in the config comment and CHANGELOG. Verified against real contrib via rector-live-test: login_emailusername (9,019 installs) and email_tfa both have their controller subclasses correctly reparented onto RestAuthenticationController.
🔴 Blocker: targets a reverted core changeThe mechanics here are solid — correct placement in the But it doesn't. Verified against
So the rename points at a class that isn't in core, on the basis of a deprecation that no longer exists. On the verification sectionThe live-test results ("subclass reparented onto RecommendationHold until #3530640 actually re-lands (non-reverted) in core. When re-checking:
The diff itself needs no changes — when the core change returns, this can merge essentially as-is. The issue is purely timing. |
mglaman
left a comment
mglaman
left a comment
There was a problem hiding this comment.
Breaking-set placement is correct. RestAuthenticationController is added to the rest module at 11.4.0 and exists on no earlier minor, so the structural rename would fatal below it (and only when rest is enabled) — DRUPAL_114_BREAKING is right.
The route-string caveat is the one worth naming: user.login.http → rest.login and friends are strings, not class references, so the rule correctly leaves them untouched and the PR documents them as a manual follow-up. The live-test against login_emailusername and email_tfa confirming the reparent, plus the docblock-only rest_password reference correctly producing no change, is good diligence.
Approving.
bbrala
changed the title
2 participants
🔴 Blocker: targets a reverted core change
What
Adds a
RenameClassRectorentry to the opt-inDRUPAL_114_BREAKINGset(
config/drupal-11/drupal-11.4-breaking.php):Source: #3530640 · CR #3552724
Why breaking (not the default deprecation set)
UserAuthenticationControlleris deprecated in drupal:11.4.0 and removed indrupal:12.0.0. Its replacement,
RestAuthenticationController, was added tothe
restmodule in the same commit as the deprecation (drupal-corec0e71efe93, 11.x only) and does not exist on any older minor. Rewriting thestructural
use/extends/::classreferences to it would produce a"class not found" fatal on Drupal < 11.4, and a class rename is not an
Expr→Expr transformation so it cannot be BC-wrapped. The
restmodule mustalso be enabled at runtime for the new controller's routes to exist.
This mirrors the other entries already in this opt-in set (the
menu_link_contentmigrate-process renames, HelpSearch, NodeViewController).Caveat (documented in the config comment + CHANGELOG)
Only PHP class references are rewritten. Route name strings
(
user.login.http→rest.login,user.logout.http→rest.logout,user.login_status.http→rest.login_status,user.pass.http→rest.pass)passed to
Url::fromRoute()etc. are not touched and must be updatedmanually.
Verification
php -lclean; targeted dry-run confirms the rename fires.rector-live-test against real D11 contrib subclasses:
login_emailusername(3.0.x)RestAuthenticationControlleremail_tfa(3.0.x)rest_passwordcorrectly produced no change (references the class only in adocblock comment).