The config schema doesn't match up with the current config structure

Created on 6 November 2023, about 1 year ago

Problem/Motivation

The config schema doesn't match up with the current config generated by the module.

One thing, I'm not sure about is the usage of the augmenter_settings property.

It introduces something along the lines of this:

+        augmenter_settings:
+          fields__field_date__settings_edit_form__third_party_settings__date_augmenter__augmenter_settings__active_tab: ''

Steps to reproduce

Test the generated third party configs with the config inspector module.

Proposed resolution

Update config schema.

Remaining tasks

Provide issue fork/patch

πŸ“Œ Task
Status

Active

Version

1.1

Component

Code

Created by

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

Merge Requests

Comments & Activities

  • Issue created by @codebymikey
  • @codebymikey opened merge request.
  • Status changed to Needs review about 1 year ago
  • Status changed to Needs work about 1 year ago
  • Just reviewed it, it's because \Drupal\smart_date\SmartDateTrait::initializeAugmenters() is called differently with \Drupal\smart_date_recur\Plugin\Field\FieldFormatter\SmartDateRecurrenceFormatter::initializeAugmenters(['instances', 'rule']) compared to \Drupal\smart_date\Plugin\Field\FieldFormatter\SmartDateDefaultFormatter::initializeAugmenters().

    The latter initializes the augmenters without an instances property, this means the third party settings differs based on formatter used, which isn't the best.

    However they should probably both be normalized to store their default augmenter config into instances, a migration path provided for field formatters as well as potential deprecation logic in ::initializeAugmenters(), which still supports configs without the instances property specified, and working that way - this is necessary for entries such as Layout Builder node overrides which might not have a clean migration path.

  • Assigned to mandclu
  • πŸ‡¨πŸ‡¦Canada mandclu

    I just ran into this, and I agree that this feels like it is upstream in Smart Date. I think there's a relative simple fix possible, but it would be good to get some feedback on how disruptive it might be on existing configuration management workflow

  • Merge request !142Default to a populated array of augmenter keys β†’ (Merged) created by mandclu
  • Status changed to Needs review 3 months ago
  • πŸ‡¨πŸ‡¦Canada mandclu

    Here's an MR that forces all Smart Date formatters to use the 'instances' key for their augmenter settings, which fixes the schema mismatch. Hopefully there are enough fallbacks built in that it shouldn't break any existing configuration, but I would appreciate feedback.

  • Assigned to mark_fullmer
  • πŸ‡ΊπŸ‡ΈUnited States mark_fullmer Tucson

    Assigning myself for review of the MR...

  • Issue was unassigned.
  • Status changed to Needs work 3 months ago
  • πŸ‡ΊπŸ‡ΈUnited States mark_fullmer Tucson

    I tested this (steps listed below), and everything worked well, with the exception of one thing. For the non-recurring date formatter, the legacy configuration was not "found" initially. As a result, an existing configuration will fail to render the date augmenters. The attached diff shows my suggestion for checking for that legacy location. With that change in place, both the recurring and non-recurring field instances successfully displayed date augmenters, both prior to and after the configuration being re-saved.

    Testing steps

    1. With the 4.1.x branch of smart_date and the addtocal_augment module used:
    2. Create two fields on a node, both of type "smartdate," one using "smart_date_recur," one not using "smart_date_recur."
    3. Configure both fields' formatters to display an date augmenter plugin. (I used addtocal_augment).
    4. When a node is created & viewed, both fields display the date augmenter. (So far, so good).
    5. Switch to the merge request.
    6. Rebuild the cache.
    7. When a node is created & viewed, the non-recurring field no longer displays the date augmenter. (The diff, attached, makes this step work as expected).
    8. Re-save the field formatter settings for both fields. As expected, the non-recurring field's structure will change:

    Before:

        third_party_settings:
          date_augmenter:
            status:
              addtocal: '1'
    

    After:

        third_party_settings:
          date_augmenter:
            instances:
              status:
                addtocal: true
    

    9. Viewing the node displays the date augmenter for both fields (works).

  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA
  • πŸ‡¨πŸ‡¦Canada mandclu

    Updating this to target the 4.2.x branch.

  • Pipeline finished with Skipped
    19 days ago
    #338527
    • mandclu β†’ committed eae73e87 on 4.2.x
      Issue #3399475 by mandclu, codebymikey, mark_fullmer: The Augmenter...
  • πŸ‡¨πŸ‡¦Canada mandclu

    Merged in. Thanks for everyone's help on this issue.

  • Status changed to Fixed 5 days ago
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024