✨ Create Efficient Content Type Fetching Endpoint

[fmontes]

Problem Statement

Fetching content types from the backend using the current API causes performance issues with large datasets (e.g., thousands of content types). This leads to oversized payloads that fail to return, causing timeouts and harming user experience and system reliability.

Objectives

• Develop a new backend endpoint that retrieves content types based on the information of a specified page.
• Implement a mechanism that effectively reduces the payload size and response time.

User Story

As a front-end developer, I want to fetch relevant content types for a specific page from the backend without sending extensive lists.

Acceptance Criteria

• [x] The new endpoint accepts page url and returns associated content types.
• [x] Backend processing of page information to content types is accurate and efficient.

External Links

[Placeholder for external links to tech specifications, API docs, or similar resources.]

Assumptions & Initiation Needs

• Assume that the server can fetch the content just from the page URL.
• Initial data mapping of pages to content types is required to facilitate efficient querying.

Quality Assurance Notes & Workarounds

Update tomcat settings to allow bigger header.

Technical Details

https://github.com/dotCMS/core/issues/32238#issuecomment-2905850011

[fmontes]

1. Summary

Dynamically get the available content types for Universal Visual Editor palette by analyzing page structure, container requirements.

2. Endpoint Definition

Method: GET
Path: /api/v1/contenttype/page
Content-Type: application/json
Authentication: YES - dotCMS permission system

3. Request

• Path Parameters: None

• Query Parameters:

  Parameter	Type	Required	Description	Default
  pagePath	string	Yes	The URL of the page to filter content types for the palette	-
  language	string	No	Language ID for content type analysis	"-1"
  filter	string	No	Filter content types by name or description	-
  page	integer	No	Page number for pagination	1
  per_page	integer	No	Items per page (max: 100)	20
  orderby	string	No	Sort field - "name", "usage", "modified"	"usage"
  direction	string	No	Sort direction - ASC|DESC	"ASC"

• Request Body: None

• Headers:

  • Content-Type: application/json
  • Authorization: Bearer {token} (if using API token authentication)

Input Validation

• Either pagePath or pageId must be provided
• pagePath must be a valid URL format if provided
• page must be >= 1
• per_page must be between 1 and 100
• direction must be either "ASC" or "DESC"
• orderby must be one of: "name", "usage", "modified"
• language must be a valid language ID or "-1"

4. Response

• Success (200): JSON structure following dotCMS ResponseEntity pattern

{
  "entity": [
    {
      ... content type object
    }
  ],
  "errors": [],
  "messages": [],
  "i18nMessagesMap": {},
  "permissions": ["READ"],
  "pagination": {
    "currentPage": 1,
    "perPage": 20,
    "totalEntries": 42
  },
}

5. Error Responses

• 400 Bad Request: Missing required parameters (pagePath), invalid URL format, invalid pagination parameters, invalid orderby/direction values
• 401 Unauthorized: Authentication required - user not logged in or invalid API token
• 403 Forbidden: Insufficient permissions to view the specified page or content types
• 404 Not Found: Page not found with provided pagePath
• 500 Internal Server Error: Page analysis failed, template parsing error, database connectivity issues

6. GraphQL Support

• GraphQL Equivalent: NO
• GraphQL Query Name: No

[github-actions[bot]]

PRs:

• https://github.com/dotCMS/core/pull/32410

[jdotcms]

Test1, one container with a single content type, should return only one type

[jdotcms]

Testing a container with multiple types and host and vanity that are on the blacklist should be not (there are 7 in the container, but only 5 are being rendered)

[jdotcms]

Now we have a template with the system container included 3 times:

Making the request to the page, it retrieves all 57 content types availables:

Also, you can filter (I have copied the rich text several times) http://localhost:8080/api/v1/contenttype/page?pagePathOrId=a420d411fdd22334c3181106f5f57906&filter=rich

Or Activities which is just one http://localhost:8080/api/v1/contenttype/page?pagePathOrId=a420d411fdd22334c3181106f5f57906&filter=activ

[erickgonzalez]

Something else we need to consider here is the property CONTENT_PALETTE_HIDDEN_CONTENT_TYPES

[jdotcms]

orderby string No Sort field - "name", "usage", "modified" "usage"

direction string No Sort direction - ASC|DESC "ASC"

• Request Body: None
• Headers:

Just as a note, we are reusing the same logic from the content type paginator so these sort criteria do not exist: "Sort field - "name", "usage", "modified"

The real ones are: "name, velocity_var_name, mod_date, sort_order``description, structuretype, category, inode"

Which are the same of other endpoints on content type api

[jdotcms]

update: now usage is being taking in consideration to sort and it is the default sort

[dsolistorres]

QA Passed Working as expected when retrieving content types for the containers in a given page

Enhancement Note: When using pagination parameters, the currentPage in the result is not working as expected. For example, after sending a request for page 3:

/api/v1/contenttype/page?pagePathOrId=/home/index&page=3&per_page=3&order_by=name

The pagination section in the results returns the wrong current page:

"pagination": {
    "currentPage": 1,
    "perPage": 3,
    "totalEntries": 3
  },