Hugo is well known for building pages! But do you know it’s also great at structuring and manipulating data? In this series we cover everything there is to know about data manipulation in Hugo starting with the basics, then its critical Slice and Map data types and the best practices to achieve finely grained data structuring in Hugo!
In this article we cover a workarkound to build pages from a remote API wth Hugo. It consists of using Hugo to grab our data from a remote source using resources.GetRemote — Hugo’s own fetch API —, keep using Hugo to generate markdown files using its resources.FromString, and finally build our Hugo project with the aforementioned content files.
At The New Dynamic we love Hugo, the framework we use to build many of our websites. Through the years there has been no objective, no client request, no challenge we were not able to meet with this amazing tool. But there is one limitation that can be tedious to circumvent: Hugo cannot build distinct pages from data sources outside of individual files! No section of a site can be safely populated from an external API such as a headless CMS.
Over the course of this two part series, we’ll get into details as we conceptually build a Monsterspotting website that will publish one page for each of its “file-less” monsters and a paginated listing page!
Back in July 2019 Hugo 0.56.0 introduced a powerful Module system. Pretty much like any package solution it allowed any Hugo project defined as a Module, be it a full website or a theme or a component to use any files stored on a repository somewhere and mount it as its own. It also enabled any Hugo project to become a full fledge Hugo Modules with its own config and dependencies which any other project could mount.
In this article, we’ll see how any Hugo project can use files stored on a distant repository and make them its own using the Module imports and mounts logic. Then, we’ll dive into what exactly constitute a Hugo Module by creating our own!
This post is not about migrating your WordPress site to Hugo, it’s about transitioning from your WordPress mindset to Hugo’s!
By cautiously comparing Hugo’s concept and vocabulary to some you’re already familiar with, we might be able to smooth out this learning curve for you!
So let’s bring up the the_post(), the_loop and the Template Hierarchy in order to better understand Hugo’s own construct!
In the first part of this Hugo’s Multilingual series, we covered how to manage our content translations and use those in our templates.
But what about translating strings for our project or our theme?
In this second part, we’ll see how Hugo, using its familiar data structure and configuration file, allows us to localize strings in any number of languages with minimum hassle.
Hugo handles multilingual perfectly from you content translation to your string localization, everything is simplified so coders and editors alike can focus on the rest.
In this first part, we’ll see how set up your multilingual Hugo project and translate your content!
{{ $style := resources.Get "main.scss" | toCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $style.Permalink }}" emotion="🤩">
Hugo’s roadmap got itself a new milestone when .43 delivered Hugo Pipes, a built-in set of asset processing methods.
From now on, Hugo will take care of bundling, minifying, fingerprinting our assets and even compiling our sass files! All of this without any external build tools.
In this post we’ll go through Hugo Pipes methods to cover how easy it is to implement a basic Hugo Pipes asset pipeline before turning to more advanced use cases, involving relinquishing some Sass and JS variables to our editors.