Replace static event pages with generated versions

[Bertg]

Problem

As per #556 generating a new event is painful because the following steps need to happen:

• Create new event static page
• Update index page to show upcoming events
  • These events aren't guaranteed to be ordered correctly
  • They might not even be relevant anymore, and require manual curation to fix these discrepancies
• Update events page with link to newly created event
  • See above

Solution

Move over to using jekyll to build a friendlier and more reliable event information

• Create contribution guide for adding new events (@csaunders in Updates some templates and corrects docs #562)
• Automatically show events that are upcoming on index
• Automatically show events on the events page
• Migrate existing events to new system (@andreionut in Automate listing upcoming events on the index #559)
• Extract basic template to reduce duplication (@mvz in Automate listing upcoming events on the index #559)
• Forward from old URLs to new URLs using meta refresh or Javascript to preserve SEO

[csaunders]

I'll help out with this tomorrow and I'd love to help out more. I'll be away from a computer until the 9th of October

[FloorD]

I really love this project and would love to help out updating the
contributors guide accordingly after this has been shipped.

[mvz]

I found out Jekyll lets you set the desired permalink for a post, so we can have it generate the individual event pages with their original names.

[mvz]

It looks like there are basically two ways each set of dates gets displayed. One way is used on the index page and looks generally like 'October 10-11, 2014'. The other one is used everywhere else and looks like '10-11 October 2014'. There are some variations that make transforming one to the other non-trivial.

Should we keep both date formats?

[Bertg]

@mvz Is there a technical reason why these should be consistent?

[mvz]

@Bertg making them different would mean setting an extra variable at the top of every event page. This would then also have to be part of the instructions, making them more complicated than perhaps necessary.

[mvz]

@Bertg another option would be to teach Jekyll about date ranges, and implement two formatting filters.

[Bertg]

I think we decided that:

• the name of an event file would be DATE-LOCATION.md Where the date is always the later one (not install party). e.g.: 2014-10-07-brussels.md
• the "combined date" would be a string in the header in the above file

Is this still correct? How would you change that?

[mvz]

As of my PR, this is still correct. The only problem is that the combined date is currently shown in two different ways on the index and events pages, which would mean two different strings in that header. This is not so nice, but we could stick with it.

The PR only implements the date as shown on index, by the way. It was when I wanted to start on the events page that I saw the date strings where different.

[Bertg]

I think we can leave it as is. There is no technical requirement, and it allows the creator to adjust the date to local preferences, or it could be enforced at a later time.

[keikoro]

"and it allows the creator to adjust the date to local preferences"
That's very considerate, thank you!

[mvz]

OK, I'll go with that option. We can always change later if it proves too much of a hassle.

[csaunders]

Because of the discoveries about permalink flexability in Jekyll, is the item Forward from old URLs to new URLs using meta refresh or Javascript to preserve SEO no longer valid?

(Assuming we roll with Jekyll of course!!)

[mvz]

@csaunders yes, we can remove that item I think.

[abelards]

Hi, I'd love to reopen that discussion.
Jekyll is nice and perhaps we could statically generate much statically from a CSV / YML:

• individual event pages
• upcoming / past event pages
• map and events list
• history pages for cities which had several events [1]
  Has anything been started? I'm willing to spend some time there.

[1] I'm thinking a directory like /paris with index, press,
and 2012, 2013, 2014a, 2014b, 2015a, 2015b pages.

[mvz]

@abelards I think first goal should be to automate what's there, then add extra stuff like history per city (a nice feature in itself, though!). As we envisioned it one year ago, the idea would be to store the data in the headers of the markdown files. I'll dig through my old branches and see what the status was regarding actually implementing this. Ping me if I don't get back on this soon (I may forget).