Plugin Catalog

Let's make plugins more useful, more used, and more plentiful as a consequence. Thoughts articulated here have lead to our current admin tooling.

We've accumulated some forgotten experiments that only confuse those who encounter them. Experiments are fine, but they should drift off into their own corner of the federation. github issue

We've elevated some plugins to the Factory menu but that small place needs to become bigger or more easily managed.

We've had server support for enumerating installed plugins. Lets make it simple to find the about pages for every plugin installed.

We have a list of all plugin names accumulated as we scrape the visible federation. We can find new plugins this way and visit the servers where they are used.

# Usage

Our search tallies the number of sites using each type of plugin. Sometimes these are mistakes that we will eventually clean out. txt

These we install aren't used in normal pages along with their suggested disposition.

efficiency => wardcunningham, moved favicon => core js? linkmap => ?? twadio => wardcunningham, moved

These are plugins in use that aren't in our npm install. We should promote their consistent deployment as independent plugins with git repos and npm packages.

microtalk => npm morseteacher => npm plugins => core js? stats => lost? useless? wikish => @interstar/wiki

Find independent plugin uses with this search.


# Independence

We need a good way to manage updates to a server with independent plugins installed.

■ Created a public script which installs the custom plugins. Remember to run this script each time wiki is installed. There is an example. github

■ Report plugins available on any server. Include factory summary or synopsis. Possibly categorize these as conventional or exceptional. See Plugins Installed Here

■ Too hard: Install a new custom plugin with npm --save followed by a commit and push to a private clone of wiki-node. Merge changes from the upstream in git and then publish this to a public scoped npm module and installing it with npm on all managed servers. npm issue

# Categories

We will categorize plugins based on where they are found and what they can do.

■ Core plugins are required by core javascript and are included within client.js.

■ Standard plugins are well known by name and expected to be present in all servers.

■ Reference plugins demonstrate plugin behaviors and coding techniques encouraged by the fedwiki org.

■ Independent plugins address specific communities while adhering to broadly adopted conventions.

The Factory plugin shows a menu organized by a category declared by the plugin itself. We suggest a fourth column for Advanced Work unique to a community of sites.

■ Format plugins render markup as enhanced text independent of other items.

■ Data plugins retrieve, process, provide or display information for use by other items.

■ Work plugins (new) are those addressing a specific kind of work and recognized by their number on a server.

■ Other plugins declare some category not already included in this breakdown.

The Factory can usefully grow vertically to allow maybe twice as many choices per column. Beyond this, and because some plugins don't interact with the Factory well, a final option, "more", will open an Available Plugins page.

Another alternative would be to design some sort of favorite scheme for obscure plugins of interest to an individual user. The persistence issue alone makes this unattractive. See Managing the Factory Menu

Another alternative would be to just keep a script handly to install all the custom plugins and run that again every time wiki is reinstalled.

npm install \ wiki-plugin-cypher \ wiki-plugin-datscript \ wiki-plugin-efficiency \ wiki-plugin-morseteacher \ wiki-plugin-plugins \ wiki-plugin-shell