Custom Page content types rejected as detail pages due to hardcoded "htmlpageasset" subtype check

[dsilvam]

Problem Statement

DetailPageTransformerImpl validates detail pages by checking assetSubType.equals("htmlpageasset"). However, assetSubType is populated from the content type's velocity variable name (set in IdentifierFactoryImpl line 360: identifier.setAssetSubType(contentlet.getContentType().variable())).

Only the default "Web Page Content" content type has velocity variable htmlpageasset. Any custom content type of base type Page (e.g., "Landing Page", "Detail Page", etc.) will have a different variable name and will always fail this check — even though it is a perfectly valid page.

The error thrown:

Bad request error
[<identifier>] in Content Type [<name>] is not a valid detail page.

This is thrown from DetailPageTransformerImpl.validateIdentifier() (lines 136–138) every time a Content Type is saved with a detail page that uses a custom Page content type. Notably:

• Pages set as detail pages before this validation was introduced still work at runtime (URL mapping reads directly from the DB)
• Trying to update those same Content Types also fails with this error
• There is no workaround through the UI; only a direct DB update to the page_detail column in the structure table can unblock customers

Steps to Reproduce

1. Create a Content Type with base type Page using a custom name (e.g., "Landing Page" with velocity variable landingPage)
2. Create a page using that custom Page content type at any path (e.g., //mysite.com/detail-pages/my-landing-page)
3. Create or edit any Content Type that supports URL mapping, set the Detail Page field to the page from step 2
4. Save the Content Type
5. Observe error: Bad request error — [<identifier>] in Content Type [X] is not a valid detail page.

Acceptance Criteria

• Content types of base type Page (regardless of velocity variable name) are accepted as valid detail pages
• The hardcoded "htmlpageasset" string check in DetailPageTransformerImpl.validateIdentifier() is replaced with a proper base-type check (e.g., verify the content type's BaseContentType is HTMLPAGE)
• Content Types that previously had custom Page content types set as detail pages (via older versions) can be successfully updated through the UI without clearing the detail page field first

dotCMS Version

Unknown — confirmed present in current codebase. Pre-existing detail pages set before this validation was introduced still function at runtime, indicating this is a regression introduced when save-time validation was added.

Severity

High - Major functionality broken

Links

• Freshdesk ticket #36039
• Freshdesk ticket #36145

[wezell]

We really need a baseType column on our identifier table, fwiw. I'm dealing with this same issue.

[github-actions]

PRs linked to this issue

• fix(content-type): accept custom Page content types as valid detail pages by @dotCMS-Machine-User

PRs linked to this issue

• fix(content-type): accept custom Page content types as valid detail pages by @dotCMS-Machine-User
• fix(content-type): accept custom Page content types as valid detail pages by @dsilvam

[dsilvam]

Note to QA:
Test both types of Page Parent Type "Destinations" and "Page" work setting them as detail page for a Content Type using URL Maps. Test that the url mapping mechanism works for both cases.