Fix #276: explore search results sections, landing page centering and search reset

[pieer]

Closes #276.

Fixes the three cases in the issue, plus a landing-page regression found while reproducing them.

1. The landing page was no longer vertically centered

The logo, heading and search bar were centered with height: 100% on the landing <main>, which only works when every ancestor has a definite height. #316 relaxed body from height: 100% to min-height: 100% so tall pages stop pushing the footer out of view (#242). With an indefinite body height, height: 100% resolved to auto, <main> shrank to its content, justify-content: center had no free space to distribute, and the block sat directly under the navbar.

Replaced the percentage height with flexbox, the same way #316 fixed the auth pages: .full.height already grows to fill the viewport via flex: 1 0 auto, so making it a flex column and giving the landing flex: 1 0 auto hands <main> a real height to center inside. flex-shrink: 0 keeps the old top-aligned behaviour on viewports too short for the content, so the page scrolls instead of clipping the logo.

Measured at 1456x836: the gap above and below the block went from 0px / 373px to 187px / 187px, with no viewport overflow.

2. Landing search went to the wrong tab (issue cases 1 and 2)

The landing form submitted to /explore/articles, while the search on /explore submits to /explore/subjects — the tab the navbar defaults to, and the one /explore itself redirects to. The same query produced a different page depending on where it was typed, and the landing one arrived on a page whose navbar shows no active tab and which renders no "Search results for ..." section.

Pointed the form at /explore/subjects and dropped three hidden inputs (only_show_relevant, sort=score, fork=0) that explore.Subjects never reads — sort=score isn't a valid subject sort and silently fell back to recentupdate. A landing search now produces exactly the ?q=... URL the explore subject search produces.

3. No "Search results for ..." / "Similar" on the users tab (issue case 3)

The users tab returned a bare list, or a bare "No matching results found.". It now splits results the way the subjects tab does.

• models: added SearchUserOptions.ExactMatchOnly, mirroring repo.FindSubjectsOptions.ExactMatchOnly. It swaps the keyword's LIKE for Eq on both lower_name and LOWER(full_name), so user1 stops dragging in user10..user18. The email condition stays a substring match on purpose — an email is never the thing a visitor typed the name of.
• routers: splitExactUserMatch runs the exact lookup as its own query rather than picking the match out of the current page. The list is paginated and ordered by name or sign-up date, not relevance, so the exactly-named user can sit on any page — someone searching "anastasia" should find her on the first one. Reusing the page's own options makes the lookup inherit every filter already applied (user type, active, visibility to the viewer, repo role), so it cannot surface a user the paginated list would have hidden. When the exact match also falls on the current page it is dropped from the "Similar" list; the pagination total is left alone so page boundaries stay stable.
• templates: custom/templates/explore/user_list.tmpl overrides the stock list. Row markup moved to custom/templates/shared/user/explore_item.tmpl, taking a dict rather than a bare user because Go rebinds $ to whatever each {{template}} call passes.

The split is gated on PageIsExploreUsers. /explore/organizations shares not just the handler but the template (explore.Organizations calls RenderUserSearch with tplExploreUsers), so without the gate an org listing would answer a search with "No user named exactly ..." — caught in review, fixed, and pinned by TestExploreOrganizationsKeepsPlainList. templates/admin/user/view.tmpl shares the handler too but sets no search data, so it renders the plain list exactly as before.

All exact matches are rendered, not just the first: lower_name is unique but full_name is not, so a name two accounts share would otherwise promote one arbitrarily and file its twin under "Similar".

4. Border framed the headings, not just the rows

The box came from .explore-users-list-container, which wraps everything the list template emits, so the new headings ended up inside it. Moved the border, radius, overflow and background onto an .explore-users-rows wrapper that only ever holds user rows; the headings and the no-exact-match note are siblings of those wrappers. A search renders two boxes — exact match and similar list — each framed on its own.

flex-list had to move onto the same element as the rows: the divider rule is .flex-list > .flex-item + .flex-item, a direct-child selector.

5. Clearing the search box now resets the page

Emptying the keyword field left the results on screen next to an empty search box. Clicking the field's own clear button (the x that <input type="search"> renders) did nothing at all — it produces an input event indistinguishable from typing, and no change until the field is left. Clearing by keyboard and pressing Enter did reload the list, but submitted q= and landed on ?q=&sort=alphabetically.

Now reset on both gestures:

• listen for search, which Blink and WebKit fire when the clear button or Escape empties the field (it bubbles, so one listener per form).
• intercept submit while the field is empty — the path Enter and the search button take, and the only one Firefox has, since it renders no clear button and does not implement search.

Both only intervene while the field is empty, so a real keyword still submits natively, and both drop only q — sort and filters are separate controls and survive. Dropping an empty q moved into a shared helper, so the existing filter/sort handler stops emitting a stray q= too.

Deliberately not hooked: input turning empty. Retyping a query starts by deleting the old one (step 2 of the issue's own repro), and navigating away on the last backspace would make the field unusable. Typing still just updates the tab links, so the keyword carry-over from #273 is untouched.

Testing

Verified in a browser against a throwaway instance seeded from a dev database:

case	result
landing search "forest"	lands on /explore/subjects?q=forest, Subjects tab active, "Search results for forest" renders
users pierre	exact pierre + Similar pierre_user
users PIERRE	same — case insensitive
users Ada Lorne	exact match on full name, no Similar section
users bubble	no-exact-match note + 11 similar
users anastasia	heading + "No matching results found." only
users, no keyword	unchanged plain list
clear button / clear + Enter	?sort=..., no q, full list, heading gone (users and subjects)
real keyword	still submits natively
type then clear without submitting	no navigation; tab links gain then lose q
change sort	still navigates, now without a stray empty q=

Also checked every rows box contains only .flex-item children, with headings as siblings outside.

TestSearchUsers gains four cases for ExactMatchOnly: username, full name, case folding, and a substring-only keyword matching nobody.

tests/integration/explore_user_test.go gains TestExploreUserSearchSplit (exact user promoted into its own box, "Similar" populated, the note for a substring-only keyword, no split without a keyword) and TestExploreOrganizationsKeepsPlainList (verified to fail without the users-tab gate). eslint, vue-tsc and stylelint are clean.

Note

The branch is based on a master that is 5 commits behind origin/master. It merges cleanly — the two overlapping files (models/user/search.go, custom/options/locale/locale_en-US.ini) received purely additive upstream changes in different regions, and ExactMatchOnly composes with the new ExcludeUserIDs / ExcludeOwnersOfSubjectID conditions as independent AND-ed clauses.

🤖 Generated with Claude Code

[pieer]

/review

---

AI review started.

[github-actions]

Advanced AI Review

• Type: Agentic (crush)
• Model: glm-5.3

Click to expand review

Review

I read the full files touched by the diff (routers/web/explore/user.go, models/user/search.go, both new templates, the CSS, explore-search.ts) plus every caller of RenderUserSearch, the subjects-tab equivalent in routers/web/explore/repo.go:239-318, and the base layout CSS. go vet passes on the changed packages. The change is solid overall; the issues below are ordered by importance.

1. 🟡 The split (and its user-specific wording) also renders on the /explore/organizations page, which the PR says it doesn't

• Addressed
• Dismissed

The PR comment in routers/web/explore/user.go:158-161 claims:

	// Split the results the way the subjects tab does: the user the keyword actually
	// names goes into its own "Search results for ..." section, everything else is
	// listed under "Similar" (#276). Only the explore user list renders these; the
	// admin pages share this handler but their templates ignore them.

But the organizations page shares not just the handler, the template: routers/web/explore/org.go:47-54 calls RenderUserSearch(..., tplExploreUsers), and templates/explore/users.tmpl:7 includes the overridden explore/user_list template. The route is still registered and enabled by default (routers/web/web.go:561, DisableOrganizationsPage defaults to false), only the navbar tab is commented out (custom/templates/explore/navbar.tmpl:14-18). So GET /explore/organizations?q=foo now renders the split, including:

{{ctx.Locale.Tr "explore.user.no_exact_match" .Keyword}}

which produces "No user named exactly 'foo'." on a page listing organizations — misleading wording, and an untested/unintended surface for the new feature. Either gate the split on the users tab, or make the wording entity-neutral:

// option A: only the users tab gets the split
ctx.Data["HasSearchKeyword"] = opts.Keyword != "" && ctx.Data["PageIsExploreUsers"] == true

; option B: neutral wording in custom/options/locale/locale_en-US.ini
user.no_exact_match = No account named exactly '%s'.

Option A is closer to what the PR description promises, and avoids the extra exact-match query on the orgs page.

2. ⚪️ Several users can share the same full name, but only one is promoted to the exact-match section

• Addressed
• Dismissed

routers/web/explore/user.go:58 caps the exact-match query at one row:

	exactOpts.ListOptions = db.ListOptions{Page: 1, PageSize: 1}

Usernames (lower_name) are unique, but full_name is not, so searching a name borne by two users arbitrarily promotes whichever comes first under the inherited sort order and lists the other(s) under "Similar". (The subjects tab doesn't have this problem; subject names are unique.) Fetching all exact matches and excluding all of them from "Similar" keeps the single exact-match display but stops twins from being mislabeled:

	exactOpts.ListOptions = db.ListOptions{Page: 1, PageSize: 50}
	exactUsers, _, err := user_model.SearchUsers(ctx, exactOpts)
	if err != nil {
		return nil, nil, err
	}
	if len(exactUsers) == 0 {
		return nil, users, nil
	}

	exactMatchIDs := container.SetOf[int64]()
	for _, u := range exactUsers {
		exactMatchIDs.Add(u.ID)
	}
	exactMatch := exactUsers[0]
	similar := make([]*user_model.User, 0, len(users))
	for _, u := range users {
		if !exactMatchIDs.Contains(u.ID) {
			similar = append(similar, u)
		}
	}
	return exactMatch, similar, nil

(container is already imported in this file.)

3. ⚪️ DRY: the Eq/Like branches in toSearchQueryBase duplicate the whole builder.Or

• Addressed
• Dismissed

models/user/search.go:96-107 repeats the identical two-column Or with only the comparison kind differing:

		var keywordCond builder.Cond
		if opts.ExactMatchOnly {
			keywordCond = builder.Or(
				builder.Eq{"lower_name": lowerKeyword},
				builder.Eq{"LOWER(full_name)": lowerKeyword},
			)
		} else {
			keywordCond = builder.Or(
				builder.Like{"lower_name", lowerKeyword},
				builder.Like{"LOWER(full_name)": lowerKeyword},
			)
		}

A small helper removes the duplication and makes the two columns impossible to drift apart:

		matchName := func(col string) builder.Cond {
			if opts.ExactMatchOnly {
				return builder.Eq{col: lowerKeyword}
			}
			return builder.Like{col, lowerKeyword}
		}
		var keywordCond builder.Cond = builder.Or(
			matchName("lower_name"),
			matchName("LOWER(full_name)"),
		)

4. ⚪️ CSS: the margin: 0 rule now targets the exact same element as the border rule and can be folded in

• Addressed
• Dismissed

Since flex-list and explore-users-rows are now on the same element (by design, per the template comment), custom/public/assets/css/explore-users.custom.css:35-37 is redundant as a separate rule:

.page-content.explore.users .explore-users-list-container .flex-list {
  margin: 0;
}

Merge it into the box rule at custom/public/assets/css/explore-users.custom.css:28-33:

.page-content.explore.users .explore-users-list-container .explore-users-rows {
  border: 1px solid var(--color-secondary);
  border-radius: 8px;
  overflow: hidden;
  background: var(--color-body);
  margin: 0;
}

5. ⚪️ Locale: user.similar is a duplicate of subject.similar

• Addressed
• Dismissed

custom/options/locale/locale_en-US.ini:440-441 adds a key whose value is identical to the existing one:

subject.similar = Similar
user.similar = Similar

A single shared key avoids two strings to keep in sync for translators:

similar = Similar

with both templates using {{ctx.Locale.Tr "explore.similar"}}. (Keeping them separate is defensible if you expect the wording to diverge, but at present they are the same sentence.)

6. ⚪️ Template: nested {{if .Keyword}} inside {{if .HasSearchKeyword}} is dead logic

• Addressed
• Dismissed

custom/templates/explore/user_list.tmpl:17-22:

{{if .HasSearchKeyword}}
	{{if .Keyword}}
		<div class="tw-font-bold tw-text-14 tw-mb-4">

HasSearchKeyword is set to opts.Keyword != "" in the only handlers that set it (routers/web/explore/user.go:167, routers/web/explore/repo.go:318), so the inner check can never be false. It was copied from custom/templates/shared/subject/list.tmpl:2-4, which has the same redundancy; dropping it in both keeps them consistent:

{{if .HasSearchKeyword}}
	<div class="tw-font-bold tw-text-14 tw-mb-4">
		{{ctx.Locale.Tr "explore.search_results_for" .Keyword}}
	</div>

7. ⚪️ No automated coverage for the rendered split, which is what issue #276 is about

• Addressed
• Dismissed

The new unit tests cover ExactMatchOnly at the model layer, but nothing pins the router/template behavior (exact user promoted, "Similar" section, no-exact-match note). tests/integration/explore_user_test.go is the natural home and already parses explore pages:

func TestExploreUserSearchSplit(t *testing.T) {
	defer tests.PrepareTestEnv(t)()

	// "user1" is the exact username; user10..user18 are only substrings
	req := NewRequest(t, "GET", "/explore/users?q=user1")
	resp := MakeRequest(t, req, http.StatusOK)
	h := NewHTMLParser(t, resp.Body)
	assert.Equal(t, "Search results for user1", h.Find(".explore-users-list-container .tw-font-bold").Text())
	// the exact match box holds exactly one row, the "Similar" box the rest
	assert.Len(t, h.Find(".explore-users-rows").Eq(0).Find(".flex-item").Nodes, 1)
	assert.True(t, h.Find(".explore-users-rows").Eq(1).Find(".flex-item").Length() > 0)

	// a keyword matching nobody exactly gets the note instead
	req = NewRequest(t, "GET", "/explore/users?q=ser1")
	resp = MakeRequest(t, req, http.StatusOK)
	h = NewHTMLParser(t, resp.Body)
	assert.Contains(t, resp.Body.String(), "No user named exactly 'ser1'.")
}

Everything else I checked holds up: the exact-match query inherits the visibility/type/role conditions of the page query (no leak of users the list would hide), the SQL stays parameterized, the keyword is auto-escaped in the new strings, admin/user/view.tmpl degrades to the plain list as claimed, and the JS submit/search interception only fires on an empty field so native submits and the #273 tab-link carry-over are untouched.

---

Review generated using glm-5.3 via Z.AI. Comment /review to re-run.

[pieer]

Approved