1. Introduction

1.1. Background

• Current State:

  • Strapi users are experiencing challenges with managing and navigating content types due to the lack of an organizational structure. This issue is prevalent among users with extensive content, making it difficult to find specific content types, understand the content model, and manage multiple endpoints. There is a significant demand from the community, evidenced by over 470 upvotes on feedback.strapi.io and detailed feedback from surveys and user interviews.

• Problem:

  • Difficulty in finding Content Types: users struggle to locate specific content types within long, unorganized lists, especially in larger projects.
  • Lack of clear structure: the absence of folders leads to an unclear overall content model, making it hard to understand the relationships between different content types.
  • Management challenges: handling content types for various endpoints from the same Strapi instance is cumbersome without a structured system.
  • Non-technical user experience: Content Managers, who are often non-technical, find it challenging to navigate and manage content types due to the flat structure.

• Opportunity:

  Introducing a feature that allows users to organize content types into folders can address these issues by:

  • Improving navigation: folders would make it easier for users to find and access specific content types quickly, enhancing overall user experience.
  • Enhancing structure: a clear hierarchical organization would help users understand the content model better and manage related content types more efficiently.
  • Supporting multiple endpoints: a structured system can simplify the management of content types across different applications and endpoints within the same Strapi instance.
  • Empowering non-technical users: an organized content management system would be more intuitive for Content Managers, reducing reliance on developers for content organization.

  Implementing this feature would not only meet a significant user demand but also improve the scalability and usability of Strapi, making it more attractive to both current and potential users.

1.2. Objectives

• Address user needs: with this initiative, we would fulfill a highly requested feature from the Strapi community, demonstrating responsiveness to user feedback. And we would also reduce the reliance on workarounds that users currently implement to organize their content types.

• Enhance UX and improve efficiency: simplify the navigation and management of content types, especially for large projects, and improve the backend interface for non-technical users by providing a more intuitive and organized structure.

  We would also enable faster content type identification and access, reducing time spent managing and finding content types, and facilitating better content type management for projects serving multiple applications and endpoints from a single Strapi instance.

• Strengthen competitive edge: align with or exceed competitors' offerings in content management features. Enhancing Strapi's market position by offering a useful feature that few other competitors offer.

1.3. Scope

• Feature design and development:
  • Design and develop a user-friendly solution for creating, organizing, and managing folders within the content type builder.
  • Implement hierarchical folder structures with up to 3 levels of nesting.
  • Folder organization is stored in src/content-structure/groups.json — a project metadata file committed to source control alongside content type schemas. This file is not a content type schema and does not affect UIDs, API routes, or database tables.
• Integration and compatibility:
  • Ensure the integration of the folder feature with existing Strapi functionalities (e.g. the terminal for content types generation, the content editor, DTS)
  • Provide support for existing projects to transition their content types into the new folder system without data loss or significant disruption.
• Testing, QA, and documentation:
  • Testing should be conducted throughout development to ensure the feature meets the requirements.
  • Create comprehensive documentation detailing how to use the new folder feature, including step-by-step guides and best practices.
• Feedback and further iterations:
  • Keep active mechanisms for continuous feedback collection post-launch to address any issues and identify areas for further improvement.

2. Functional Requirements

2.1 Folders management:

• Create folder:
  • Users should be able to create new folders within the content type builder interface.
  • The creation process should allow users to name the folder and specify its hierarchical position if nested folders are supported, with validation on the chosen name.
• Edit folder:
  • Users must be able to rename existing folders, with validation on the chosen name, and change their hierarchical position if nested folders are supported.
  • The system should ensure that renaming or moving folders does not disrupt the existing structure or relationships of the content types.
• Delete folder:
  • The feature supports two deletion modes:
    • Delete folder only (default): removes the folder; moves its directly contained content types and child folders to the deleted folder's parent. A confirmation prompt is shown before deletion.
    • Delete folder and its content types (destructive): uses the existing Content-Type Builder content type deletion flow to delete all content types inside the folder and its descendant folders; requires the existing destructive confirmation. This option must be visually less prominent than the default.