[static_comments] Use json / yaml

[sukiletxe]

Of course, encouragement to suggest this came from getnikola/nikola#2801, though it was crossing my mind before.

Rationale: Staticman saves its data in these formats, so this plugin could just render the comments saved by it. This would increase interoperability with other ssgs, as the format for files would be a widely used one.

If used with Staticman, the blog author would need to customize (as the plugin cannot guess his / her configuration for fields). For this reason, I understand that this feature may be out of scope for this plugin (i. e. too abstract).

[ralsina]

But staticman works just fine without any plugins?

http://staticman-demo.netlify.com/posts/sample-post-with-staticman-comments.html

[sukiletxe]

Yup, it does. But, seeing as we have threaded comment support here, plus ready made templates, I thought of asking if we couldcombine the best of both worlds. Plus, this plugin can handle Markdown and HTML, which is nice to have.

[ralsina]

Ok, so, sure!

I don't really know what would need to happen, but if anyone wants to tackle it, it's probably not that difficult :-)

[felixfontein]

Sorry, I didn't notice this thread until now. Sure, it shouldn't be hard to add this.

@ralsina: do you mind if I move the PageCompiler.split_metadata in plugin_categories.py and parts of the _get_metadata_from_file function in post.py to one or two new functions in util.py to make it simpler to reuse the same metadata parsing/splitting in other places, like here?

[ralsina]

No problem.

El sáb., 1 jul. 2017 13:57, Felix Fontein notifications@github.com escribió:

Sorry, I didn't notice this thread until now. Sure, it shouldn't be hard to add this.

@ralsina https://github.com/ralsina: do you mind if I move the PageCompiler.split_metadata in plugin_categories.py and parts of the _get_metadata_from_file function in post.py to one or two new functions in util.py to make it simpler to reuse the same metadata parsing/splitting in other places, like here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/getnikola/plugins/issues/232#issuecomment-312443257, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAGK6PUBBP3ZK_ZBJY8puxR83jrkFdYks5sJnp7gaJpZM4No6m4 .

[felixfontein]

Ok, I guess I forgot about getnikola/nikola#2830. Maybe it is/was not a good idea to extract these functions. I think we should wait how getnikola/nikola#2830 evolves before implementing this.

[felixfontein]

I now added a new version using the new metadata extraction capabilities of Nikola introduced in getnikola/nikola#2861, which will be available in Nikola v8 (and can currently be used in the Nikola master branch).

The metadata parsing expects the same metadata structure as in the old plugin, there are currently no converters as for Nikola's metadata parsing code. Also (as before), the parser doesn't like headers it doesn't know about. If you want that changed, give me examples where this is useful :)

[sukiletxe]

OK, so I feel guilty now for not replying. Thing is, I've been using Staticman as a comment system with data files for more than one year. I've regretted not coming back to you (mainly because it was my idea), but decided I might as well make the changes on my own. But then, seeing as the system turned out to be good enough for my needs and that I haven't got any comments besides spammy ones for a long time I let it go.

And now comes getnikola/nikola/issues/3311, and I feel I need to explain things just in case things break for the author of that when integrating things.

Aside from integrating Staticman with the repository (look in its issues for that, the main docs are outdated), the most obvious issue is that of post location. Given that comment_form exposes post._base_path (cache/path/file.html) you will have to work with that to construct the comment's filename (or subclass post or something which I don't know how would be done). Second, the extension of the post will be the standard one (yml, json, can't remember if any other). And lastly, staticman uses a field in the output for storing the content of the comment instead of having a concept of a header (so like in standard forms you designate the destination when building the form and it gets mapped to a key in the output). It's quite flexible so you should be able to adjust the rest in Staticman itself.

[sukiletxe]

The first issue I mention doesn’t really apply here, it only applies if you use the builtin tools. So disregard it.

[sukiletxe]

As I didn't do the right thing and rtfm / rtfc, I didn't realise Staticman supports frontmatter format (set transforms object in config with the key of a field an value 'frontmatterContent') with custom extension. So I can set the extension to wpcomment and forget about the other things I said, just by stripping path and extension components from post._base_path everything should be fine to work with my custom helper (to show the form to submit comments as always) and (optionally) the static_plugins plugin to show the comments themselves. When staticman gets up again, I'll test this and update, because this should have been closed a long time ago. Also, @felixfontein, would you mind that if this works I send a pr with info in readme about this?

(Note: Frontmatter format works by putting the top fields in valid yaml and the rest separated, just like the plugin expects (or that should be in theory))