are plugins planned? #1126

New Issue

OVERLORD · 2026-02-04T23:52:48+03:00

OVERLORD commented

2026-02-04 23:52:48 +03:00

Originally created by @ezzra on GitHub (Apr 5, 2019).

In the roadmap it is stated

A REST API covering, at minimum, control of core content models (Books, Chapters, Pages) for automation and platform extension.

does "extension" mean here that the software should become ready for plugins? Like, that features can be created by external programmers and implemented as a plugin if the instance administrator needs it? That would also require hooks in the frontend etc.

Or is it just thought for external control of the database actions?

Originally created by @ezzra on GitHub (Apr 5, 2019). In the roadmap it is stated > A REST API covering, at minimum, control of core content models (Books, Chapters, Pages) for automation and platform extension. does "extension" mean here that the software should become ready for plugins? Like, that features can be created by external programmers and implemented as a plugin if the instance administrator needs it? That would also require hooks in the frontend etc. Or is it just thought for external control of the database actions?

OVERLORD added the :octocat: Admin/Meta ❓ Question labels 2026-02-04 23:52:48 +03:00

OVERLORD closed this issue

2026-02-04 23:52:53 +03:00

OVERLORD commented

2026-02-04 23:53:03 +03:00

@ssddanbrown commented on GitHub (Apr 6, 2019):

Hi @ezzra,

Short Answer: No

Long Answer: Kind of. The REST API item on the roadmap is really just intended to cover an externally accessible way to perform actions and fetch content from BookStack for the purpose of extension, connection and automation.

For interface-based stuff we'll have the theming system, which already exists but is undocumented and unstable. This allows you to make overrides on a selective, per-blade-view level basis. There's still a fair bit of view changes I want to do to before documenting this and I'm looking to make the application JS functionality more accessible. (Let me know if you want details of using this system if you have not already found it).

I think the REST API and theming system combined will introduce loads of possibilities for extension and customization.

In terms of offering the ability to add pre-packaged "plug-ins", that customize both UI and functionality, This is something I'm not really looking to implement/support right now for the following reasons:

BookStack is intended to be pre-packaged, set-up and go application with much of it's core functionality ready to go with a sensible design. It's not really intended to be a "base platform" which people build upon using plugins. There are other, more mature, wiki systems that take the base+plugin approach and here is where I think BookStack differentiates.
I don't really have the time or capability to support a "plug-in" ecosystem technically. The REST API and theme system are fairly well defined with focused scope whereas a "plug-in" system would be rather open to interpretation and likely spawn many further requests and support instances. In addition, I feel we'd also get an influx of issues from those wanting support for plugins created by others which again would be hard to support.
A plug-in system would be another project-wide consideration that would slow down usual development.

Don't get me wrong though, I can totally see why people would want a plugin system but, for the above reasons, I don't think It's something the project can support at this stage of its life.

Once the REST API and theme system have bedded-in for a little while I'd imagine we'd look to integrate those bits a little further to empower development-minded folks that want to dig a little deeper but I'd be hesitant of brand that as a "Plugin-in" system as it'll open things up to my points above as it's attract less-technically capable users.

I hope that provides some insight!

@ssddanbrown commented on GitHub (Apr 6, 2019): Hi @ezzra, Short Answer: No Long Answer: Kind of. The REST API item on the roadmap is really just intended to cover an externally accessible way to perform actions and fetch content from BookStack for the purpose of extension, connection and automation. For interface-based stuff we'll have the theming system, which already exists but is undocumented and unstable. This allows you to make overrides on a selective, per-blade-view level basis. There's still a fair bit of view changes I want to do to before documenting this and I'm looking to make the application JS functionality more accessible. _(Let me know if you want details of using this system if you have not already found it)._ I think the REST API and theming system combined will introduce loads of possibilities for extension and customization. In terms of offering the ability to add pre-packaged "plug-ins", that customize both UI and functionality, This is something I'm not really looking to implement/support right now for the following reasons: 1. BookStack is intended to be pre-packaged, set-up and go application with much of it's core functionality ready to go with a sensible design. It's not really intended to be a "base platform" which people build upon using plugins. There are other, more mature, wiki systems that take the base+plugin approach and here is where I think BookStack differentiates. 2. I don't really have the time or capability to support a "plug-in" ecosystem technically. The REST API and theme system are fairly well defined with focused scope whereas a "plug-in" system would be rather open to interpretation and likely spawn many further requests and support instances. In addition, I feel we'd also get an influx of issues from those wanting support for plugins created by others which again would be hard to support. 3. A plug-in system would be another project-wide consideration that would slow down usual development. Don't get me wrong though, I can totally see why people would want a plugin system but, for the above reasons, I don't think It's something the project can support at this stage of its life. Once the REST API and theme system have bedded-in for a little while I'd imagine we'd look to integrate those bits a little further to empower development-minded folks that want to dig a little deeper but I'd be hesitant of brand that as a "Plugin-in" system as it'll open things up to my points above as it's attract less-technically capable users. I hope that provides some insight!

OVERLORD commented

2026-02-04 23:53:08 +03:00

@ssddanbrown commented on GitHub (Apr 20, 2019):

Will now close this, Further discussion can be added in #127 if required.

@ssddanbrown commented on GitHub (Apr 20, 2019): Will now close this, Further discussion can be added in #127 if required.

OVERLORD referenced this issue

2026-02-05 00:28:11 +03:00

Ability to control meta description #1274

OVERLORD referenced this issue

2026-02-05 00:28:15 +03:00

Ability to control meta description #1274

OVERLORD referenced this issue