Add automatic publish-on-date functionality #58

New Issue

2026-10-05T05:11:57+02:00

adam commented

2026-10-05 05:11:57 +02:00

Mostly for events, but auto publish is something that would be a nice to have for any kind of content in the blog.

Proposed Solution

Editor flow

The main flow from an editor perspective would be the same as creating a normal post to publish with the small difference of having an extra field to fill "Publishing Date" for example that would indicate when the post would be published (timezones can be configured to be either the content editor's or always UTC, see docs here).

We already have a "Date" field, but having a separate one for publishing would allow for us to support use cases like: I add an event that happens in 3 weeks but I want to publish its link 2 weeks before the event.

Implementation

On forestry we need to set the new "Publishing Date" field with the timezone configuration (either the content editor's timezone or always UTC) and then add a description to the field input referencing the config so that content editors know which timezone is being considered when they are inputting the date and time.
The "Publishing Date" would be used to either include a post in the build or not. If it's not the time yet to publish, it wouldn't be included and the link would result in a 404. Careful take into account all of the use cases (blog post listing, sitemap, and rss feed – index.json for ipfs.io is derived from rss feed).
The bulk of the work would be to auto publish the website with the new entry, meaning simply trigger a deployment of the production fleek app.
Fleek provides a CLI which we can use to trigger a deployment programmatically.
To correctly trigger the publish we can run an action daily to check for posts to publish on the current day (it will run unnecessarily most of the days, but since this is public repo, we don't pay for it – the limit until we pay is 72h which will be very hard to reach).
- we could increase the frequency in order to have more accurate publishing considering that running only once a day would mean we could publish an event 23 hours and 59mins too late? Maybe twice or thrice a day?

Mostly for events, but auto publish is something that would be a nice to have for any kind of content in the blog. ### Proposed Solution #### Editor flow The main flow from an editor perspective would be the same as creating a normal post to publish with the small difference of having an extra field to fill "Publishing Date" for example that would indicate _when_ the post would be published (timezones can be configured to be either the content editor's or always UTC, see docs [here](https://forestry.io/docs/settings/fields/datetime/)). We already have a "Date" field, but having a separate one for publishing would allow for us to support use cases like: I add an event that happens in 3 weeks but I want to publish its link 2 weeks before the event. #### Implementation - On forestry we need to set the new "Publishing Date" field with the timezone configuration (either the content editor's timezone or always UTC) and then add a description to the field input referencing the config so that content editors know which timezone is being considered when they are inputting the date and time. - The "Publishing Date" would be used to either include a post in the build or not. If it's not the time yet to publish, it wouldn't be included and the link would result in a 404. Careful take into account all of the use cases (blog post listing, sitemap, and rss feed – index.json for ipfs.io is derived from rss feed). - The bulk of the work would be to auto publish the website with the new entry, meaning simply trigger a deployment of the production fleek app. Fleek provides a [CLI](https://docs.fleek.co/fleek-cli/overview/) which we can use to trigger a deployment programmatically. - To correctly trigger the publish we can run an action daily to check for posts to publish on the current day (it will run unnecessarily most of the days, but since this is public repo, we don't pay for it – the limit until we pay is [72h](https://docs.github.com/en/actions/reference/usage-limits-billing-and-administration#usage-limits) which will be very hard to reach). - we could increase the frequency in order to have more accurate publishing considering that running only once a day would mean we could publish an event 23 hours and 59mins too late? Maybe twice or thrice a day?

adam closed this issue

2026-10-05 05:11:57 +02:00

adam commented

2026-10-05 05:11:58 +02:00

Another idea to schedule a publish would be to programmatically create and remove workflow files from the repo to allow to schedule a trigger exactly when we want the post to be published using cron, but that is a bit more complex and "hacky". I don't see any disadvantages on the initial proposed solution to run the action frequently.

Another idea to schedule a publish would be to programmatically create and remove workflow files from the repo to allow to schedule a trigger exactly when we want the post to be published using cron, but that is a bit more complex and "hacky". I don't see any disadvantages on the initial proposed solution to run the action frequently.

adam commented

2026-10-05 05:11:59 +02:00

This is great analysis, thank you! Two thoughts:

twice a day seems plenty - if we need more granularity we can post manually
UTC is OK, as PL staff are supposed to be operating in a UTC frame of mind anyway

I think this is worth doing for the sake of making it easier for multiple authors to work at once, or for "set and forget" tasks - eg someone could drop a year's worth of meetup links when those dates are scheduled.

This is great analysis, thank you! Two thoughts: - twice a day seems plenty - if we need more granularity we can post manually - UTC is OK, as PL staff are supposed to be operating in a UTC frame of mind anyway I think this is worth doing for the sake of making it easier for multiple authors to work at once, or for "set and forget" tasks - eg someone could drop a year's worth of meetup links when those dates are scheduled.

adam commented

2026-10-05 05:12:00 +02:00

@jessicaschilling I can work on this this week then 👍

@jessicaschilling I can work on this this week then 👍

adam commented

2026-10-05 05:12:01 +02:00

One thing to note: because forestry will commit the data to the repo on the staging branch regardless, any information on that post will be public on this repo as soon as it is saved from forestry. So if there is any sensitive information that we only want to disclose publicly on the publish date, then we should not schedule the post. It should follow the old method by creating and publishing it on the same day.

One thing to note: because forestry will commit the data to the repo on the `staging` branch regardless, **any information on that post will be public on this repo as soon as it is saved from forestry**. So if there is any sensitive information that we only want to disclose publicly on the publish date, then we should not schedule the post. It should follow the old method by creating and publishing it on the same day.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/ipfs-blog#58