Bookstack: Add plugin/module support

Created on 15 Jun 2016  路  8Comments  路  Source: BookStackApp/BookStack

I am suggesting an API for plugins/modules should be developed to encourage extention of bookstack functionality according to need by laravel developers

Open to discussion Enhancement

Most helpful comment

I thought about adding support for up/downvoting aticles or books. Something like the system of GitHub.
Would be nice if i could just bundle it up in a plugin and throw in a folder or something along those lines.

All 8 comments

What plugins are you suggesting?

@patoroco I would like to have templates/skeletons for the doc. At the moment we just have one template.

Title
Content

That's would be awesome to have the possibility to create custom fields so if you create a doc for an item in the cartegory A before to create the page you can chose a template.

WEB api to Create documentation automatically based on other systems

It would be great if you added extensibility / plug-in capabilities to BookStack so that dynamic content from other databases can be displayed. See for example confluence and documize.

EDIT: To be more clear, it should be easy for someone hosting a BookStack app to install/remove in-house developed plug-ins / user macros.

I thought about adding support for up/downvoting aticles or books. Something like the system of GitHub.
Would be nice if i could just bundle it up in a plugin and throw in a folder or something along those lines.

Or a plugin to auto sort pages/chapters. Or a plugin to allow the markdown editor to have a "helper" of sorts, something like SimpleMDE (https://simplemde.com/) where bulleted lists are much easier to auto type the next line.

Or a plugin to allow users to mark favorite items (pages, books, etc).

Just copying in my response from #1373 since it's relevant for anyone wanting an update on some sort of official plugin system.

Are plugins planned?

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'll attract less-technically capable users.

I hope that provides some insight!

Was this page helpful?
0 / 5 - 0 ratings