Exercise 1: Contact Info Published as a Post Instead of a Page — Possible Solution ==================================================================== WHAT THIS CHAPTER SAYS ABOUT POSTS SPECIFICALLY ------------------------------ Per this chapter, Posts are "chronological, date-driven" content that is "included in the site's RSS feed" and typically "organized via categories and tags" - the defining trait is that Posts are meant to appear in a reverse-chronological stream, not to sit as a fixed, standalone destination. WHAT WOULD VISIBLY GO WRONG ------------------------------ Per this chapter's own tip-box, "a Contact page accidentally published as a Post would show up in the blog feed alongside articles, which is rarely what anyone actually wants." Concretely: the contact information would appear mixed into the site's chronological blog listing, get pushed further down the page (and eventually off it) as new posts are published over time, be delivered to anyone subscribed to the site's RSS feed as though it were a new article, and could end up tagged/ categorized alongside unrelated blog content rather than sitting in a fixed, predictable location like a main navigation menu. WHY THIS HAPPENS MECHANICALLY, NOT ARBITRARILY ------------------------------ Because Posts and Pages are treated as distinct content types with different intended display behavior (per this chapter's own comparison table), WordPress's blog listing and RSS feed logic specifically pull in Posts - a Page is deliberately excluded from that logic. Publishing contact information as a Post puts it directly inside a system built for time-ordered content, so it inherits all of that system's behavior (feed inclusion, chronological listing, eventual burial under newer posts) whether or not that behavior is wanted. WHY THIS IS A CONTENT-MODELING MISTAKE, NOT A TECHNICAL FAILURE ------------------------------ Per this chapter, "getting this wrong doesn't break anything technically" - the site won't error out or malfunction. The problem is purely about the content ending up in the wrong conceptual place, displayed and organized in a way that doesn't match what a Contact page is actually meant to be: a fixed, easily-findable, non-time-sensitive destination. WHY THIS WORKS AS AN ANSWER ------------------------------ It applies this chapter's own specific Post traits (chronological listing, RSS inclusion, categorization) to predict concretely what would visibly happen, and distinguishes the resulting content-modeling problem from an actual technical failure, matching this chapter's own framing precisely.