>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3618036. --> Reported by: [fabianderijk](https://www.drupal.org/user/278745) Related to !121 >>> <h3>Problem/Motivation</h3> <p><code>FullCalendar::prepareEvents()</code> collects date fields inside the<br> loop over the view's result rows:</p> <pre><pre>foreach ($this-&gt;view-&gt;result as $delta =&gt; $row) {<br>&nbsp; &hellip;<br>&nbsp; // If there are no date fields, return.<br>&nbsp; if (empty($date_fields)) {<br>&nbsp;&nbsp;&nbsp; return $events;<br>&nbsp; }</pre></pre><p><code>src/Plugin/views/style/FullCalendar.php</code>, line 470 on<br> <code>4.0.x</code>.</p> <p>That <code>return</code> sits inside the row loop, so the first row without a<br> date value abandons every remaining row. When it is the first row,<br> <code>$events</code> is still empty and the calendar renders with no Drupal<br> events at all &mdash; silently, with nothing in the logs and no message to the site<br> builder.</p> <p>Any calendar view whose result set can contain a row without a date value is<br> affected. That is not an exotic configuration: a view over content with no<br> bundle filter, an entity whose date field is optional and left empty, or a<br> translation without the field populated will all do it.</p> <p>The comment above the check reads "If there are no date fields,<br> return", so the intent seems to have been a per-row guard.<br> <code>continue</code> is what that intent needs; <code>return</code> makes it a<br> per-view guard driven by whichever row happens to sort first.</p> <p>Verified against <code>4.0.x</code> HEAD <code>68b7901</code> and against the<br> released <code>4.0.0-rc1</code>. Present in both.</p> <h3>Steps to reproduce</h3> <ol> <li>Create a content type <code>event</code> with a required date range<br> field.</li> <li>Add seven published <code>event</code> nodes with dates in the current<br> month.</li> <li>Create a view of Content, format FullCalendar, with the date field added<br> as a view field. Do not filter on the bundle.</li> <li>Make sure at least one published node of another type exists &mdash; a standard<br> <code>page</code> from a fresh install is enough.</li> <li>Visit the view.</li> </ol> <p><strong>Expected:</strong> the seven dated nodes appear on the calendar.<br><br> <strong>Actual:</strong> the calendar is empty. <code>$view-&gt;result</code><br> holds all eight rows, but <code>prepareEvents()</code> returns on the dateless<br> one.</p> <p>Adding a filter on the <code>event</code> bundle makes all seven appear,<br> which confirms the dateless row is the trigger rather than anything about the<br> dated ones.</p> <h3>Proposed resolution</h3> <p>Change the <code>return</code> to <code>continue</code>, so a row without a<br> usable date is skipped and the remaining rows are still processed.</p> <pre><pre>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // If there are no date fields, return.<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // If this row has no date fields, skip it and keep going.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (empty($date_fields)) {<br>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return $events;<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</pre></pre><h3>Remaining tasks</h3> <p>A test covering a mixed result set &mdash; one dated row and one dateless row &mdash;<br> would pin the behaviour, since the current tests appear to use uniformly dated<br> fixtures.</p> <h3>Unrelated observation, same file</h3> <p><code>getExposedDates()</code> (line 668 on <code>4.0.x</code>) uses<br> <code>drupal_static(__METHOD__, [])</code> keyed only by<br> <code>$field_name</code>, not by view or display. Two calendars on one page<br> using the same date field with different exposed input would share a min/max<br> window. This is the same class of defect as the<br> <code>prepareSettings()</code> static that was already removed on<br> <code>4.0.x</code>. Happy to open it separately if preferred.</p>