As discussed in, for reasons of entity translation and entity access enforcement, we need to be rendering all base entity fields in Views using Field API formatters and the entity rendering pipleline, rather than using special-purpose Views handlers or generic Views data formatters. Views data formatters that are not entity-aware or that do not use the standard entity rendering pipeline simply don't get it right, and it's a critical issue because we need to respect entity access for all entity base fields.
This meta-issue exists to track the progress of converting all entity base fields to use Field API formatters.
One problem that occurs in this conversion is that the Field API formatters do not all have the same functionality as the Views generic formatters. For instance, the timestamp Entity field formatter, just renders out the date using
format_date(). Views itself allows you to configure basically everything:
$form['date_format'] = array( '#type' => 'select', '#title' => $this->t('Date format'), '#options' => $date_formats + array( 'custom' => $this->t('Custom'), 'raw time ago' => $this->t('Time ago'), 'time ago' => $this->t('Time ago (with "ago" appended)'), 'raw time hence' => $this->t('Time hence'), 'time hence' => $this->t('Time hence (with "hence" appended)'), 'raw time span' => $this->t('Time span (future dates have "-" prepended)'), 'inverse time span' => $this->t('Time span (past dates have "-" prepended)'), 'time span' => $this->t('Time span (with "ago/hence" appended)'), ), )' $form['timezone'] = array( '#type' => 'select', '#title' => $this->t('Timezone'), '#description' => $this->t('Timezone to be used for date output.'), '#options' => array('' => $this->t('- Default site/user timezone -')) + system_time_zones(FALSE), '#default_value' => $this->options['timezone'], );
So, we may lose some functionality when we convert. A secondary part of this issue is to avoid that by adding functionality to the Entity Field formatters so that they will match options available currently in the Views formatters that we need to not be using any more.
In the discussion on this issue, we decided that the correct resolution was to go ahead and switch to using Entity Field formatting, and live with lost functionality as a first step. This is necessary to enforce entity access on all entity fields, and to support translation properly. Since it involves entity access enforcement, all base fields that are not using entity-aware formatting need to be switched to using entity-aware formatting and this is a critical issue.
As a second step, we want to update the Entity Field formatters so that they support all of the options available in Views formatters. This is not as critical -- we can live with reduced functionality if we have to.
Here is a list of the Views formatters that (prior to any of this work) are being used for Entity base fields, what functionality is missing from the corresponding Field formatters, and the plans for replacing them. All of the base fields need to be switched to using entity-aware formatters (these are Critical issues). Replacing the missing functionality is not so Critical.
And there's an issue for making sure entity access is tested:
And a follow-up to make sure it's complete:
Outstanding issues (see below for details)
Here's the list of formatters to be replaced:
|Plugin, status||Where used||Missing functionality||Issues|
|Used in: EntityViewsData base class||Raw output (0/1), several options for the yes/no values, and the fully "custom" option.||
updated the formatter.|
- makes the base EntityViewsData use it.
||Used in EntityViewsData. Note that while NodeViewsData and other data classes have specific formats added as pseudo-fields, they are only for arguments (contextual filters), not field output, so we don't have to worry about them here.||Selecting a date format, custom date formats, time zone selection, time ago||
updated the formatter.|
- makes entities use it. Major
- language: \Drupal\views\Plugin\views\field\LanguageField, used in EntityViewsData
- node_language: \Drupal\node\Plugin\views\field\Language, used in NodeViewsData
- user_language: \Drupal\user\Plugin\views\field\Language, used in UserViewsData
- taxonomy_term_language: \Drupal\taxonomy\Plugin\views\field\Language, used in TermViewsData
|Link to entity, display language using native name||adds the formatting options, updates EntityViewsData to use formatter, and removes all three of these entity-specific plugins.|
||Used in EntityViewsData||None.||changes EntityViewsData to use field formatting.|
|numeric: \Drupal\views\Plugin\views\field\Numeric - in progress [Critical part is done]||
- Used in EntityViewsData both for regular numeric fields and Entity Reference fields.
- Used in FileViewsData for fields on file_usage table: id, count [not base entity fields!]
- Used in CommentViewsData for fields on comment_entity_statistics table: comment_count, last_comment_uid [not base entity fields!]
|Plural formatting, such as "1 thing" vs. "2 things"||
changed EntityViewsData to use field formatting.|
- Add settings for plural: , now closed as a duplicate of . This depended on , which in turn depended on ; both of those are done.
- Cannot convert non-base fields to use field formatting, so the rest are not issues.
Used in EntityViewsData both for regular text fields and Entity Reference fields.
Used in FileViewsData for fields on file_usage table: module, type [not base table!]
Used in CommentViewsData for fields comment_field_data.field_name, comment_entity_statistics.field_name [not base table!], comment_entity_statistics.entity_type [not base table!]
changes EntityViewsData to use field formatting.|
- for CommentViewsData use on comment_field_data.field_name
- Database fields that are not on base tables cannot use field formatting, so the others are not issues.
||Used in EntityViewsData, UserViewsData (signature field)||None.||
changes EntityViewsData to use field formatting.|
- is for where it is used in UserViewsData for the Signature field.
||These are used in NodeViewsData:
- node (fields: nid, title)
- node_type (fields: type) [entity bundle... not sure what to do with this, but it is probably OK?]
- node_link (pseudo-field: view_node)
- node_link_edit (pseudo-field: edit_node)
- node_link_delete (pseudo-field: delete_node)
- node_path (pseudo-field: path)
- node_bulk_form (pseudo-field: node_bulk_form)
- node_revision (field: title on node_revision)
- node_revision_link (pseudo-field: link_to_revision on node_revision)
- node_revision_link_revert (pseudo-field: revert_revision on node_revision)
- node_revision_link_delete (pseudo-field: delete_revision on node_revision)
removes node handler for base table title field.|
- Post-2342045, the remaining plugins in NodeViewsData for fields are:
-- node_type (bundle field, not sure what to do with it, as it's not really an entity field).
-- Various link-related fields/plugins: node_link, node_link_edit, node_link_delete, node_path, node_revision_link, node_revision_link_revert, node_revision_link_delete. See .
-- node_bulk_form -- this appears to be entity-aware so is probably OK
-- node_revision: Critical [done]
- Post-2322949 and 2456599, the remaining link plugins that are still in NodeFieldData are:
These are probably fine to leave as-is. Search is not in the base entity tables. Revision links are not covered by the generic entity link plugins. Node path... probably not necessary but not really horrible to have. And the bulk form is its own thing too. So, this is done!
||Here's the list:
- user (fields: NodeViewsData - uid, UserFieldData - uid, CommentViewsData - uid)
- user_name (field: UserFieldData - name)
- user_mail (field: UserFieldData - mail)
- user_link_edit (pseudo-field: UserFieldData - edit_node, which despite the name is actually a link to edit the user)
- user_link_cancel (pseudo-field: UserFieldData - cancel_node, which despite the name is actually a link to cancel the user)
- user_data (pseudo-field: UserFieldData - data)
- user_bulk_form (pseudo-field: UserFieldData - user_bulk_form)
- user_roles (UserFieldData - roles_target_id in user__roles table - not on a base table)
- user_permission (UserFieldData - permission pseudo-field in user__roles table - not on a base table)
- Post-2342045, the base field plugins remaining in UserViewsData (as well as Node/Comment where they reference User) on base tables are:
-- user_mail: see Critical [done]
-- user_name: see Major [done]
-- user: see Major [done]
-- various link fields/plugins: view_user, user_link_edit, user_link_cancel - see but not sure if that will actually fix these. Probably not critical anyway since the worst is someone gets a link they shouldn't and it 403s on them.
-- user_data: This gets data from the "user_data" service. See -- decided this was OK as-is.
-- user_bulk_form -- this appears to be entity-aware so is probably OK
- aggregator_title_link: in AggregatorFeedViewsData and AggregatorItemViewsData for the title fields
- aggregator_xss: in AggregatorItemViewsData for the author and description fields
|The XSS plugin derives from the Views XSS base plugin. We would need to have XSS filtering available on a Field UI formatter.||
for aggregator_title_link - Major [done]|
- for aggregator_xss formatter - Major [done]
- comment: Used in CommentViewsData for fields subject, cid
- comment_username: Used in CommentViewsData for field name
- comment_link: Used in CommentViewsData for pseudo-field view_comment
- comment_link_edit: Used in CommentViewsData for pseudo-field edit_comment
- comment_link_delete: Used in CommentViewsData for pseudo-field delete_comment
- comment_link_approve: Used in CommentViewsData for pseudo-field approve_comment
- comment_link_reply: Used in CommentViewsData for pseudo-field replyto_comment
- comment_depth: Used in CommentViewsData for field thread
- comment_last_timestamp: Used in CommentViewsData for field last_comment_timestamp [this is on comment_entity_statistics, not on base entity table]
- comment_ces_last_comment_name: Used in CommentViewsData for field last_comment_name [not base table]
- comment_ces_last_updated: Used in CommentViewsData for field last_updated [not base table]
- Post-2342045, the Comment module base field plugins remaining in CommentViewsData on base tables are:
-- 'comment', used on comment_field_data.subject, comment_field_data.cid; 'comment_depth' used for comment_field_data.thread. Issue: Critical [done]
-- 'comment_username' used for comment_field_data.name - Issue: Critical [done]
-- various link fields/plugins: comment_link, comment_link_edit, comment_link_delete, comment_link_approve, comment_link_reply - see but not sure if that will actually fix these. Probably not critical anyway since the worst is someone gets a link they shouldn't and it 403s on them.
- block_content: Used in BlockContentViewsData for field id on base table, info on field data table
- block_content_type: Used in BlockContentViewsData for field type on field data table
- file: In FileViewsData for fields fid, filename
- file_uri: In FileViewsData for field uri
- file_filemime: In FileViewsData for field filemime
- file_extension: In FileViewsData for field extension
- file_size: In FileViewsData for field filsize
- file_status: In FileViewsData for field status
|Probably not?||Critical [done]|
||Used in TermViewsData:
- term_edit_link - field edit_term
- taxonomy - field name
- Post-2342045, the remaining plugins in TermViewsData for fields are:
-- 'taxonomy', used in taxonomy_term_field_data.name Critical [done]
-- Various link-related fields/plugin: term_link_edit. See but not sure if that will actually fix this. Probably not critical anyway since the worst is someone gets a link they shouldn't and it 403s on them
- 'term_name' - which derives from an entity-aware plugin, so it's OK
- content_translation_link (Used in pseudo-fields called translation_link in: NodeViewsData, UserViewsData, BlockContentViewsData, CommentViewsData, TermViewsData)
- xss (used in fields: NodeViewsData - revision_log, AggregatorFeedViewsData - description, BlockContentViewsData - revision_log)
- search_score (fields: NodeViewsData - node_search_index.score) [not an Entity field, cannot use Field rendering]
entity_label (fields: FileViewsData - file_usage.entity_label) [not an Entity field, cannot use field rendering]
- content_translation_link -- see
Probably not critical anyway since the worst is someone gets a link they shouldn't and it 403s on them|
- AggregatorFeedViewsData use of xss -
- Other uses of xss -
User interface changes
Entity fields will be formatted using Entity rendering in Views. Entity fields in and out of Views will have more formatting options available, and they'll be consistent with what is available in Views for base data fields.