Block Editor 2.0: restore internal dotCMS page search in the link popover

[jdcmsd]

Description

The legacy Block Editor's link popover lets authors search for internal dotCMS pages directly from the URL field — typing a few characters (e.g. /inde) surfaces a live, autocomplete-style list of matching pages with title, path, and thumbnail, so the author can pick a page instead of pasting a raw URL.

The new Block Editor (2.0) link popover does not have this capability — the URL field is a plain text input with no page search/autocomplete. This is a feature-parity gap. We need to bring the behavior back before the new editor reaches customers, so authors don't lose the ability to link to internal pages by search.

Legacy behavior (reference):

Aspect	Legacy link popover
URL field	Typing a partial path/term triggers a live page search
Results	Dropdown of matching dotCMS pages — title, path, thumbnail
Selection	Picking a result fills the link with the page's URL
Fallback	Author can still type/paste an arbitrary external URL

New behavior (current): URL field is a plain input only — no search, no suggestions, no way to look up an internal page by title/path.

Acceptance Criteria

• The new Block Editor link popover URL field supports searching internal dotCMS pages by typing a partial title or path.
• Matching pages appear in an autocomplete/dropdown list showing at least the page title and path (thumbnail if feasible, matching legacy).
• Selecting a result populates the link href with the selected page's URL.
• Authors can still type or paste an arbitrary external URL (the search must not block manual entry).
• Behavior reaches parity with the legacy link popover's page-search experience.
• Works in both the create-link (text selected) and edit-link (existing link) flows.

Priority

Medium

Additional Context

• Part of the Block Editor 2.0 effort.
• Reuse the same backend page-search the legacy popover and the slash menu's contentlet drill-down already use, rather than introducing a new HTTP service.
• New link popover lives at libs/new-block-editor/src/lib/editor/components/link-popover/.

---

Mirrored from dotCMS#35890 for autodoc pipeline testing.

[github-actions]

PRs linked to this issue

• feat(Block Editor): Restore internal dotCMS page search in the link popover by @jdcmsd

[github-actions]

Documentation Audit: Epic #491 — Block Editor 2.0: restore internal dotCMS page search in the link popover

Report type: No documentation change required
Epic: #491 — "Block Editor 2.0: restore internal dotCMS page search in the link popover"
Repo: dotCMS/core-workflow-test (mirrored from dotCMS#35890)
State: CLOSED
Prompt: burlap
Sub-issues: (none)
Related PRs: #492 (mirrored from dotCMS#35907) — MERGED 2026-06-17

action: none

Determination

No documentation change required. Epic #491 is a feature-parity restoration: it brings the legacy Block Editor's link-popover behavior — typing a partial title/path to search internal dotCMS pages and pick one instead of pasting a raw URL — back into the reimplemented Block Editor 2.0 link popover. The Epic and its delivering PR (#492) are explicit about three things that, taken together, mean the Epic's delivery does not warrant a documentation change:

1. It restores pre-existing behavior, not a new capability. The acceptance criteria are framed entirely around reaching "parity with the legacy link popover's page-search experience." From a customer's standpoint the resulting behavior is identical to what the product already shipped; nothing new becomes possible.
2. It is scoped to ship before the new editor reaches customers. The Epic states the gap must be closed "before the new editor reaches customers," so Block Editor 2.0 is not yet the customer-facing editor. This is internal re-implementation work to avoid a regression at cutover, not a change to live product behavior.
3. No new public surface. PR feat(Block Editor): Restore internal dotCMS page search in the link popover #492 reuses the existing DotContentSearchService / /api/content/_search endpoint, builds the Lucene query inline (mirroring the legacy editor), and introduces no new HTTP service, configuration property, API contract, or environment variable. The only externalized strings are a UI placeholder and an empty-state message (dot.block.editor.dialog.link.search.empty) — translation keys, not documentable configuration.

Because the Epic neither introduces a new end-user capability nor changes documented product behavior, there is nothing for this Epic's delivery to add to or correct in the docs.

Vault Context

The dotcms-vault connector is not available as a live tool in this evaluation environment. The vault scoping block supplied in the context was off-topic for this Epic — it describes an "OpenSearch 3.x Upgrade — Code Complete" infrastructure milestone (GitHub dotCMS#33946), which is unrelated to the Block Editor link popover. It was therefore disregarded for persona and grouping inference, which is instead derived from the Epic and PR #492 and should be treated as provisional:

• Feature area / grouping: Content authoring → Block Editor field. Any future coverage of this behavior would belong on the existing block-editor page, not a new page.
• Likely personas: Content authors and editors who compose rich content in the Block Editor and link to internal pages. This is an authoring-UX concern, not an administrator or developer integration concern.
• Product intent: Prevent a feature regression — ensure authors do not lose the legacy ability to find and link internal pages by search when Block Editor 2.0 becomes the default editor.

Search Evidence

A dotCMS AI semantic search was run to confirm where, if anywhere, the Block Editor link experience is documented.

Search	Top relevant results	Documents the link popover / page search?
"Block Editor adding and editing links insert link URL"	block-editor, the-wysiwyg-field, comparing-block-editor-and-wysiwyg-fields	No
"Block Editor link mark hyperlink bubble menu add link to text"	block-editor, the-wysiwyg-field, dotcms-block-editor	No
"link to internal page by title or path search dropdown"	searching-for-menu-links, searching-for-a-page, pages-tool	No — these cover the Pages tool and Menu Links, not the Block Editor link popover
"Block Editor link popover search internal dotCMS page autocomplete"	block-editor, blog/LTS announcement posts	No

The canonical page is block-editor (dotcms.dev, published 2026-04-15). A full read of its documentation field confirms it covers block types, the formatting bubble menu (bold/italic/underline/strike/super/subscript marks), alignment, AI blocks, markdown, field variables, the JSON schema, VTL and headless rendering, and embedded contentlet behavior — but it does not document the link feature at all, in either the legacy or the new editor.

Coverage Mapping

Epic deliverable (PR #492)	User-facing?	Already product behavior (legacy)?	Action
Internal page search in the link URL field (debounced p-autoComplete)	Yes	Yes — restores legacy behavior	None — parity restoration
Result template (name, path, /dA/{inode} thumbnail)	Yes	Yes — mirrors legacy dropdown	None
External URLs never blocked / manual entry always allowed	Yes	Yes — matches legacy fallback	None
Empty-state message + URL placeholder (Language.properties)	Yes	New strings only	None — translation keys, not documentable config
Selection highlight via ProseMirror decoration while editing	Yes	Internal UX polish	None
Click-outside whitelist for .p-autocomplete-overlay; rel defaults to null	No	Bug/shell fixes	None — not customer-facing

Every user-facing item is a restoration of behavior the product already had; the remainder are internal fixes.

Latent Documentation Gap (separate from this Epic)

For transparency: the Block Editor link popover — including the legacy internal-page-search behavior — has never been documented on the block-editor page, even though the page documents the comparable bubble-menu formatting marks. This gap predates Epic #491 and is independent of it: the legacy editor exhibited this behavior for years without doc coverage, so the gap was not created or widened by this Epic's delivery.

This report does not treat that latent gap as an action item for Epic #491, because the Epic's job was parity restoration, not introducing a documentable feature. It is flagged here only as a candidate for the documentation backlog: if and when the team documents Block Editor 2.0's link-authoring UX holistically (most naturally as a new subsection on the block-editor page, alongside Block Formatting), the internal page-search behavior restored by this Epic would belong there. That is an editorial decision for the docs team, not a change triggered by this Epic.