web.dev
web.dev copied to clipboard
GoogleChrome
Allow posts to be merged but not go live until a certain date
It would be useful to be able to merge posts that are ready, but not show them live until a "live" date. This would mean that a scheduled release of content doesn't need someone ready to click the button on the day.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. To prevent this from happening, leave a comment.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Closing this issue because it has been marked as stale for more than 7 days.
I know that this is still a much-requested feature, so let's leave it open.
(I don't have a solution or anything, but it should be kept on our radar.)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. To prevent this from happening, leave a comment.
Closing this issue because it has been marked as stale for more than 7 days.
https://github.com/GoogleChrome/webdev-infra/pull/31 is some simple logic that would check the date field of an item against any time value in ms (presumably from Date.now()). If the date value is greater than the time value, then the item will be marked with draft: true.
I think that will give us the behavior we want—items that are marked as draft will be visible in local staging builds, but not visible in public production builds.
How does that sound? Once that other PR is merged, we can add the logic to each site's 11ty config.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. To prevent this from happening, leave a comment.
webdev-infra has stubs for this functionality and it is also implemented here:
https://github.com/GoogleChrome/web.dev/blob/main/src/site/_filters/is-live.js#L23-L46
It isn't documented in the handbook though and more granular control (hourly as constrained by the build schedule) would be desired.
Closing this as we are moving to a new non-Github based platform. Our new issue tracker lives at https://issuetracker.google.com/issues?q=status:open%20componentid:1400680&s=created_time:desc
