Figur out how to do "time-boxed" entries to the banner

[svrnm]

In our banner we most entries are time-bound (e.g KubeCon, GC-election, an end user SIG event, etc.), and sometimes we forget about those entries and they stay in the banner for way to long.

I suggest that we add a feature where we time-box those entries with some hugo code, e.g. something like

{{- if (today <= enddate) -}}
Here is my banner entry that is only valid until enddate
{{- end -}}

Using time functions this should be fairly easy to figure out. There are 2 advanced features we might doing at the same time:

• Move the banner entries themselves into a data file, so people can just append them to a list (and we can update previous entries more easily). Disadvantage is that this list may grow over time containing a lot of outdated stuff
• Verify that 2 entries at max are shown. I am not 100% sure exactly how we want to enforce this best.

[ricardoamaro]

@svrnm can someone assign this one to me?

[ricardoamaro]

To ensure that banner entries are only displayed until their relevant end date, we could define the End Date for each Banner entry.
If we move the banner entries to a data file, each entry could look something like this in a YAML file:
eg. data/banners.yml

- title: "New Event"
  url: "https://example.com/new-event"
  message: "Join our new event until May 20th!"
  endDate: 2023-05-20

- title: "OTel Community Day"
  url: "https://sessionize.com/OTel-Community-Day/"
  message: "Join us for OTel Community Day on June 25th!"
  endDate: 2023-06-25

- title: "OTel and Prometheus Survey"
  url: "https://forms.gle/bZAG9f7udoJsjZUG9"
  message: "Help improve OTel and Prometheus interoperability: complete our survey by May 31"
  endDate: 2023-05-31

Option 1: Then we will need to modify the banner display logic in banner.md partial to loop through the banner entries and check the current date against each entry's endDate. Something on these lines:

{{ if .Params.show_banner }}
  {{ $currentDate := now.Format "2006-01-02" }}
  {{ range $.Site.Data.banners }}
    {{ if le $currentDate .endDate }}
      <div class="o-banner">
        <i class="fas fa-bullhorn"></i> <a href="{{ .url }}">{{ .message }}</a>
      </div>
    {{ end }}
  {{ end }}
{{ end }}

Option 2: if we also want to implement other logic, where the website banner shows the two entries with the closest end dates, we could follow this example that uses Sort and Filter and limits display using the first function. This limits the selection to the first two entries:

{{ if .Params.show_banner }}
  {{ $currentDate := now.Format "2006-01-02" }}
  {{ $sortedAndFiltered := slice }}

  {{/* Sort entries by endDate and filter out past ones */}}
  {{ range $.Site.Data.banners }}
    {{ if ge .endDate $currentDate }}
      {{ $sortedAndFiltered = $sortedAndFiltered | append . }}
    {{ end }}
  {{ end }}
  {{ $sortedAndFiltered = $sortedAndFiltered | sort "endDate" }}

  {{/* Limit to the two entries with the closest end dates */}}
  {{ $entriesToShow := first 2 $sortedAndFiltered }}

  {{ range $entriesToShow }}
    <div class="o-banner">
      <i class="fas fa-bullhorn"></i> <a href="{{ .url }}">{{ .message }}</a>
    </div>
  {{ end }}
{{ end }}

A consideration to take is that over time, banners.yml file may grow with outdated entries. Periodically, we will need to clean it or create a script to automatically remove past entries.

Opinions, thoughts, suggestions?

[svrnm]

I prefer Option 2, since we should limit the number of banner entries, 2 is what we do max right now.

Would you mind raising a PR for this such that we can see a preview of that? Maybe add some outdated example entries and some examples in the future to see the logic working.

Note that we do not assign issues, just raise the PR and by that you are the one working on that.

@chalin wdyt?

[chalin]

Overall, I prefer option 2, but with these changes:

• Banner YAML entries of the following form:

  - text: Some markdown text possibly with HTML
    from: <some-date> # optional
    to: <some-other-date> # also optional

• Keep banner data as close to where it is displayed, so I'd suggest putting it in the front matter of content/en/_index.md as a field named something like banners.

Thoughts?

[svrnm]

@chalin thanks, sounds good to me, @ricardoamaro please take a look at @chalin's comment and if possible add it to your PR #4429

[chalin]

Closed by:

• [i18n] Support automatic banner management across localizations #4625