Structure A
Classic structure with assets in the static
folder.
Pros
- Clear separation of content files that are processed and assets that are static.
- Flat content tree.
Cons
- Managing assets in the static folder can be a pain: If we put all images in
one folder it is difficult to tell which images are still in use and which images
could be deleted. We could replicate the entire structure of the content for
images but this is also a lot of work to maintain. - References to images are long and may lead to mistakes
(for example/images/blog/firstpost/post-image-1.jpg
).
CONTENT
No assets in the content folder.
├── content/
└── _index.md
└── about/
│ └── _index.md
└── blog/
├── _index.md
├── firstpost.md
└── secondpost.md
LAYOUTS
├── layouts/
└── index.html
└── about/
│ └── list.html
└── blog/
├── list.html
└── single.html
STATIC SOURCE FILES (OPTIONAL)
This folder is ignored by Hugo. It is only used for preprocessors to generate files
into the static folder.
An alternative to this can be found in the
Victor Hugo boilerplate by Netlify.
It puts the Hugo folder in a site
subfolder and uses Gulp + Webpack as an
asset pipeline.
├── static-src/
└── sass/
│ └── style.scss
└── js/
└── main.js
STATIC
All assets are in the static folder. Here I replicate the content folder structure
for images. We could also create folders by date (like WordPress does) or put all
images in one folder.
├── static/
└── favicon.ico
└── images/
│ └── logo.png
│ └── home-image.jpg
│ └── blog/
│ ├── firstpost/
│ │ └── post-image-1.jpg
│ └── secondpost/
│ └── post-image-2.jpg
└── css/
│ └── style.min.css
└── js/
└── main.min.js
PUBLIC (generated files)
├── public/
└── index.html
└── favicon.ico
└── images/
│ └── logo.png
│ └── home-image.jpg
│ └── blog/
│ ├── firstpost/
│ │ └── post-image-1.jpg
│ └── secondpost/
│ └── post-image-2.jpg
└── about/
│ └── index.html
└── blog/
├── index.html
├── firstpost/
│ └── index.html
└── secondpost/
└── index.html