Plugin structure
When creating a plugin with Plugin SDK, Strapi generates the following boilerplate structure for you in the /src/plugins/my-plugin
folder:
- TypeScript-based plugins
- JavaScript-based plugins
. # root of the plugin folder (e.g., /src/plugins/my-plugin)
├── admin # Admin panel part of your plugin.
│ ├── src
│ │ ├── components # Contains your front-end components
│ │ │ ├── Initializer.tsx # Plugin initializer
│ │ │ └── PluginIcon.tsx # Contains the icon of your plugin in the main navigation
│ │ ├── pages # Contains the pages of your plugin
│ │ │ ├── App.tsx # Skeleton around the actual pages
│ │ │ └── HomePage.tsx # Homepage of your plugin
│ │ ├── translations # Translations files to make your plugin i18n-friendly
│ │ │ ├── en.json
│ │ ├── utils
│ │ │ └── getTranslations.ts # getTranslations function to return the corresponding plugin translations
│ │ ├── index.ts # Main setup of your plugin, used to register elements in the admin panel
│ │ └── pluginId.ts # pluginId variable computed from package.tsxon name
│ ├── custom.d.ts # Generated types
│ ├── tsconfig.build.json
│ └── tsconfig.json # TypeScript compiler options for the admin panel part
├── dist # Build of the plugin (front end and back end)
├── node_modules
├── server # Back-end part of your plugin
│ ├── src
│ │ ├── config
│ │ │ └── index.ts # Contains the default server configuration
│ │ ├── content-types # Content-types specific to your plugin
│ │ │ └── index.ts # Loads all the plugin's content-types
│ │ ├── controllers # Controllers specific to your plugin
│ │ │ ├── index.ts # Loads all the plugin's controllers
│ │ │ └── controller.ts # Custom controller example. You can rename it or delete it.
│ │ ├── middlewares # Middlewares specific to your plugin
│ │ │ └── index.ts # Loads all the plugin's middlewares
│ │ ├── policies # Policies specific to your plugin
│ │ │ └── index.ts # Loads all the plugin's policies
│ │ ├── routes # Routes specific to your plugin
│ │ │ └── index.ts # Contains an example route for the my-controller custom controller example
│ │ ├── services # Services specific to your plugin
│ │ │ ├── index.ts # Loads all the plugin's services
│ │ │ └── service.ts # Custom service example. You can rename it or delete it.
│ │ ├── bootstrap.ts # Function that is called right after the plugin has registered
│ │ ├── destroy.ts # Function that is called to clean up the plugin after Strapi instance is destroyed
│ │ ├── index.ts # Entrypoint for the server (back end)
│ │ └── register.ts # Function that is called to load the plugin, before bootstrap.
│ ├── tsconfig.build.json
│ └── tsconfig.json # TypeScript compiler options for the server part
├── .editorconfig
├── .eslintignore
├── .gitignore
├── .prettierignore
├── .prettierrc
├── package-lock.json
├── package.json
└── README.md
. # root of the plugin folder (e.g., /src/plugins/my-plugin)
├── admin # Admin panel part of your plugin.
│ ├── src
│ │ ├── components # Contains your front-end components
│ │ │ ├── Initializer.jsx # Plugin initializer
│ │ │ └── PluginIcon.jsx # Contains the icon of your plugin in the main navigation
│ │ ├── pages # Contains the pages of your plugin
│ │ │ ├── App.jsx # Skeleton around the actual pages
│ │ │ └── HomePage.jsx # Homepage of your plugin
│ │ ├── translations # Translations files to make your plugin i18n-friendly
│ │ │ ├── en.json
│ │ ├── utils
│ │ │ └── getTranslations.js # getTranslations function to return the corresponding plugin translations
│ │ ├── index.js # Main setup of your plugin, used to register elements in the admin panel
│ │ └── pluginId.js # pluginId variable computed from package.json name
│ └── jsconfig.json
├── dist # Build of the plugin (front end and back end)
├── node_modules
├── server # Back-end part of your plugin
│ ├── src
│ │ ├── config
│ │ │ └── index.js # Contains the default server configuration
│ │ ├── content-types # Content-types specific to your plugin
│ │ │ └── index.js # Loads all the plugin's content-types
│ │ ├── controllers # Controllers specific to your plugin
│ │ │ ├── index.js # Loads all the plugin's controllers
│ │ │ └── controller.js # Custom controller example. You can rename it or delete it.
│ │ ├── middlewares # Middlewares specific to your plugin
│ │ │ └── index.js # Loads all the plugin's middlewares
│ │ ├── policies # Policies specific to your plugin
│ │ │ └── index.js # Loads all the plugin's policies
│ │ ├── routes # Routes specific to your plugin
│ │ │ └── index.js # Contains an example route for the my-controller custom controller example
│ │ ├── services # Services specific to your plugin
│ │ │ ├── index.js # Loads all the plugin's services
│ │ │ └── service.js # Custom service example. You can rename it or delete it.
│ │ ├── bootstrap.js # Function that is called right after the plugin has registered
│ │ ├── destroy.js # Function that is called to clean up the plugin after Strapi instance is destroyed
│ │ ├── index.js # Entrypoint for the server (back end)
│ │ └── register.js # Function that is called to load the plugin, before bootstrap.
├── .editorconfig
├── .eslintignore
├── .gitignore
├── .prettierignore
├── .prettierrc
├── package-lock.json
├── package.json
└── README.md
A Strapi plugin is divided into 2 parts, each living in a different folder and offering a different API:
Plugin part | Description | Folder | API |
---|---|---|---|
Admin panel | Includes what will be visible in the admin panel (components, navigation, settings, etc.) | admin/ | Admin Panel API |
Backend server | Includes what relates to the backend server (content-types, controllers, middlewares, etc.) | server/ | Server API |
Server-only plugin: You can create a plugin that will just use the server part to enhance the API of your application. For instance, this plugin could have its own visible or invisible content-types, controller actions, and routes that are useful for a specific use case. In such a scenario, you don't need your plugin to have an interface in the admin panel.
Admin panel plugin vs. application-specific customization: You can create a plugin to inject some components into the admin panel. However, you can also achieve this by creating a
/src/admin/index.js
file and invoking thebootstrap
lifecycle function to inject your components. In this case, deciding whether to create a plugin depends on whether you plan to reuse and distribute the code or if it's only useful for a unique Strapi application.
The next steps of your Strapi plugin development journey will require you to use any of the Strapi plugins APIs.
2 different types of resources help you understand how to use the plugin APIs:
- The reference documentation for the Admin Panel API and Server API give an overview of what is possible to do with a Strapi plugin.
- Guides cover some specific, use-case based examples.