Included plugins

By Serdar Yegulalp | 2016/06/30 08:00

Aside from the themes to be bundled with MeTal, I also plan to include a slew of plugins as a way to selectively expand its functionality. Here's some discussion of what I might include.

First, I need to spell out the philosophy of what goes into MeTal.core vs. what goes into MeTal.plugins. To my mind, the core should be all the stuff that is going to be used by the vast majority of the common userbase. Plugins are for expanding on that functionality, or for providing it in ways that are highly dependent on the user's needs.

For instance, one of the standard plugins I plan to bundle with MeTal is one of the first ones I wrote to give the plugin system its current shape: Minify. It's nothing but a plugin to condense the output of HTML from the system. It ships toggled off by default, and once I get some more elaborate settings running I'll allow it to be customized in greater detail -- e.g., toggled off on a per-blog basis, or with different minification rules for blogs. It strikes me as the sort of thing that doesn't really belong in core because it's not something everyone is going to want in the first place, and it's a good test bed for how a plugin should work.

Another plugin I plan to ship by default, but also leave disabled by default, is Transformer.


... uh, no. Transformer is basically a regex-replacement plugin to allow sophisticated transformations of text on output. My original reason for devising it was to perform the kinds of formatting that seem best left for the last stage in publishing a document -- e.g., adding affiliate links, or allow images that follow a certain format to be automatically provided with a copyright caption. These are the kinds of things not everyone will want, but the few that do will make great use of it, so it's another good example of something best left as a plugin.

Another possibility I toyed with was a plugin that would allow integration with Disqus or other comment systems. In truth, I think this is something best left to individual themes, although what I might do is give standard themes the ability to talk to standard plugins, so that there's one standard Disqus plugin that is used by all the themes that integrate with Disqus. Even this might be overkill, though, because from what I can tell the kind of customization I need for Disqus doesn't need to be much more than a user ID -- something that can be provided in a theme's customization panel.

I haven't yet considered plugins that do things like integration with Google APIs or other metrics systems, but I imagine those will be desired somewhere along the way. Those are also good candidates for services provided by a plugin that themes can leverage generically.

So, to sum up:

Tags: core features plugins

comments powered by Disqus