Skip to content

blog: keep a scheduled post hidden on its own URL - #5689

Open
dimitrieh wants to merge 1 commit into
mainfrom
fix/scheduled-post-direct-url
Open

blog: keep a scheduled post hidden on its own URL#5689
dimitrieh wants to merge 1 commit into
mainfrom
fix/scheduled-post-direct-url

Conversation

@dimitrieh

Copy link
Copy Markdown
Contributor

Description

A blog post dated in the future is kept out of the blog list, the feed and the sitemap until that date passes. Opening its link directly still served the whole post. This change makes that link return page not found until the date passes, so a scheduled post is unpublished everywhere rather than almost everywhere.

Review flow is unchanged. A scheduled post is still fully visible on a pull request preview and when working locally, which is how it gets read before its date.

While a post is still dated in the future Before After
In the blog list, tag pages and author page Hidden Hidden
In the feed and the sitemap Hidden Hidden
Opening its link directly Shows the full post Page not found
Preview of the pull request Shows the full post Shows the full post
Working locally Shows the full post Shows the full post
First build after the date passes Live everywhere Live everywhere

Only the live site behaves differently, so the change can be confirmed after merge by dating a throwaway post for tomorrow and opening its link.

Related Issue(s)

None.

Checklist

  • I have read the contribution guidelines
  • I have considered the performance impact of these changes
  • Suitable unit/system level tests have been added and they pass
  • Documentation has been updated
  • For blog PRs, an Art Request has been created (instructions)

A future-dated post is left out of the prerender set, so its URL is served by
the deployed Netlify function instead of a static file. Netlify passes only URL,
SITE_NAME and SITE_ID to a function at runtime, so the process.env.CONTEXT read
in isFuturePost was always undefined there, the check switched itself off, and
the post rendered in full before its date.

Take the production flag from runtimeConfig, which is captured at build time
where CONTEXT is set, and move it under public so the same value is available
wherever the check runs. Deploy previews and local dev are unaffected: their
builds capture a non-production context, exactly as before.
@dimitrieh

Copy link
Copy Markdown
Contributor Author

I checked out functionality for posting things in the future, while being merged. We have a small discrepancy that this PR fixes. See body description of the PR.

@netlify

netlify Bot commented Aug 27, 2026

Copy link
Copy Markdown

Deploy Preview for flowforge-website ready!

Name Link
🔨 Latest commit 365b387
🔍 Latest deploy log https://app.netlify.com/projects/flowforge-website/deploys/6a9007a8174df60008513fc0
😎 Deploy Preview https://deploy-preview-5689--flowforge-website.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse
1 paths audited
Performance: 63 (🟢 up 16 from production)
Accessibility: 96 (no change from production)
Best Practices: 100 (no change from production)
SEO: 85 (no change from production)
PWA: -
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify project configuration.

@dimitrieh

Copy link
Copy Markdown
Contributor Author

@KristopherLeads let's hold off on this until next week, and test it out on production with a before test blogpost and and after test blogpost, that we both delete after.

@Yndira-E

Copy link
Copy Markdown
Contributor

I'll leave the merge to you since you want to delay it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants