Admin search gives every setting result of an extension the id "<extension>-[object Object]"

Closed Beginner friendly
  • Is something wrong?
#5,362 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@imorland is already working on this.

Since Nov 1, 2026.

  • #5385 by @imorland — merged

Assessment

Difficulty
2/5
Estimated time
Under an hour
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
react, typescript
Domain
frontend

Research direction

The bad id comes from the lookup() method in framework/core/js/src/admin/components/GeneralSearchSource.tsx, around line 116. Read how setting is typed there, then use its key property instead of the whole object when building the id. Add a case to GeneralSearchSource.test.ts with two matching settings from one extension, and check that their ids differ. Done when the rendered li shows an id like flarum-likes-flarum-likes.like_own_post. Nearby lines are changed by #5260 and #5294, so rebase before editing.

Written by the indexing model from the issue text.

Description

Current Behavior

In the admin search, every setting result of an extension gets the same id, for example flarum-likes-[object Object]. GeneralSearchSource.lookup() builds the id from the whole setting object instead of its key:

// framework/core/js/src/admin/components/GeneralSearchSource.tsx:116
const id = extensionId + '-' + ('setting' in setting ? setting : 'id' in setting ? setting.id : '');

setting is the registry's settings object here, so the string concatenation calls its toString(). The rendered result shows it:

<li class="GeneralSearchResult" data-index="general-flarum-likes-[object Object]" data-id="flarum-likes-[object Object]">

Nothing visibly breaks today. Keyboard selection in SearchModal falls back to the item's position, because parseInt('general-…') is NaN. But GeneralSearchResult.id, data-id and data-index aren't unique across an extension's settings, so anything that tells results apart by id gets the wrong answer. That includes extensions extending the search, tests, and future keying of the list.

Steps to Reproduce
  1. In the admin, open the search and type part of a setting label, for example like their own.
  2. Inspect the result's <li>. Its data-id is flarum-likes-[object Object].
  3. Search for anything that matches two settings of the same extension: both results have the same id.
Expected Behavior

Each result has its own id built from the setting's key, for example flarum-likes-flarum-likes.like_own_post.

Environment
  • Flarum version: 2.x (present on current 2.x)
Possible Solution
const id = extensionId + '-' + ('setting' in setting ? setting.setting : 'id' in setting ? setting.id : '');

A test in GeneralSearchSource.test.ts could assert that two matching settings of one extension get different ids.

Additional Context

#5260 and #5294 change the result's link a few lines further down, in the same function.

Dominant language
PHP
Stars
6.8k
Forks
892
Avg merge
23h 6m
Merged PRs (30d)
210

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from flarum/framework

All issues in flarum/framework

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.