Drupal faceted search with Facets and Search API: when teams build it and why
Facets on Search API lets visitors narrow a result set by the attributes that matter to them, such as product category, price range, location, author or publication year. Teams build it when a catalog, directory or document library has grown past the point where a keyword box and a single sorted list are enough, and visitors start leaving because they cannot reach the one item they need. The Facets module adds filters to Search API results, and Search API Autocomplete adds autocomplete for Search API searches, as described on their Facets project page and Search API Autocomplete project page. Both are contributed modules, and Drupal and its GPL-2.0-or-later contributed modules carry no license fee, so the cost of this work sits in planning, configuration, indexing design, testing and ongoing maintenance.
The decision to build usually starts with a short audit of the content. Ask which fields visitors actually filter on today through site search logs, customer support tickets or sales conversations, and which of those fields are clean enough to index. A directory where categories are free text, or a document library where dates are stored in three formats, will produce facets that look correct and return wrong counts. Facets depend on the indexed fields in the Search API index, so the content model and taxonomy decisions made earlier in the project set the ceiling for what the filters can do. Confirm with your content owners which facets they will maintain over the next few years, because each facet becomes a permanent part of the interface and the index.
Expect the trigger for the project to be a mix of user experience and operations. Editors may want to publish new filter values without a developer, and the search team may want autocomplete to handle typos and partial product names. Before committing, check which search backend your hosting can support, since the database backend and an Apache Solr backend differ in their indexing and query behavior, and the choice shapes how many facets and how much traffic the site can handle. Ask your implementation partner for a written scope that names the facet types, the search backend and the acceptance tests for result counts, so the decision to build rests on measurable outcomes rather than on a general wish for better search.
What the Facets and Search API modules do
Filterable search in Drupal rests on two contributed projects that work as a pair. Search API defines what gets indexed and where it is stored, while Facets turns indexed fields into filters that visitors can click, and Search API Autocomplete adds suggestions as people type.
Search API indexes and servers
A Search API index is the set of content, fields and datasources that gets sent to a search backend, and a server is the configured connection to that backend. The index is where you decide which entity types and bundles are included, which fields are stored and how they are typed. Confirm which backends your version of Search API supports and whether your database backend version has the features your facet types need, because index design decisions are expensive to reverse once content is indexed.
Facet sources and fields
A facet is attached to a field that already exists in a Search API index, so each facet maps to one indexed field, not to a raw database column. Fields that are multi-valued, such as taxonomy references, need a deliberate choice about how values are counted and displayed. Check during design that every field a visitor will filter on is indexed as a filterable field with the right data type, since a facet cannot show a value the index does not hold.
Facet blocks and widgets
Each facet is rendered as a block placed in a region of a search page, and its widget controls how options appear, such as checkboxes, links, dropdowns or ranges. The widget and its processors decide how counts are shown, whether empty options are hidden and how selected values combine. Confirm the widget and processor options available in the current Facets release, since these change between versions and determine how much custom theming the interface will need.
Search API Autocomplete suggestions
Search API Autocomplete adds suggestions to a search box as the user types, drawing them from configured Search API searches. It is attached to a specific search view or page, so suggestions only reflect the indexed content and filters of that search. Plan which suggestion sources are allowed, how many suggestions are returned and whether suggestions respect the same access rules as results, because suggestions can expose titles that a visitor should not see.
Facet URLs and query state
Facets write active selections into the page URL, so a filtered result set can be bookmarked, shared and reloaded. This behavior depends on the URL processors and the search view's query handling, and it affects caching, analytics and how search engines treat filtered pages. Decide early which facet combinations should be indexable and which should be blocked from search engines, and confirm the URL processor settings in the module documentation before building page templates around them.
Solr or the database backend for faceted search
Facets does not compute results itself. It reads facet counts from whatever Search API server backs the index, so the backend choice shapes how every filter behaves. The Solr option sends indexing and queries to a dedicated search engine, while the Search API database backend stores the index in your existing Drupal database and answers queries with SQL. Both work with the Facets module, but they differ in what they need to run and where the load lands.
- Search engine role: Solr is a separate service that handles text relevance, faceting and filtering. The database backend relies on the same MariaDB, MySQL, PostgreSQL or SQLite instance that serves Drupal content.
- Feature depth: Solr offers a wider set of search features. Confirm which faceting and text options your chosen Search API backend supports before the design is locked.
- Index location: Solr keeps the index outside Drupal. The database backend keeps it inside the site database.
- Lifecycle: Solr adds a second system to upgrade and monitor. The database backend adds no extra service.
- Module support: Check the current Search API Solr and Search API database backend documentation for the Drupal version you run.
Check which backend your catalog's filter needs require before comparing performance.
Index size and facet counting are where the two backends diverge most visibly. A Solr index is built for search and holds term data in its own structures, which keeps the Drupal database lighter. The database backend writes index rows into the site database, so every indexed field, language and entity adds rows that backups and replication must carry. Facet counts depend on how each backend aggregates matching items, and counts can be expensive when many filters combine.
- Index footprint: Expect the database backend to grow the Drupal database with each indexed field. Solr stores its index in its own data directory.
- Count accuracy under filters: Test that facet counts update correctly when several filters are active, on realistic data volumes.
- Multivalued fields: Categories, tags and attributes with many values increase index size on both backends.
- Translations: Each language multiplies index entries, so count the languages in the index scope.
- Reindexing: Plan how long a full reindex takes on your data volume and whether the site stays usable during it.
Ask the team to size the index from a test import of your real product or document data, not from the count of nodes alone.
Query speed under load depends on how many users filter at once and how large the catalog grows. A dedicated search engine is designed to serve many concurrent search and filter requests without competing with page rendering. The database backend answers searches inside the same database that handles logins, cart writes and content edits, so heavy search traffic can slow other parts of the site. Neither option is fast by default: caching, field choices and the number of facets shown all change response times.
- Shared resources: On the database backend, search queries share CPU, memory and connections with the rest of Drupal.
- Concurrency: Solr can be scaled separately from the Drupal web tier when search traffic rises.
- Facet count cost: Every visible facet adds work to each query. Limit facets per page and test the heaviest filter combinations.
- Caching: Confirm how page and facet caching interacts with filter state and cache invalidation on each backend.
- Load testing: Measure response times on a staging environment sized like production, with concurrent filter sessions.
No benchmark figures are given here. Ask for load test results on data similar to yours before choosing either backend.
The Solr option needs a separately hosted Solr service, so it adds infrastructure, configuration, patching and monitoring work that the database backend does not. The Solr page in this group covers index design, Solr version support and hosting Solr alongside Drupal. Teams should weigh that operational load against the performance and feature needs of their catalog, and budget for it in the quote.
- Separate service: Solr needs its own servers or containers, storage, network access from Drupal and a backup plan for its index.
- Upgrades: Solr and the Search API Solr connector each need version compatibility checks during Drupal upgrades.
- Monitoring: Solr adds its own health, memory and index metrics to the alerting scope.
- Database backend work: Search load and index growth become part of database capacity planning, backups and maintenance windows.
- Skills: Confirm which team members can run Solr configuration and troubleshoot it, or whether a partner will support it.
For Solr hosting details, see the Drupal search with Search API and Solr page in this group.
No single backend fits every catalog. The decision follows from the number of records, the number of filters that users combine, the traffic peak and the team's capacity to run another service. Smaller directories with modest filtering can often be served by the database backend, while large catalogs with heavy filtering and autocomplete may need a dedicated engine. Write the choice down with the test results and the operating model so later upgrades and audits can follow the reasoning.
- Catalog size: Compare record counts and indexed fields against your expected growth.
- Filter complexity: Count the facets and combinations users will need.
- Traffic profile: Identify peak search volume and whether it coincides with transactions.
- Team capacity: Decide who runs each service after launch.
- Exit path: Confirm that moving from one backend to the other is possible without rebuilding the front end.
Before the build starts, ask for a short proof of concept on your real data with both backends, and record the results alongside the decision.
Which facet types and settings fit which catalog
This table compares the main Facets configuration decisions for catalogs, directories and document libraries, with the indexing or interface cost of each. Read each row as a question to settle before the build starts, since most of these choices are hard to reverse once editors and visitors depend on them.
| Decision | Best fit | Trade-off and cost |
|---|---|---|
| Checkbox facets | Catalogs with a few discrete attributes such as brand, material or availability, where visitors pick several values | Easy to understand and fast to scan, but long lists need a limit or a show-more control, and each value adds a count query to every results page |
| Link facets | Browse-style navigation with a small set of mutually exclusive values, such as product category or document type | Simple to build and clear for single selection, but visitors cannot combine values, so it suits navigation more than refinement |
| Dropdown facets | Long value lists in narrow layouts, such as a location or department selector in a directory | Saves space and handles many values, but hides options from view and is less accessible for some users unless the labels and keyboard behavior are tested |
| Range slider facets | Numeric fields such as price, weight or dimensions where the value spread matters more than exact values | Requires a numeric field indexed as a suitable data type and careful handling of empty or outlier values, which adds configuration and testing effort |
| Date range facets | Document libraries and event or publication archives filtered by year, quarter or a custom window | Needs a date field indexed correctly and a decision on time zones and granularity; large date spans can produce many buckets |
| Hierarchical taxonomy facets | Large category trees, regional structures or nested document classifications | Needs taxonomy terms with stable parent-child structure and a plan for parent selection behavior; deep trees are harder to read on mobile |
| Multi-select behavior (OR versus AND) | OR within one facet suits catalogs where visitors compare brands or sizes; AND across facets narrows results | Choosing OR within a facet and AND across facets is a common pattern, but the logic must match how visitors search, and it should be confirmed in the Facets documentation for the version in use |
| Empty facet handling | Hide facets with no matching results in the current search for clean interfaces; show empty values only when visitors need to see what is missing | Hiding empty values reduces clutter but can hide options a visitor expects, and it adds per-request calculation on large result sets |
| Sort order | Alphabetical for directories and document types, by count for catalogs where popularity guides choice, or by a defined weight for ordered categories | Count-based sorting changes as results change, which can confuse visitors who expect a stable list; plan the sort per facet |
| URL aliasing | Public catalogs and document libraries where shareable, indexable URLs for filtered results matter for SEO and sharing | Aliases must be planned for each facet and value and kept stable through renames, which adds maintenance and needs redirect handling during changes |
| Autocomplete scope | Large catalogs where visitors type product or document names, with Search API Autocomplete limiting suggestions to chosen fields | Broad scope returns noisy suggestions and extra queries; narrow scope can miss terms, so testing with real search logs is needed before launch |
Preparing the index and fields for facets
Every facet starts as an indexed field on a Search API index, so the first decision is which entity fields feed the index and how each one is typed. A content type's plain text and string fields, taxonomy term references and entity reference fields each reach the index differently. Taxonomy term references should be indexed as entity references to the term ID and label, not as free text, because facets then count discrete terms and selecting one filters on an exact value. Check the field cardinality too: a multi-value field produces several values per item, and the facet counts those values, so an article with three tags contributes to three facet items. Decide before the build whether editors will pick from a controlled vocabulary or type free text, since free text fields that are indexed as text are tokenized and are usually unsuitable as facet sources without a separate string field.
Once fields are mapped, the index needs a reindex whenever the mapping changes, a term is renamed, or a referenced entity is edited in a way that changes its indexed values. Plan who triggers a full reindex after a release, how long it runs on the production data volume (confirm this with a staging run, since the duration depends on your content and backend), and whether the site can serve results from the old index in the meantime. Facet counts are the first thing editors and reviewers will question, so test them against real content rather than a few seeded nodes. Pick a sample of items for each facet, compare the count shown with the number of published items you expect to match, and repeat the check for multi-value and referenced fields, where counts are easiest to get wrong. Record the results so the same check can run after each module update.
How a faceted search build runs from index design to launch
The sequence moves from agreed search requirements through index design, backend choice, facet and autocomplete configuration, accessibility and performance testing, and a reindexed launch, with a written artifact closing each stage.
Inventory requirements and approve the facet map
Editors, product or records owners and the DeployOpen team list the searches users actually run, the filters they expect, and the content types each filter applies to. The output is an approved facet map that names each facet, its source field, its expected values, whether it is multi-select, and which pages or views it appears on. The step is done when the business owner signs off the map and the list of facets that are explicitly out of scope.
Design the search index and fields
Map each facet to a Search API index field, choosing the data type, tokenization and whether the value comes from an entity reference, taxonomy term or computed property. Decide which entity types and bundles go into each index and how translations, unpublished content and access checks are handled. The output is an index design document with a field table and a list of computed fields. It is complete when a developer can reproduce the index on a clean install from configuration alone.
Select the backend and hosting model
Compare the Search API database backend with a Solr backend against the facet count, document volume, query concurrency and the operations capacity your team has. The Drupal Search API with Solr module set is the usual path for larger catalogs, and Solr then runs as a service you host, back up and upgrade. The output is a written backend decision, a hosting diagram showing where Solr and Drupal connect, and a list of Solr version and Drupal compatibility checks to confirm against the module pages before build.
Configure facets, widgets and query behavior
Build the Facets blocks or views integrations for each approved facet, selecting the widget type, sort order, empty-value handling, hierarchy display and the URL alias pattern that keeps filtered pages indexable and shareable. Set default result counts and make sure the facet counts reflect the active filters you intend. The output is an exported configuration set and a short widget specification. The step closes when every facet in the approved map renders and filters correctly on the staging site.
Add autocomplete and query suggestions
Install and configure Search API Autocomplete on the indexed fields that users type into, choosing suggestion sources, minimum characters, result limits and whether suggestions respect the active facet filters. Test misspellings, stop words and multilingual terms against real content. The output is an autocomplete configuration and a list of queries with expected suggestions. It is done when the suggestion list matches the expected results for the agreed query set.
Test accessibility of facet widgets
Check each widget with keyboard-only navigation and a screen reader, confirming that checkboxes, links and dropdowns expose their state, that result count changes are announced, and that the filter summary and reset controls are reachable. Review color contrast and focus visibility on the theme the widgets use. The output is an accessibility test report listing each defect, its owner and its fix status. The step is complete when no open defect blocks completing a search or applying a filter.
Run performance tests on realistic data volumes
Load the staging index with a volume that matches production content, then measure query time, facet count time, indexing time and cache behavior under concurrent filtered searches, on the database backend or Solr as chosen. Record which facets drive the slowest queries and whether caching, indexing batch size or Solr resources close the gap. The output is a test plan and results report with the data set size and test scripts documented, so the numbers can be rerun before each release.
Launch with a full reindex and a rollback plan
Schedule the production cutover, run a full index build on production content, and confirm index counts against the source database before enabling the search pages for users. Keep the previous search route or backend available until the new index is verified, and document the cron or queue settings that keep the index current after launch. The output is a signed launch checklist, a verified index count record and a rollback procedure that the operations team has rehearsed.
Making facet widgets accessible to keyboard and screen reader users
Do Facets widgets work with a keyboard and screen reader out of the box?
Not reliably. The Facets module supplies the filtering logic and several widget types, but the markup, labels and announcements that assistive technology relies on depend on your theme and on how the widgets are built. Expect to review each widget type you use, including checkboxes, links, dropdowns and range sliders, and to test them with a keyboard and at least one screen reader before you call them accessible. Treat the default output as a starting point, not as a finished result.
How should facet groups be labelled for screen reader users?
Each facet should sit inside a named group, so a user hears the facet name, such as Category or Location, before the list of options. Use a fieldset with a legend for checkbox groups, or a labelled navigation or region landmark for link lists. Every option should announce its label and its count together, and the selected state should be exposed to assistive technology, not only shown by colour or a tick icon. Confirm the markup your chosen widget produces, then adjust the Twig templates in your theme where it falls short.
How do you make the selected filters visible and easy to remove?
Show active filters as a summary above the results, with each one as a real button or link that removes it, and label the control with the facet and value, for example "Remove filter: Category, Training". Keep the selected state visible without relying on colour alone. This work is custom theme and template effort, and it is usually the part of the build that users notice most. Ask any team quoting the work to show the selected state in both the default and high-contrast themes.
How do keyboard users move through facets and results without losing their place?
Every control must be reachable in a logical tab order, operable with the Enter or Space keys, and visibly focused. Facet widgets that load results through AJAX need deliberate focus management: after a filter is applied, focus should land on a predictable element such as the results heading or the first result, not reset to the top of the page. Test the full path from a facet to a result and back, because focus bugs usually appear at the boundary between filtering and the results list.
How are result counts and filter changes announced to screen readers?
Place the result count in a live region so that a screen reader announces the new total after each filter change, for example "42 results" or "No results match these filters". Keep the announcement short and avoid repeating it for every intermediate update. Autocomplete suggestions need the same care: the number of suggestions should be announced, and the list should support arrow-key navigation with the active option exposed to assistive technology. Check these announcements in the browser and screen reader combinations your users rely on.
How much effort does accessible facet work add to a Facets project?
It is custom effort in addition to the configuration of facets and the search index. The main cost drivers are the number of widget types, how much the theme differs from the core defaults, whether results update through AJAX, and how many autocomplete and filter states need checking. The work is usually one-time for the build, with recurring checks after module, theme and content changes. Ask any partner for the widgets and states in scope, the testing method, and whether the audit is included or separate.
How do you verify that facet widgets meet accessibility requirements?
Combine a manual check with keyboard only navigation and screen reader testing with an automated scan, then have an accessibility specialist audit the result. Automated tools catch missing labels and some contrast problems, but they cannot judge whether an announcement makes sense in context. Document which widgets, browsers and assistive technologies you tested, and keep that record with your release notes. DeployOpen can prepare these checks as part of a scoped engagement, but the conformance judgement sits with your auditor or accessibility specialist.
Who owns accessibility fixes after the facets go live?
Your team or your support partner owns them after launch, because every new facet, widget or theme change can reintroduce a problem. Agree on who reviews changes to facet templates, who runs the keyboard and screen reader checks on each release, and where accessibility defects are logged. Keep the widget markup in your custom theme under version control so fixes are traceable and survive Drupal and module upgrades. Confirm this ownership in writing before the build closes.
What drives faceted search effort and how to keep it down
This table lists the factors that most change the build and run effort for Facets on Search API, with the direction each one moves cost or duration and a way to contain it. Read it before scoping, because most of the savings come from deciding which facets users need and how many indexes the site really requires.
| Driver | Effect on cost or duration | How to keep it down |
|---|---|---|
| Number of facets | Each facet adds field mapping, a widget, query processing and testing, so effort rises with every addition | Limit the first release to facets tied to validated user tasks and add others after search log review |
| Content volume and indexed fields | Larger indexes lengthen initial indexing and reindexing after schema changes, and raise hosting load | Index only published, searchable entities and fields used for filtering or display |
| Hierarchical taxonomies | Nested terms need hierarchy handling, depth limits and widget choices that take extra configuration and testing | Cap hierarchy depth, flatten where users do not need the tree, and agree the term display rules early |
| Custom widgets and processors | Bespoke widgets and processors are custom code to build, test and maintain through Drupal upgrades | Start with the widgets Facets provides and justify each custom widget against a named user need |
| Solr hosting versus database backend | Solr adds a separate service to provision, secure, patch and monitor, while the database backend adds load on the Drupal database | Confirm expected result volume and traffic, then choose the backend in writing before the build starts |
| Multilingual indexes | Each language adds translated field values, stemming and facet labels, and more test cases | Agree which languages are indexed and which facet labels are translated before design begins |
| Accessibility requirements | Keyboard operation, announced result counts and labeled filter groups need design and manual testing across browsers and assistive technology | Write facet widget accessibility criteria into the design brief and test with real assistive technology users where possible |
| Autocomplete scope | Search API Autocomplete adds suggestion sources, ranking and caching decisions that grow with the number of fields suggested | Limit suggestions to the fields users actually search and confirm response time with your team |
How faceted search connects to content, Solr and the rest of the platform
Facets only filter what the index holds, so the search design depends on what gets indexed, when, and from which backend. The cards below name the platform areas that feed or constrain a Facets and Search API build, and what to confirm with each before scope is fixed.
Solr hosting alongside Drupal
Facet performance and index freshness depend on whether the Search API server runs on the database backend or an Apache Solr backend hosted beside the site. A Solr cluster adds its own servers, patching, heap sizing, backups and version support to the platform. Confirm who operates Solr, which Solr versions your Search API connector supports, and where the index lives relative to Drupal web nodes. The related Drupal search with Search API and Solr topic covers the backend decision in depth.
Geofield proximity search
Directories and store finders often combine facets with a distance filter. Coordinates stored with Geofield must be indexed as a field the search backend can query, and distance sorting or radius filters are features to confirm for your chosen backend, not assume. Geocoding quality, address cleanup and map rendering are separate work items that affect what appears in results. See the related Geofield topic for storage and proximity design before you commit to a radius filter in the facet UI.
Content moderation and scheduled publishing
Search indexes follow entity state, so content in a draft, review or embargoed state may or may not appear in facet counts depending on how the index is configured. Content Moderation and Scheduler both change when a node becomes visible, which changes facet totals at publish time. Decide which states are indexed, how unpublished items are excluded, and who verifies counts after a scheduled release. The editorial workflow and scheduling pages cover the roles and timing rules.
Media and taxonomy data
Most facets are taxonomy references, so vocabulary design determines the filter list editors and users see. Hierarchical terms, term naming and deduplication affect facet readability, and media fields such as file type or document category need to be indexed as sortable values rather than raw IDs. Check whether referenced entities are indexed with their labels, and whether unpublished or unused terms should drop out of facet options. Asset handling is covered in the Media Library topic.
Caching and cron-driven indexing
Search API indexes items through queued processing that runs on cron or a dedicated runner, so a change in content may not reach facet results until the next batch completes. Page caches, facet block caches and reverse proxy rules can also show stale counts after an index update. Confirm the indexing batch size, the cron schedule, how cache tags invalidate facet blocks, and what a visitor sees during a reindex. Caching and queue behavior should be tested under realistic traffic before launch.
External search and CRM sources
Some catalogs pull records from a CRM, PIM or external service rather than from Drupal entities alone. Those sources need an import or sync step before they can be indexed, and their identifiers must stay stable so facet filters and bookmarked URLs keep working. Confirm the system of record for each field, the sync frequency, and how deleted or renamed records are removed from the index. The CRM and feed integration pages describe the connection options.
Questions teams ask before building faceted search
What drives the cost of a faceted search build?
The cost follows the number of indexes, facet types and data sources in the agreed scope, and the amount of testing that the facets need. Facets itself is a contributed module that is free to download under GPL-2.0-or-later, so the spend goes to people and infrastructure. Scope drivers include how many content types feed the index, whether facets need ranges, hierarchies or date widgets, whether autocomplete is required, and how much relevance tuning is expected. Recurring costs include hosting for the search backend and support for module updates. Ask any quote to split one-time build work from ongoing support, and to name the Drupal version, Search API and Facets releases it targets.
How long does faceted search take to build?
Duration depends on how well the content model is settled before development starts. Teams that already have clean fields, consistent taxonomy terms and a defined list of facets usually move faster than teams that still debate what a result means. The main timeline drivers are the number of facets, the search backend decision, the volume of test data for relevance checks, and the accessibility review of facet widgets. Ask for a timeline tied to written milestones in the fixed scope, and confirm which environment, data load and review steps the timeline includes.
What must our team provide before the build starts?
Three inputs prevent most rework: a content model, a facet list and representative test data. The content model names each field that becomes a filter, its type (for example, entity reference, list, boolean or date) and whether it is required. The facet list states each filter, its widget, its default sort, and what happens when a user selects several values. Test data should include realistic volume and edge cases such as empty fields, duplicate terms and very long labels. Provide a sandbox copy of production-like content so relevance and performance checks reflect real conditions.
Can our internal team build faceted search without a partner?
Yes, if your team has Drupal developers who can work with configuration, Search API indexes and custom theming, and a person who owns the search experience. Facets and Search API Autocomplete are contributed modules, so no license purchase is needed for the code. The harder parts are index design, query tuning, accessibility testing of facet widgets and keeping the setup stable through upgrades. Assess whether your team can handle those tasks in a sprint plan, and whether someone will maintain the work after launch. A partner is most useful when the scope is fixed and the deadline is firm.
Should we run facets on Solr or the database backend?
The database backend suits smaller catalogs with modest query volume and fewer facets, because it avoids running another service. Solr usually fits larger indexes, more complex text matching and heavier faceting, but it adds a service to host, secure, back up and upgrade. Solr setup also requires Search API Solr Search and a supported Solr version, so confirm version support against the module release you plan to use. Decide with a load test on your own data, and plan who operates Solr if you choose it.
How do Drupal upgrades affect Facets and Search API?
Facets and Search API must be checked each time Drupal core moves to a new major version, because contributed modules declare which core versions they support. Drupal 11 is the current major version, and it requires PHP 8.3 or later. Drupal 12 is scheduled for the week of December 7, 2026 and requires PHP 8.5 or later, so the search stack will need its own compatibility review then. Drupal 10 reaches end of life on December 9, 2026. Bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, so plan a regular update routine. Confirm module compatibility for your release on each project page before upgrading, and test facet configuration and index rebuilds in staging first.
Does faceted search raise security or compliance concerns?
Search indexes can expose content that users should not see, so access checks must match your permission model before facets are offered. Index only fields that are intended for search, and confirm that filters respect content moderation and role-based access. If your organization is subject to a compliance framework, ask the auditor which evidence of access control and logging they expect, because DeployOpen prepares controls and evidence but does not issue audit reports or certifications. Include search endpoints in the security testing scope.
How DeployOpen scopes and delivers faceted search
DeployOpen fixes the scope of faceted search in writing before any build starts. The written scope names the Search API index and its datasources, the backend (the database or a Solr server), each facet with its source field, widget type and default sort, the autocomplete behavior from Search API Autocomplete, and the accessibility checks that will be run against the rendered widgets. It also states what is out of scope, such as new content types, custom query processors or a change of backend after go-live. Because the page lists the facet inventory as a deliverable, the client can review it against real catalog or directory data before development begins, and changes to the inventory are priced through a written change request rather than absorbed into the original scope.
Delivery runs inside the client's own infrastructure, on their web servers, database and, where chosen, a Solr instance they operate. DeployOpen builds the index and facets as exportable configuration, so the same settings move from development to staging to production through the client's normal release process. Each facet is tested against the expected result counts, empty-state and multi-value behavior, and the reset path. Autocomplete is tested with the suggestion limits and minimum character settings agreed in scope. Facet widgets are checked for keyboard operation, labelled groups and announced changes to result counts, and the findings are logged against the scope so the client sees what passed, what was fixed and what remains a known limitation.
Handover includes the exported configuration, a facet and index reference document, a runbook for reindexing and cron-driven index updates, and the test scripts used for acceptance. Ongoing support, security updates for Facets, Search API and Search API Autocomplete, and upgrades to later Drupal versions are available as retainers, with the response expectations written into the retainer agreement. Before signing, ask DeployOpen to confirm which Drupal and contributed module versions the retainer covers and how indexing capacity will be reviewed as the catalog grows.
