data: scheme prefix stripped from .ics links in views custom field

Took a look with XDebug to see that the output from spatie/calendar-link was as expected. It was.

I then took a look for issues relating to data: URIs in Drupal, and found 🐛 Url::fromUri($uri)->isExternal() and UrlHelper::isExternal($uri) do not always match Needs work (noting that the maintainer of Calendar Link opened that issue for what looks like this specific case), so I tried the patch from that issue ... still no change in behaviour.

Very interesting - it seems like there's an output filter in play. I even tried adding an extra data: prefix to the link in Twig, and still saw that it was removed. Even when I used a nonsense prefix, anything up to and including the colon in the link was stripped out.

To cross-check, I added HTML containing a colon <a href="some:silly:url">some silly url</a> to the Views custom field, and saw it was output as <a href="url">some silly url</a>.

Used curl to check whether this was a JS post-process running in the site theme or similar, and it wasn't - the HTML returned is getting this treatment.

Well, it really seems like isn't having it. I don't see a tidy way to output a data: scheme URI from Views custom field Twig.

I was able to work around this clientside, not my proudest hour but it'll do for this situation:

      // Workaround for Calendar Links data: URI issue.
      // @see https://www.drupal.org/project/calendar_link/issues/3392787
      document.querySelectorAll('.calendar-link-ics').forEach(element => {
        if (!element.href.match(/^data:/)) {
          element.href = element.href.replace(/^.*text\/calendar/, 'data:text/calendar');
        };
      });

Reading further, I expect this is because Drupal runs the views custom field value through xss filter. By moving that twig into a template, this may not be applied. Something to try tomorrow :)

Yep! It works from a "proper" Twig template, but not from an inline (eg Views "Custom text" field) Twig template. Templates rendered from DB are passed through a #post_render function which (among other things) prevents links with unsafe schemes, where safe schemes are "http:" and "https:" (but not "data:").

Used from a Views "Custom text" field, the template code example from the README works for most calendar types but not "ics" (the URL has "data:" removed, and becomes a local path leading to a 404).

That same template code does work if used in a regular Twig template file.

Automatically closed - issue fixed for 2 weeks with no activity.