I’m in the process of migrating a few small Wordpress blog sites over to Hugo, a task I’ve been putting off but now required as they were compromised and that was the final straw.
I’ve used one of the tools to convert what I can over, but there will be some manual work to tidy things up and also effort to ‘recreate’ some of the WP functionality (further questions coming on that…).
However, I’d like to get opinions on which approach is ‘better’:
Select a developed theme and start populating posts / pages (small number initially to get functionality / custom features locked down, then increasing), or
Concentrate on getting the content in place with a basic/vanilla theme (before knowing what frontmatter variables might be implemented) and then selecting a more developed theme to be customised.
The answer to both will depend on if you have the basic understanding of tinkering with a Hugo theme. I would suggest getting a theme with as much features and functionality out of the box as you want, then add the missing features/functionality.
Good points. I’m happy tinkering with themes, but hope not to fall down any rabbit holes - also keen to hear recommendations on themes to use.
In this instance I have two main sites to transfer:
a vanilla blog with many image gallery grids in posts/pages that’ll need recreated
the other a more image-gallery-heavy site for a long-dead photographer of note, so galleries created based on tags/categories applied to images, perhaps via a data file, whereby images can have multiple tags/categories and thus appear on multiple pages.
So I’d like responsive images, SCSS processing, and ideally Bootstrap based. Many themes I’ve seen don’t use Hugo’s image processing capabilities which I find crazy…
The two approaches in the OP do highlight something I hadn’t appreciated with SSGs (I’ve used Hugo and Jekyll) in general: content and theme are actually quite interlinked. ie, I can’t simply take a posts/pages/content dir and swap a theme from A to B without needing to, potentially, modify many content files or deal with frontmatter/layout conflicts. Hence my question and potentially the answer - pick how you want it to look / function before you insert content.
I’m having the same issue/challenge, porting two wordpress (or associated) sites.
I want them to look as close as possible in looks and functionalities.
Fortunately they’re not too complicated, so I first set up a skeleton theme with a layout as close as possible from the original, so that its css sheets work out of the box.
Unfortunately they use scripts to add classes, and I know close to nothing about js, so the least straightforward task is to emulate these features with pure css and html, for instance with it has code injected in a container when clicking on a link, I don’t want / can’t have that, so I used an iframe element and a target attribute in links instead, with meager oneliner js scripts copied from the internet.
Of course with this approach, you must create the theme from scratch.
Then for the second site, I’ll use the first as a template, it should get faster.
I would use the second path - moving content first. Once I know what data I want to represent, I can find or create a new theme / layout. WordPress is a different system altogether and most of the time data is passed via WordPress plugins rather the WordPress theme. So direct porting doesn’t work.
First data then theming ( pre built or custom, I prefer custom though since it is faster and more compliant this way ).
“Better” is a relative term. It’s the ambiguous response of, “it depends”. A couple thoughts on migrating WP (or any other existing site) over to Hugo. These are concepts that have worked well for me. They may not be a good fit for everyone. Happy to share my experience.
I’m in the second camp - getting an understanding of your data before designs happen. Form Follows Function. I would even go so far as to prototype out the sections of a site you would need (Information Architecture) and possibly different template types that might be needed for posts. I use Figma for this. But Sketch, Illustrator would work fine. I’m sure there are online prototyping tools as well. Breaking things out by the data that is common to each area/post type will better help you schema your data.
Having your content abstracted from your design is a good practice. It will help ensure portability of your content should you want to re-theme or even re-platform at a later date.
Some WP gotchas to keep on your radar:
Short codes. These often point to plugin functionality that isn’t at parity with the typical SSG. That would be one of the first things on my radar to identify - What functionality is needed.
Image processing is not the same. WP has extensive image controls. If similar functionality is needed there, it might be worth looking into a DAM (Digital Asset Management) tool like Cloudinary. As much as I like the image processing in Hugo, there is some lift on the dev side and some work to keep your cache clean, build after build.
I’m even further into this camp building sites from scratch. I’ll avoid libraries and front-end frameworks wherever possible to keep things as performant as possible. Use the tools that you know but challenge yourself to go just beyond your comfort zone. New challenges mean new learning.