Plugin API RFC

[alexandrebodin]

Plugin API RFC

This PR introduces the Plugin API.

Because of the size of this RFC it lives outside this repository.

You can read it here

[Lith]

Hi @alexandrebodin,

It's a nice future update 👍

My first question is about the autoloading feature :

• If same plugin's name is load, this will throw an error : that means the project can be broken if the user load a plugin with a same name, and can be obvious. Manage priority folder, and display a warning message can be better ?
• This can produce a misunderstand with extensions feature (for overloading files) ?

Long time ago, I've publish a bug report about documentation of a plugin (generated in extensions folder, instead plugins folder, I think this refactoring need to take in consideration this bug :) A plugin need a documentation to explain how it works and how you can used it, I working with a teammates and sometimes, it's unclear with our custom plugins.

If I understand correctly, the extensions folder will not change, and we will able to overload any plugins with this folder with this new version. For now, I'm part of some user than used extensions to override users-permissions plugin for add provider (like Apple Sign-in) or authorise users to use many connection type with the same email address (by default, we can use only one provider OR custom email, I change this part for better user experience on our services). For now, with every Strapi update, I copy the official files and launch a diff between files, it's clearly ugly and can produce some bugs, I'm dreaming about a magic solution to improve that.

It's not possible for now to fork official plugin, because it's part of Strapi project. So, are you thinking to extrude official plugins and create a Github repo for each one ?

I will continue to work on plugin's projects and read this RFC with attendance. Thanks 😊

[Aurelsicoko]

First of all, excellent work! I'm very excited to read this RFC. It's going to be a huge step for the project, the scalability and quality of the ecosystem 👏

Server API

I've also some concerns about the autoloading feature and the fact that it can be disabled. In the future, we could imagine plugins which would be very content editing oriented (SEO, comments, review, content workflow, theming for the dashboard, etc).

Does it mean every time we install a plugin the server has to restart?

Admin API

Register

app.menu.addSection({
  label: { id: 'upload', defaultMessage: 'Upload' },
  to: '/upload',
  component: Main,
  permissions: [],
});

I'm not a huge fan of the addSection function. I would rather register a plugin id, then a default label.

app.menu.addSection({
  id: 'upload', 
  defaultLabel: 'Upload',
  to: '/upload',
  component: Main,
  permissions: [],
});

Injection Zones

Why the injection zones aren't following a programmatic approach but an object one?

module.exports = () => {
  app.zones.addZone({
    id: 'editView',
    blocks: [
      { name: 'test', Component: (props) => 'button' },
    ],
  });
};

[adegbengaagoro]

Hi Guys,

The RFC is really excellent work. As earlier stated, it would be a huge step forward for the Strapi ecosystem. I think the proposed approach of loading the conflicting plugin under another name is awesome.

[sunnysonx]

Excellent work! What about adding a public folder to plugins? This would allow adding a frontend part outside of the admin panel. As an example, let's say I build a plugin that adds a complete Blog functionality to strapi, It will contain articles, categories, tags, login, register, comments, everything that's needed for a blog, but also the public/frontend part. And for example, it should be accessible under a custom path, defined in plugins.js or in plugin's configuration, or in server.js, idk.

Something like:

./config/server.js:

module.exports = () => {
   //...
    publicFolder: 'default' // for strapi's default public folder
   //... AND
    publicFolder: 'plugin-name' //to use the plugin's public folder
}

After installing the Blog plugin and overwriting the default public folder, there should be a complete blog website accessible at root path of the website.

[stafyniaksacha]

Hello @sunnysonx

What about adding a public folder to plugins? This would allow adding a frontend part outside of the admin panel.

I think that would be out of concern about what strapi is: a headless cms. (It does not aim to serve frontend ui, but only data)
If you really want to use strapi to serve your frontend, you will need to write a custom koa middleware.

[sunnysonx]

Hello @stafyniaksacha, this is why I'm talking about plugins - their role is to extend the basic functionality. Currently, Strapi already uses a Public folder, and switching the path of the default public folder will not break the strapi's concern of headless cms since the frontend will be a part of the custom Plugin and not a part of the Core Strapi.

A good example is WordPress, it was also a blog platform, and nobody was disturbed when woo-commerce extended its functionality by adding a complete e-commerce solution to it and breaking the concern of blog platform. It got more popular after this.

[strapi-cla]

All committers have signed the CLA.

[derrickmehaffy]

This pull request has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/new-version-questions-thoughts-v4/4824/1

[navaru]

I would suggest using generally understood terms, some suggestions:

• bootstrap -> initialize, as in "initialize the system"
• teardown -> terminate, as in "terminate the system"
• policies -> permissions
• resolve: '...' -> resolve is the underlying mechanism, what I declare here in this setting is the entry|source|import of my plugin

Writing technical docs I noticed that people ask questions using generally understood terms, like

• "how do we set permissions for this user?"
• "where do I add the plugin cleanup logic when the process/system terminates?"

Hope this helps.

[laurenskling]

I like that this would allow me to write a (addon) plugin that when installed can change another (base) plugin. This sounds very powerful for writing small deviations for different clients. Very nice.

I also like that it removes some of the import/loading magic. That really confused me when I started using Strapi.

[laurenskling]

There would still be no support for components inside of plugins?

[rikkit]

Really love that the proposal will enable transpilation for plugins - it will be possible to write them in TypeScript. I'm at the point where I use TS for everything apart from Strapi.

[nikushx]

^ just a quick note upload has a typo on the RFC for plugins

[oliversd]

Fantastic work!

I would suggest a standard way to manage plugin information and updates. i.e.:

It could be a file (json, yaml, or other), with this information:

• Author
• URL (landing page, github, etc).
• Last update
• Is an upgrade available?
• Dependencies
• Changelog
• Version compatibility
• Number of downloads? Rating?

I know that a system to update the plugins maybe escapes a little on this phase. But at least know if there is an update, especially when it is a critical one.

[webdelin]

Fantastic work! Create a collection type relartion does not work? Hierarchical Thanks :-)

[MattieBelt]

Create a collection type relartion does not work? Hierarchical

Hey @webdelin, please file a detailed bug report on strapi/strapi, so it can be picked up. Thanks!