Creating Custom Drupal Views With Exposed Filters
Drupal Views turns stored content into useful listings without requiring a custom controller for every page. With the right fields, relationships, sort rules, and exposed filters, a site can provide searchable directories, filtered resource libraries, event calendars, product catalogues, or administration reports that editors can maintain through the Drupal interface.
A well-designed view is more than a list of nodes. It defines how visitors find information, how empty results are handled, how filters appear on mobile, and how URLs can be shared. These details matter for Australian websites as much as for any other market: a community organisation in Brisbane may need suburb filtering, while a national service directory may need state, postcode, and availability options.
| View requirement | Useful Drupal configuration | Typical result |
|---|---|---|
| Search by phrase | Exposed title or full-text filter | Keyword search field |
| Narrow by topic | Exposed taxonomy term filter | Category dropdown |
| Find local content | Exposed state, suburb, or postcode field | Location-based listing |
| Restrict by time | Date filter with exposed controls | Events or archive search |
| Display related data | Relationship and contextual filter | Author, department, or venue details |
| Keep results shareable | AJAX disabled or query settings retained | Filtered URL |
Planning The View And Its Data
Begin with the information visitors need to locate, rather than with the display style. A useful content model might include a content type called “Service”, taxonomy vocabularies for “Category” and “State”, and fields for suburb, opening hours, contact details, and service status. Views can expose filters reliably only when the underlying values are structured consistently.
Free-text fields are convenient for editors but difficult to filter accurately. If one node contains “Melbourne”, another says “Naarm”, and a third uses an abbreviated suburb, a location filter will produce confusing results. Taxonomy terms, entity reference fields, and dedicated list fields are generally better for predictable filtering. This is especially important for organisations serving areas such as the Northern Beaches, regional Victoria, or remote Western Australia.
In the administration menu, go to Structure, Views, and select Add view. Choose the base table that matches the content you want to display, usually Content for a node listing. Set a meaningful name, choose whether the view creates a page or block, and select an initial display such as Unformatted list, Grid, or HTML list. A page display gives the view a path such as /services, while a block display allows the same results to appear in a landing page or sidebar.
Useful Planning Checks
- Which content type should be included?
- Which fields require controlled values?
- Should visitors filter published content only?
- What should appear when no results match?
Give the view a clear machine-readable path and a human-friendly title. A title such as “Find a Service” is more useful to visitors than an internal label like “Service View 1”. If the website has separate content for New South Wales and Queensland, decide whether one national view with a state filter is more maintainable than several nearly identical views.
Adding Fields And Relationships
The Fields section controls what visitors see in each result. Add a title, image, summary, category, location, and link to the full content where appropriate. The order matters: a result should communicate its purpose quickly, particularly on a phone. A short summary is usually more useful than a full body field, which can create long and inconsistent cards.
When using a field in a view, Drupal offers options such as excluding it from display, rewriting its output, linking it to the entity, and trimming long text. Excluding a field does not remove it from the query; it can still be used to build a combined result. For example, a view can use a hidden category field to create a CSS class or use a hidden date field for sorting.
Relationships allow a view to access data stored in another entity. A content item may reference a venue, organisation, author, or department, and a relationship can expose the referenced entity’s name or address. Enable the relationship before adding fields from that entity. If a result appears multiple times, the relationship may be producing duplicate rows; use aggregation, distinct query settings, or a more precise relationship configuration to correct it.
Views has a powerful rewriting feature for fields. A title can be wrapped in a custom link, a status value can be converted into a label, and a field can be combined with static text. Use this carefully. Excessive rewriting can make a view difficult to maintain and may create accessibility problems if links lack meaningful text. Keep the original field where possible and use a Twig template for complex markup.
For a renovation information directory, a filtered content listing might include articles about flooring, preparation, and maintenance. A result can link to a laminate installation guide alongside other practical resources, provided the content fits the site’s editorial purpose and the link is reviewed as part of normal content governance.
Configuring Exposed Filters
A filter becomes visitor-controlled when its Expose this filter to visitors option is enabled. Common choices include Content: Title, Content: Published, taxonomy term fields, author, and date fields. For a service directory, expose category and state. For an events view, expose event type and date range. For a resource library, expose topic, audience, and keyword.
Taxonomy filters can appear as select lists, autocomplete fields, checkboxes, or links, depending on the filter plugin and available contributed modules. A select list is compact and familiar, but checkboxes make several simultaneous choices easier to understand. Autocomplete is useful when a vocabulary contains hundreds of suburbs or organisations. Avoid presenting a massive unfiltered dropdown to a visitor on a mobile connection in regional Australia.
The filter operator determines whether multiple selections use AND or OR logic. OR logic is usually expected when a visitor selects “Sydney” and “Newcastle” and wants results from either location. AND logic is appropriate when each selected condition must be true, such as content tagged with both “Flood preparation” and “Insurance”. Test this behaviour with real data because labels do not always make the operator obvious.
Set a descriptive label, a useful placeholder, and a sensible default value. “All states” is clearer than an empty select box. For dates, decide whether visitors need an exact date, a range, or relative options such as “upcoming”. Drupal’s date filters can be less intuitive when time zones are involved, so check the site timezone and content date storage. A Sydney event should not disappear early because the site is configured to UTC without considering Australian daylight saving.
Filter Choices That Usually Work
- Keyword search for titles and summaries
- Taxonomy selection for category or service type
- State, suburb, or region for local discovery
- Date range for current and upcoming content
Use the filter criteria preview while building the view, but do not rely on preview results alone. Test published and unpublished content, missing field values, duplicate taxonomy terms, long titles, and terms with apostrophes or accented characters. A view that works with six sample nodes can behave very differently after several thousand records are imported.
Improving URLs, Performance, And Accessibility
Exposed filters can add query parameters to the page URL, allowing users to bookmark or share a filtered result. A URL such as /services?state=Victoria&category=training is useful to staff, campaign teams, and support workers who regularly send specific search results. Configure the exposed form so that the submit button has an explicit label such as “Apply filters”, and decide whether a reset button should be visible.
AJAX can update results without a full page reload, but it is not automatically the best choice. It may make the interface feel quicker on a fast connection, while a complete page request is often easier to debug, cache, index, and share. If AJAX is enabled, verify that the exposed form still works with keyboard navigation, browser history, screen readers, and JavaScript disabled.
Performance depends on the query, the number of relationships, and the amount of data returned. Limit the pager to a sensible number of items, avoid adding every available field, and use indexed fields for frequent filters. A view listing thousands of nodes with several taxonomy joins can become expensive. Drupal caching helps repeated requests, but personalised or rapidly changing results need careful cache metadata.
Accessibility should be checked in the rendered page rather than assumed from the configuration screen. Labels must be visible or programmatically associated with controls, focus should move logically, and result cards should have useful link text. Do not rely on colour alone to show a status such as “Open” or “Closed”. A clear heading, result count, and empty-state message help users understand what happened after submitting a filter.
Troubleshooting Empty And Incorrect Results
An empty result can come from several different causes. The view may be restricted to the wrong content type, the content may be unpublished, or the selected field may contain no value. Check the filter criteria and access settings first. If the view has a relationship, temporarily remove it to see whether the join is excluding items without a referenced entity.
Date filtering causes frequent surprises. “After” and “before” conditions may exclude the boundary date, while an event stored as a date range may need separate start and end field logic. For upcoming events, filter on the event start date rather than the node creation date. Review the site’s configured timezone and test around midnight, especially when content is managed by teams in Perth, Adelaide, and the eastern states.
Duplicate rows usually indicate a multi-value field or relationship. A node tagged with three terms may appear three times when the view joins all term records. Enable DISTINCT query behaviour where suitable, use aggregation for grouped results, or revise the display so the multi-value field is rendered once. Be cautious with DISTINCT when sorting by related fields, because database behaviour can vary.
Exposed filters may appear correct but return unexpected results when the wrong field is selected. A filter on a rendered label is different from a filter on the stored entity reference ID. Likewise, a taxonomy filter may use a parent term without automatically including child terms. Test hierarchical vocabularies deliberately and decide whether selecting “Victoria” should include every regional term beneath it.
When a view is embedded as a block, check whether the page or block has additional contextual filters. A contextual filter can silently restrict results based on the current node, user, or URL segment. The View preview’s query information and SQL query display, available in development environments, can help identify unexpected joins and conditions. Avoid exposing query details on a public production site.
Reusing And Maintaining Custom Views
A single view can provide several displays for different purposes. The page display may offer a full directory with exposed filters, while a block display shows three featured results on the homepage. Keep shared filters and fields in the master configuration, then override only what differs. This reduces duplication and makes later changes safer.
For editorial teams, document what each filter means and how vocabulary terms should be assigned. A short internal note can prevent editors from creating near-duplicate terms such as “Community services”, “Community Service”, and “Community support”. On a large Australian organisation’s website, consistent state and regional naming is particularly valuable when content is shared between local offices.
Use configuration management to move view changes between development, staging, and production. Export configuration with Drush or the Drupal administrative interface, review the YAML changes, and test on a staging copy before deployment. A filter that depends on a taxonomy term, field machine name, or contributed module must exist in the target environment.
Review the view after major content model changes and Drupal core or module updates. Confirm that exposed controls retain their labels, translated terms remain available, caching behaves correctly, and the result markup still matches the site theme. With disciplined content modelling and realistic testing, custom Drupal Views with exposed filters can provide a fast, maintainable search experience for both national audiences and local users looking for services close to home.