---
title: "Why the Rebuilt Module Hid Its Competition and Find-a-Team Filters"
canonical: https://dxdev.com/blog/the-missing-filters-were-a-drifted-default/
datePublished: 2026-07-01
---
The wrench dialog said the competition and find-a-team filters should be showing on the rebuilt module. On the live test site, they weren't. Nothing in the rendering code was broken. Three layers disagreed about one default value.

We were reworking the module after feedback: restore those missing filters, make every view tab and search tool available by default, add a Location Search option, fix a wrench checkbox that would not save when unchecked, [remove the Display Type toggle](/blog/desktop-hidden-ui-bug-verify-before-coding/), and rename the module. The missing filters were the exact regression the rebuild was supposed to close, and it was still open on the site we were about to hand back for review.

We started with the filters. We would find the code that renders them and work out why they had stopped.

## The renderer was fine

The rendering code for both filters was fine. The regression was one level up, in what each part of the system believed the default should be.

- A shared options library set one default.
- The wrench dialog's apply logic wrote a different one when it saved a change.
- The display template that showed the current setting back to the admin assumed a third.

Three places, three answers, and none of them was wrong on its own. Change any one of the three in isolation and the filters would look fixed on whichever screen you were staring at, while staying broken everywhere the other two mattered.

## The fix that would have looked right

The fast fix was sitting right there: [hardcode the filters back on in the renderer](/blog/back-out-partial-fix-dont-ship-misleading/) and close the ticket. It would have worked, on that one screen. It also would have left the disagreement in place for whoever next touched the wrench dialog or the options schema, with no reason to expect three sources of truth for one setting.

The fix we made aligned the default across the options library, the wrench's apply logic, and the display template. Then we checked that the admin screen, the wrench dialog, and the live module all agreed at once. The Location Search addition, the checkbox save bug, the Display Type removal, and the module rename went into the same pass. All of it was verified end to end on the test site before the branch was committed.

## One screen only tells you about one layer

Reading the renderer, or testing one dropdown, would have confirmed the fix looked right without ever showing that two other layers still disagreed. The only way to know the setting was fixed was to trace it through every place that defined or read it and confirm they told the same story.

The filters were never broken. The system couldn't agree with itself about what "on" meant, and nothing forced it to check until we looked in all three places at once. When a setting looks broken on one screen, find where it is defined, saved and displayed, and confirm all of those agree before you close the ticket.