Status
Priority
Medium
<p><strong>Problem</strong><br>
Events created as <code>rsvp_event</code> nodes were not appearing on FullCalendar calendar month pages (e.g. <code>/neighborhood/west-philly/calendar/2026/03</code>). The calendar rendered with an empty <code>events: []</code> array in <code>drupalSettings</code> despite events existing in the database.</p>
<p><strong>Root cause</strong><br>
The base <code>fullcalendar_view</code> module's <code>FullcalendarViewPreprocess::process()</code> iterates view result rows and checks the field formatter type before building FullCalendar event entries. For <code>smartdate_default</code> formatters it looks for a <code>'smartdate'</code> entry in <code>$variables['fullcalendar_fieldtypes']</code>, which is populated by <code>FullcalendarViewProcessor</code> plugins. The SmartDate module's <code>SmartDateProcessor</code> plugin was not being discovered, so all rows hit <code>continue 2</code> and the events array stayed empty.</p>
<p><strong>Fix</strong><br>
Rewrote <code>rsvp_system_module_preprocess_views_view_fullcalendar()</code> in <code>rsvp_system_module.module</code> to bypass base fullcalendar_view processing entirely for the <code>rsvp_event_calendar</code> view. It now reads raw Unix timestamps directly from <code>field_rsvp_event_smartdate</code> on each <code>$view->result</code> entity and converts them with <code>gmdate()</code>. EventInstance recurring events are still injected via <code>_rsvp_system_module_get_recurring_calendar_events()</code>.</p>
<p><strong>Commit</strong><br>
<code>b380fd1</code> on <code>rsvp-system-module</code> <code>main</code> branch. Pushed to GitLab.</p>
<p><strong>Related</strong><br>
Also fixed <code>rsvp_smartdate_jsonapi</code> sub-module (separate earlier work) which resolves a parallel issue where <code>SmartDateNormalizer</code> incorrectly claimed <code>Timestamp::class</code> support, causing 500 errors on JSON:API POST/PATCH to <code>rsvp_event</code> nodes.</p>