loading...

A really hacky way to prevent dev.to posts turning up on your stackbit website by tag

daveparr profile image Dave Parr ・2 min read

Stackbit integration (3 Part Series)

1) I made my dev.to content into a website to find a new job 2) A really hacky way to prevent dev.to posts turning up on your stackbit website by tag 3) Investigating interactions between dev.to and stackbit

So I have found a method to prevent posts with discuss, watercooler, help, etc. turning up in my Stackbit dev.to site by tag. However, I'm actually pretty disappointed with the solution. It's very verbose, very unconfigurable. However, it also does work.

The Dream

The user can put a single line of code into the hugo template that will accept some array type data object that represents multiple tags. That object can then get fed from the config.yaml with some array type data object.

The Opposite of the dream

The opposite of the dream was easy, it was this one line:

{{ range $post := (where $display_posts "Params.tags" "intersect" (slice "Rstats" "rstats" "python")) }}

This commit puts it in more context. This line will
only range the $post variable over the $display_posts that have a tag that is in the slice. So now I just need to invert that.

Warning signs

This post onf the Hugo Discourse Forum was an early find, and a bit disheartening. Still, I cracked on with some more research, and in the end I had to ask for some help.

The 'Ugly' truth

We ended up settling on the most basic of consecutive if else statements, with one line for each of the tags we didn't want. As my very helpful new friend put it:

{{ if in .Params.tags "tag1" }}<!-- nah //-->
{{ else if in .Params.tags "tag2" }}<!-- nah either //-->
{{ else }}
 <Your content here>
{{end}}

This is the commit I ended up with

Why I don't like it

My new buddy was very helpful, and had some interesting info about Schrodingers cat, but I think he also could see this was an imperfect solution. It creates one specific problem for maintenance, and means it's more difficult to implement another related feature:

Maintenance problem

Each time I want to add a new tag to exclude, I need to modify the actual page with new lines of code. Each new tag requires a new line {{ else if in .Params.tags "tag-to-remove" }}

Desired feature

It would be safer and also easier if a data structure in the config.yaml could be used, as then the page template remains removed from the business logic, however as a whole line needs to be added for each tag, I don't see a way that the logic can be abstracted away from the template here, which is a shame

Can you help?

I've written an amount of hugo in side projects, but I'm far from an expert. If you can find a better solution please let me know :)

Stackbit integration (3 Part Series)

1) I made my dev.to content into a website to find a new job 2) A really hacky way to prevent dev.to posts turning up on your stackbit website by tag 3) Investigating interactions between dev.to and stackbit

Posted on by:

daveparr profile

Dave Parr

@daveparr

Data-scientist who loves to use #datascienceforgood, especially in ecology, energy and the environment. Bonsai, gardening, bikes and music when I'm not at a keyboard.

Discussion

markdown guide