Feature request: tags plugin

Issue #8 resolved
Sergey Astanin
created an issue

Please find a tags plugin in this commit.

It depends on the PR #2. Bitbucket doesn't let me create a new PR, unless that one is accepted. Hence, this issue.

Comments (7)

  1. Sergey Astanin reporter

    I don't quite understand how your plugin works. Who and when builds site["tags"]? Why you site.get["pages"] twice and discard them the second time? Are site["tags"] available in normal page templates (it's necessary to build an index of all used tags)?

    My plugin is a little longer but more explicit. It builds a table of all used tags first. It generates all per-tag pages later. Global tags table is available in all templates. It requires only two steps: 1) drop a plugin file into _plugins, 2) (optionally) create a specially named tag page template, which is a perfectly normal template, and can use standard layout. The generated files are put where their source is.

    In your plugin there is an indirection via _config.yml, the generated files appear where there is nothing in the tree. The corresponding templates are located elsewhere. Shorter code, messier site config. Obraz is already quite hard to get started.

    It would be kind of you to name your plugin differently, to avoid name clashes.

  2. Andrey Vlasovskikh repo owner

    site['tags'] is defined by Jekyll and supported by Obraz, see this line. But there is no standard way in Jekyll to generate tag pages.

    The second site.get('pages') without assignment was a mistake, I've already deleted this line.

    My intention was to simplify tags configuration by providing an implicit default config. I'm not sure about it.

    Of course you can use your tags plugin. If you're fine with it, then just update it a little bit when a new documented plugin interface will appear in Obraz 0.4. The name of the plugin doesn't matter, it's just a tags plugin, not the tags plugin. Note that my tags plugin is for Obraz the site, not for Obraz the tool. Maybe I will put it in a separate plugins repository, but I'm more comfortable with just a page containing links to different plugins, so I will not have to manage all the plugins/requests/etc.

  3. Sergey Astanin reporter

    I'll definitely update my plugin when 0.4 is out.

    BTW, I propose to create a contrib/ subdirectory in the source distribution, which could be a central repository of user-contributed plugins. Every plugin goes to a separate subfolder, with a README, and a minimal working example to get started. That would make easier to (1) discover existing plugins, (2) enable and configure them, and (3) be an example of how to write and contribute your own. There are already plugins and examples in the tests subfolder, but that way they are no discoverable. Examples could be written with a human reader in mind, rather than nosetests...

    An alternative is to setup a separate obraz-contrib repo, but I don't think we are getting so many contributions any time soon.

  4. Log in to comment