Views RSS Feed Fields adds <time> tag.

In case anyone lands on this, our workaround is to enable "rewrite results" for the field, and use twig:
{{ created__value|date('D, d M Y H:i:s O') }}
This "fixes" it.

Thanks for posting your issue and workaround, I have some questions that might help get

this broke a bunch of our feeds

When did this break a bunch of feeds, was this after an update? If so, which one? It might help track down what changed this. Or is this just an issue when creating any new Feed that doesn't align with how the feed should be formatted?

Also, I'm wondering, is this just using core/modules/system/templates/time.html.twig for rendering? And if so, is this a problem in Views or somewhere else?

@lendude - It's hard to say, because I was notified by a volunteer. If I had to guess, it was around the time we updated the site to Drupal 10, but I can't be sure.

I am seeing this on my REST Export feeds after updating Drupal from 9.5.11 to 10.1.4.
I am surprised this is not better documented somewhere, if it is I haven't found it.

I worked around this by checking "Strip HTML tags" and "Remove whitespace" under "rewrite results".

We updated Drupal from 9.5.10 to 10.1.4.

@lendude The template doesn't seem to matter. The markup of all our field based feeds changed from

<pubDate>

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'core/themes/stable/templates/views/views-view-field.html.twig' -->
Tue, 26 Sep 2023 12:55:17 +0200
<!-- END OUTPUT from 'core/themes/stable/templates/views/views-view-field.html.twig' -->

</pubDate>

to

  <pubDate>

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'themes/contrib/stable/templates/views/views-view-field.html.twig' -->


<!-- THEME DEBUG -->
<!-- THEME HOOK: 'time' -->
<!-- BEGIN OUTPUT from 'themes/contrib/stable/templates/field/time.html.twig' -->
<time datetime="2023-09-26T12:55:17+02:00">Tue, 26 Sep 2023 12:55:17 +0200</time>

<!-- END OUTPUT from 'themes/contrib/stable/templates/field/time.html.twig' -->


<!-- END OUTPUT from 'themes/contrib/stable/templates/views/views-view-field.html.twig' -->

</pubDate>

As you can see we are using a theme based on contrib stable. But the issue is also present when using the current stark theme with core/modules/system/templates/time.html.twig:

  <pubDate>

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'core/modules/views/templates/views-view-field.html.twig' -->


<!-- THEME DEBUG -->
<!-- THEME HOOK: 'time' -->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/time.html.twig' -->
<time datetime="2023-09-26T12:55:17+02:00">Tue, 26 Sep 2023 12:55:17 +0200</time>

<!-- END OUTPUT from 'core/modules/system/templates/time.html.twig' -->


<!-- END OUTPUT from 'core/modules/views/templates/views-view-field.html.twig' -->

</pubDate>

I can confirm the workaround from #5:

  <pubDate>

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'themes/contrib/stable/templates/views/views-view-field.html.twig' -->



Tue, 26 Sep 2023 12:55:17 +0200


<!-- END OUTPUT from 'themes/contrib/stable/templates/views/views-view-field.html.twig' -->

</pubDate>

(Ignore the whitespaces. They are not present if theme debug is disabled.)

We are currently experiencing this in all of our Views Rest Exports (the ones with time fields, anyway) after upgrading from Drupal 9.5.11 to Drupal 10.1.5 and running `drush updb`. Looks like there is an update in the list that is likely the cause (highlighted text in attached screenshot).

#5 solves the issue, but since we are running headless, this affects a lot of our endpoints and is unfortunately causing a heck of a lift between identifying and manually editing all of the affected views

Same problem for me--updated to D10 and RSS feeds break. And the workaround in #5 fixes it.

Based on git blame it looks like the change was introduced in https://www.drupal.org/project/drupal/issues/2921810 🐛 Allow TimestampFormatter to show as a fully cacheable time difference with JS Fixed . Perhaps the Views RSS row formatter needs tweaking to exclude the <time> element.

#8 seems to point to the right issue, looking at the MR, this change was needed there:

    $this->assertEquals($date_formatter->format($this->testUsers[0]->getCreatedTime(), 'custom', 'Y'), $executable->getStyle()->getField(0, 'created'));

to

    $this->assertEquals($date_formatter->format($this->testUsers[0]->getCreatedTime(), 'custom', 'Y'), trim(strip_tags($executable->getStyle()->getField(0, 'created'))));

Which would indicate that new things got added to the output there.

We encountered the same issue in two projects that updated from core 9.5.11 to 10.x. We were able to hotfix this by enabling the Strip HTML tags (strip_tags) and Trim whitespace (trim_whitespace) options in the view.

@Dave Reid pointed me to this issue, which explains the occasional flooding of old blog posts on Drupal Planet.

Marking up <time> as code, since it is invisible otherwise :)

I guess we could apply the "fix" in comment #5 in RssFields::render. The date field doesn't have a formatter without the time element so we need to strip to get pubDate as plain text.

Stripping tags on the pubDate sounds logical, that shouldn't contain HTML

Added that as a fix and added test coverage

I tested the fix from #16. It seems to fix the problem and I didn't see any extra empty space either in my testing.

Probably makes sense to have a second review also and check the tests attached.

The test was showing the reported whitespace, so lets trim that too

Added a comment explaining why we are doing this

Great! I tested it myself the following way:

1. Removed the Strip tags and trim settings mentioned #10.
2. Verified that the time tag was in back in the feed.
3. Applied the patch.
4. Verified that time tag was removed.

I didn't encounter the whitespace issue when checking the actual feed so great that it was catched by the tests. Might have been a browser feature when checking the feed.

I vote this could be marked as RTBC.

Looks great! Thanks @Lendude and @HeikkiY.

Committed/pushed to 11.x and cherry-picked to 10.2.x, thanks!

Thanks everyone! There was another surge of old posts on Drupal Planet today, but from Drupal 10.2.1 it looks like this should be fixed.

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