Problem/Motivation
My use case involves a computed LOCATION field, as well as a URL field using "link to content." Neither is rendered by the
iCal fields row wizard, because neither maps to a "real" database-stored entity field.
The URL field problem appears to be addressed, in a case-specific way, in
issue 3380184
🐛
Allow to use the "Link to Content" as link of event
Fixed
. This doesn't solve the general problem, though.
Steps to reproduce
The Easy Way: add a Custom Text field to your iCal view, set its output value to "hello world", and set it as the LOCATION field in
iCal Style Wizard | Settings. Since it isn't a real entity field, it quietly fails to render.
My Complicated Case: For unrelated reasons I had to implement a computed field (incl. Views Field plugin) to retrieve and format my event addresses, which live in a referenced entity and are stored as a series of sub-fields. I followed this guide:
https://www.drupal.org/docs/drupal-apis/entity-api/dynamicvirtual-field-... →
My field works fine with standard Views output methods, but the iCal row plugin fails in the same way as it does with Custom Text- there's no field storage defined, thus the row plugin doesn't know what to do with them.
Proposed resolution
My workaround was to use the render method attached to the Field object, e.g.
$html = $this->view->field[$field_mapping['location_field']]->render($row);
I'm attaching a patch against 8.x-1.0-alpha11 to demonstrate what I did. This is merely a hack and not a complete or correct solution. I haven't done serious Drupal development in a long time and don't know anything about current norms, like whether we can always expect a field object to have a render() method, how to properly cope with its various outputs, or whether that's even the Right Way to get at styled field output from a rows plugin.
Hopefully this can help serve as a signpost towards the correct solution, for someone who knows what they're doing.
Incidentally, the blocks of code that implement these also hard-code render methods for SUMMARY, LOCATION, URL, DESCRIPTION, etc, which is the proximal cause of issues like
3261566
🐛
No way to modify/alter/preprocess fields/rows when using wizard plugins
Needs review
. You'll see meddling in my diff that corrects this for my specific use case in DESCRIPTION. That should be ignored, but the underlying issue probably shouldn't be.
Remaining tasks
User interface changes
API changes
Data model changes