Smart Date Format in Views with Formatter set to Recurring

This is probably not helpful but I am having a similar issue with using views to output node teasers with dates.

https://www.drupal.org/project/smart_date/issues/3362019

The first one in the results renders correctly but the rest are wrong. I am stumped on how to troubleshoot it though. Are you using layout builder at all?

I have come back to this after a bit and I am having this exact same issue on Smart date 4.0.3 with Drupal 9.5.11

I feel like this is a major issue as the longer the site exists the more unusable this becomes. Full node view works perfectly fine, but then the teasers on the view results page show incorrectly. All except the first result which works fine? Seems to me it's definitely a bug but I am really struggling to pinpoint where it is going wrong.

Would it be possible to use a view mode instead of fields for your view display? It's possible that the recurring formatter doesn't work as well with views field otput.

Not the original issue reporter and it's been a while since I worked on this site but I believe I was using view modes as I don't ever use Fields as views output. I was using the teaser view mode and layout builder when I was getting this issue.

Also to note I have not updated the module in a while but will be updating and working on this site again soon so I can report back, but would be good to know if you have any tips for debugging this one.

I'm also experiencing this issue. Only my first date was respecting the smart date format and the others fell back to default.

I am unable to use view modes as we are listing single instances in the view and need the contextual date for the row. I previously was using that functionality and this is how I uncovered this issue -- trying to create parity with views fields.

Thanks.

I have been debugging this issue again as we put it on the backburner for a while but now are back to needing it working. Just a caveat that its been a while since I was deep in Drupal core code so my understanding of core Drupal 10 may be missing some key info.

From my understanding it looks like the settings for the field/formatter are being reset somewhere along the way after the first instance is displayed. When it goes to output the next nodes the settings for the field are different, including force chronological to be false even though it is definitely set to true for that view mode. It almost looks like the settings are first being reset to the defaults and then the next node gets the settings for base smart date field (maybe even core Drupal date field settings) and not the recurring format as it seems force chronological isn't even there at all.

I would be interested to see if this would happen on a full view of a node with multiple instances of the field showing as well.

I have had to jump onto something else over the holidays so will try and get to the bottom of it in the new year but thought I would put my update here incase anyone else could think of where this might be happening and could add some more insight. I would love to be able to provide a patch for this but may need extra checking.

Drupal + Layout builder 10.5.6
Smart date 4.2.4

I found this same issues, Claude solved it for me

The root cause is in SmartDateRecurrenceFormatter::viewElements(). It writes a
locally-built settings array back onto the plugin's own configuration store:

// SmartDateRecurrenceFormatter.php, ~line 182
$settings['augmenters'] = $augmenters;
$this->settings = $settings; // <-- clobbers the plugin config

$this->settings is PluginSettingsBase's persistent config. The local $settings
array built earlier in this method omits keys such as 'force_chronological' and
'format'. Because PluginSettingsBase has already merged defaults by this point
(defaultSettingsMerged === TRUE), the missing keys are NOT restored on later
getSetting() calls.

This only manifests when more than one entity is rendered through the SAME
formatter instance, which is exactly what EntityViewDisplay does in
buildMultiple()/viewMultiple() (Views field rendering, entity teaser lists via
viewMultiple(), etc.). The display instantiates one formatter object and reuses
it for every row/entity:

- Entity #1: getSetting('force_chronological') === TRUE -> items routed through
subsetInstances() -> 'smart_date_recurring_formatter' theme (correct output).
- After entity #1, $this->settings is overwritten and the keys are gone.
- Entity #2+: getSetting('force_chronological') === NULL -> FALSE. Non-recurring
items (empty rrule) take the empty($item->rrule) branch and fall back to
buildOutput() directly -> the plain SmartDateDefault output. The recurring
format/styling is lost.

That's why a single full-node view always renders correctly (one viewElements()
call) but lists/Views only style the first item, regardless of which item is
first or how the dates are ordered.

Fix: $this->settings is never read back anywhere in smart_date_recur (all
downstream code uses the local $settings variable), so the assignment can simply
be removed. Patch attached, applies cleanly against 4.2.x (verified on 4.2.8).

Reproduced on: Smart Date 4.2.8, Drupal 11.

------------
sorry but Im not savy with uploading patches correctly, here it is

diff --git a/modules/smart_date_recur/src/Plugin/Field/FieldFormatter/SmartDateRecurrenceFormatter.php b/modules/smart_date_recur/src/Plugin/Field/FieldFormatter/SmartDateRecurrenceFormatter.php
--- a/modules/smart_date_recur/src/Plugin/Field/FieldFormatter/SmartDateRecurrenceFormatter.php
+++ b/modules/smart_date_recur/src/Plugin/Field/FieldFormatter/SmartDateRecurrenceFormatter.php
@@ -179,7 +179,6 @@ class SmartDateRecurrenceFormatter extends SmartDateDefaultFormatter {
       $this->entity = $items->getEntity();
     }
     $settings['augmenters'] = $augmenters;
-    $this->settings = $settings;

     $rrules = [];
     foreach ($items as $delta => $item) {

@lindsay.wils thanks for your contribution! I have rolled your proposed change into an MR. Feedback from anyone else who has experienced this issue would be appreciated.

Thanks for everyone's work here. Merged into the 4.3.x branch.

Oh wow that's amazing. So glad to have this one fixed, thanks everyone.

Out of curiosity @lindsay.wils how did you use Claude to find this issue? Was it much work with the prompts to narrow it down or did you just need to describe the issue and it worked it out?

Hey @tisteegz, I gave Claude Code a description of the issue, a screenshot of the issue on the front end, explained the setup i have in the view, and gave it the output HTML from the front end, it pretty much just worked it out itself. My experience with the latest models is that they are extremely proficient in taking an issue and working until a solution is found. It really impressive to watch! Key is just given as much context as you can, but even when you don't, they still manage to solve most things.