Post Date Block: Published & Modified 🔗 **Source:** [Post Date Block: Published & Modified](https://weston.ruter.net/2026/01/19/post-date-block-published-modified/) > [!note]+ Document Notes > ```yaml > tags: [wordpress, gutenberg, plugins] > author: Weston Ruter > source: weston.ruter.net > reference: [https://weston.ruter.net/2026/01/19/post-date-block-published-modified/] > date created: 2026-01-20 10:00 > > --- > > # 🏷️ Title: Post Date Block: Published & Modified > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened. - Weston built a WordPress plugin that lets the Post Date block show the published date plus the modified date, but only when they differ. - Why it matters. - Solves a common UX issue for evergreen posts: readers can see both original publish and last update without manual notes. - Key stakeholders. - WordPress site owners, theme developers, core Gutenberg contributors. - Risks and tradeoffs. - Extra configuration complexity; no live editor preview; acts as a stopgap until core provides a first‑class solution. - Bottom line. - Practical prototype that fills a gap in the Date block’s behavior and suggests directions for future core improvements. ## 📖 Main Content - The article explains limitations in WordPress’s Date/Post Date/Modified Date blocks: you can show either publish or modified dates, but not both together with conditional logic. - Weston wanted evergreen content (like WCUS “Portland picks”) to clearly show when it was updated without manual paragraphs. - Community feedback highlighted conflicting needs: some want only modified dates, some want both, and the current Modified Date block can render empty for never-edited posts. - Weston argues the block should show the published date and conditionally append the modified date when different, e.g. “December 25, 2025 (Modified: January 1, 2026)” or on two lines with “Published” / “Modified” prefixes. - Existing Gutenberg work on prefixes/suffixes and block bindings didn’t cover conditional dual‑date display. - He built the **Post Date Block: Published & Modified** plugin: - Adds a “With Modified Date” panel to the Post Date variation. - Adds a toggle: “Show modified date when different from published date”. - Compares rendered dates; only outputs the modified date if it differs to avoid duplicates. - Lets you configure prefixes/suffixes for each date and choose same-line or separate-line output. - Adds microformats classes (`entry-date published`, `updated`, and wrapper classes) and uses the HTML Tag Processor for markup manipulation. - The plugin currently has no editor preview and is meant as a prototype until core handles this better (possibly via Bits/Shortblocks and inline tokens). ### 🗒️ Notes - WordPress 6.4 removed “Post” prefixes from the Date and Modified Date blocks; they’re variations of the same Date block. - WordPress 6.9’s block bindings generalize the Date block to represent arbitrary dates, but the UX still exposes an “either publish or modified” choice. - Real‑world problem: Modified Date block shows nothing if a post has never been updated, creating visual gaps. - Core issue discussions note: - Confusing UI: old “display modified date” toggle replaced publish date entirely. - No one-size-fits-all behavior; different sites have different expectations. - Weston’s desired behavior: - Never let modified date fully replace the original publish date. - Instead, always show publish date, and append modified date only if different (with clear labeling). - UI constraints: - Inline content plus lack of conditional visibility for blocks make it hard to solve purely in templates. - Existing proposal for prefixes/suffixes only covers a single date, not conditional dual-date output. - Plugin behavior: - When the special toggle is enabled, the plugin: - Renders publish and modified dates using the configured format. - Compares the rendered values to determine if they differ. - Optionally adds prefixes/suffixes per date. - Optionally inserts a line break and wraps modified date in a span. - Example two-line output: - First line: “Published: December 25, 2025”. - Second line: “Modified: January 1, 2026”. - Technical notes: - Uses HTML Tag Processor to inject prefixes, suffixes, classes, and `<br>` cleanly. - Adds microformats to distinguish dates semantically for consumers. - Limitations: - No live preview in the editor; must check frontend. - Date block in block templates often shows “Invalid date” due to missing post context. - Weston frames this as a stopgap, not a final UX pattern. - Future direction: - Bits/Shortblocks could let authors insert tokens inline, configure alternative renderings when modified date differs, and avoid sidebar-heavy configuration. - Ideal: simple default for equal dates; richer config via popovers when dates diverge. ## 📚 References - Post Date Block: Published & Modified (article): https://weston.ruter.net/2026/01/19/post-date-block-published-modified/ - GitHub plugin repo (mentioned in article): https://github.com/westonruter/wp-post-date-published-modified - Gutenberg issue on Date/Modified Date confusion: https://github.com/WordPress/gutenberg/issues/53099 - Gutenberg issue on prefixes/suffixes for Date block: https://github.com/WordPress/gutenberg/issues/61920 - Block bindings (WordPress 6.9 dev notes): https://make.wordpress.org/core/tag/block-bindings/ ## 🗣️ Paraphrase - Paragraph A paraphrase. - Weston wanted his blog’s Post Date block to automatically show both when a post was originally published and when it was later updated, instead of hand-writing update notes. - Paragraph B paraphrase. - Core Date/Modified Date functionality and existing Gutenberg issues did not support this conditional dual-date display, so he built a plugin that appends the modified date only if it’s different and lets users label and format both dates. ## 📰 Newsletter WordPress site owners love evergreen posts—but not the guesswork around “how fresh is this?”. Weston Ruter just released **Post Date Block: Published & Modified**, a small but mighty plugin that extends the core Post Date block to show both published and last modified dates only when they differ, with configurable prefixes/suffixes and layout. If you’re building content libraries, docs, or long-lived posts on block themes (especially Twenty Twenty‑Five), this is a simple win for reader trust and clarity. Check out the write‑up and code for implementation details, microformats, and ideas for future core enhancements using Bits/Shortblocks. ## ✅ Action Items #### DevRel - Advocate this plugin as a pattern for responsible “last updated” UX in tutorials and talks. - Add example block patterns showing dual-date display in theme dev workshops. - Provide code samples for using HTML Tag Processor to modify block output. #### OSPO - Document how plugins that alter core block output (like dates) intersect with content lifecycle and archival policies. - Encourage license clarity and contribution pathways if this pattern moves toward core. #### Community - Gather feedback from site owners on preferred date display patterns (publish-only, modified-only, or both). - Run a small survey for theme authors about how they currently handle updated content labeling. #### WordPress - **Core:** Explore a native option in the Date/Post Date block for “show publish + modified when different” with sane defaults. - Core Performance: Confirm date-rendering and HTML Tag Processor usage have negligible impact at scale. - Core AI: Consider examples where AI-assisted editing should or shouldn’t update the visible modified date. - Core Program Team: Track issues related to Date block UX and coordinate designs for prefixes/suffixes and conditional display. - Mobile: Ensure mobile app editors expose any future dual-date configuration cleanly. - Playground: Provide a Playground preset demonstrating the plugin with starter content. - Community: Promote the pattern in meetup talks on evergreen content strategy. - Training: Add a lesson plan on “Communicating content freshness” using Post Date configurations. - Marketing: Highlight “clear content freshness” as a trust feature in WP storytelling. - Support: Add KB entries explaining Date vs Modified Date vs plugins like this. - Design: Propose default UI patterns for dual-date layouts (single-line vs stacked). - Documentation: Update DevHub/HelpHub with guidance on Date block behaviors and microformats. - Photos/TV/Openverse: N/A beyond general content freshness guidance. - Polyglots: Make sure any new labels (“Published”, “Modified”, “Updated”) are easy to translate. - Accessibility: Review dual-date patterns for clarity with screen readers. - Meta: Consider surfacing modified dates consistently across .org properties (plugins, themes, docs). - CLI: Optionally explore commands to bulk-check or adjust post modified dates for consistency. - Hosting/Tide: Note how dual-date output may affect caching and scanning; no major changes expected. - Themes: Offer starter patterns for dual-date display in new block themes. - Plugins: Encourage other plugins that alter post metadata to respect and not conflict with this pattern. #### The WPOCC - Programs: Fund small experiments around UX patterns for evergreen content indication across themes. - Projects: Run documentation sprints to standardize how “last updated” appears in official materials. - Funding experiments: Pilot microgrants for plugins that prototype better content lifecycle UX. ### FAIR - Technical independence: Encourage local configuration of date display, not SaaS-dependent features. - Policies and covenants: Be transparent about when and why content dates change. - Productized governance artifacts: Define clear patterns/docs for content freshness indicators and their ownership. ## 🧪 Hypotheses - H1: Sites that display both publish and modified dates will see increased user trust metrics (e.g., time on page, lower bounce) for evergreen content. - H2: Theme authors prefer a core-level dual-date option over custom code snippets or ad hoc paragraphs. - H3: Conditional dual-date display reduces support requests where readers are confused about whether content is outdated. - H4: A Bits/Shortblocks-based configuration will be more usable than sidebar-only settings for advanced date logic. ### 📊 Methodology - For H1: A/B test sites with publish-only vs publish+modified date on high-traffic evergreen posts; track engagement and survey trust. - For H2: Survey and interviews with theme developers; analyze theme codebases for custom date hacks. - For H3: Review support ticket topics before/after enabling dual-date patterns on large doc sites. - For H4: Run usability tests comparing a prototype Bits/Shortblocks UI with current sidebar toggles, measuring completion time and errors. ### ❓ Questions - How often do readers actually rely on visible modified dates when judging content freshness? - Should modified dates always be visible, or only after “substantial” changes? - What is the best default wording globally (“Updated”, “Modified”, “Last edited”) for translations and clarity? - How should dual-date display interact with SEO considerations (e.g., structured data, snippet dates)? ### 🔮 Future Research - Define heuristics for when to bump modified dates (typos vs substantive edits). - Explore integration with revision comments so modified dates can link to meaningful change logs. - Investigate date presentation patterns in other CMSs and large documentation sites. - Prototype Shortblocks-based date templates and measure adoption. ### 💡 Implications - Practice: Clearer date display could become a standard element of professional WordPress content strategy. - Policy: Organizations may codify rules around how and when modified dates must be visible. - Security: Accurate dates can help readers assess timeliness of security-related guidance. - Education: Training materials should cover not only *what* modified dates are, but *how* to communicate them well. - Funding models: Small UX-focused plugins like this can be low-cost high-impact targets for ecosystem grants. ### 🧠 Learning Styles Assessment - Reading level estimate: Approx. Flesch-Kincaid Grade 9–10 (developer-focused but approachable, moderate sentence length, some jargon). #### 👀 Visual learners - Present: Screenshots of Date block settings; sample HTML output. - Improve: Add side-by-side visuals of “before plugin” vs “after plugin” front-end display. #### 🔊 Aural learners - Present: None inherent. - Improve: Short audio or screencast explaining the problem, settings, and output. #### 🗣️ Verbal learners - Present: Clear narrative, definitions of Date vs Modified Date, examples of phrasing. - Improve: More analogies (e.g., “changelog for blog posts”) and glossary callouts. #### 🧩 Kinesthetic learners - Present: Concrete steps: install plugin, toggle options, see output. - Improve: Guided “lab” instructions using Playground, with tasks and expected outcomes. #### 🧠 Logical learners - Present: Systematic comparison of scenarios (never updated, updated same day, updated later), conditional logic. - Improve: Tables mapping settings → resulting markup and UX. #### 🧑‍🤝‍🧑 Social learners - Present: References to community discussions and GitHub issues. - Improve: Provide prompts for meetup discussions or paired theme-audit exercises. #### 🧘‍♀️ Solitary learners - Present: Self-paced article with clear structure. - Improve: Add reflective prompts like “How do you currently signal freshness on your site?” #### 🌿 Naturalistic learners - Present: No specific environmental framing. - Improve: Use lifecycle/ecosystem analogies (content aging, renewal) to explain evergreen content maintenance. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Use of `<time>` elements and microformats classes to distinguish published vs updated dates. - Improve: Ensure accessible labels (e.g., visually hidden “Published on” / “Updated on”) are present and localized. #### Keyboard navigation - Present: Date info is static text; no keyboard traps. - Improve: Confirm focus order remains logical in themes with multiple meta elements. #### Contrast and readability - Present: Depends on theme; plugin itself just extends markup. - Improve: Recommend minimum contrast in design docs for meta text. #### Text resizing and reflow - Present: Simple inline/stacked text is resilient to zoom. - Improve: Verify that line-break configurations still reflow gracefully in narrow viewports. #### Media and captions - Present: Not applicable; primarily text and screenshots. - Improve: Ensure screenshots include alt text summarizing configurations. #### Forms and interactions - Present: Block sidebar controls in the editor follow Gutenberg patterns. - Improve: Double-check control labels and descriptions for clarity and assistive tech. #### Standards reference - Map gaps to WCAG 2.2 AA: 1.4.x (contrast), 1.3.1 (info and relationships for time labels), 3.3.2 (labels for editor controls). ### 🌍 DEIB Assessment #### Cultural breadth - Present: Example dates and events tied to WCUS/Portland (US-centric). - Improve: Include examples and screenshots using different locales and date formats. #### Inclusive language - Present: Neutral, technical language; minimal idioms. - Improve: Add plain-language summaries for non-developers who configure themes. #### Neurodiversity support - Present: Structured headings and clear sections. - Improve: More consistent pattern of examples and explicit “if/then” rules. #### Representation - Present: Focus on technical features; few people mentioned by name. - Improve: Highlight contributions from a diverse set of community members in related issues. #### Psychological safety - Present: Respectful tone toward differing use cases and preferences. - Improve: Encourage experimentation and explicitly state that no single pattern is “correct” for all sites. ### ✅ Logical Validity #### Strong reasoning - Type: Inductive and pragmatic. - From real examples (evergreen posts and WCUS content), Weston infers that readers benefit from seeing both publish and modified dates. He then tests and implements a plugin matching that logic. - He recognizes conflicting use cases and avoids overclaiming: the plugin solves his scenario and some others but is not a universal solution. #### Fallacies - No clear logical fallacies; claims are modest and grounded in experience and community discussion. #### Tone of voice - Practical, reflective, and mildly self-deprecating (e.g., comments about the Customizer). - Collaborative: references and builds on others’ issue reports rather than dismissing them. ### 🛡️ DARVO Analysis - Deny: No denial or minimization of others’ concerns; he explicitly acknowledges tradeoffs and conflicting needs. - Attack: No attacks on other contributors or users; disagreements are framed constructively. - Reverse victim/offender: Not present; he does not claim to be harmed by core decisions, just constrained by current capabilities. ## 🎯 Conclusion Weston’s plugin neatly addresses a real gap in WordPress’s Date block: clearly communicating both when content was first published and when it was last updated, without manual workarounds. It’s a thoughtful prototype that demonstrates how core could eventually handle conditional dual-date display—likely with more flexible inline configuration via Bits/Shortblocks. For now, it’s a practical tool for anyone maintaining evergreen content who wants to improve reader trust and clarity. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) by [[{Author or [MISSING]}]] via [[{Site or [MISSING]}]]. Published {DATE_OR_[MISSING]}. Accessed . > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight]({ARTICLE_URL}#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight]({ARTICLE_URL}#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F2] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F3] Short action — context/{ARTICLE_URL} #fleeting #inbox --- <!-- deep-read:sections end -->