- Issue created by @codebymikey
- @codebymikey opened merge request.
- Status changed to Needs review
about 1 year ago 10:51am 6 November 2023 - Status changed to Needs work
about 1 year ago 1:53pm 6 November 2023 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 theinstances
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
- Status changed to Needs review
3 months ago 7:34pm 24 August 2024 - π¨π¦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 7:50pm 26 August 2024 - πΊπΈ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).
-
mandclu β
committed eae73e87 on 4.2.x
Issue #3399475 by mandclu, codebymikey, mark_fullmer: The Augmenter...
-
mandclu β
committed eae73e87 on 4.2.x
- Status changed to Fixed
5 days ago 11:39am 28 November 2024 Automatically closed - issue fixed for 2 weeks with no activity.