Support always-on plugins #714

jamos-tay · 2019-02-20T10:20:34Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes #702

What is the rationale for this request?

Certain plugins are unlikely to be excluded from every project
Support for plugins that are always on by default for every project

What changes did you make? (Give an overview)

Added support for default plugins:

Reside in the src/plugins/default folder
Folder is scanned and all plugins are included
Overriding allowed: If there's a plugin with the same name in the project plugin folder, Markbind will use that one. A warning will be displayed if the default plugin is being overridden so they don't accidentally override
Can be turned off by supplying off to pluginsContext:

{
  ...
  plugins : {
     // Do not need to specify plugin name in plugins
  },
  pluginsContext : {
    "anchors" : {
      "off": true
    }
  }
}

Also:

Convert anchors to default plugins to test it

jamos-tay · 2019-02-20T10:25:40Z

src/plugins/default/anchors.js

+ * Adds anchor links to headers
+ */
+module.exports = {
+  postRender: (content, pluginContext, frontMatter, page) => {


I needed access to Page.headingIndexingLevel, so I added a 4th parameter, page which is the Page object itself... Other plugins might need access to page config so this could be helpful

I'm thinking we can use this for internal plugins, but don't document it in user docs, since we don't want to expose authors to the implementation

I'm just thinking it might be dangerous to pass the entire Page object down to plugins, since that would allow the plugin to modify or invoke the variables and methods of Page which could be dangerous. 😅

What do you think about passing down a copy of the pageConfig object instead? Or maybe having a helper method getDefaultPluginsContext which constructs the context for default plugins and appends it to the other pluginsContext?

Sure, I think I'll do the page config method, I think getDefaultPluginsContext might end up growing pretty large if we have a lot of default plugins =P

This part doesn't seem to be addressed?

marvinchin

Just a couple of questions 🙂

marvinchin · 2019-02-20T14:14:59Z

src/Site.js

+    .filter(plugin => !_.includes(defaultPlugins, plugin))
+    .forEach(plugin => this.loadPlugin(plugin, false));
+  defaultPlugins
+    .filter(plugin => !this.siteConfig.pluginsContext


Just wondering - would using lodash's get method make this more readable? 🙂

Possibly something like this:

_.get(this.siteConfig, ["pluginsContext", plugin, "off"], false)

TIL, thanks

marvinchin · 2019-02-20T14:24:01Z

src/plugins/default/anchors.js

+ * Adds anchor links to headers
+ */
+module.exports = {
+  postRender: (content, pluginContext, frontMatter, page) => {


I'm just thinking it might be dangerous to pass the entire Page object down to plugins, since that would allow the plugin to modify or invoke the variables and methods of Page which could be dangerous. 😅

What do you think about passing down a copy of the pageConfig object instead? Or maybe having a helper method getDefaultPluginsContext which constructs the context for default plugins and appends it to the other pluginsContext?

jamos-tay · 2019-02-22T16:29:46Z

Rebased and updated

docs/userGuide/usingPlugins.md

yamgent · 2019-02-25T02:38:11Z

src/plugins/default/anchors.js

+ * Adds anchor links to headers
+ */
+module.exports = {
+  postRender: (content, pluginContext, frontMatter, page) => {


This part doesn't seem to be addressed?

acjh · 2019-02-26T01:46:05Z

src/Site.js

+ * Finds plugins in the site's default plugin folder
+ */
+function findDefaultPlugins() {
+  const globPath = path.join(__dirname, BUILT_IN_PLUGIN_DEFAULT_FOLDER_NAME);


This assumes all built-in plugins are default plugins (i.e. turned on by default), which is not true.
For example, Algolia search plugin loads unnecessary files in the site if not used, so it should be turned off by default.

Also, this is known at MarkBind dev time. Shall we use a constant as a whitelist?

Currently there's a separate folder for plugins that are always on (BUILT_IN_PLUGIN_FOLDER_NAME vs BUILT_IN_PLUGIN_DEFAULT_FOLDER_NAME)

src/ plugins/ default/ always-on.js ... other default plugins must-be-turned-on.js ... other normal plugins

Plugins that should be off can be placed outside the default folder, where they are treated like normal plugins

I think this might be better than using a whitelist as that has to be hardcoded...

Ah. BUILT_IN_PLUGIN_DEFAULT_FOLDER_NAME → BUILT_IN_DEFAULT_PLUGIN_FOLDER_NAME?

Ah. BUILT_IN_PLUGIN_DEFAULT_FOLDER_NAME → BUILT_IN_DEFAULT_PLUGIN_FOLDER_NAME?

Sounds better 👍.

Sure no problem

jamos-tay · 2019-03-01T13:21:22Z

Updated and rebased

jamos-tay · 2019-03-02T11:50:29Z

Updated, rebased

docs/userGuide/usingPlugins.md

src/Site.js

jamos-tay · 2019-03-07T15:12:03Z

Updated

yamgent

I think you forgot to remove the prefix when obtaining the names of the default plugins, because the example in the documentation no longer works, and I have to do this instead:

  "pluginsContext": {
    "markbind-plugin-anchors": {
      "off": true
    }
  }

jamos-tay · 2019-03-13T08:30:45Z

Sorry for the delay, rebased and updated

yamgent

@nicholaschuayunzhi has some additional comments for this PR, let me post my minor nit first:

src/Site.js

nicholaschuayunzhi

Sorry for my late comments. Perhaps the tests could be done in separate PR?

src/Page.js

src/plugins/default/markbind-plugin-anchors.js

jamos-tay · 2019-03-18T11:54:47Z

Sorry for lateness, updated

yamgent

Apologies for the late reply.

src/Page.js

jamos-tay · 2019-03-26T09:22:01Z

Updated

yamgent · 2019-03-28T08:55:11Z

Travis is currently borked, don't really know why, the builds are all getting stuck. I will return to this PR and merge it when I have the next free time.

Meanwhile the proposed commit message:

Support always-on plugins (#714)

When authors want to use plugins for his website, he or she must
modify site.json to enable them manually. There are no plugins that
are enabled by default.

In the future, there may be built-in MarkBind plugins that should be
enabled by default. For example, we want to move the anchor
functionality into a plugin. However, as there are no default plugins,
MarkBind will have them disabled by default, even though anchors are
a common feature in websites and it would be troublesome for authors
to enable this manually.

Let's add always-on plugins, plugins that are always enabled by default
unless the author specify in site.json to disable them. As a
"proof-of-concept", let's also refactor the anchor logic to an
always-on plugin to demonstrate how always-on plugins can be utilized.

jamos-tay commented Feb 20, 2019

View reviewed changes

marvinchin reviewed Feb 20, 2019

View reviewed changes

jamos-tay force-pushed the always-on-plugins branch from f3b37b0 to 331d1a2 Compare February 22, 2019 16:29

yamgent self-requested a review February 25, 2019 01:51

yamgent approved these changes Feb 25, 2019

View reviewed changes

yamgent added this to the v1.19.2 milestone Feb 25, 2019

yamgent requested changes Feb 25, 2019

View reviewed changes

yamgent removed this from the v1.19.2 milestone Feb 25, 2019

acjh reviewed Feb 26, 2019

View reviewed changes

nicholaschuayunzhi mentioned this pull request Feb 27, 2019

Support page top header #733

Merged

jamos-tay force-pushed the always-on-plugins branch from 331d1a2 to 1a4b7f0 Compare March 1, 2019 13:19

jamos-tay force-pushed the always-on-plugins branch from f1722b8 to e537c54 Compare March 2, 2019 11:50

yamgent reviewed Mar 3, 2019

View reviewed changes

docs/userGuide/usingPlugins.md Outdated Show resolved Hide resolved

src/Site.js Outdated Show resolved Hide resolved

yamgent requested changes Mar 8, 2019

View reviewed changes

yamgent force-pushed the master branch from 7f35131 to 43a048d Compare March 8, 2019 15:01

jamos-tay force-pushed the always-on-plugins branch from d498a4c to 7c8dfbb Compare March 13, 2019 08:28

yamgent requested changes Mar 14, 2019

View reviewed changes

src/Site.js Outdated Show resolved Hide resolved

nicholaschuayunzhi reviewed Mar 14, 2019

View reviewed changes

src/Page.js Show resolved Hide resolved

src/plugins/default/markbind-plugin-anchors.js Show resolved Hide resolved

jamos-tay mentioned this pull request Mar 18, 2019

Write unit tests for plugins #781

Open

jamos-tay force-pushed the always-on-plugins branch from 0aa5e66 to f919f03 Compare March 18, 2019 11:52

yamgent requested changes Mar 21, 2019

View reviewed changes

src/Page.js Outdated Show resolved Hide resolved

jamos-tay added 2 commits March 26, 2019 17:01

Add support for always on plugins

53ff869

Change to plugin config

37e89e8

jamos-tay force-pushed the always-on-plugins branch from f919f03 to 37e89e8 Compare March 26, 2019 09:03

Anchor logic changed caused test value change

13d3377

yamgent approved these changes Mar 27, 2019

View reviewed changes

yamgent added this to the v1.22.1 milestone Mar 27, 2019

yamgent changed the title ~~Support always on plugins~~ Support always-on plugins Mar 28, 2019

yamgent merged commit a2f88a2 into MarkBind:master Mar 28, 2019

acjh mentioned this pull request Dec 18, 2019

Allow live reloading for plugin defined sources #955

Merged

ang-zeyu mentioned this pull request Mar 23, 2020

Inline puml #1100

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support always-on plugins #714

Support always-on plugins #714

jamos-tay commented Feb 20, 2019 •

edited

Loading

jamos-tay Feb 20, 2019 •

edited

Loading

marvinchin Feb 20, 2019

jamos-tay Feb 22, 2019

yamgent Feb 25, 2019

marvinchin left a comment

marvinchin Feb 20, 2019

jamos-tay Feb 22, 2019

marvinchin Feb 20, 2019

jamos-tay commented Feb 22, 2019

yamgent Feb 25, 2019

acjh Feb 26, 2019

jamos-tay Mar 1, 2019 •

edited

Loading

acjh Mar 1, 2019

yamgent Mar 2, 2019

jamos-tay Mar 2, 2019

jamos-tay commented Mar 1, 2019

jamos-tay commented Mar 2, 2019

jamos-tay commented Mar 7, 2019

yamgent left a comment

jamos-tay commented Mar 13, 2019

yamgent left a comment

nicholaschuayunzhi left a comment

jamos-tay commented Mar 18, 2019

yamgent left a comment

jamos-tay commented Mar 26, 2019

yamgent commented Mar 28, 2019

Support always-on plugins #714

Support always-on plugins #714

Conversation

jamos-tay commented Feb 20, 2019 • edited Loading

jamos-tay Feb 20, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marvinchin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamos-tay commented Feb 22, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamos-tay Mar 1, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamos-tay commented Mar 1, 2019

jamos-tay commented Mar 2, 2019

jamos-tay commented Mar 7, 2019

yamgent left a comment

Choose a reason for hiding this comment

jamos-tay commented Mar 13, 2019

yamgent left a comment

Choose a reason for hiding this comment

nicholaschuayunzhi left a comment

Choose a reason for hiding this comment

jamos-tay commented Mar 18, 2019

yamgent left a comment

Choose a reason for hiding this comment

jamos-tay commented Mar 26, 2019

yamgent commented Mar 28, 2019

jamos-tay commented Feb 20, 2019 •

edited

Loading

jamos-tay Feb 20, 2019 •

edited

Loading

jamos-tay Mar 1, 2019 •

edited

Loading