I did end up seeing duplicates calendar items, per grahamC in #10. I created another issue in the calendar queue, 🐛 Duplicate rows for some entities with multiple entity references Active , which addresses the problem in the way grahamC suggests.
apkwilson → changed the visibility of the branch 3452532-duplicate-rows-for to hidden.
apkwilson → changed the visibility of the branch 3452532-duplicate-rows-for to active.
apkwilson → changed the visibility of the branch 3452532-duplicate-rows-for to hidden.
apkwilson → created an issue.
I've just set this up using #6 and the patch in
#3177760-13: Support Calendar module →
. Aside from having to add the date contextual filter before selecting the calendar format, the experience was seamless.
Agree that referencing smartdate isn't the best, but what would be required to avoid it? A new plugin type?
I've just set this up using #13 and the patch in #3177761-6: Support for Smart Date, other contrib modules → . Aside from having to add the date contextual filter before selecting the calendar format, the experience was seamless. I'd say RTBC.
I've run into this same issue with a D7 date_repeat field, including getting the follow-up error 'field_smart_date_end_value' cannot be null. While trying to handle that, I came to a different conclusion.
The migration plugin is written to handle all the field values for the migrating row at once, but the migration system was passing values one by one. That meant that, rather than being a field deltas, $k was value, value2, or rrule. After casting $k as (int), the key the plugin was trying to access for the end value wasn't present - it was that very key that had been casted.
The solution in MR!117 was adding the migration plugin annotation handle_multiples, which tells the migration system to pass in all the row's field values at once. That's the input the plugin expects, and it resolved all the errors I encountered. All the instances of my repeating dates were created correctly.
Any UNTIL date of the rrule isn't being converted from D7 date format, but that's a separate issue.
apkwilson → made their first commit to this issue’s fork.
Suggested changes applied. Setting to Needs Review.
Removing the encoding seemed a better solution. I've updated the merge request to do that, instead.
Filled out the issue template.
\Drupal\views\Plugin\views\field\FieldPluginBase::renderText() calls FieldPluginBase::getRenderTokens(), calls addSelfTokens(), which for \Drupal\views\Plugin\views\field\EntityField::addSelfTokens() calls Xss:filterAdmin(), encoding special characters.
Then renderText() calls FieldPluginBase::renderAltered(), calls \Drupal\views\Plugin\views\PluginBase::viewsTokenReplace(), calls Xss:filterAdmin() (either explicitly or as a post-render callback), encoding special characters a second time.
The proposed encode/decode process also takes place elsewhere, e.g. in \Drupal\views\Plugin\views\field\FieldPluginBase::renderText() at 1331-1333.
However, other core field plugins omit encoding the value, and so don't need to decode it. See \Drupal\taxonomy\Plugin\views\field\TaxonomyIndexTid::addSelfTokens() and \Drupal\user\Plugin\views\field\Roles:addSelfTokens(). Maybe that is a better route, to avoid the extra back-and-forth calls. The value does get filtered in the call to viewsTokenReplace(), anyway.
I ended up making a new test class and view, after all. I updated their naming to make what their testing more clear.
Updating the issue title and description to indicate that this is only a problem for field plugin generated subtokens.
I did see this test-only job, but it deleted the test view configuration the rerolled patch included, so the test couldn't run and fail the expected way.
I think I'm going to remove the new test view configuration and use an existing one, so this shouldn't be an issue, here, but what happens when a merge request need to include new test configuration?
I don't think there's anything wrong with gitlab. I wanted to run the test suite on the commit with just the new test, to show that it failed. In looking around for how to do that, I found this Patch or merge request → section of the docs, which seemed to suggest that I should stick with patches here, since that's how the issue started. I'm happy to be corrected.
I'll reroll again for 11.x and open another merge request - is a test-only commit and test run not really necessary?
These patches reroll #22 for Drupal 10.1.x. Tests only patch is expected to fail. The full patch includes the fix and should succeed.
I'm not familiar with the GitLab system, so I've fallen back to patches.
Updating version to 10.1.x.-dev (which still has this problem), since D9 is EOL.