Problem/Motivation

I need to set a custom "Date format" for a field in a "REST export" display in a view.

Screenshot of /admin/structure/views

Changed"

Steps to reproduce

  1. Create a view with a "REST export" display.
  2. Use "Show: Fields"
  3. Add a date field, like "Content: changed"
  4. Configure the field with "Date Format: Custom" and any "Custom date format"
  5. Preview the view. Observe that the custom date format is ignored. Observe that the custom date format is wrapped in an unwanted HTML time tag.
  6. Do the same with a "Page" display.
  7. Observe that the custom date format is not ignored on the page.

Or you can simply import the exported views config I have attached.

Proposed resolution

The "REST export" display should not wrap field values in HTML tags.

Also, when using the "U" date format, I would expect the output to be an integer rather than a string.

None yet.

Remaining tasks

TODO

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TODO

CommentFileSizeAuthor
#13 3418845-nr-bot.txt2 KBneeds-review-queue-bot
#2 view-rest-export-custom-format-2.png27.92 KBakhil babu
#2 view-rest-export-custom-format-1.png27.56 KBakhil babu
views.view_.test.yml6.19 KBrudolfbyker
Screenshot from 2024-02-02 11-22-14.png51.81 KBrudolfbyker
Screenshot from 2024-02-02 11-15-19.png33.27 KBrudolfbyker

Issue fork drupal-3418845

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

rudolfbyker created an issue. See original summary.

akhil babu’s picture

akhil babu
he/him
commented
StatusFileSize
new view-rest-export-custom-format-1.png27.56 KB
new view-rest-export-custom-format-2.png27.92 KB

Thanks for the detailed issue decsription. I tried to recreate this issue with the given view configuration in Drupal 10.2.2 & Drupal 11 versions and these are the observations.

If custom date format is selected and 'U' is given as the format, Timestamp value of the date appeares correctly in the response.
https://www.drupal.org/files/issues/2024-02-05/view-rest-export-custom-format-1.png
If another custom date format is used (Eg: m/d/Y), date gets correctly formated in the response.
https://www.drupal.org/files/issues/2024-02-05/view-rest-export-custom-format-2.png

So, the date appears in the configured format (I am not sure why it is enclosed within <time> tags) in the REST export.

lendude’s picture

lendude
Primary language Dutch
Location Amsterdam
commented

Feels similar to #3383219: Views RSS Feed Fields adds <time> tag. and probably also caused by #2921810: Allow TimestampFormatter to show as a fully cacheable time difference with JS

Version: 10.2.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

rudolfbyker’s picture

rudolfbyker
Primary language Afrikaans
Location South Africa
commented
Title: Views do not respect "Date format" setting in a "REST Export" display » Dates are always wrapped in a <time> HTML tag in a Views "REST Export" display
Issue summary: View changes

@Lendude those issues look similar, indeed, but they are marked as fixed, while I can still reproduce this issue by importing the attached `views.view.test.yml` file into a fresh Drupal 10.3.2 instance.

@akhil babu you are correct. With the latest Drupal version, the "Date format" is respected, but the whole thing is still wrapped in HTML. I'll update the title and description of this issue.

Partial workaround: Enable "Strip HTML tags" and "Remove whitespace" under "Rewrite results" when configuring the views field. The only problem is that it's still a string instead of an int when using "U" as the "Date format".

rudolfbyker’s picture

rudolfbyker
Primary language Afrikaans
Location South Africa
commented
Issue summary: View changes
steven snedker’s picture

steven snedker commented

@rudolfbyker has correctly identified a bug that should be squashed.

When exporting your nodes as json, you'd probably want to be able to easily export your dates in some easily machine-readable format.

For a project I'm currently working on
05.12.2024 - 17:11
is WAY superior to
<time datetime="2024-12-05T17:11:05+01:00">05.12.2024 - 17:11</time>\n

Silly workaround that works for me, but should only be temporary:
In the view, configuring the date fields: rewrite the result. Remove HTML tags and trim it to 18 characters (no ellipsis).

Another workaround:
Ask for "raw output" at Format - Fields - Config.
This will give you a timestamp, no HTML.

The correct solution:
Configuring the field, you should be able to set Formatter as "raw/no html markup"

niranjan_panem made their first commit to this issue’s fork.

niranjan_panem opened merge request !11062

niranjan_panem’s picture

niranjan_panem commented

Removed the tag for unix timestamp in views rest export, below is the patch for it.
tag removed code

niranjan_panem’s picture

niranjan_panem commented
Status: Active » Needs review
steven snedker’s picture

steven snedker commented

@niranjan_panem the patch in #10 is probably better than nothing, but it's not a long term useful solution.

Before patching:
Ask for "raw output" at Format - Fields - Config. This will give you a timestamp, no HTML.

After patching:
Ask or Custom: U at Date Format. This will give you a timestamp, no HTML.

What we need is
The correct solution:
Configuring the field, you should be able to set Formatter as "raw/no html markup"
Default/Time Ago just doesn't cut it as formatting options.

needs-review-queue-bot’s picture

needs-review-queue-bot commented
Status: Needs review » Needs work
StatusFileSize
new 3418845-nr-bot.txt2 KB

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.