Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
I am using MacOS Calendar application. I am exporting the the .ics file generated by this module, and I do not see the new event in application.
I compared the generated file with an ics file generated from date_ical module. I found that this module's file is missing a lot of data - DTSTART, TZID, and much more. I believe due to this missing data, the exported entity is not getting identified in the application.
Proposed resolution
- Make sure that the template generated by
views-view-ical.html.twigis correct - Use https://packagist.org/packages/kigkonsult/icalcreator to generate the ics file - refer
date_ical
Using https://packagist.org/packages/kigkonsult/icalcreator would be a better approach as we do not have handle the creation manually.
Remaining tasks
N/A
User interface changes
Not sure as of now.
API changes
Not sure as of now.
Data model changes
N/A
Release notes snippet
Not sure as of now.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | views_ical-wizard-3052866-10.patch | 28.85 KB | bburg |
| #8 | interdiff-6-8.txt | 19.1 KB | bburg |
| #8 | views_ical-wizard-3052866-8.patch | 31.3 KB | bburg |
| #6 | interdiff-4-6.txt | 22.66 KB | bburg |
| #6 | views_ical-wizard-3052866-6.patch | 24.21 KB | bburg |
Comments
Comment #2
subhojit777I would advise this to be done as 8.x-2.x because the implementation for ical generation has been changed.
Comment #3
bburgSetting up fields has been a very manual process so far, manually set field labels to identify what values should be used for what iCal field. I made an attempt at some instructions, so I hope people follow that.
With that said, I do like this approach, and I do agree that this would probably need to be used for a 2.x branch. Thanks for the patch! I'll get to reviewing it in more detail later.
Comment #4
subhojit777I have made some improvements in the patch. The motive was to write tests for the changes I have made.
I am using this module in my project, and we are using
drupal-test-traitsframework for tests. I haven't written tests using Drupal testing framework for a long time. Due to time constraints I was not able to convert the tests.Comment #5
bburgHello,
My apoligies for not responding here. I've been thinking about this patch though. It might make the most sense to offer the display changes you've made as a different Views display option altogether. This would provide support for a more guided use that you provided, but also the more flexible approach that the module currently implements. I haven't yet tested your patch, but this is what I am understanding.
Comment #6
bburgI have made some progress on this. Rather than breaking backward compatibility, I am opting to create a new views style that I am calling iCal Wizard, which will provide the UI for mapping fields to properties in the ical event object.
I have made a number of changes, like moving your changes to the Ical class to the new IcalWizard style plugin. I've also made several changes to support all-day events utilizing the new leceo/ical library.
Also one side note, I already committed the changes add a composer.json and composer.lock files for the eluceo/ical library to the dev branch.
Comment #7
bburgThe previous patch does still break backward compatibility. We need to revert the twig files and come up with a new set for the new Wizard style plugin.
Comment #8
bburgHere are several updates.
I've moved the updated Ical style plugin to a new IcalWizard plugin.
Added end date field as an option.
Started a framework to handle daterange, datetime and date_all_day fields differently.
Ability to use node id as the uid of the event.
Logic for handling end date and all day events.
Changed function signature for addEvent so it includes the ResultRow instead of the ContentEntityInterface (which is a part of ResultRow). The _entity property on that is supposed to be private anyway.
New wizard theme/template, restored previous theme template to be used with restored Ical style.
Comment #9
bburgOne problem with the patch so far, it does not appear to allow field rewriting.
Comment #10
bburg@subhojit777, my apoligies if this breaks your current implementation. But I don't want to break the other hundreds of implementations currently using this module, and I don't feel ready to start on a 2.0 release.
New patch. Adds some variable checking/hardening. It seems to work for me. so I am going to commit to dev. Although I feel that it does need tests at this point. I'd rather not sit longer with uncommitted code.
I'm still want to get field re-writing to work at least. Anyone seeking to upgrade to the new style will need to replicate their existing event UID values or risk generating duplicate events on their users calendars.
Comment #11
subhojit777No worries @bburg. I am using the patch in #4 for my project. I will update the module version and settings once your patch #10 gets committed. My implementation was mostly inspired from the core's rss feed views display. I haven't tested your patch, but can you tell me, what would be the behavior if the mapping is not configured.
Comment #12
bburg@subhojit777,
Without any mappings, I believe it should just render an empty calendar. I did commit the patch in 10 to the dev branch, though the Drupal packaging script seems a bit show that.
I'm worried I may have broken the work in another issue, which is highlighting the need for tests on this module. I've created separate issues to create tests (#3084060: Write tests), and resolve the rewriting of fields (#3084059: Alter/Rewrites don't work in Wizard). I'm not going to roll another alpha release until those are resolved.
Comment #13
bburg(closing this issue as fixed for now). If you run into any bugs, please open a new issue.