Add to Summernote's features and extend the editors abilities
Plugins
This page is currently a Work In Progress, we welcome contributions to update or add explanations. Please do so either by creating an Issue, or a Pull Request.
Before taking on the journey of building a custom plugin, please visit our official repository awesome-summernote. Which contains user contributed plugins. This may save you a lot of time building your own, or afford you the opportunity to contribute to an already existing plugin, making it better.
Adding a Plugin
Adding a Plugin to Summernote is as easy as adding Summernote to the page you want Summernote to appear in.
Most scripts don’t require you to add a CSS file, although some plugins depending on the functionality of the script may require you to add necessary styles, either inline in the page, or by adding a link to the CSS file to add it’s required styles. Some Plugins may also dynamically add styles to the DOM when initialised.
We typically load the Plugin Script after loading the Summernote Script.
Most scripts are added in the head area of the typical HTML page.
Other things that may need to be loaded along with the plugin file, might be language files, which should follow the plugin inclusion.
For those new to using Javascript, loading Plugins after the main Summernote script, then loading language files if needed are done in this manner as some scripts are designed to execute upon loading and need to be done in order so they have access to functions they may need which would be available in the preceding script. This is more commonly the reason some scripts don’t function correctly until they are put into an order that allows them to function correctly.
Adding the Interactive Modules.
Adding the Interactive Module to Summernote is as easy as calling the options available in Summernote when we initialize the Summernote Editor.
Adding interaction to the Toolbar.
Adding interaction to a Popover
Creating Plugins
For those uninitiated with script styling, we’d like to point out that comments (// This is a comment) inline in the code area’s describe what is happening, or what options you can change in the code areas below the comment. While this may not always be the style of others, we just wanted to make sure while your reading through the examples below that there isn’t any confusion on which parts the comments may be describing.
Language
If your Plugin contains textual context we need to extend the Language lang references within the Summernote script to add our own language references.
To access the language translations variables in your plugin script you can simply use lang.examplePlugin.exampleText.
You can also create language files to link into your pages just like adding language files into Summernote itself, and using the format exactly like the code above.
Plugin Options
This allows us to add options to our plugin to modify behaviour on a user based configuration.
The Plugin Functionality
This section is the Functional part of the Plugin.
The vars below are not all needed, what you need depends on what your trying accompish with your plugin. Most commonly you need self, ui, options, and lang.
This section performs functions when the Plugin is first initialised. Note, this is when the Plugin is loaded, not when the Plugin is used.
See the section “Modal Markup” for element markup options inside Modals.
Modal Markup
This section explains and shows example of the elements and classes that can be used inside Modals.
Note: You can mix the classes from BS3, BS4 (which are similar) and Lite versions so plugins can be version controlled to Bootstrap or not be Bootstrap specific, or they can be made compatible to work with all (the preferred method).
The main problem with using markup elements in Summernote Modals becomes evident when trying to work with elements so they are compatible with all versions of Bootstrap or the Lite version of Summernote. To try and aleviate this, there is a settings variable that can be checked interface, checking this setting within the plugin will return BS3, BS4 or Lite which will allow adding logic control to determine which markup or behaviour the plugin needs use for compatibility, or you can just use a standard layout for the elements and add the appropriate classes to cover all versions (preferred).
Generally, the elements and classes for the version of Bootstrap you want to make a plugin for can use that version of Bootstraps elements, and we have tried, even with the Lite version to keep those as close as we can.
We’ve included some examples below to facilitate constructing Modals a bit quicker for you.
Any classes with note- at their start are primarily the Summernote classes to minimise interfering with other DOM classes that you may be using for other purposes, however, most of the modals use the Bootstrap classes as their primary styling, except for in the Lite version of Summernote, it relies on the note-* classes to style elements.