-
Notifications
You must be signed in to change notification settings - Fork 26
MPI Forum Web Maintenance
Instead of using:
https://github.com/mpi-forum/meetings.mpi-forum.org
you will now use:
https://github.com/mpi-forum/mpi-forum.github.io
The latter automatically gets compiled in Jekyll by GitHub and posted on the website. This is different from PHP because it’s not generated on the fly as the user asks for it. All of the pages are static.
The formatting of the pages is in _layouts. Ideally, no one should ever have to change these HTML files, but in case you do, there they are. If you see something with {{ }} or {% %}, that’s the fancy formatting for Jekyll/Liquid (the formatting that GitHub uses to interact with data files.
The pages themselves are in meetings/year/month/<page.md>. These are the actual pages that show up on the web. They all have a header that looks something like this:
---
layout: attendance
date: December 5, 2016 - December 8, 2016
year: "2016"
month: "12"
permalink: meetings/2016/12/attendance
---
That block picks the right layout and gives the important metadata to be able to track down the right data files. Underneath that metadata, there’s usually nothing. If you put something there, it will show up on the page, but most of the pages are generated from the data files. The exceptions are the logistics pages, which just have regular markdown to describe what’s going on. You can see an example here (you might want to click on the “Raw” button to see the source instead of the formatted markdown).
The all important data files are in _data/meetings/year/month/<data-file>. There are generally three different data files for each meeting.
First (and hardest) is the agenda data. Here’s an example.
For the most part, it should be pretty self explanatory. There’s three blocks of data, the schedule, the votes, and the plenaries. Each one has a few pieces of data that will need to be filled in for each item (similar to how the old page had PHP functions for each item. You can use HTML in these blocks (there are some places where we had embedded links), just make sure to put things in double quotes and escape any extra double quotes. There’s an example here.
The second (and simplest) is the attendance data. Example here (again, the “Raw” button might be helpful).
This is just a normal CSV file. Just make sure to put anything in quotes that needs to be (I’m looking at you "Cisco Systems, Inc.”).
The last file is the votes data. Example here (again, “Raw”).
This one is also a CSV that’s pretty straightforward. The labels at the top of the page describe what they are. The further back into the archives you go, these files change a bit to account for our old voting system. Again, quotes should be used to clean things up.
For the most part, when creating a new set of pages for a new meeting, you can just copy the previous meetings pages into the same places (make sure to get both the meetings/ and _data/ pages). Then you’ll want to update the main meetings page to link to the new pages. That page is called Meeting_details.md and is in the top level directory. If you’re not familiar with how Markdown works, you should be able to just copy/paste what I’ve already done. The main thing you’ll need to know is that | symbols are usually for table formatting and [text](link) is how links work. There’s lots of quick references on the web if you need to know more, but is how our wikis have worked for a while so it shouldn’t be too new.
GitHub has made it pretty easy beyond that. We don’t have to worry about re-compiling or anything like that. If you really want to try out the website locally before pushing things remotely (or you’re having trouble figuring out why something isn’t showing up correctly), it’s possible to serve up the website on your own computer. It’s not too hard to do. Instructions are here: https://jekyllrb.com/ It’s the 5 lines in the middle of the page (really, it’s more than 5 commands because you probably don’t have “gem” installed on your laptop). I’ve been using it on my laptop to do this whole migration and it works really well. It even gives you decent error reporting if you have a syntax error (usually I missed a quote in my .yml file somewhere).