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;
  • _data for at least one structured dataset;
  • _posts for a technical journal;
  • a custom projects collection 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:

  1. one data record becomes generated markup;
  2. one post appears through site.posts;
  3. one project appears through site.projects;
  4. one page has a deliberate permalink;
  5. 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:

  1. When is _data better than a collection?
  2. Why are posts special?
  3. Why might projects belong in a collection?
  4. What is a permalink?
  5. Why can a source path differ from a public URL?
  6. Why can /about/ work locally but fail under a repository subpath?
  7. 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.