Skip to main content
Commonmark migration
Source Link

I posted the following as a bug report to Drupal Core

When a custom entity is created, and one of the fields is a datetime FieldType, views filters are not treating this field like a datetime field, but, instead, like a string. Timestamp Fieldtypes on the other hand are presented with the correct filter options.

The response I received was:

Yes, it does default to a string. I think the underlying reason is this:

 

Datetime support comes from the datetime module, so if you want your entity to use that, add a dependency to datetime and override any defaults for your entity in an extension of \Drupal\views\EntityViewsData.

 

The Views 'date' filter only works for timestamps (hence your timestamp fields work out-of-the-box), so just setting the filter plugin_id to 'date' won't help either.

 

So this works as designed I think.

I posted the following as a bug report to Drupal Core

When a custom entity is created, and one of the fields is a datetime FieldType, views filters are not treating this field like a datetime field, but, instead, like a string. Timestamp Fieldtypes on the other hand are presented with the correct filter options.

The response I received was:

Yes, it does default to a string. I think the underlying reason is this:

 

Datetime support comes from the datetime module, so if you want your entity to use that, add a dependency to datetime and override any defaults for your entity in an extension of \Drupal\views\EntityViewsData.

 

The Views 'date' filter only works for timestamps (hence your timestamp fields work out-of-the-box), so just setting the filter plugin_id to 'date' won't help either.

 

So this works as designed I think.

I posted the following as a bug report to Drupal Core

When a custom entity is created, and one of the fields is a datetime FieldType, views filters are not treating this field like a datetime field, but, instead, like a string. Timestamp Fieldtypes on the other hand are presented with the correct filter options.

The response I received was:

Yes, it does default to a string. I think the underlying reason is this:

Datetime support comes from the datetime module, so if you want your entity to use that, add a dependency to datetime and override any defaults for your entity in an extension of \Drupal\views\EntityViewsData.

The Views 'date' filter only works for timestamps (hence your timestamp fields work out-of-the-box), so just setting the filter plugin_id to 'date' won't help either.

So this works as designed I think.

added 284 characters in body
Source Link
Kevin Nowaczyk
  • 1.4k
  • 3
  • 13
  • 37

Here isI posted the following as a bug report to Drupal Core

When a custom entity is created, and one of the fields is a datetime FieldType, views filters are not treating this field like a datetime field, but, instead, like a string. Timestamp Fieldtypes on the other hand are presented with the correct filter options.

The response I received from the Drupal Development teamwas:

Yes, it does default to a string. I think the underlying reason is this:

Datetime support comes from the datetime module, so if you want your entity to use that, add a dependency to datetime and override any defaults for your entity in an extension of \Drupal\views\EntityViewsData.

The Views 'date' filter only works for timestamps (hence your timestamp fields work out-of-the-box), so just setting the filter plugin_id to 'date' won't help either.

So this works as designed I think.

Here is the response I received from the Drupal Development team:

Yes, it does default to a string. I think the underlying reason is this:

Datetime support comes from the datetime module, so if you want your entity to use that, add a dependency to datetime and override any defaults for your entity in an extension of \Drupal\views\EntityViewsData.

The Views 'date' filter only works for timestamps (hence your timestamp fields work out-of-the-box), so just setting the filter plugin_id to 'date' won't help either.

So this works as designed I think.

I posted the following as a bug report to Drupal Core

When a custom entity is created, and one of the fields is a datetime FieldType, views filters are not treating this field like a datetime field, but, instead, like a string. Timestamp Fieldtypes on the other hand are presented with the correct filter options.

The response I received was:

Yes, it does default to a string. I think the underlying reason is this:

Datetime support comes from the datetime module, so if you want your entity to use that, add a dependency to datetime and override any defaults for your entity in an extension of \Drupal\views\EntityViewsData.

The Views 'date' filter only works for timestamps (hence your timestamp fields work out-of-the-box), so just setting the filter plugin_id to 'date' won't help either.

So this works as designed I think.

Source Link
Kevin Nowaczyk
  • 1.4k
  • 3
  • 13
  • 37

Here is the response I received from the Drupal Development team:

Yes, it does default to a string. I think the underlying reason is this:

Datetime support comes from the datetime module, so if you want your entity to use that, add a dependency to datetime and override any defaults for your entity in an extension of \Drupal\views\EntityViewsData.

The Views 'date' filter only works for timestamps (hence your timestamp fields work out-of-the-box), so just setting the filter plugin_id to 'date' won't help either.

So this works as designed I think.