User error: "0" is an invalid render array key when the SmartDateRecurrenceFormatter has a date with a deleted RRule

Added logic which renders all the date instances if it's unable to load the Smart Date Rule entity, as well as ensure that the $elements[$delta] is always an array rather than a string/integer.

Tests might still be necessary, but this solves the issue for me, and renders exactly as it would post resaving the piece of content with the missing RRule.

Thanks for identifying this, and providing a fix. The only part I'm not sure I understand is why the div wrapper is needed in the fallback render.

As a potential alternate approach, what about validating the rule object during the initial loop through the $items array? Then the items with invalid rrule references could be rendered as normal. If there was only one rule evaluated and it was an invalid reference, perhaps it could even still subset the elements based on the formatter settings, similar to if $force_chrono was true.

The only part I'm not sure I understand is why the div wrapper is needed in the fallback render.

It was necessary because without it, the HTML output was in a different format than if it still had an RRule attached - I think from memory, it'd be just the inner content which makes styling a bit more difficult.

As a potential alternate approach, what about validating the rule object during the initial loop through the $items array?

That'a a good idea, but given the way the rest of the code worked wrt loading the SmartDateRule, I didn't want to move the logic around and potentially break something else or make it harder to review.

OK one last thought: in the scenario where the store rrule value is invalid, should we log an error?

I added an error since I think it's important to have visibility on where rules could be getting deleted unexpectedly. Thanks for your work on this!

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