This is a great module, and it's features like the ones it provides, which makes Drupal so great. So thanks for maintaining it.

Problem/Motivation

If I open and save a multiple registration page at /admin/config/people/multiple_registration and then export configuration, the resulting configuration file contains the same content, but "nested" one level under "member" ... Every time I save, a new level is added:

$ drush config:import --diff
[...]
@@ -1,18 +1,4 @@
 member:
-  member:
-    member:
-      path: /user/become-member
-      url: /user/register/member
-      redirect_path: ''
-      hidden: 1
-      form_mode_register: register
-      form_mode_edit: default
-    path: /user/become-member
-    url: /user/register/member
-    redirect_path: ''
-    hidden: 0
-    form_mode_register: register
-    form_mode_edit: default
   path: /user/become-member
   url: /user/register/member
   redirect_path: ''

Steps to reproduce

  1. Save the form, making no changes
  2. Export configuration, for example with drush config:export --diff
  3. See that the configuration file has changed, when it should not, since there were no changes
  4. See that the resulting configuration file contains "nested configuration"

Proposed resolution

Remaining tasks

Fix the configuration set up, so that is not nested, nor updated, when there has been no changes.

User interface changes

API changes

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

ressa created an issue. See original summary.

ressa’s picture

Issue summary: View changes
teknocat’s picture

I noticed this happening as well, but it's not just if you don't make any changes. Even if you do make changes, it saves a nested configuration set, leaving the parent with the previous values, for example:

community_member:
  community_member:
    path: /user/register-community-member
    url: /user/register/community_member
    redirect_path: /<front>
    hidden: 0
    form_mode_register: register
    form_mode_edit: default
  path: /user/register-community-member
  url: /user/register/community_member
  redirect_path: /user/login
  hidden: 0
  form_mode_register: register
  form_mode_edit: default
teknocat’s picture

The issue is in the submitForm function in the way that it tries to set the given configuration key with the new data merged with ALL the original config data. That array merge is appending the new config that's only for the one $rid to the end of ALL the configuration. Then, it sets that new array in the configuration with that $rid as the configuration key. As a result, every save keeps a nested copy of the original config along with the new config keys. That then throws things off when you try to import the config and use it.

If you want to merge the new config with the original, then instead of $config->getOriginal() you should use $config->get($rid). However, I don't see any need for merging anyway, since you're setting a new array containing ALL the config values that were submitted. Merging the array is only helpful when you want to combine some new data into an existing array, where existing keys that match will be updated while new keys will be added.

Lines 190 to 200 can be changed to the following and it works as expected:

$data = [
  'path'               => $alias,
  'url'                => $source,
  'redirect_path'      => $redirectPath,
  'hidden'             => $isHidden,
  'form_mode_register' => $formModeRegister,
  'form_mode_edit'     => $formModeEdit,
];
$config->set($rid, $data)
  ->save();

orkutmuratyilmaz’s picture

Status: Active » Reviewed & tested by the community

The changeset looks mergeable.

orkutmuratyilmaz’s picture

any chance for the merge?

ysamoylenko made their first commit to this issue’s fork.

ysamoylenko’s picture

Status: Reviewed & tested by the community » Fixed

The changes have been merged.

Thank you for your contribution to module development and code review!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.