Plugin hooks in posts processing

[eldh]

We should add hooks for plugins (and themes?) in the posts processing.

Core (paths.js) collects all the posts and process them one by one. We should lift out the processing to a separate file, then add hooks for plugins before and after the core processing. We should also add a hook for replacing the core processing.

Something like preProcess(), process() and postProcess().

[eldh]

Ok, now we have preProcessPosts(posts) and postProcessPosts(posts) hooks implemented. It looks in both theme/functions and antwar.config.js for functions. At this time there is still no plugin support, but the hooks system is prepared for it.

We just need to figure out how we want to define plugins. The nicest would be just an array om plugin names, but that will require some webpack alias magic to avoid doing require(unknownPluginName).

Second thing we need to do is to implement similar hooks for things inside the processing of each post, like url, date or even content. But I'll create a separate task for that.

[bebraw]

From antwar.config.js point of view the interface explained at #11 is likely enough. You just provide an object of objects (plugin name -> configuration). Plugin name maps to NPM by default but we could support paths just like in case of themes right now to make it more versatile.

A plugin itself could look something like this (index.js):

module.exports = {
    preProcess: function(...) {},
    process: function(...) {}, // needed???
    postProcess: function(...) {},
}

This would be enough. We can add more hooks if/when needed.

[eldh]

Skipping process(), at least for now. Otherwise that looks good.

If we assume plugins are installed in the site folder I suppose we can require("plugin/"+pluginName) and have an alias: {'plugins': cwd + '/node_modules'}

[eldh]

Didn't get the require("plugin/"+pluginName) strategy to work. We have to think of some other way. One alternative is that the config file just gives an array of plugin objects. That would mean they are required from within the config file and we don't have to care if they are npm modules, local things or just something that's declared directly in the config file.

Something like:

plugins:  [
    require('a-plugin-from-npm'),
    {preProcessPosts: function(posts){…}},
    require('./local-plugin.js')
]

Not sure that would work?

[bebraw]

Yeah, I can see your point. Isn't that analogous to how functions work now? Given that I can't see why this would fail.

[eldh]

I only see a possible issue with doing require's from there. But I'll try it.

[bebraw]

As far as I can see preProcess/postProcess works now, even with require. I set up a demo plugin to try this out, https://github.com/antwarjs/prevnext-plugin .

While at it I simplified the plugin contract a little bit (no need for extra functions key). I think this might have been your original intention given the example above.