fix(block-editor): support spaces in contentlet search (#34416)

[oidacra]

Summary

Fixes the Block Editor contentlet search to support multi-word queries with spaces.

When typing inside the Block Editor's contentlet picker (after / → Contentlets → <ContentType>), spaces appear in the input but the result list does not refine. Root cause: SuggestionsService.getContentlets interpolated the user filter into +catchall:*${filter}* title:'${filter}'^15. With a multi-word filter like White Water, Lucene parses +catchall:*White Water* as two terms — +catchall:*White (mandatory) plus Water* (optional) — so the query degrades to a single-word filter on the first token only. The single-quoted title clause is also broken (Lucene phrase queries require double quotes).

CleanShot.2026-04-29.at.17.32.41.mp4

Fix

In suggestions.service.ts (getContentlets):

• Tokenize the filter on whitespace and emit one mandatory +catchall:*token* clause per token, joined with spaces. Multi-word queries now require ALL tokens to match.
• Switch the title boost from title:'${filter}'^15 to title:"${filter}"^15 for proper Lucene phrase semantics.
• Compose the final query via array + filter + join so empty parts (e.g. missing identifierQuery) don't introduce double spaces.
• Empty / whitespace-only filters omit the catchall and title clauses entirely.
• Hyphen-bearing filters keep the existing identifier branch unchanged (+catchall:${filter}, no wildcards).

Closes

Closes #34416

Acceptance Criteria

• Search input accepts space characters (was already preserved by TipTap; the fix targets the resulting query).
• Multi-word query (e.g., White Water) narrows results to contentlets matching ALL tokens.
• Single-word query still works — no regression.
• Empty filter returns the default contentlet list (no catchall/title clauses emitted).
• Filter containing - preserves the identifier branch.

Test Plan

Automated tests added in suggestions.service.spec.ts (now 8 tests, was 1) using HttpTestingController to assert the exact query string sent to /api/content/_search for: multi-word, single-word, empty, whitespace-only, hyphen, and contentletIdentifier exclusion cases, plus response mapping.

Manual verification:

• Open a content type with a Block Editor field, type /, choose Contentlets → Activity.
• Type White Water — list filters to contentlets containing both words (e.g., White Water Rafting).
• Type Water — single-word search still works.
• Clear the filter — full default list returns.

Changed Files

• core-web/libs/block-editor/src/lib/shared/services/suggestions/suggestions.service.ts
• core-web/libs/block-editor/src/lib/shared/services/suggestions/suggestions.service.spec.ts
• core-web/libs/block-editor/src/lib/elements/dot-bubble-menu/dot-bubble-menu.component.spec.ts (drive-by: 1-line import order fix to satisfy nx affected:lint)

Visual Changes

User-facing behavior change in the Block Editor contentlet search popup; the visual UI itself is unchanged. A before/after screen recording can be shared if needed.

[claude]

Claude finished @oidacra's task in 2m 38s —— View job

---

PR Review

• Gather context and read changed files
• Review suggestions.service.ts — core logic change
• Review suggestions.service.spec.ts — test coverage
• Review dot-bubble-menu.component.spec.ts — drive-by fix
• Post findings

---

Issues

1. UUID_LIKE regex silently kills searches for hex English words (suggestions.service.ts:15)

const UUID_LIKE = /^[0-9a-f]+(-[0-9a-f]+)+$/i;

The comment claims it's "narrow enough to skip ordinary hyphenated English titles," but it matches any hyphen-separated sequence where every segment is all-hex. Short, real English words that are also valid hex: ace, cafe, bead, dead, beef, face, babe, fade. A user searching for content titled ace-cafe or dead-beef silently hits the no-wildcard exact-match path and gets nothing. This is user-invisible: no error, just empty results.

A proper UUID pattern (/^[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}$/i) would be narrow enough to cover the actual identifier use case without these false positives. The test at spec:112 uses abc-def as the UUID case — that's also not a UUID and would be better served by a proper UUID regex.

Fix this →

2. Hyphenated-word tokens won't match via wildcard (suggestions.service.ts:63)

When filter = 'White-Water Falls', whitespace-split produces ['White-Water', 'Falls'], and the query includes +catchall:*White\-Water*. Standard Lucene text analysis would index White-Water as two terms (white, water), so a single wildcard over White\-Water finds nothing. The +Falls clause still narrows results, but the hyphenated token is effectively dead weight.

This existed before (the old - branch also used no wildcards), so it's not a regression introduced here — but the PR now routes this through the "works correctly" path without addressing the actual matching issue. Worth a comment acknowledging the limitation, or splitting tokens on [-\s]+ instead of just \s+.

3. contentletIdentifier is interpolated without escaping (suggestions.service.ts:52)

const identifierQuery = contentletIdentifier ? `-identifier:${contentletIdentifier}` : '';

The PR adds escapeLucene for user-typed input but leaves this call site unescaped. In practice, dotCMS identifiers are UUIDs and safe, but it's an inconsistency: if someone passes an identifier with a Lucene special char, it bypasses the new escaping logic. One-liner fix: escapeLucene(contentletIdentifier).

---

Minor

• The getContentletsByLink method (line 115) interpolates link unescaped — pre-existing, not this PR's problem, but the new escapeLucene helper is sitting right there.
• &&/|| multi-char operator handling in LUCENE_SPECIAL_CHARS produces \&& / \|| (escapes only the first char). This neutralises the operator in practice but isn't the canonical form (\&\& / \|\|). Harmless given typical content search input.
• Tests are thorough: 8 cases covering multi-word, single-word, empty, whitespace-only, UUID, injection, identifier exclusion, and response mapping. The flushEmpty helper and httpMock.verify() in afterEach are clean. The injection test (spec:143) is a good addition.
• dot-bubble-menu.component.spec.ts drive-by: correct, no concerns.