Provide a way to deprecate form API array value keys

Created on 15 April 2025, 3 months ago

Problem/Motivation

From πŸ“Œ ConfirmFormInterface::getFormName() serves no purpose in ConfirmFormBase Active :

I discussed with @longwave - the thing that's tricky here is that we are only removing this because it is dead code but the value is still being used by contrib and these modules will break silently because the deprecation we're adding here is only for the method. The current implementation will break modules using $form_state->getValue('confirm') immediately. Obviously form arrays are not part of the BC promise - see https://www.drupal.org/about/core/policies/core-change-policies/frontend... β†’ - but I think we can/should do better. I think we should consider adding a #deprecated key to the form arrays so we can issue a deprecation when calling $form_state->getValue() for a specific key. I think doing this would allow us to remove old stuff like this and get modules to update without breaking stuff.

Steps to reproduce

Proposed resolution

One thing to consider is that $form_state->getValue() can be passed nested keys as arguments, so the implementation of #deprecated might need to account for that.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component

forms system

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @godotislate
  • πŸ‡¬πŸ‡§United Kingdom joachim

    Does something for this need to be added to the core BC policy too?

  • πŸ‡¬πŸ‡§United Kingdom catch

    Once it exists we should add to the 'how to deprecate' page. For me this is a nicety that doesn't change the BC policy for forms though - there are plenty of form changes that would not be able to use this and we don't want to preclude ourselves from doing them. I also don't think we'd bother using this on obscure admin forms either.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    I agree with catch. Adding tag and item to the remaining tasks about updating the 'how to'.

  • Another thing to consider whether it's worth covering for the deprecation: Some form submit methods use $form_state->getValues(), then reference a specific key on the array, e.g. $form_state->getValues()['confirm']; or $values = $form_state->getValues(); $confirm = $values['confirm'];.

  • Merge request !11945Resolve #3519300 "Provide a way" β†’ (Open) created by godotislate
  • Pipeline finished with Failed
    2 months ago
    #482225
  • Pipeline finished with Success
    2 months ago
    Total: 1222s
    #482259
  • MR is ready.

    Can't trigger deprecations for usages ofgetValues() after all, so focusing strictly on getValue().

    CR: https://www.drupal.org/node/3521264 β†’

  • Pipeline finished with Success
    6 days ago
    #532612
  • Status changed to Needs review 6 days ago
  • Updated deprecation version to 11.3 and refactored the test a little.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    This looks great - just had one question about some extra coverage for subform state which this code will run for, but we don't have any tests for in the MR yet

  • Pipeline finished with Success
    5 days ago
    Total: 647s
    #533357
  • Pipeline finished with Success
    5 days ago
    #533363
  • Rebased for the merge conflict.
    Subform state should be accounted for now, and some logic issues fixed, with additional test coverage.

Production build 0.71.5 2024