Decision Use human-readable names as exposed filter identifiers in Views
acceptedContext and Problem Statement
When using exposed filters in Views, they are usually given default filter identifiers based on the field name (e.g., field_topic_target_id
). This can lead to lengthy and unreadable query strings in public-facing URLs, such as /my-view-path?field_topic_target_id=5
.
A significant issue arises when the underlying implementation of a filter changes, for example, by switching from Drupal core's taxonomy filter to a different plugin like taxonomy_entity_index
. This change can alter the filter identifier (e.g., from field_name_target_id
to taxonomy_entity_index_tid_depth
), which breaks any pre-filtered URLs that users may have saved as bookmarks. This highlights a need for a strategy to ensure exposed filter identifiers are consistent, maintainable, and user-friendly, reducing the risk of broken links and improving the clarity of URLs.
Decision
When configuring Views filters that are exposed for non-administrative (public-facing) Views, we will override the default filter identifier to use a shorter, user-friendly, and semantically consistent name .
Examples:
- Instead of using
field_topic_target_id
as the filter identifier, we will usetopic
. - For a filter on
field_event_date
, we will useevent_date
ordate
.
Consequences
- Reduced Broken Links: Bookmarked URLs or external links that include Views filters will be more resilient to backend changes in field names or filter plugin implementations. This helps prevent a poor user experience caused by broken links.
- Improved User Experience: Shorter, more descriptive, and consistent URLs are easier for users to understand, remember, and share . This enhances the overall usability of the site.