Excluding a content type from related posts?

I just moved my blog from Wordpress to Hugo, and am loving being back on a static site generator (I used Blosxom back in the before time). I’ve got my site working great, but after adding a bunch of content exported from Wordpress, it’s taking a long time to generate the site. It looks like enabling relatedposts adds about a minute to site generation.

I have 2 content types - posts (2,821 entries) and photos (4,953 entries). I use tags and categories for posts, but don’t need them for photos (they’re just a simple post with an image and maybe a sentence of text - basically replacing flickr etc. for posting photos).

Any ideas for how I could exclude the photos content type from relatedposts, and I guess to prevent photos from being included in the tags taxonomy list?

The site’s live at https://darcynorman.net and the tags list is at https://darcynorman.net/tags (it’s… a long page with the photos content type included)

You would need to change some things around. First of all, if you REALLY have two post types post and photos you could create two new taxonomies called photo-tags and photo-categories and then use two sets of tempates calling the indexes like {{ $related := .Site.RegularPages.RelatedIndices . "tags" }} and {{ $related := .Site.RegularPages.RelatedIndices . "photo-tags" }}

By the way: Do your photos have tags and categories? Leave them out of the frontmatter and they will not be listed. But I think what you want is two new taxonomies to separate posts from photos.

I am not sure if I understand you correctly.

What exactly do you mean by “enabling relatedposts”?

Thanks for your thoughts on this. It’s pretty likely that I’m doing something stupid in migrating everything from WordPress. There are 2 separate content types content/posts (which were the Post content type in WP) and content/photos (which were the Image content type in WP, mostly, and had a category of “ephemera”). I’ve excluded photos from the main page through the config.toml line mainSections = [“posts”].

The export from WP included all tags and categories - I might get to either edit each of the 2,821 files or set up WP again to re-export without tags. Or maybe I’ll be able to try a script that nukes the tags from front matter in those .html files. I may take the opportunity to just retire that content and not worry about carrying it forward. Digital hoarding? Maybe I’ll get a show on TLC!

sorry - I was a bit ambiguous there. I’m using the beautifulhugo theme, which is fantastic. It can display related posts in a “See also” section at the bottom of single pages, and that feature is enabled by showRelatedPosts = true in my site’s config.toml. That seems to add a bunch of processing time, of course, because it’s matching up dates/tags/categories to find related posts for each post. It’s super useful for following a trail through the published site.

That was pretty straightforward. I did a multi-file search/replace in BBEdit, using this grep pattern on the folder of photos html files exported from WordPress. It removes categories and tags from front matter (and anything that might have strayed between them and the end of front matter, but that wasn’t a concern for these files)

(?s)categories:(.*?)[-][-][-]

replaced with
---

I never experienced an export from Wordpress without lots of rework… half of my blog (posts from 2005 to today) is still having weird stuff in their frontmatter. It’s a lot of preg-replacing… The problem is always that there is lot’s of thought behind how it’s set up and special requirements don’t “drop” through the exports well.

Did your replacing solve your issue?

Hugo has a built-in “Related Content” feature which is very fast. But it is also possible to “implement your” own, which is usually very slow. I don’t have time to investigate the theme in question, but I’m guessing it has “implemented its own”.

thanks - yeah, I think I have things working nicely now.

 +----------------+-------+
 Pages            | 10344  
 Paginator pages  |  1498  
 Non-page files   |     0  
 Static files     |   202  
 Processed images |     0  
 Aliases          |  1279  
 Sitemaps         |     1  
 Cleaned          |     0  

 Total in 40230 ms

I can live with a 40 second build time. Jekyll was taking over 45 minutes for the same files…

No worries. I may have misunderstood how it was implemented, too. It’s likely just exposing built-in functionality. Looks like it’s working better now that I’ve removed tags from the 4,900 photo items.

You’re right @bep.

@dnorman: The beautifulhugo them uses intersect & Co. For exemple in single.html (https://github.com/halogenica/beautifulhugo/blob/f838d06d8477b19a3764d7c07f168138d2a7aea1/layouts/_default/single.html)

{{ range first 1 (where (where .Site.Pages ".Params.tags" "intersect" .Params.tags) "Permalink" "!=" .Permalink) }}

or

{{ range first $num_to_show (where (where .Site.Pages ".Params.tags" "intersect" .Params.tags) "Permalink" "!=" .Permalink) }}

You probably should read: https://www.regisphilibert.com/blog/2018/04/hugo-optmized-relationships-with-related-content/

1 Like

yeah - removing the categories and tags from the photo .md files definitely helped. I also figured out that beautifulhugo was using a custom related-posts feature, so I removed that and replaced it with the native Hugo feature and it’s much faster as well.

1 Like

thanks! I’ve modified my copy of beautifulhugo to use the native Hugo related post code and it’s working MUCH faster now.

1 Like