Merge pull request #2571 from hydephp/v3/skip-future-dated-posts

[3.x] Skip blog posts dated in the future during auto-discovery hydephp/develop@bed072b

Author: emmadesilva

HYDEPHP_V3_PLANNING.md

@@ -22,6 +22,7 @@ Having this document in code lets us know the devlopment state at any given poin
 
 - Added native support for versioned documentation pages. Register versions in the new `docs.versions` configuration option, and store the pages for each version in a matching subdirectory of the documentation source directory (like `_docs/1.x` and `_docs/2.x`). Each version is compiled to a matching subdirectory of the documentation output directory, and gets its own sidebar, search index, and search page. A version switcher dropdown is shown in the documentation sidebar, the main navigation links to the default version's index page, and a redirect page is generated at the documentation root pointing to the default version. Sidebar and search configuration entries (`docs.sidebar.order`, `docs.sidebar.labels`, `docs.sidebar.exclude`, and `docs.exclude_from_search`) match version-agnostic identifiers and route keys, so a single entry applies to the page in every version, while full versioned keys allow version-specific overrides. Enabling the feature is all or nothing: documentation source files stored outside the version directories are ignored, so pages that should live at the documentation root belong in the normal page source directory (like `_pages/docs/index.md`). Versioning is disabled by default, and single-version sites are unaffected. ([#2516](https://github.com/hydephp/develop/pull/2516))
 - Redirects can now be declared as source and destination path pairs in the `hyde.redirects` configuration array. Hyde registers them with the kernel, includes them in `route:list`, and generates them through the normal site build.
+- Blog posts dated in the future are now treated as scheduled drafts and are skipped during auto-discovery when building the site. Such posts get no route, are not present in the kernel's page and route collections, and are left out of post listings, the sitemap, and the RSS feed. Both front matter dates and filename date prefixes are supported. Scheduled posts are still served by the realtime compiler, which is treated as an authoring preview, so they can be written and proofread at their normal URL without changing their date: `serve` shows everything you are working on, while `build` publishes only what is eligible. Since Hyde is a static site generator, a scheduled post does not publish itself once its date passes: it is included in the first site build run after that point, so recurring builds (for example a cron-scheduled GitHub Actions workflow) are needed for a post to go live on its own. The new `MarkdownPost::isScheduled()` method exposes the check. ([#2441](https://github.com/hydephp/develop/issues/2441))
 - Added Blade Blocks for rendering Blade and Blade components from fenced code blocks in Markdown pages. The supported directives are `blade render` and `blade component(name)`, and the feature is controlled by `markdown.enable_blade`. ([#2504](https://github.com/hydephp/develop/pull/2504))
 - Added built-in terminal code blocks using the `terminal` fence language. Command prompts are styled for selection-free copying, and `terminal xml` supports four Symfony-style Console formatter tags. ([#2188](https://github.com/hydephp/develop/issues/2188), [#2485](https://github.com/hydephp/develop/issues/2485))
 
@@ -54,6 +55,7 @@ Please fill in UPGRADE.md as you make changes.
 
 - Blade in Markdown is now enabled by default, including `[Blade]:` directives and the new executable `blade render` and `blade component(name)` fenced code blocks. Existing projects with a published `config/markdown.php` retain their current `markdown.enable_blade` setting; set it to `true` to adopt the v3 default, or keep it `false` to disable both forms when compiling untrusted or unreviewed Markdown.
 - Raw HTML in Markdown is now enabled by default. Existing projects with a published `config/markdown.php` retain their current `markdown.allow_html` setting; set it to `true` to adopt the v3 default, or keep it `false` when compiling untrusted or unreviewed Markdown.
+- Blog posts dated in the future are no longer built, though they remain visible when serving the site. Check `_posts` for dates ahead of your build time, correcting any mistyped dates. If you want to schedule posts, set up recurring builds, as a scheduled post is only published by a build run after its date has passed.
 - The `rebuild` command has been removed. If you need to build a single page programmatically, use `Hyde\Framework\Actions\StaticPageBuilder::handle()` instead.
 - Move any calls to `Redirect::create()` or `Redirect::store()` into the `redirects` array in `config/hyde.php`, using the old path as the key and the destination as the value.
 - Move `InMemoryPage` `compile` macro callbacks into the contents argument, and replace other instance macros with methods on an `InMemoryPage` subclass.

UPGRADE.md

@@ -302,6 +302,18 @@ new InMemoryPage('example', view: '');
 new InMemoryPage('example', view: null);
 ```
 
+## Review Blog Posts Dated in the Future
+
+HydePHP v3 treats a blog post whose date is set in the future as a scheduled draft. When you build the site, such posts are skipped during auto-discovery, so they get no route, are not compiled to `_site`, and are left out of post listings, the sitemap, and the RSS feed. This applies to both front matter dates and filename date prefixes.
+
+Scheduled posts are still included by `php hyde serve`, which is treated as an authoring preview, so you can keep writing and previewing them at their normal URL.
+
+In v2 these posts were built like any other. If your site has posts dated ahead of the build time — whether deliberately or because of a typo — they will disappear from your site after upgrading.
+
+To find affected posts, check your `_posts` directory for dates ahead of the build time, in both front matter and filename prefixes. If a post disappears after upgrading but remains visible through `php hyde serve`, check whether its date was accidentally set in the future.
+
+If a post that was supposed to be published turns out to have a future date, correct the date. If you actually want to schedule posts, remember that **Hyde is a static site generator**: a scheduled post does not publish itself when its date passes. It is included in the first site build that runs after that point, so you need recurring builds for a post to go live on its own, for example a cron-scheduled GitHub Actions workflow.
+
 ## Migration Checklist
 
 Use this checklist to track your upgrade progress:
@@ -311,6 +323,7 @@ Use this checklist to track your upgrade progress:
 - [ ] Moved calls to `Redirect::create()` or `Redirect::store()` into the `hyde.redirects` configuration array
 - [ ] Moved `InMemoryPage` `compile` macro callbacks into the contents argument and replaced other macros with subclass methods
 - [ ] Updated `InMemoryPage` calls to supply only one of `contents` and `view`
+- [ ] Checked `_posts` for blog posts dated in the future, and set up recurring builds if scheduling posts
 
 ## Troubleshooting