Descriptions with newline characters cause invalid ics files to be generated

I think you can test and report to iCalcreator
it uses $event->setDescription($longText) so this method must handle rfc5545
line 88 // render description, just remove all unsupported HTML tags
I try multiline description on iPhone, it works fine.

I’m not sure that my issue is quite the same as that reported here, but I too am finding that the DESCRIPTION property is not being formatted as expected in the .ics feed.

I’ve attached an example .ics file (saved as .txt for uploading as: calendar-test-d10.txt) created in Drupal 10 (10.3.10) with Date iCal 4.0.10. If you open this you will see that the DESCRIPTION property contains HTML paragraph tags where I was expecting to see /n as the paragraph separator. Also, I would have expected the HTML <strong> tag to have been removed.

When entered into the calendar on my Android phone/tablet, all is well, but when loaded into the Microsoft Outlook calendar on my desktop PC, the HTML tags are not recognised as such and appear, uninterpreted (see screen shot of Outlook entry attached: calendar-test-d10_in_Outlook.png).

My setup in Drupal 10, as far as I can see, mimics that which I have been using successfully in Drupal 7 for years without issue. The same calendar entry generated there (using Date iCal 7.x-3.12) has all HTML tags removed and the expected /n to separate paragraphs (see calendar-test-d7.txt attached). This renders correctly in both Outlook and my Android devices.

In the above cases I have a single content field configured as the DESCRIPTION property. I have found; however, that if the iCal view mode display for my content type is set to display that same, single field and I include this as a "Rendered entity" field in my iCal feed view and set this as the DESCRIPTION property then, in addition to the DESCRIPTION property in the .ics feed, I see also the X-ALT-DESC property (see calendar-test-render-d10.txt). When I load that feed it renders AOK in both Outlook calendar and in my Android devices (Outlook screenshot: calendar-test-render-d10_Outlook.png).

That’s great, but I want to be able to create some calendar feeds with the DESCRIPTION property set to be the rendered entity and others with an individual content field configured directly as the DESCRIPTION property – and with the X-ALT-DESC property present only when utilising the rendered entity method, the directly configured individual content field method isn't working for me.

Am I failing to configure something correctly or is there really an issue when an individual content field is configured directly as the DESCRIPTION property, rather than a rendered entity being configured as the DESCRIPTION ?

In your description field settings you can select option strip the HTML tag.
Most of the new generation ical feeds accept HTML code (no test on outlook but you can test on latest version or to the new outlook on windows 11) If only Outlook doesn't support HTML in the description, the module date ical won't support it.

Interesting. Which standard are "Most of the new generation ical feeds" working to? Clearly not rfc5545.

I had already tried stripping HTML tags from the description field; the DESCRIPTION property then displays as a single paragraph, which is really not acceptable, particularly as I generally "rewrite" 2 or 3 fields to generate the DESCRIPTION property.

I'm surprised that you say "If only Outlook doesn't support HTML in the description, the module date ical won't support it" as you are already doing so - to a degree - note the mention of Microsoft in the following section of date_ical/src/DateICal.php:

// Render description.
      if (!empty($field['description_field'])) {
        $description = trim(strip_tags(html_entity_decode($field['description_field']), '<a><b><u><strong><ul><ol><li><br><hr><h5><h4><h3><h2><h1><p>'));
        $event->setDescription(preg_replace('/(\s{2,})/', ' ', $description));
        // Check html add X-ALT_DESC support VCal Microsoft.
        if ($description != $field['description_field']) {
          $event->setXprop('X-ALT-DESC;FMTTYPE=text/html', preg_replace('/(\s{2,}|\r?\n)/', ' ', $field['description_field']));
        }
      }

I'm finding that when the description field is a rendered entity, production of the X-ALT-DESC property is triggered, which Outlook uses in preference to the DESCRIPTION property, and all is well. If the X-ALT-DESC property were created in all cases, my issue would, I believe, be resolved - but maybe there's a reason why its use is limited.

On a positive note, I now realise that I can achieve everything I need by using the rendered "iCal" view mode as the description field for one calendar export, and the "Teaser" view mode for another - so my issue is now resolved, thank you.

I tested all the ical readers which I have except outlook for the description field. I found that most of them support html with basic tags. So of course I chose to leave the tags supported without removing all the tags. outlook has very few users. when you render an entity, there is more than the basic tag, so it will add X-ALT-DESC. Why i have to limit X-ALT-DESC because it will create duplicate content and it crashes sometimes (if the content is too long) you can see it render X-ALT-DESC on one line another reader will crashes (I don't remember exactly, maybe Thunderbird)

Apologies for returning to this but I've noticed an occasional anomaly when viewing calendar entries in the Samsung calendar app on my phone – a HTML tag is sometimes visible e.g. </a>, </p>. Investigation has shown that HTML tags are not always properly represented within the calendar feed. Anomalies are seen when line folding, according to rfc5545, occurs within a tag. Some examples (once again as .txt files):

1. calendar-trailing-p.txt - Here, a requirement for line folding occurs between the "<" and "/" of a trailing </p> tag. The "<" and ">", have here been converted to &lt; and &gt; and, on my phone, the tag is visible as </p>.
2. calendar-trailing-mid-strong.txt - In this case, line folding is required within a trailing </strong> tag, but not immediately following the leading "<". Here, the </strong> tag has been removed completely. The Samsung calendar app appears not to recognise the <strong> tag anyway, and is unaffected by the loss of the trailing tag. The modified trailing </p> tag, seen in example 1, is also seen in this example, once again this tag is visible in the Samsung calendar entry.
3. calendar-leading-strong.txt - Here, a line is folded immediately following the opening "<" of a leading <strong> tag. As with the </p> tag in example 1, the "<" and ">", have here been converted to &lt; and &gt; and, on my phone, the leading <strong> tag is made visible. The trailing </strong> tag is ignored.

Whilst these examples were all captured with the description field configured as a rendered entity, the same behaviours are seen with a simple content field as the description field. The same behaviour can also be seen in the X-ALT-DESC property, and as a consequence HTML tags are occasionally visible in my Outlook calendar. I don't have ready access to other calendar apps so can't say how they might respond to these modified HTML tags, but they will all be receiving them wherever line folding occurs within a HTML tag.

Line folding is, I presume, performed by iCalcreator. Whether the behaviour I'm seeing is caused by a bug in iCalcreator, or whether iCalcreator is simply not designed to accommodate HTML as an input I cannot say, but it seems clear that there is currently an incompatibility between Date iCal and iCalcreator, which should be investigated further. I am not a developer, so doubt that I can assist with that, but am happy to be involved in the testing of any changes that may be proposed.

Has anyone reported the bug to the author of iCalcreator? They didn't think the description to support html so when breaking the line, it have to avoid cutting off the tag html.

Not me. I firmly believe that raising an issue with the author of iCalcreator is best done by the person / entity making direct use of iCalcreator. I would be unable (for example) to answer any queries that the iCalcreator author might have regarding the way Date iCal interfaces with iCalcreator.

I would note also that since my last post I have discovered that iCalcreator is HTML encoding ampersands (&) as &amp; and that this is causing the ampersand to be displayed as &amp; by some calendar clients (notably Outlook, Outlook.com, Samsung and Google) particualrly where the ampersand appears in the SUMMARY or LOCATION fields.

I'm left wondering what other gremlins iCalcreator might contain.

I encountered a problem where & characters in the generated iCal feed were being HTML-escaped to & when the feed was rendered through Drupal’s rendering system.

This was not caused by the kigkonsult/icalcreator library. The library’s output correctly contained plain &. The escaping happened later when Drupal treated the iCal output as HTML markup and automatically encoded special characters.

The following small change in public/modules/contrib/date_ical/src/Plugin/views/style/DateIcal.php in the DateIcal::render() method fixes the issue by stripping any HTML tags and decoding entities before marking the cleaned string as safe for rendering.

use Drupal\Component\Render\PlainTextOutput;
use Drupal\Core\Render\Markup;

return [
  '#type' => 'markup',
  '#markup' => Markup::create(PlainTextOutput::renderFromHtml($vcalendar)),
];

It's been merged, thanks @lazzyvn. I will mark this as fixed.

My apologies to kigkonsult/icalcreator for mistakenly attributing the ampersand problem to that library.

I can confirm that the change at #13 fixes the ampersand issue for me - thank you.

Unfortunately, it does not fix what I understand to be the original issue, and that upon which I have expanded, which is primarily to do with line folding - that issue is still present, indeed the proposed change at #13 makes it worse.

Removing all HTML tags from the DESCRIPTION property means that where the description comprises more than one paragraph, the paragraphs all roll into one. Not only that, but HTML tags are also removed from the X-ALT-DESC property, thus removing any benefit previously seen when referencing a rendered entity as the description field in Date iCal field settings.

Sorry, but I do not consider this issue to be fixed

So the break line problem is due to the library kigkonsult/icalcreator, the ampersand issue it's not a big problem, we can format it another way with Drupal. So can I revert it back to how it was before?

Yes, reverting to how it was and addressing the ampersand issue in a way that doesn't compound the line folding issue gets my vote.

Apologies, I failed to appreciate that you had already applied the alternative format. I have now patched the committed change into my test site and can confirm that not only does it fix the ampersand issue but also the line folding issue!

Inspection of the downloaded .ics file shows line folding being performed perfectly in each of the test cases I've highlighted previously.

In each test case the DESCRIPTION property now displays correctly on my Android phone and in Google calendar.

Yahoo calendar, unfortunately, fails to recognise HTML tags in the DESCRIPTION property and displays them as if they were plain text.

Outlook calendar also fails to recognise HTML tags in the DESCRIPTION property but, when offered the X-ALT-DESC property, uses that and displays correctly.

So I'm happy now to accept this as fixed - thank you

RE #21 @stevewilson, I am lost in your back and forth. Are we to re-apply MR12 changes that were reverted?

I fixed it. We just need to test the development version; if it works, we can close this issue.

Sorry for the confusion, I read the comment at #18 and agreed (#20) to the reversion of MR !12 before examining the committed fix (1171460f) at #19. Once I realised that 1171460f was effectively a modified version of what had been offered as MR !12, I tried that on a test site running version 4.0.12 of Date iCal and found it to have fixed both the ampersand and line folding issues. So, I agree with @lazzyvn, that 1171460f needs testing on the dev version but for me, it looks good to go.

Do please note, however, (#21) that not all calendar clients correctly interpret HTML tags in the DESCRIPTION property.

https://www.drupal.org/project/date_ical/releases/4.0.14