Create program page template for theme 2.0

[mattstratton]

For the Program page template, I think that the easiest thing to do (and the least impactful) is to move the YAML for program out of the data file and into the frontmatter on the program.md file for the event. That frontmatter will look HUGE, but it should work.

If we want to make enhancements to how the program template functions (later!!), the move will be to create a new template for type "old-program" and then we will need to update all the existing program.md files to use that type, and have new stuff use the new version.

I did go back to the survey I ran years ago to see what people prefer, and data fields in a YAML file (for this purpose, TOML in frontmatter is just as fine) was the overwhelming preference.

if we migrate the YAML "as-is" to TOML, I think the frontmatter for a program page would look something like this:

Title = "Program"
Type = "program"
Description = "Program for devopsdays Chicago 2019"
icons = "TRUE"
program_elements = [
    { title = "Registration, Breakfast, Sponsors", type = "custom", start = 2019-02-15T08:00:00-06:00, end = 2019-02-15T09:00:00-06:00 },
    { title = "Opening Welcome", type = "custom", start = 2019-02-15T09:00:00-06:00, end = 2019-02-15T09:15:00-06:00 },
    { title = "jeff-smith", type = "talk", start = 2019-02-15T09:15:00-06:00, end = 2019-02-15T09:45:00-06:00 },
    { title = "Ignites", type = "ignite", start = 2019-02-15T09:45:00-06:00, end = 2019-02-15T10:15:00-06:00 },
    { title = "Registration, Breakfast, Sponsors", type = "custom", start = 2019-02-16T08:00:00-06:00, end = 2019-02-16T09:00:00-06:00 },
]

and so on...the upshot of this is that we get timezone info. But we don't necessarily have that. We might have to do something where "if we don't know the timezone from another field in the main data file, we just set it to US central" because this is only for historical programs and if the time isn't right, it's probably Not the End of the World.

We could also have the following be supported:

program_elements = [
    { title = "Registration, Breakfast, Sponsors", type = "custom", date = "2019-02-15",start_time = "08:00", end_time = "09:00" },
]

so the template code for the program page would have to be pretty weird; it would have to check for an element that has date set, and if so, it works differently. This might be okay (we did this for the speaker page to handle the backward-compatibility with the data files; it means that in the template you have one big giant "if" statement to say "do I draw the program the new fancy way or use the old way?" and go from there.

We also need to handle #6543 as long as we are here; I think it works the same way. If it detects any elements with date set, then it displays ignites a certain way; if not, it will do whatever magic I come up with to handle this idea of multiple ignite blocks per day (fyi, this is something that I need to solve for 2020 Chicago, so it's Kind of Important to me, lol)

[mattstratton]

I have been able to get a pretty decent POC for the initial stuff - it's using frontmatter in the program.md file as explained above (right now it only works with .start and .end set as datetime; I think it will be pretty easy to add the exceptions for if ".date is set, etc, once I have all the logic working).

Basically, there are just a couple places where the date and time stuff gets pulled/set; I can set those to use variables or something based upon if the element has .date set or not, etc.

I will try to also get #6543 addressed in this one as well (since I have to touch ignite code anyway)

[mattstratton]

I also occurs to me that if we aren't doing any time-zone conversion stuff, we can actually turn .date and .start_time etc into a single constructed datetime field in the migration; we would just set everything to a standard timezone offset (this might cause some weirdness if we wanted to have the TZ conversion stuff mentioned in #9819 if, for example, all migrated events are set to -6:00 offset, etc...but this could just be some search-replace cleanup for existing events when we want to add it; we could also have an optional frontmatter flag that enables the conversion so you have to opt-into it, so you won't get caught in a weird way)

[mattstratton]

I got it all working in the template! I also handled #6543; the way it works looks a little like this:

"old-style" ignite block in schedule:
{ title = "Ignites", type = "ignite", start = 2019-08-27T13:00:00-06:00, end = 2019-08-27T13:30:00-06:00 },

ignite block that is custom/named:
{ title = "Ignites", type = "ignite", block = "ignite-1", start = 2019-08-27T13:00:00-06:00, end = 2019-08-27T13:30:00-06:00 },

inside the ignites[] array:

ignites = [
  { title = "veronica-hanus", block = "ignite-1",date = 2019-08-27},
  { title = "jay-gordon", date = 2019-08-27},
  { title = "adam-shake", date = 2019-08-27},
  { title = "jason-yee", date = 2019-08-28},
  { title = "heidi-waterhouse", date = 2019-08-28},
 ]

So what ends up happening (bear in mind that you would likely not mix elements with a block and without in the ignites[] array, but it works if you do) is this:

• You get a block of Ignites on the program with just Veronica (this is the block called "ignite-1")
• You get a block of Ignites on the program on 8-27 with Jay and Adam
• You get a block of Ignites on the program on 8-28 with Jason and Heidi

So if you want to go "traditional" style of one ignite block per-day, all you need to do is set a program element of type "ignite" for that date, and put a bunch of elements in ignites[] with that same date (that is how it works today).

If you want to have multiple ignite blocks on the same day, you use the optional block parameter in both program_elements[] and ignites[] entries.

[mattstratton]

OK, so this is a pretty big improvement! Keeping in mind that my test doesn't have a full second day in the program, here are the differences in processing for the program page:

     cumulative       average       maximum
       duration      duration      duration  count  template
     ----------      --------      --------  -----  --------
  1m1.969173719s   746.61655ms  2.321037845s     83  program/single.html
     7.208317ms    7.208317ms    7.208317ms      1  new-program/single.html

Ignore "cumulative duration" as obviously it only processed 1 program vs 83.

BUT...

7 ms vs 746 ms! That's huge, especially since the program page is the heaviest thing we do. If my math checks out, we will be processing ALL the program pages in under a second, vs taking a minute to do them now.

Of course, if we end up "unarchiving", we'll have more program pages to handle, but this is a big win.

UPDATE: the program template with a full day (so basically, this was with 12 talks and 10 ignites) is 11.621999ms, so it's still pretty dang efficient.