Redirect target page selector ("Select a file" dialog) shows all folders empty — application/dotpage mimeType filter excludes all pages

[syedATdot]

Problem Statement

When editing a page's Properties and using the redirect field, opening the "Select link" dialog to browse for a destination page shows "No files found" for every folder — even folders that clearly contain pages. This makes it impossible to select a redirect target via the browser.

The Site Browser portlet lists the same folders' pages correctly, so the content and permissions are fine — only the redirect/file-selector dialog is affected.

Root Cause

The redirect selector calls BrowserAjax.getFolderContentWithDotAssets(...) with mimeTypes = ["application/dotpage"].

In com.dotcms.browser.BrowserAPIImpl.selectQuery(...), whenever mimeTypes is set, appendMIMETypeQuery(...) adds this SQL clause:

AND (jsonb_path_exists(c.contentlet_as_json,
  '$.fields.**.metadata ? (@.contentType like_regex ".*application/dotpage.*")'))

However, application/dotpage is a synthetic mimetype that is assigned to pages only in-memory at display/transform time — see:

com.dotmarketing.portlets.contentlet.transform.strategy.PageViewStrategy (~line 79)
com.dotmarketing.portlets.contentlet.ajax.ContentletAjax (~line 1437)
com.dotmarketing.portlets.browser.ajax.BrowserAjax (~line 788)

It is never persisted into contentlet_as_json. Therefore the jsonb_path_exists(...) check matches zero page rows, and every page is filtered out → empty result.

Confirmation (A/B): The Site Browser path (BrowserAjax.openFolderContent) calls the internal getFolderContent(...) with mimeTypes = null, so appendMIMETypeQuery is skipped and the pages return normally. Same folder, user, language, and session — the only differing variable is the application/dotpage mimeType filter.

Regression Origin

The appendMIMETypeQuery method and the if (UtilMethods.isSet(browserQuery.mimeTypes)) trigger in selectQuery were introduced (net-new, verified from the diff) in:

Commit f4ff803 — "feat(Content Drive) #34205: Support mimeTypes filtering in /api/v1/drive/search endpoint" (2026-01-08)
PR: #34217
Issue: #34205

This change was intended for the new Content Drive search endpoint, but it landed in the shared selectQuery / appendMIMETypeQuery code path that the legacy DWR browser (getFolderContentWithDotAssets) also uses — breaking the redirect/page selector as a side effect. No mimeType SQL filter existed in this path before this commit.

Proposed Fix

When the requested mimeTypes include the synthetic application/dotpage, match pages by base type (HTMLPAGE) rather than applying the asset-metadata jsonb_path_exists contentType check to them. More generally, appendMIMETypeQuery should not be applied to HTMLPAGE base-type rows, since pages have no stored asset metadata contentType.

Notes
The broken clause uses PostgreSQL jsonb_path_exists syntax; the MS SQL path should be reviewed separately.
Related (older, already-fixed) file-browser issues for context: #24358, #24444.
Affected file: dotCMS/src/main/java/com/dotcms/browser/BrowserAPIImpl.java

Steps to Reproduce

• Edit any Page's properties (or any field that opens the legacy file/page browser for pages).
• In the redirect field, click to browse and open the "Select link" dialog.
• Expand a folder that contains pages (e.g. /store).

Expected Behavior

The dialog lists the pages contained in the selected folder, so one can be chosen as the redirect target.

Actual Behavior

The dialog shows "No files found" for every folder. The underlying DWR call BrowserAjax.getFolderContentWithDotAssets returns {total:0, list:[]}.

Acceptance Criteria

Acceptance Criteria

1. Opening the redirect field's "Select a file" dialog and browsing a folder that contains pages lists those pages (no longer shows "No files found").
2. A selected page can be chosen and saved as a redirect target end-to-end.
3. The dialog's results match what the Site Browser shows for the same folder, user, and language.
4. Fix holds for nested/subfolders and for folders containing a mix of pages, file assets, and links (each type still shown/filtered as expected).
5. Passing a real mimeType (e.g. image/*, application/pdf) to the browser still filters correctly — i.e. the fix does not disable legitimate mimeType filtering for file assets or for the Content Drive /api/v1/drive/search endpoint (no regression to [TASK] Support mimeTypes filtering in /api/v1/drive/search #34205 / PR feat(Content Drive) #34205 : Support mimeTypes filtering in /api/v1/drive/search endpoint #34217).
6. application/dotpage requests return pages by base type (HTMLPAGE); pages are not excluded by the asset-metadata contentType check.
7. Language behavior is unchanged — pages resolve under the content-selected language with default-language fallback, consistent with the Site Browser.

dotCMS Version

Version: 26.07.21-01 (dotEvergreen)
Database: PostgreSQL

Severity

High - Major functionality broken

Links

https://helpdesk.dotcms.com/a/tickets/38692

[github-actions]

PRs linked to this issue

• fix(browser): resolve application/dotpage MIME filter to the HTMLPAGE base type (#36916) by @ihoffmann-dot