🤖 Update LLMs files [skip ci]

web-flow · web-flow · commit 91c004280a46 · 2026-03-11T13:15:29.000Z
diff --git a/docusaurus/static/llms-code.txt b/docusaurus/static/llms-code.txt
@@ -30314,7 +30314,7 @@ export default ({ strapi }: { strapi: Core.Strapi }) => ({
 
 
 ## Sanitization
-Description: Plugin controllers are plain factory functions and do not extend createCoreController.
+Description: Plugin controllers are plain factory functions and do not extend createCoreController like in the Strapi core (see backend customization for details).
 (Source: https://docs.strapi.io/cms/plugins-development/server-controllers-services#sanitization)
 
 Language: JavaScript
@@ -30541,7 +30541,7 @@ strapi.controller('plugin::plugin-name.controller-name')
 
 
 ## Calling a plugin service from a controller
-Description: The most common pattern: a controller delegates to its own plugin's service.
+Description: The most common pattern: a controller delegates to its own plugin's service:
 (Source: https://docs.strapi.io/cms/plugins-development/server-getters-usage#calling-a-plugin-service-from-a-controller)
 
 Language: JavaScript
@@ -30600,7 +30600,7 @@ export default ({ strapi }: { strapi: Core.Strapi }) => ({
 
 
 ## Calling a plugin service from bootstrap
-Description: Services called in bootstrap() have access to the full strapi instance, including other plugins' services.
+Description: Services called in bootstrap() have access to the full strapi instance, including other plugins' services:
 (Source: https://docs.strapi.io/cms/plugins-development/server-getters-usage#calling-a-plugin-service-from-bootstrap)
 
 Language: JavaScript
@@ -30713,21 +30713,26 @@ Language: JavaScript
 File path: N/A
 
 ```js
-// highlight-start
-const maxItems = strapi.plugin('todo').config('maxItems');       // read a single key
-const todoConfig = strapi.config.get('plugin::todo');            // read the full config object
-const endpoint = strapi.config.get('plugin::todo.endpoint');     // read a nested key
-// highlight-end
+// Read a single key
+const maxItems = strapi.plugin('todo').config('maxItems');
 ```
 
 ---
-Language: TypeScript
+Language: JavaScript
 File path: N/A
 
-```ts
-const maxItems = strapi.plugin('todo').config('maxItems') as number;
-const todoConfig = strapi.config.get('plugin::todo') as Record<string, unknown>;
-const endpoint = strapi.config.get('plugin::todo.endpoint') as string;
+```js
+// Read the full config object
+const todoConfig = strapi.config.get('plugin::todo');
+```
+
+---
+Language: JavaScript
+File path: N/A
+
+```js
+// Read a nested key
+const endpoint = strapi.config.get('plugin::todo.endpoint');
 ```
 
 
@@ -30739,8 +30744,8 @@ Language: JavaScript
 File path: N/A
 
 ```js
-// highlight-next-line
-const schema = strapi.contentType('plugin::todo.task'); // access the content-type schema
+// Access the content-type schema
+const schema = strapi.contentType('plugin::todo.task');
 
 const sanitizedOutput = await strapi.contentAPI.sanitize.output(
   data,
@@ -31141,6 +31146,7 @@ module.exports = [
     path: '/articles',
     handler: 'article.create',
     config: {
+      // highlight-next-line
       middlewares: ['plugin::my-plugin.logRequest'],
     },
   },
@@ -31240,7 +31246,7 @@ export default ({ strapi }: { strapi: Core.Strapi }) => {
 Source: https://docs.strapi.io/cms/plugins-development/server-routes
 
 ## Array format
-Description: The simplest format: export an array of route objects directly.
+Description: The array format is the most basic format: it exports an array of route objects directly.
 (Source: https://docs.strapi.io/cms/plugins-development/server-routes#array-format)
 
 Language: JavaScript
@@ -31296,7 +31302,7 @@ export default [
 
 
 ## Named router format
-Description: Use an object with named keys (admin, content-api, or any custom name) to declare separate router groups.
+Description: With the named router format, use an object with named keys (admin, content-api, or any custom name) to declare separate router groups.
 (Source: https://docs.strapi.io/cms/plugins-development/server-routes#named-router-format)
 
 Language: JavaScript
diff --git a/docusaurus/static/llms-full.txt b/docusaurus/static/llms-full.txt
@@ -11307,7 +11307,7 @@ All server code can technically live in the single entry file, but splitting eac
 
 :::note Notes
 * The entry file accepts either an object literal or a function that receives `{ strapi }` and returns the same object shape. The function form is useful when you need a reference to the Strapi instance at declaration time.
-* `config` is a configuration object, not an executable lifecycle hook. Unlike `register()`, `bootstrap()`, or `destroy()`, it is not called as a function during the plugin lifecycle. It is loaded at startup and used to set defaults and validate user configuration.
+* `config` is a configuration object, not an executable lifecycle hook. Unlike `register()`, `bootstrap()`, or `destroy()`, it is not called as a function during the plugin lifecycle. It is loaded at startup and used to set defaults and validate user configuration. See [server lifecycle](/cms/plugins-development/server-lifecycle) for more information.
 :::
 
 ## Available actions
@@ -11335,7 +11335,7 @@ Use the following table to find which capability matches your goal:
 The following cards link directly to each dedicated page:
 
 :::strapi Backend customization
-Plugin routes, controllers, services, policies, and middlewares follow the same conventions as [backend customization](/cms/backend-customization) in a standard Strapi application. The Server API wraps these into the plugin namespace automatically — see [Content-types](/cms/plugins-development/server-content-types#uids-and-naming-conventions) for details on UIDs and naming conventions.
+Plugin routes, controllers, services, policies, and middlewares follow the same conventions as [backend customization](/cms/backend-customization) in a standard Strapi application. The Server API wraps these into the plugin namespace automatically (see [server content types](/cms/plugins-development/server-content-types#uids-and-naming-conventions) for details on UIDs and naming conventions).
 :::
 
 
@@ -11421,7 +11421,7 @@ This UID is used consistently across all APIs:
 Controllers, services, policies, and middlewares use the same `plugin::<plugin-name>.<resource-name>` UID format for global getters, but are referenced by their short registry key (e.g., `'article'`) within plugin-level APIs such as route `handler` and `policies`. See [Getters & usage](/cms/plugins-development/server-getters-usage) for details.
 :::
 
-## Accessing content-types at runtime
+## Access at runtime
 
 ### Querying with the Document Service API
 
@@ -11471,7 +11471,7 @@ Controllers and services are the 2 building blocks that handle request processin
 
 When your plugin exposes Content API routes, sanitize query parameters and output data before returning them. This prevents leaking private fields or bypassing access rules.
 
-Plugin controllers are plain factory functions and do not extend `createCoreController`. This means the `this.sanitizeQuery` and `this.sanitizeOutput` shorthands are not available. Use `strapi.contentAPI.sanitize` directly instead, passing the content-type schema explicitly:
+Plugin controllers are plain factory functions and do not extend `createCoreController` like in the Strapi core (see [backend customization](/cms/backend-customization/controllers) for details). This means the `this.sanitizeQuery` and `this.sanitizeOutput` shorthands are not available. Use `strapi.contentAPI.sanitize` directly instead, passing the content-type schema explicitly:
 
 </Tabs>
 
@@ -11528,7 +11528,7 @@ Plugin server resources, such as controllers, services, policies, middlewares, a
 
 ### Calling a plugin service from bootstrap
 
-Services called in `bootstrap()` have access to the full `strapi` instance, including other plugins' services.
+Services called in `bootstrap()` have access to the full `strapi` instance, including other plugins' services:
 
 </Tabs>
 
@@ -11540,7 +11540,20 @@ From application-level controllers or services (outside the plugin), or when cal
 
 ### Reading plugin configuration at runtime
 
-</Tabs>
+```js
+// Read a single key
+const maxItems = strapi.plugin('todo').config('maxItems');
+```
+
+```js
+// Read the full config object
+const todoConfig = strapi.config.get('plugin::todo');
+```
+
+```js
+// Read a nested key
+const endpoint = strapi.config.get('plugin::todo.endpoint');
+```
 
 :::note
 `strapi.plugin('my-plugin').config('key')` reads the merged configuration (user overrides applied on top of plugin defaults). It is the recommended way to read config inside plugin code. See [Server configuration](/cms/plugins-development/server-configuration) for how plugin configuration is declared and merged.
@@ -11562,10 +11575,10 @@ Use the content-type getter when you need the schema object, for example to pass
 
 - **Using an incomplete UID in global getters.** `strapi.service('todo.task')` is not a valid plugin UID. Use the full `plugin::todo.task` form. Without the proper namespace, the service call fails or returns `undefined` at runtime.
 
-| Scope | Example UID |
-| --- | --- |
-| Plugin service | `plugin::todo.task` |
-| API service | `api::project.project` |
+  | Scope | Example UID |
+  | --- | --- |
+  | Plugin service | `plugin::todo.task` |
+  | API service | `api::project.project` |
 
 ## Best practices
 
@@ -11656,7 +11669,7 @@ For the full policy reference including GraphQL support and the `policyContext`
 
 ## Middlewares
 
-A middleware is a Koa-style function that wraps the request/response cycle. Unlike policies (which are pass/fail guards), middlewares can read and modify the request before it reaches the controller, and modify the response after the controller has executed.
+A middleware is a Koa-style function that wraps the request/response cycle. Unlike [policies](#policies) (which are pass/fail guards), middlewares can read and modify the request before it reaches the controller, and modify the response after the controller has executed.
 
 Plugins can export middlewares in 2 ways:
 
@@ -11720,7 +11733,7 @@ Routes expose your plugin's HTTP endpoints and map incoming requests to controll
 
 ### Named router format
 
-Use an object with named keys (`admin`, `content-api`, or any custom name) to declare separate router groups. Each group is a router object with a `type`, optional `prefix`, and a `routes` array. Use this format when your plugin exposes both admin and Content API routes.
+With the named router format, use an object with named keys (`admin`, `content-api`, or any custom name) to declare separate router groups. Each group is a router object with a `type`, optional `prefix`, and a `routes` array. Use this format when your plugin exposes both admin and Content API routes.
 
 </Tabs>
 
@@ -11790,7 +11803,7 @@ For configuration examples including policies, public routes, dynamic URL parame
 
 - **Use the named router format when exposing both admin and Content API endpoints.** It makes the intent of each route explicit and avoids relying on the `type` default, which can be surprising.
 
-- **Keep `handler` as a string.** String handlers get automatic auth scope generation. Function handlers do not: authentication still runs for both string and function handlers unless you set `config.auth: false`, but only string handlers get automatic `config.auth.scope`. If you use a function handler and need route-level permission scoping, define `config.auth.scope` explicitly.
+- **Keep `handler` as a string.** String handlers get automatic auth scope generation, function handlers do not. Authentication still runs for both string and function handlers unless you set `config.auth: false`, but only string handlers get automatic `config.auth.scope`. If you use a function handler and need route-level permission scoping, define `config.auth.scope` explicitly.
 
 - **Scope policies to their namespace.** When referencing a plugin policy in a route, use the full `plugin::my-plugin.policy-name` form. This avoids ambiguity if a policy with the same short name exists elsewhere in the application.
 
diff --git a/docusaurus/static/llms.txt b/docusaurus/static/llms.txt
@@ -119,13 +119,13 @@
 - [Plugin structure](https://docs.strapi.io/cms/plugins-development/plugin-structure): Learn more about the structure of a Strapi plugin
 - [Plugins extension](https://docs.strapi.io/cms/plugins-development/plugins-extension): Existing plugins can be overriden by placing code in /src/extensions or using global register/bootstrap hooks. Instructions in this documentation cover reshaping plugin content-type schemas or server logic — altough upstream updates may break extensions.
 - [Server API for plugins](https://docs.strapi.io/cms/plugins-development/server-api): The Server API defines what a plugin registers, exposes, and executes on the Strapi server. It covers lifecycle hooks, routes, controllers, services, policies, middlewares, and configuration. Use the entry file to declare what the plugin contributes, then navigate to the dedicated pages below for each capability.
-- [Server configuration](https://docs.strapi.io/cms/plugins-development/server-configuration): Expose a config object with a default property and a validator function. Strapi deep-merges the defaults with the user's config/plugins file, then runs validation before the plugin loads. Read configuration at runtime with strapi.plugin('my-plugin').config('key').
-- [Server content-types](https://docs.strapi.io/cms/plugins-development/server-content-types): Export a contentTypes object from the server entry file to declare plugin content-types. Each key must match the content-type's info.singularName. The UID follows the plugin:: . convention and is used to query, sanitize, and reference the content-type at runtime.
-- [Server controllers & services](https://docs.strapi.io/cms/plugins-development/server-controllers-services): Controllers handle the HTTP layer: they receive ctx, call services, and return responses. Services hold reusable business logic and interact with content-types through the Document Service API. Keep controllers thin and put domain logic in services.
-- [Server getters & usage](https://docs.strapi.io/cms/plugins-development/server-getters-usage): Access plugin resources through top-level getters (strapi.plugin('my-plugin').service('name')) or global getters (strapi.service('plugin::my-plugin.name')). Both return the same object. Use top-level getters inside your own plugin, and global getters from application code or other plugins. Routes have no global getter equivalent. Configuration uses dedicated config APIs.
-- [Server lifecycle](https://docs.strapi.io/cms/plugins-development/server-lifecycle): Use register() to declare capabilities before the app is fully initialized, bootstrap() to run logic once Strapi is initialized, and destroy() to clean up resources on shutdown. Each function receives { strapi } as its argument.
-- [Server policies & middlewares](https://docs.strapi.io/cms/plugins-development/server-policies-middlewares): Policies run before a controller action and return true or false to allow or block the request. Middlewares run in sequence around the full request/response cycle and call next() to continue. Declare policies and middlewares as objects of factory functions and reference them by their plugin-namespaced name in routes.
-- [Server routes](https://docs.strapi.io/cms/plugins-development/server-routes): Export a routes value from the server entry file to expose plugin endpoints. Use the array format for simple cases, the named router format to separate admin and Content API routes, or the factory callback format for dynamic route configuration.
+- [Server configuration](https://docs.strapi.io/cms/plugins-development/server-configuration): The Server API exposes a config object with a default property and a validator function. Strapi deep-merges the defaults with the user's config/plugins file, then runs validation before the plugin loads. Read configuration at runtime with strapi.plugin('my-plugin').config('key').
+- [Server content-types](https://docs.strapi.io/cms/plugins-development/server-content-types): The Server API exports a contentTypes object from the server entry file to declare plugin content-types. The UID follows the plugin:: . convention and is used to query, sanitize, and reference the content-type at runtime.
+- [Server controllers & services](https://docs.strapi.io/cms/plugins-development/server-controllers-services): Just like the Strapi core, plugins can have controllers and services. Plugin controllers handle the HTTP layer: they receive ctx, call services, and return responses. Plugin services hold reusable business logic and interact with content-types through the Document Service API. Keep controllers thin and put domain logic in services.
+- [Server getters & usage](https://docs.strapi.io/cms/plugins-development/server-getters-usage): Access plugin resources through top-level getters (strapi.plugin('my-plugin').service('name')) or global getters (strapi.service('plugin::my-plugin.name')). Both return the same object. Use top-level getters inside your own plugin, and global getters from application code or other plugins. Routes have no global getter equivalent. Configuration uses dedicated configuration APIs.
+- [Server lifecycle](https://docs.strapi.io/cms/plugins-development/server-lifecycle): The Server API has 3 lifecycle functions. Use register() to declare capabilities before the app is fully initialized, bootstrap() to run logic once Strapi is initialized, and destroy() to clean up resources on shutdown. Each function receives { strapi } as its argument.
+- [Server policies & middlewares](https://docs.strapi.io/cms/plugins-development/server-policies-middlewares): Just like the Strapi core, plugins can have policies and middlewares. Plugin policies run before a controller action and return true or false to allow or block the request. Plugin middlewares run in sequence around the full request/response cycle and call next() to continue. Declare policies and middlewares as objects of factory functions and reference them by their plugin-namespaced name in routes.
+- [Server routes](https://docs.strapi.io/cms/plugins-development/server-routes): The Server API exports a routes value from the server entry file to expose plugin endpoints. Use the array format for simple cases, the named router format to separate admin and Content API routes, or the factory callback format for dynamic route configuration.
 - [Documentation plugin](https://docs.strapi.io/cms/plugins/documentation): The Documentation plugin auto-generates OpenAPI/Swagger docs for your API by scanning content types and routes. This documentation walks you through installation, customizing settings, and restricting access to the docs.
 - [GraphQL plugin](https://docs.strapi.io/cms/plugins/graphql): The GraphQL plugin adds a GraphQL endpoint and Apollo-based sandbox for crafting queries and mutations. Options in config/plugins let you tune depth, item limits, and other Apollo Server settings which are explained in this documentation.
 - [Installing Plugins via the Marketplace](https://docs.strapi.io/cms/plugins/installing-plugins-via-marketplace): The in-app Marketplace lists plugins and providers with badges, search, and “More” links to detailed Strapi Market pages. This documentation outlines browsing cards and following provider-specific instructions to install new integrations.
