Config::resetOverriddenData() should reset overriddenData value not remove the class property

Created on 8 December 2016, over 8 years ago
Updated 25 February 2023, about 2 years ago

Problem/Motivation

Currently Config::resetOverriddenData() completely removes the overriddenData class's property instead of reset the property value.

  /**
   * Resets the current data, so overrides are re-applied.
   *
   * This method should be called after the original data or the overridden data
   * has been changed.
   *
   * @return \Drupal\Core\Config\Config
   *   The configuration object.
   */
  protected function resetOverriddenData() {
    unset($this->overriddenData);
    return $this;
  }

the instruction unset($this->overriddenData); remove the class's property when the correct behaviour should be set overriddenData to NULL.

This is not a big deal in se but
1) it is not consistent (and IMHO this can be marked as a bug).
2) it can cause warning with code that use reflection (but this of course is not a strong point). Libs like Kint or Doctrine Debug are affected by this issue.

Proposed resolution

Make Config::resetOverriddenData() behaves consistently and reset only the VALUE of the property, not remove the class's property itself

Remaining tasks

Issue Summary update
Answer questions in #8 and #16

User interface changes

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Postponed: needs info

Version

10.1

Component
Configuration 

Last updated about 16 hours ago

Created by

🇮🇹Italy willzyx

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇳🇿New Zealand quietone

    Adding tag for IS update.

  • 🇦🇺Australia acbramley

    Based on the lack of feedback since #16 and given this is not unique to this class I can't see how this should be classified as a bug.

    Swapping to a task, IMO we could/close this if no one can answer #16 within a couple of months?

  • Status changed to Closed: works as designed about 16 hours ago
  • 🇳🇿New Zealand quietone

    It has been 3 years since a committer asked for more information and none has been supplied. @acbramley suggested waiting a few more months, and that was about 1 year ago and still no comment. Therefore, I am closing this.

    If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

Production build 0.71.5 2024