Structure B
Keep content and assets together.
Pros
- Content files and corresponding assets are in one folder. This is very clean
from a content perspective since I consider images of a blog post also as
content (not processd, but still content). For example, we can create a zip
file from a blog post folder with markdown and images and we have everything
that belongs to that blog post. - Images in the content folder are also much easier to maintain.
For example, if we delete a blog post, we can savely delete the blog posts
images as they live in the same folder. - References to images are short (for example
post-image-1.jpg). This also
means that Github finds and displays the images when the markdown file is opened.
Cons
- Content contains a mix of files to be processed (markdown) and static files
(images). If we did some image optimization/resizing/cropping, we could argue
that images are processed as well and thus belong to the content folder. - A lot of folders to manage in the content directory (comment by @alexandros).
CONTENT
Includes images and possibly other assets.
├── content/
└── _index.md
└── home-image.jpg
└── about/
│ └── _index.md
└── blog/
├── _index.md
├── firstpost/
│ └── index.md
│ └── post-image-1.jpg
└── secondpost/
└── index.md
└── post-image-2.jpg
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.
├── static-src/
└── sass/
│ └── style.scss
└── js/
└── main.js
STATIC
├── static/
└── favicon.ico
└── images/ // (only globally used images)
│ └── logo.png
└── css/
│ └── style.min.css
└── js/
└── main.min.js
PUBLIC (generated files)
├── public/
└── index.html
└── favicon.ico
└── home-image.jpg
└── images/
│ └── logo.png
└── about/
│ └── index.html
└── blog/
├── index.html
├── firstpost/
│ └── index.html
│ └── post-image-1.jpg
└── secondpost/
└── index.html
└── post-image-2.jpg