Understood, @jurgenhaas. I have one last bit of amateur sleuthing to pass along and then I'll leave it to the experts.
In the ECA code you referenced in \Drupal\eca_form\Plugin\Action\FormBuildEntity::execute, where $form is being fed into buildEntity(), $form is defined in this way:
$form = &$this->getCurrentForm();
This is followed by some logic to determine whether $needs_manual_build should be triggered. If it is triggered, $form is redefined (as is $form_state). I can't say what is being accounted for in that process, but I can say that negating $needs_manual_build, and thereby negating the redefinition of $form, seems to fix the issue with unlimited values, by which I mean that field instances added in the form are correctly represented in the built entity.
So in my (admittedly simplistic) analysis, something is lost when $form is redefined.
I don't have the skills to delve into php code, so I'm trying to probe this problem from the outside with Drupal and ECA.
For unlimited value fields, adding values beyond the first requires that you add field instances to the form. So one possible explanation is that "build entity" is working with the form as it exists when the page loads, and is not able to make use of fields that are added to the DOM after the fact. Evidence supporting this idea: If you edit a previously-saved entity with a single value in an unlimited values field, the edit form appears with the previously saved value, plus an additional (empty) field instance. Data entered into that second field instance does appear in the built entity, but if you add a third field instance, it will be ignored. (This holds true for any number of values; if the saved entity has four values, a fifth field instance appears and is functional, but an added sixth instance is not.)
Looking for other ways to test this idea -- that fields added to an existing form are a not accessible to "build entity" -- I used "Form: add text field" and "Form field: set submitted value" to add and populate a field after the form is loaded. Using "Form field: get submitted value" on the newly-added field gives the proper result, but "Entity form: build entity" shows no value for that same field.
brian.barry@utexas.edu → created an issue.
Following up on this, I boiled it down to a minimal install.
Steps to reproduce
Install Drupal 10.3.10
Install module Smart Date 4.2.1
Install module Token 8.x-1.15
Install module Twig Tweak 3.4.0
Create content type with Smart Date field (field_when)
Insert code into node.html.twig template:
value - {{ drupal_token('node:field_when:0:value', {node}) }}<br>
format:default - {{ drupal_token('node:field_when:0:format:default', {node}) }}<br>
value - {{ drupal_token('node:field_when:1:value', {node}) }}<br>
format:default - {{ drupal_token('node:field_when:1:format:default', {node}) }}<br>
value - {{ drupal_token('node:field_when:2:value', {node}) }}<br>
format:default - {{ drupal_token('node:field_when:2:format:default', {node}) }}<br>
In this case I created a node with only two date values, but invoking a formatted token for delta 2, which is empty, still returns the value of delta 0.
value - 1733572800
format:default - Sat, Dec 7 2024, 6 - 7am
value - 1733659200
format:default - Sat, Dec 7 2024, 6 - 7am
value - [node:field_when:2:value]
format:default - Sat, Dec 7 2024, 6 - 7am
brian.barry@utexas.edu → created an issue.
Thanks for your reply. It seems like what I'm trying to do is not possible (i.e., use "Views: Set filter value" within the process of form validation). I'll see if I can find a different approach.
brian.barry@utexas.edu → created an issue.
Following up on this: I found what I believe is the source of the problem.
While trying to solve this, I realized that no matter what sort criteria are used, events sort the same way. Looking through the components of the module for some other sorting mechanism, I found this in calendar_view.theme.inc:
// Sort events in each cells to keep order of multiday events.
if (count($list) > 1) {
usort($list, function ($row1, $row2) {
$instance1 = $row1['#values']['first_instance'] ?? NULL;
$instance2 = $row2['#values']['first_instance'] ?? NULL;
return $instance1 <=> $instance2;
});
}I don't know what problem this is intended to solve, but for this issue it appears to be causing the problem. I removed that function, and the events on each day now appear in the correct order, i.e., chronological for that specific day, rather than chronological according to the first instance of each event. And with that function out of the way, sort criteria in the view are taking effect as they should.
I'm running into this issue as well, and I think I understand what the problem is. When Date is used as a sort criteria, recurring events are sorted according to the first day on which they occur, regardless of the day on which they are appearing. So if a weekly event starts on October 1, the instance of the event that appears on October 8th will be sorted according to the October 1st date/time, and will therefore appear before any event that only occurs on October 8th. Put another way, this event will sort correctly on October 1st, but will sort incorrectly on every day that it appears after October 1st.