search

devopsdays / devopsdays-web

This is the website for devopsdays
https://www.devopsdays.org
Other
171 stars 664 forks source link

Make specific pages for individual organizers #13757

Open mattstratton opened 6 months ago

mattstratton commented 6 months ago

This had been part of the refactor, but this is to move the organizer information out of the data file, and instead use pages for it

mattstratton commented 2 months ago

If we are to do this, i think that we need to keep in mind the following:

  1. ensure backwards compatibility - this is actually pretty easy. the current way organizers are shown is using the shortcode list_organizers, which is just put in the example file for contact.md. So once there is a capability for this breakdown, you would "opt in" to using it by making your contact.md of the type "contact", which would use a different template (and make sure your contact.md doesn't have the shortcode.
  2. I guess i really only was thinking about the first thing, so there isn't a number 2
mattstratton commented 2 months ago

for more info on above, consider this:

the current content of /utilities/examples/events/yyyy-city/contact.md is:

+++
Title = "Contact"
Type = "event"
Description = "Contact information for devopsdays CITY YYYY"
+++

If you'd like to contact us by email: {{< email_organizers >}}

**Our local team**

{{< list_organizers >}}

{{< list_core >}}

This change be implemented by creating (in the theme directory) layouts/organizer/single.md and layouts/contact/single.md. (the first is the layout for a single organizer, the second is the layout for the contact page)

The example file referenced above would be changed to something like:

+++
Title = "Contact"
Type = "contact"
Description = "Contact information for devopsdays CITY YYYY"
+++

We also need to update utilities/add_organizers.sh to create each organizer file (likely path is /content/events/yyyy-city/organizers/ instead of manipulating the data file.

Also, update utilities/examples/data/events/main.yml to remove the entire team_members section.

Basically, in this setup, any old pages using the old setup will just keep working, but new things can use the new one.

mattstratton commented 2 months ago

I started to spike on this and I'm starting to wonder if it's worth it - it also will add a lot more pages to generate at build time. Hmm.

phrawzty commented 2 months ago

I'm not personally convinced that the additional complexity & build time is worth it. 🤷

On Mon, Jul 8, 2024, 13:33 Matty Stratton @.***> wrote:

I started to spike on this and I'm starting to wonder if it's worth it - it also will add a lot more pages to generate at build time. Hmm.

— Reply to this email directly, view it on GitHub https://github.com/devopsdays/devopsdays-web/issues/13757#issuecomment-2213769438, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEYUUAUJUTO7K2422OG2BDZLJ2JRAVCNFSM6AAAAABEABNQKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJTG43DSNBTHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

mattstratton commented 2 months ago

I wish I could remember why I wanted to implement this.

It might have just been part of the “everything is a page” model of the theme refactor that I’ve kind of given up on at this point 😂

toshywoshy commented 2 months ago

The only reason this could be interesting, is if you want to link organisers to multiple events and then have them listed on a page, so an individual organiser's page would state the other events they would be helping out with But I think the overhead is too much and most probabily not worth the effort