Twigfeeds RSS Feed Labelling/Categorisation

1

I’m working with the very nice Twigfeeds plugin and wondered if anyone else had ever done any work to group feeds by some kind of label, using this plugin. I’d like to be able to group feeds into ‘News’, ‘Blogs’, ‘People’ or ‘Organisations’ or other categorisation, and then sort them into being displayed in a template according to their label/category. Maybe this could be done either by adding another field to the form in the plugin for a label or category, or maybe having some method of doing this in a template by assigning a category there. (NB Im not looking to store any of the feed results.)

I’m already using a simple if/else to display Bluesky and Mastodon feeds with a slightly different template to ‘normal’ blog feeds, due to them not having an item title, so maybe this method of sorting could be extended further for categorisation.

Any ideas welcome on this.

2

Ive made some progress on this, but am stuck at the point where I think I need to add ‘category’ to a php array in some way. Possibly either to twigfeeds.php or to Manifest.php.

Ive added ‘category’ to the plugin blueprints and languages yaml files, with relevant info:

user/plugins/twigfeeds/blueprints.yaml

      .category:
          type: text
          label: PLUGIN_TWIGFEEDS.ADMIN.OPTIONS.TWIG_FEEDS.CATEGORY.LABEL
          description: PLUGIN_TWIGFEEDS.ADMIN.OPTIONS.TWIG_FEEDS.CATEGORY.DESCRIPTION

user/plugins/twigfeeds/languages.yaml

          CATEGORY:
            LABEL: Category
            DESCRIPTION: A name for the category, eg people or news

Ive also added category info to a few feed sources in user/config/plugins/twigfeeds.yaml. Eg:

    source: 'https://rss.app/feeds/aCP6dUDhK6NHoftc.xml'
    name: 'Rob Kitchin'
    start: 0
    end: 3
    cache_time: null
    category: people

This all shows up in the Twigfeeds plugin admin panel.

Adding {{ category }} to the twig template would make the category info show up (if it’s defined!) so I need to add something to the php somewhere. I get an error at the moment of "Undefined array key "config_file"", referring to line 117 in Manifest.php - $this->configFile = $config['config_file'];. Im thinking tis may well refer to something defined somewhere else, eg twigfeeds.php. Maybe not. I dont know.

So Im stuck. Ive looked a lot at where might be how to do this but at the moment I cannot figure it out.

3

Update.
I think I solved it. I was wrong about having to add anything to any php file. The solution was very simple. If everything is in place as shown in the previous post, just use {{ feed.category }} to call each group in twig templates and it works. This means that it is now possible to groups feeds into various categories that can be collected together or shared into other areas as a single group of feeds.

4

That is a rather elegant solution, adding metadata where it was not originally expected and utilizing it to organize the data. I added it to the README for future reference.

1 Like
5

Thanks, I really appreciate that. It’s a very good plugin, but I think with categorisation it provides a lot more power, as we can now manage a greater number of feeds in very specific ways. RSS is enjoying a bit of a renaissance due to bigtech negativity so maybe this contributes positively to that.

I was wondering, should I move the customised blueprints and languages yaml files to the user/config area to avoid being overwritten in an update process?

6

Yes, that would preserve your overrides. And as far as I can recall that’s picked up by the internals.

7

Unfortunately it breaks the plugin if you move blueprints and languages yaml files to user/config/plugins, even if they’re loose in that folder. So best to just keep a record of changes/additions to those files and then replace after any plugin upgrade.

(For the benefit of new users, twigfeeds.yaml in user/config/plugins would be unaffected by updating the plugin.)

Edit

I noticed that in the github readme the urls for the blueprints and languages files are incorrect. They should be user/plugins/twigfeeds/blueprints.yaml and user/plugins/twigfeeds/languages.yaml. So, not in the user/config.

8

I’ll change it to that. My memory on this is a bit sketchy, as it’s been a few years since I worked with advanced and programmatic manipulation of blueprints. The files likely have to co-exist as the original source within user/plugins/twigfeeds/*, and be overridden by user/config/plugins/twigfeeds/*. This should be handled without extra effort by Grav and Admin’s internals, but could possibly need extending.

In any case, it’s a worthwhile use-case to add the user-defined or default taxonomy to the plugin’s blueprint from site.yaml. If someone wants to wrestle a bit with it, it would be a good pull request to merge, and a good addition to the Cookbook-section of the docs.

9

Yes you are right re placing duplicate files in the user/config/plugin - I forgot that you don’t move them, you duplicate and edit, to override in a hierarchy of processing. That seems to work fine.
Update - unfortunately, placing languages and blueprint yaml files (duplicates, edited) in user/config/plugins does not override the standard plugin form, which loses the ‘category’ field. The front end is intact which was why I initially thought it worked (duh) but blueprints and languages are backend only and dont seem to override.

Ive already thought about how default taxonomies might work with this - I’ll look into it a bit (as I run various taxonomy stuff in my other Grav site) and test with template calls. Its probably beyond my skillset to go into it deeply in terms of your repo or the official docs etc but Im happy to help if I can.

10

As it turns out, there’s quite a lot about how blueprints are handled that cause issues. I’ve revised the README and published a pre-release in v5.1.0-beta.1, which solves this minimally by destructuring blueprints.yaml into blueprints/plugins/twigfeeds/*.yaml. The superfluous path is necessary for user/blueprints/plugins/twigfeeds/*.yaml to work without programmatic interference.

The natural solution to allow for default taxonomies would be:

form:
  options:
    fields:
      twig_feeds:
        fields:
          .taxonomy:
            type: taxonomy
            multiple: true
            validate:
              type: array

But in testing that almost without fail caused some cyclical regression that exhausted memory and crashed the site. Regardless, the new structure allows for any form-fields to be utilized.

If you have opportunity to test the beta, that would be appreciated.

11

Apologies for slow response. Ill try to test locally and remotely in next few days.