Views support

I get the same issue but with more details:

passing title (a views field token) gives me:
some error about title but i cant see it now as it only chokes on the date error.. odd.

passing various date formatted fields gives me:
Drupal\calendar_link\CalendarLinkException: Could not get valid \DateTime object from input

- suggesting i need to pass a DateTime object - not sure why this module would make it so difficult; why not have the module convert to Datetime()?

The twig function attempts to coerce various data types in to \DateTime (see src/Twig/CalendarLinkTwigExtension.php#L218). I think the issue here is that the date and string coercion methods are not accounting properly for data types passed from Views (I have never used the functions from Views so hadn't thought to test them this way).

Tasks required for this ticket are:

• Determine data types passed from views.
• Refactor twig functions to account for those data types. Probably to check for interface instances instead of specific classes.
• Add tests for Views use cases.
• BONUS: Improve exception output to be more useful (i.e., identify the data type that cannot be coerced).

I'd be thrilled to get an MR for this but otherwise I'll get around to looking when I am able.

i made changes to get this working in Views by simply checking if datetime object and if not, converting it and the same for string function which checks if twig markup, i added similar to check if std core markup object.

pretty minor changes but now works with a Views custom field like this:

{% set link = calendar_link('google', title ~ " (" ~ field_session_language ~ ")", field_session_date | split(' - ')[0] | striptags,  field_session_date | split(' - ')[1] | striptags, FALSE, body, "My Location") %}
<a href="{{ link }}">Add to Calendar</a>

the split function, if not obvious, is because i am using a date range field and there is no mechanism yet to output only start or end. So this simply uses twig to split them apart.

this works great for google as my example shows but doesn't work for ICS (nothing to do with my change). The link i get for ICS is something like:

http://mysite.com/en/news/events/text/calendar;charset=utf8;base64,QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KQkVHSU46VkVWRU5UDQpVSUQ6YjcxM2RlZmI3YzY0YzFkMzBkN2U5M2M2NmM4MjhhZDANClNVTU1BUlk6TmV3IEV2ZW50IDEgKEJpbGluZ3VhbCkNCkRUU1RBUlQ7VFpJRD1BbWVyaWNhL1Rvcm9udG86MjAyMTExMjlUMDIwMDAwDQpEVEVORDtUWklEPUFtZXJpY2EvVG9yb250bzoyMDIxMTEyOVQwMzAwMDANCkRFU0NSSVBUSU9OOjxwPkxvcmVtIGlwc3VtIGRvbG9yIHNpdCBhbWV0XCwgY29uc2VjdGV0dWVyIGFkaXBpc2NpbmcgZWxpdFwsIHNlZCBkaWFtIG5vbnVtbXkgbmliaCBldWlzbW9kIHRpbmNpZHVudCB1dCBsYW9yZWV0IGRvbG9yZSBtYWduYSBhbGlxdWFtIGVyYXQgdm9sdXRwYXQuIER1aXMgYXV0ZW0gdmVsIGV1bSBpcml1cmUgZG9sb3IgaW4gaGVuZHJlcml0IGluIHZ1bHB1dGF0ZSB2ZWxpdCBlc3NlIG1vbGVzdGllIGNvbnNlcXVhdFwsIHZlbCBpbGx1bSBkb2xvcmUgZXUgZmV1Z2lhdCBudWxsYSBmYWNpbGlzaXMgYXQgdmVybyBlcm9zIGV0IGFjY3Vtc2FuIGV0IGl1c3RvIG9kaW8gZGlnbmlzc2ltIHF1aSBibGFuZGl0IHByYWVzZW50IGx1cHRhdHVtIHp6cmlsIGRlbGVuaXQgYXVndWUgZHVpcyBkb2xvcmUgdGUgZmV1Z2FpdCBudWxsYSBmYWNpbGlzaS48L3A+XG5cbjxwPlN0ZXQgY2xpdGEga2FzZCBndWJlcmdyZW5cLCBubyBzZWEgdGFraW1hdGEgc2FuY3R1cyBlc3QgTG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQuIEF0IHZlcm8gZW9zIGV0IGFjY3VzYW0gZXQganVzdG8gZHVvIGRvbG9yZXMgZXQgZWEgcmVidW0uIExvcmVtIGlwc3VtIGRvbG9yIHNpdCBhbWV0XCwgY29uc2V0ZXR1ciBzYWRpcHNjaW5nIGVsaXRyXCwgc2VkIGRpYW0gbm9udW15IGVpcm1vZCB0ZW1wb3IgaW52aWR1bnQgdXQgbGFib3JlIGV0IGRvbG9yZSBtYWduYSBhbGlxdXlhbSBlcmF0XCwgc2VkIGRpYW0gdm9sdXB0dWEuPC9wPlxuDQpMT0NBVElPTjpNeSBMb2NhdGlvbg0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg==

I am not entirely sure how that is supposed to work although i get it is encoding the ICS file and passing on url (i guess rather than how the Calendar Links Token module does it which is using the same library but creates a public ics file and a link to that file). When i click that link i simply get 404 (which makes sense as no route to that link). When i sort out the ics issue i'll post patch.

i tried using this for my A tag:
<a href="/{{ link }}">Add to Calendar</a>

and this gives me:

http://ssc.peter/data:text/calendar;charset=utf8;base64,QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KQkVHSU46VkVWRU5UDQpVSUQ6YjcxM2RlZmI3YzY0YzFkMzBkN2U5M2M2NmM4MjhhZDANClNVTU1BUlk6TmV3IEV2ZW50IDEgKEJpbGluZ3VhbCkNCkRUU1RBUlQ7VFpJRD1BbWVyaWNhL1Rvcm9udG86MjAyMTExMjlUMDIwMDAwDQpEVEVORDtUWklEPUFtZXJpY2EvVG9yb250bzoyMDIxMTEyOVQwMzAwMDANCkRFU0NSSVBUSU9OOjxwPkxvcmVtIGlwc3VtIGRvbG9yIHNpdCBhbWV0XCwgY29uc2VjdGV0dWVyIGFkaXBpc2NpbmcgZWxpdFwsIHNlZCBkaWFtIG5vbnVtbXkgbmliaCBldWlzbW9kIHRpbmNpZHVudCB1dCBsYW9yZWV0IGRvbG9yZSBtYWduYSBhbGlxdWFtIGVyYXQgdm9sdXRwYXQuIER1aXMgYXV0ZW0gdmVsIGV1bSBpcml1cmUgZG9sb3IgaW4gaGVuZHJlcml0IGluIHZ1bHB1dGF0ZSB2ZWxpdCBlc3NlIG1vbGVzdGllIGNvbnNlcXVhdFwsIHZlbCBpbGx1bSBkb2xvcmUgZXUgZmV1Z2lhdCBudWxsYSBmYWNpbGlzaXMgYXQgdmVybyBlcm9zIGV0IGFjY3Vtc2FuIGV0IGl1c3RvIG9kaW8gZGlnbmlzc2ltIHF1aSBibGFuZGl0IHByYWVzZW50IGx1cHRhdHVtIHp6cmlsIGRlbGVuaXQgYXVndWUgZHVpcyBkb2xvcmUgdGUgZmV1Z2FpdCBudWxsYSBmYWNpbGlzaS48L3A+XG5cbjxwPlN0ZXQgY2xpdGEga2FzZCBndWJlcmdyZW5cLCBubyBzZWEgdGFraW1hdGEgc2FuY3R1cyBlc3QgTG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQuIEF0IHZlcm8gZW9zIGV0IGFjY3VzYW0gZXQganVzdG8gZHVvIGRvbG9yZXMgZXQgZWEgcmVidW0uIExvcmVtIGlwc3VtIGRvbG9yIHNpdCBhbWV0XCwgY29uc2V0ZXR1ciBzYWRpcHNjaW5nIGVsaXRyXCwgc2VkIGRpYW0gbm9udW15IGVpcm1vZCB0ZW1wb3IgaW52aWR1bnQgdXQgbGFib3JlIGV0IGRvbG9yZSBtYWduYSBhbGlxdXlhbSBlcmF0XCwgc2VkIGRpYW0gdm9sdXB0dWEuPC9wPlxuDQpMT0NBVElPTjpNeSBMb2NhdGlvbg0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg==

which seems closer; but still blocked by Drupal. Not a 404 though, simply a 403 (forbidden) so thinking an .htaccess thing and possibly pointing to the idea that this is not the correct way to do this? Maybe the create/link .ics file is the way to go?

back with my original <a href="{{ link }}">Add to Calendar</a>

and i see that even though on hover it shows: mysite.com/en/news/events/text/calendar.... etc, if i inspect the HTML source it is actually:

<a href="text/calendar;charset=utf8;base64,QkVHSU46VkNBTEVOREFSDQpWRVJT...">Add to Calendar</a>

which is almost right except something has removed the data: at the beginning. If i modify the url directly with browser dev tools and add it back in; the link works correctly.

This patch allows this to work with Views; but as mentioned above, something in Drupal removes the data: prefix to the href for ICS links. Got tired of looking for a proper solution so i just fixed it with js using this:

    $("a.ics-link").each(function() {
      var href = $(this).attr('href');
      href = href.replace("text/calendar", "data:text/calendar");
      $(this).attr('href', href);
    });

Thanks for your efforts here @liquidcms. I’ll review this in the next few days. Did you or @bakulahluwalia have this working on Views before the 2.1.x releases? If so the URL data stripping part of this seems curious…

Not sure how that could have ever worked in Views unless 2.1 is completely different than 2.0. Sorry, I've never used this module before so hadn't tried it.

And yes, the data: stripping thing is odd. If someone tells me this doesn't happen, I'll dig into it further. Not sure why it would work directly in twig if filtered elsewhere. But have never tried the direct twig use. That should be tested with my patch though to make sure this didn't break the original use case.

Hmm, not sure how I missed that other issue when looking at this but yes, it does sound like this used to work in Views. Must have been done much different then.

And thanks for shedding light on the data: stripping thing. That was what I suspected was going on. I don't see how its a security issue and certainly isn't in my specific use case (intranet site). Perhaps something to do with user input adding a link with a PHP file in it? Not sure.

And my js approach is better. :)

@bakulahluwalia, thanks for testing this with the original fields use case. I don't use that case so not too concerned about it.. but please submit patch to fix my mistake. :)

@bakulahluwalia @liquidcms I don't necessarily love the approach being pursued here. I see that the Views output when using the twig functions this way is just plain text and converting that to a DateTime object works (for plain output) using the patch in #8. But I don't like the idea of applying the system timezome to the created DateTime object. This does support, for example, modifying the timezone of the outputted field in Views. What would be the drawback of just using the UTC value that Views outputs?

As for the default formatter -- it does seem we should handle that as well. I guess my parsing the HTML time tag even though that seems like such overkill...

@bakulahluwalia I'm not totally sure what to conclude. It seems like handling the default will dictate how we should deal with timezones, right? That or we simply don't support the default and update the documentation to reflect. Regardless, I'd be happy to review your approach to the items you list in your notes.

Here's a new pass at this. Attached patch attempts to handle string-based date representations and works with the default views formatter for dates, plain text, and even specific forms of relative dates.

Also attempting to add some new tests to start covering these various use cases. More work to be done there.

Re-rolling #20 after fixes to base branch tests.

Fixing missed declaration in tests twig syntax.

Adjusting expected test results to use encoding ampersands.

Add TZ to string-based test.

Use UTC to simplify basic string test.

Ok so the results from #20 onward actually don't resolve the lack of TZ data provided by Views outputs. Attaching a new approach that only supports the default Views formatter creating a time HTML element. Other formatters (plain text, primarily) simply don't give enough context for accurate handling of dates. The module documentation will also need to be updated to note this.

D'oh! Reapply Twig syntax fix.

Revert accidental change to expected output of testCalendarLinksFunction.

This functionality is broken after upgrading from Drupal 10.2 to Drupal 10.3.

TO get this functionality working

downgrade to Drupal 10.2