Other

## Problem Strapi allows content editors to manually reorder relations using drag-and-drop in the Admin UI. This creates a natural expectation that the order of those relations is meaningful content and can be consumed by applications through the API. However, while Strapi persists and displays the editor-defined order in the Admin UI, there is currently no supported or reliable way to retrieve relations in that same order through REST or GraphQL APIs. As a result: Editors spend time curating and ordering content. Strapi stores and restores that ordering in the Admin UI. Developers cannot reliably retrieve that ordering through the API. This creates a disconnect between the editorial experience and the developer experience. --- ## Why this matters The order of related content is often part of the content itself, not merely a presentation concern. Common examples include: Featured articles Homepage content blocks Product showcases Learning paths Curated collections Navigation structures Related content sections Recommended products or resources In these cases, editors intentionally arrange items in a specific order. When a CMS exposes drag-and-drop ordering, users reasonably expect that ordering to be available to API consumers. --- ## Existing workarounds Current workarounds include: Creating explicit sort fields on related entities Creating wrapper content types Using repeatable components instead of relations Maintaining ordering logic outside the relation itself While these approaches can work, they duplicate functionality already available in the Admin UI and add unnecessary complexity to content modeling. --- ## Why this feels like a product gap The key point is that Strapi already supports editorial ordering: Editors can reorder relations. The order is persisted. The order is restored when editing content later. The information already exists. The missing capability is providing a supported way for developers to retrieve that editor-defined order through the API. This is not a request for a completely new editorial feature. The editorial workflow already exists. --- ## Community history This topic has been raised repeatedly over multiple years and across multiple major versions of Strapi. GitHub issues: #2616 (2019) — Relation order not preserved #6010 (2020) — GraphQL relation ordering concerns #16961 (2023) — Relation ordering inconsistencies in API responses #24212 (2025) — Closed as "will not fix" #25582 (2026) — Similar concerns around relation ordering Forum discussions: https://forum.strapi.io/t/save-relation-items-order-issue-2166/332 The recurrence of this topic suggests a mismatch between user expectations and the current platform behavior. Many users appear to assume that if a relation can be ordered by an editor, that order can also be retrieved by applications. --- ## Requested enhancement Provide a supported way to retrieve relations in the exact order configured by editors. Possible implementations could include: ### Option 1 Return relations in editor-defined order by default. ### Option 2 Expose the stored relation order through a dedicated field. ### Option 3 Provide an explicit query parameter or API option that requests editor-defined ordering. The specific implementation is less important than providing a supported and documented mechanism. --- ## Expected behavior If an editor manually reorders relations in the Admin UI and saves the entry, developers should have a supported way to retrieve those relations in the same order through REST and GraphQL APIs. Editor-defined order is content and should be retrievable.

Strapi version: 5.x (latest) Node.js version: 20.x Package manager: yarn 4.12.0 Problem: server/index.ts mounts the admin panel, content API, upload handler, cron jobs, and webhook runner all on one Koa app in one OS process. There is no built-in mechanism to run multiple worker processes (Node.js cluster mode). This means: You can only scale the entire Strapi process — you cannot scale just the Content API under traffic while leaving the admin panel on a single instance. Running multiple instances externally (via pm2 or Kubernetes replicas) causes cron jobs to fire on every instance simultaneously, producing race conditions and duplicate side-effects (duplicate emails, duplicate webhook calls). See also: #15634. The cron service ( cron.ts ) uses node-schedule with no leader- election or instance awareness — every instance runs every cron task. What the code does today: In packages/core/core/src/services/server/index.ts , createServer() builds one Koa app with both createAdminAPI(strapi) and createContentAPI(strapi) on the same process and same port. In packages/core/core/src/services/cron.ts , createCronService() schedules jobs unconditionally with no check for whether this process is the designated primary. Proposed solution (monolith fix, no microservices required): Add opt-in built-in cluster support: A server.cluster.enabled config flag (default: false). When enabled, Strapi's entry point forks N worker processes using Node.js cluster module (default: os.cpus().length ). A STRAPI_INSTANCE_TYPE environment variable ( primary / worker ) lets services guard singleton behaviour: - Cron jobs only run on the primary process. - Webhook runner only runs on the primary process. - Database migrations only run on the primary process. Workers handle all HTTP traffic (load-balanced by the OS). Related issues: #3976 (cluster mode question, closed 2019, no code change made) #15634 (cron race condition, open/stale, no PR merged) I plan to submit a PR implementing this. reproduce: Deploy two Strapi v5 instances pointing to the same database (e.g. two pm2 instances or two Kubernetes pods). Configure a cron task in config/cron-tasks.ts that sends an email or writes a unique log entry. Wait for the cron schedule to fire. Observe: the cron task executes on BOTH instances simultaneously, producing duplicate emails or duplicate log entries. For the scaling limitation: Monitor CPU usage on a single Strapi instance under load. Attempt to scale only the content API (e.g. by running a second instance that only serves /api/* routes). Observe: impossible without running a full second Strapi process, which doubles the cron, webhook, and admin overhead unnecessarily. #Expected behavior When server.cluster.enabled: true is set in config: Strapi should fork N worker processes automatically. Only the primary process should run cron jobs and webhook delivery. All workers should handle HTTP requests, load-balanced by the OS. Database migrations should run once on the primary before workers start. The behaviour should be identical to the current single-process mode when cluster.enabled is false (default), so there is zero breaking change for existing deployments.

When using the yarn strapi generate command to create a custom API, the following folders are created under the api folder: controllers, routes, and services. However, inside this folder, I already have folders created from the admin panel for different collections. Now all these folders are mixed together.

I'd like to request native autosave functionality in the Strapi v5 Content Manager, covering both periodic autosave (every X seconds) and save-on-blur (when leaving a field). This is a common UX expectation in modern CMS platforms and its absence is a frequent source of data loss for editors. Problem When working in the Content Manager, there is currently no mechanism that automatically saves a user's progress. If a user accidentally closes the tab, navigates away, or experiences a browser crash, all unsaved work is permanently lost. This is especially painful when editing long-form content or complex entries with many fields. This issue affects: Content editors working on large or long-form entries Teams using Strapi on the Community plan, who have no access to plugin workarounds in some cases Any user on an unstable connection or device Proposed Solution Add a native autosave mechanism to the Content Manager with the following behavior: Periodic Autosave — Automatically save the current entry as a draft every configurable interval (e.g., every 30 seconds), only when changes are detected. Save on Blur — Trigger a save when the user moves focus away from a field. Visual Indicator — Show a subtle status indicator (e.g., "Saving…" / "Saved") in the toolbar so editors know their work is being persisted. Draft-safe — Autosave should save to draft state only, without triggering a publish, to avoid unintended content going live. Proof of Concept (Community Workaround) To validate this is technically feasible within the current architecture, I implemented a custom autosave solution on Strapi v5 using the admin panel extension injection system: Injected a custom React component into the Content Manager via admin/src/app.tsx Used a MutationObserver to detect DOM-level changes in the editor Triggered the Strapi PUT API (/api/{contentType}/{id}) on a debounced interval when changes were detected Displayed a live autosave status badge in the toolbar This worked reliably for both simple and relational fields. The fact that this could be achieved externally confirms that native support at the core level is both feasible and would be significantly more robust. Why This Should Be Native A community workaround via MutationObserver is fragile — it depends on DOM structure that can change between versions It requires each team to re-implement the same logic independently Native autosave would have access to the internal form state directly, making it more reliable, accurate, and maintainable It aligns with UX standards set by other CMS platforms (WordPress, Contentful, Sanity, etc.) Environment Strapi Versionv5 (latest)DeploymentSelf-hosted / CloudPlanCommunity (no plugin access) Additional Context This feature has been discussed informally in the community for some time. Autosave is considered a baseline expectation for content editing tools in 2025. I believe adding it natively — even behind a feature flag or admin toggle — would significantly improve the editor experience for all Strapi users. I'm happy to contribute or provide more details about the PoC implementation if helpful.

Referencing to: https://github.com/strapi/strapi/security/advisories/GHSA-g637-9xhc-39qf Currently the initial configuration for strapi is not secure (using wildcard with allow-credential). After discussed with strapi security team, we agreed that this is operator responsibility. However, the current state, the strapi still allows insecure configuration to be deployed without any warning. The security could be improved by blocking the deployment until the operator securely configure the CORS setting. Note that it's currently insecure by default so adding a block will impact compatibility.

Add official support for GaussDB (Huawei openGauss) in Strapi's PostgreSQL dialect. GaussDB is a widely deployed enterprise database in APAC (particularly required for Huawei Cloud / China-region deployments) and is functionally PostgreSQL-compatible when configured with DBCOMPATIBILITY = 'PG' . ### Motivation Customers deploying Strapi on Huawei Cloud or in environments requiring GaussDB currently face a limitation. They cannot use Strapi without patching node_modules after installation. To address this, official compatibility or a documented configuration path would be necessary to enable a significant number of enterprise deployments. ### Environment * Strapi version: 5.45.1 * Node.js: v20.20.1 * Database: GaussDB (for openGauss) V2.0-8.218, Kernel 505.2.1.SPC0800, Centralized Basic edition | * DB compatibility mode: DBCOMPATIBILITY = 'PG' ### Problem On startup, Strapi → Knex executes SELECT version() and parses the result with the regex /^PostgreSQL (.*?)( |$)/. GaussDB returns a vendor-branded banner instead of the standard PostgreSQL format: gaussdb (GaussDB Kernel 505.2.1.SPC0800 ...) TypeError: Cannot read properties of null (reading '1') at Client_PG._parseVersion (.../knex/lib/dialects/postgres/index.js:135:56) Strapi never finishes bootstrapping — the failure happens before any Strapi code runs.

Hi Strapi team, A recurring concern for teams running Strapi as a public-facing backend — form submissions, user-contributed media, community platforms — is that the Upload plugin accepts files with no content inspection. Today this has to be solved out of band, usually with a separate scanner watching the upload folder or the S3 bucket, which creates a window where malicious files are reachable via the Media Library before detection. Would there be interest in either (a) a documented extension point in the Upload plugin for pre-save validation of file bytes, or (b) a first-party "antivirus" plugin that runs ClamAV (local or remote clamd) before the file is persisted? The ergonomic API would be a beforeUpload / afterUpload lifecycle that can reject a file before it reaches the provider, with a typed verdict (clean / malicious / scan_error) so that timeouts and scanner failures don't silently fall through as "clean". In the Node.js ecosystem, the two practical ClamAV wrappers are clamscan and pompelmi. Happy to prototype a plugin if there's interest. Disclosure: I maintain pompelmi ( https://github.com/pompelmi/pompelmi ). This is not a pitch for pompelmi specifically — the underlying gap is Strapi-side and any scanner works.

Summary Add stable data-test-id attributes to DOM elements in the Strapi Admin Panel to enable reliable E2E testing with tools like Selenium and Puppeteer. Problem Currently, the Strapi Admin Panel uses dynamically generated CSS classes, making it difficult to write stable and maintainable E2E tests. Selectors based on dynamic class names break frequently and make test suites brittle. Proposed Solution Add data-test-id attributes to key interactive and structural elements throughout the Admin Panel, including but not limited to: 1. List Views - table elements, rows, action buttons, pagination, filters 2. Edit/Detail Views - content blocks, sections, field groups 3. Form Elements - input wrappers, buttons, validation messages Even partial coverage would be valuable - anything is better than nothing. Starting with the most commonly tested elements (tables, inputs, buttons) would already significantly improve testability.

Opening a feature request as suggested by the bot. We would like to be able to configure the transaction isolation level in the REST API (specially GET request that we use for exporting content) and also specify the transaction isolation level in the request itself (maybe as a request attribute). https://github.com/strapi/documentation/issues/2990

In the admin Content Manager, when bulk unpublishing or deleting entries, there is a confirmation modal with texts like: - "Are you sure you want to unpublish these entries?" "This will unpublish the active locale versions (from internationalization)" "Are you sure you want to delete these entries?" "This will delete the active locale versions (from internationalization)" These strings do not seem to be exposed through the usual src/admin/translations/*.json mechanism, so they remain in English even when the admin interface language is set to Arabic. Why is this important? We are building a fully Arabic admin experience for non‑English editors. All other admin texts can be translated via ar.json, but these critical confirmation messages stay in English and confuse users. Proposed solution Expose these messages via the same i18n system used for other admin texts (e.g. content‑manager translation keys). Expose these messages via the same i18n system used for other admin texts (e.g. content‑manager translation keys).