Unit 04 · lesson
Unit Build: Portfolio Content Architecture
Unit 4 ends with a portfolio whose content model can be explained.
You should not have projects, journal entries, navigation, and pages all stored the same way unless you can defend that choice.
Required architecture
Your project should now include purposeful use of:
- pages;
_datafor at least one structured dataset;_postsfor a technical journal;- a custom
projectscollection or a defended alternative; - deliberate permalinks/URLs;
- safer internal link construction for your deployment model.
Content architecture diagram
Create:
_DATA --------→ NAVIGATION / SMALL STRUCTURED LISTS
PAGES --------→ HOME / ABOUT
_POSTS -------→ TECHNICAL JOURNAL
_PROJECTS ----→ PROJECT CASE STUDIES
Add the Liquid variables that expose each model.
Build verification
Prove:
- one data record becomes generated markup;
- one post appears through
site.posts; - one project appears through
site.projects; - one page has a deliberate permalink;
- one internal link respects your base-path strategy.
Migration evidence
Keep the before/after project model from _data → collection if you performed that migration.
Explain what improved and what configuration complexity you accepted.
Controlled failure
Choose one content-model failure and produce a bounded diagnosis.
Unit defense
Answer:
- When is
_databetter than a collection? - Why are posts special?
- Why might projects belong in a collection?
- What is a permalink?
- Why can a source path differ from a public URL?
- Why can
/about/work locally but fail under a repository subpath? - What evidence tells you which content model failed?
Move on when
Another student can inspect your source tree and correctly predict where they would add:
- a new journal post;
- a new project case study;
- a navigation link;
- a one-off page.