Better explain content types #165

Merged
stb merged 1 commit from explain-content-types into main 2026-06-14 21:20:52 +02:00
Owner
  • make it clear that Hugo/the template distinguishes content types based on frontmatter fields
  • explain what the key differences are
  • link to the archetypes so people can better understand what the relevant fields are
* make it clear that Hugo/the template distinguishes content types based on frontmatter fields * explain what the key differences are * link to the archetypes so people can better understand what the relevant fields are
Clarify date / publishDate
All checks were successful
/ build (pull_request) Successful in 42s
242ef58bc2

You can view your changes at https://staging.hamburg.ccc.de/pr165/

You can view your changes at https://staging.hamburg.ccc.de/pr165/
jtbx requested changes 2026-06-13 20:57:01 +02:00
Dismissed
jtbx left a comment

Inhalt ist OK, aber bitte nur einen Satz pro Zeile

Inhalt ist OK, aber bitte nur einen Satz pro Zeile
clarify and correct language
All checks were successful
/ build (pull_request) Successful in 41s
640658f8c3
stb scheduled this pull request to auto merge when all checks succeed 2026-06-13 21:02:35 +02:00
jtbx canceled auto merging this pull request when all checks succeed 2026-06-13 21:12:54 +02:00
Improve source formatting
All checks were successful
/ build (pull_request) Successful in 43s
bfde817bc6
A single sentence per line
jtbx requested changes 2026-06-13 21:25:45 +02:00
Dismissed
README.md Outdated
@ -47,0 +55,4 @@
#### Add a Blog Entry
Blog posts (the archetype is called `article`) should be used for information that will be relevant for a longer period, for example explanations about technical, political or cultural topics.
Articles will be shown in chronological order on the [blog main page](https://hamburg.ccc.de/blog/), until newer posts push them down.
Owner

Not 100% correct. They will be shows for some days since we don't want to clutter the front page with "old" blog posts. If people are interested in all posts they should use an RSS reader.

Not 100% correct. They will be shows for some days since we don't want to clutter the front page with "old" blog posts. If people are interested in all posts they should use an RSS reader.
stb marked this conversation as resolved
README.md Outdated
@ -47,0 +64,4 @@
```
If you want to create a blog post from scratch, or convert an event into a blog post, see the frontmatter data in [themes/ccchh/archetypes/article.md](themes/ccchh/archetypes/article.md).
In particular, you need to set `categories: article` and remove any `date:` or `location:`.
Owner

Wrong: date always needs to be there. publishDate can (and should) be omitted on articles.

Wrong: `date` always needs to be there. `publishDate` can (and should) be omitted on articles.
stb marked this conversation as resolved
README.md Outdated
@ -47,0 +65,4 @@
If you want to create a blog post from scratch, or convert an event into a blog post, see the frontmatter data in [themes/ccchh/archetypes/article.md](themes/ccchh/archetypes/article.md).
In particular, you need to set `categories: article` and remove any `date:` or `location:`.
Note that `publishDate:` is fine, as it determines when the content will start appearing on the the site.
Owner

I don't see a use case for a separate publish date on blog posts. We can still schedule them by using the date field, but why should there be a different publication date from the date that's shown in the post?

I don't see a use case for a separate publish date on blog posts. We can still schedule them by using the `date` field, but why should there be a different publication date from the date that's shown in the post?
stb marked this conversation as resolved
README.md Outdated
@ -48,3 +71,2 @@
There are two basic types of posts: Events and articles.
Events will be shown on the home page from their publishing date until they have happened and shall be used for things which happen at a certain date.
Events will be shown on the home page from the frontmatter `publishDate` until the `date:`.
Owner

Not 100% correct, they will also be shown up to 6 hours after the date so that events that are currently running are still present on the home page.
This time frame was enough for the usual event we host which last an evening.

Not 100% correct, they will also be shown up to 6 hours after the `date` so that events that are currently running are still present on the home page. This time frame was enough for the usual event we host which last an evening.
stb marked this conversation as resolved
README.md Outdated
@ -68,2 +82,2 @@
hugo new content --kind article blog/yyyy/yyyy-mm-dd-your-article-title/index.md
```
If you want to create an event from scratch, or convert a blog post into an event, see the frontmatter data in [themes/ccchh/archetypes/event.md](themes/ccchh/archetypes/event.md).
In particular, you need to set `categories: event`, `date:` for the date of the event, and `location: Z9` (or whereever your event takes place).
Owner

Events should also have a publishDate since the post should usually be published before the event is happening.

Events should also have a `publishDate` since the post should usually be published before the event is happening.
stb marked this conversation as resolved
Improve explanations further
All checks were successful
/ build (pull_request) Successful in 41s
6c73476ca6
Merge branch 'main' into explain-content-types
All checks were successful
/ build (pull_request) Successful in 44s
876443cd4d
README.md Outdated
@ -47,0 +50,4 @@
Hugo and the template set distinguish between these two types based on frontmatter information.
When manually creating content, you need to take extra care to use the correct frontmatter data.
See the link to the Hugo archetypes below for details.
If at all possible, use `hugo new content` with the appropriate parameters to create the new content file correctly.
Owner

nit-pick: I would put this line in a separate paragraph so that it stands out. And maybe even make it also bold.

Because the easiest and least error-prone way to add new content is to use the Hugo command.

nit-pick: I would put this line in a separate paragraph so that it stands out. And maybe even make it also bold. Because the easiest and least error-prone way to add new content is to use the Hugo command.
stb marked this conversation as resolved
jtbx left a comment

just some editorial comments

just some editorial comments
README.md Outdated
@ -47,0 +56,4 @@
* `date`: the date displayed for this content.
For events, that should be when the event takes place; for blog posts, it is when the post was written.
* `publishDate`: the date and time the content should be published.
Note that the date is evaluated only during site generation, so if you pick a date in the future, it might take up to 24 hours longer before your content appears.
Owner

I don't understand what this sentence should tell me, especially with the explicit time of "24 hours longer".

When a publish date is set, the post will be visible on the deployed site at this date and time (or up to 20 minutes later in the worst case, because the deployment only runs every 20 minutes).
The deployed pull request however will also show posts which are in the future.

So I would rather say something like this:

- Note that the date is evaluated only during site generation, so if you pick a date in the future, it might take up to 24 hours longer before your content appears.
- Also note that if you do not specify a `publishDate`, the value of `date` will be used.
+ If a date in the future is used, the post will only appear on the web page after the specified time is due (or up to 20 minutes later since auto-deployment only runs 3 times every hour).
+ Note that the preview deployments on the staging domain will also publish posts in the future.
+ This field is only needed for events which shall be published before they actually happen (blog posts will use the `date` value as fallback for `publishDate`).
I don't understand what this sentence should tell me, especially with the explicit time of "24 hours longer". When a publish date is set, the post will be visible on the deployed site at this date and time (or up to 20 minutes later in the worst case, because the deployment only runs every 20 minutes). The deployed pull request however will also show posts which are in the future. So I would rather say something like this: ```diff - Note that the date is evaluated only during site generation, so if you pick a date in the future, it might take up to 24 hours longer before your content appears. - Also note that if you do not specify a `publishDate`, the value of `date` will be used. + If a date in the future is used, the post will only appear on the web page after the specified time is due (or up to 20 minutes later since auto-deployment only runs 3 times every hour). + Note that the preview deployments on the staging domain will also publish posts in the future. + This field is only needed for events which shall be published before they actually happen (blog posts will use the `date` value as fallback for `publishDate`). ```
Author
Owner

I thought auto deploy only runs once a day. If it's running multiple times each hour, there is no need to explain this in more detail. I'll add more explanation to the preview section.

I thought auto deploy only runs once a day. If it's running multiple times each hour, there is no need to explain this in more detail. I'll add more explanation to the preview section.
stb marked this conversation as resolved
README.md Outdated
@ -47,0 +64,4 @@
#### Add a Blog Entry
Blog posts (the archetype is called `article`) should be used for information that will be relevant for a longer period, for example explanations about technical, political or cultural topics.
Articles will be shown for a few days on the home page, and in chronological order on the [blog main page](https://hamburg.ccc.de/blog/), until newer posts push them down.
Owner

nit-pick: no comma before the "and" (because an Oxford comma is only used for lists with at least 3 items AFAIK).
And it's not really clear if the last phrase "until newer posts push them down" applies to the home page or the blog page.

nit-pick: no comma before the "and" (because an Oxford comma is only used for lists with at least 3 items AFAIK). And it's not really clear if the last phrase "until newer posts push them down" applies to the home page or the blog page.
stb marked this conversation as resolved
changes based on jtbx's review
All checks were successful
/ build (pull_request) Successful in 44s
dca8a2afb4
jtbx force-pushed explain-content-types from dca8a2afb4
All checks were successful
/ build (pull_request) Successful in 44s
to d0785aaa81
Some checks failed
/ build (pull_request) Successful in 41s
/ cleanup-staging (pull_request) Failing after 2m16s
2026-06-14 20:40:45 +02:00
Compare
jtbx approved these changes 2026-06-14 20:41:19 +02:00
Owner

I allowed myself to add some line breaks between sentences (only affects the markdown source, but not the HTML output) and squash everything into one commit.

I allowed myself to add some line breaks between sentences (only affects the markdown source, but not the HTML output) and squash everything into one commit.
stb merged commit 0992ff34c4 into main 2026-06-14 21:20:52 +02:00
stb deleted branch explain-content-types 2026-06-14 21:20:52 +02:00
stb referenced this pull request from a commit 2026-06-14 21:20:53 +02:00
stb referenced this pull request from a commit 2026-06-14 21:30:38 +02:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
CCCHH/ccchh-website!165
No description provided.