Migrating to Exposed Filters with Configurable Views Filter Block
Overview
➡️ We render them as exposed filters inside a Views filter block, which is then treated as a standard Drupal block and uses Ingress module Block Flyout feature.
In the View:
Previous Implementation
Key Components
- Views + Facets module
- Custom Ingress module
- Custom JavaScript for:
- Flyout behavior of facet filters on mobile
- Managing filters rendered in a specific region
- Additional flyout logic for blocks
How It Worked
- Facets were rendered in a region (e.g., sidebar).
- On mobile:
- Custom JS intercepted the UI.
- Filters were transformed into a flyout panel.
- Logic for display and behavior was tightly coupled with:
- DOM structure
- Region placement
- Custom scripts
Limitations
- Heavy reliance on custom JavaScript
- Tight coupling between UI behavior and theme structure
- Difficult to maintain and extend
- Not fully aligned with Drupal’s configuration-driven approach
- Limited flexibility when reusing filters across displays
New Implementation
Key Components
- Facets module (updated capabilities)
- Views exposed filters
- Configurable Views Filter Block module
- Simplified Ingress module
Core Idea
In our Drupal implementation, we originally built a faceted search experience using the Facets module, combined with a custom module (Ingress) that injected JavaScript to control the mobile UI behavior—specifically, a flyout panel for filters.
Configuration Changes
1. Enable Facets as Exposed Filters
- Configure facets to work as Views exposed filters
- Attach facets directly to the target View display
2. Enable Exposed Form in Block
The Ingress module is now lighter, focusing only on UI behavior.
- Enable “Exposed form in block”
- This separates filters from the main view output
3. Use Configurable Views Filter Block
This refactor replaces a custom, JS-heavy solution with a configuration-driven, Drupal-native approach. By leveraging exposed filters and block-based rendering, we gain:
- Place the exposed filter form as a block
- Gain control over:
- Block placement
- Visibility conditions
- Theming
Changes in Ingress Module
Removed
- Custom JavaScript for:
- Detecting facet regions
- Transforming filters into flyout panels
- Managing DOM-based UI manipulation
Retained / Updated
- Flyout behavior now targets:
- A single block (Views filter block)
- Simplified JS:
- Only responsible for toggling block visibility
- No awareness of facets or regions
Result
- Cleaner separation of concerns:
- Drupal handles structure
- Ingress handles UI behavior only
UI Behavior (Mobile Flyout)
Before
- JS dynamically:
- Located facet elements in a region
- Rebuilt them into a flyout
Now
- A single block (filter block) is:
- Placed in the layout
- Wrapped in a flyout container
- JS simply:
- Toggles visibility of the block
Benefits of the New Approach
1. Drupal-Native Architecture
- Uses Views + blocks + configuration
2. Improved Maintainability
- Less custom JS
- Easier debugging
- Clear responsibility boundaries
3. Better Flexibility
- Filters can be:
- Reused across displays
- Repositioned via block layout
- No dependency on specific regions
4. Cleaner Theming
- Exposed filters follow standard theming patterns
5. Enhanced UX Consistency
- Flyout behavior is generic and reusable
Migration Notes
With the Configurable Views Filter Block module:
- Remove old facet region placements
- Removed custom JS tied to facet in a regions
- Enable exposed filters in the View
- Install and configure Configurable Views Filter Block
- Place the filter block appropriately
- Update Ingress JS to target the block instead of region
Conclusion
When upgrading existing implementations:
- Simpler architecture
- Better maintainability
- Greater flexibility
With recent improvements in the Facets ecosystem, we’ve refactored this approach to use Facets as exposed filters within Views, along with the Configurable Views Filter Block module. This change simplifies the architecture, improves maintainability, and aligns better with Drupal best practices.





