Start using templates again

[bennlich]

@sierkje @jnny @paidforby @jhpoelen @maisutton

This PR changes the peoplesopen-front directory structure and build process to match that of https://github.com/sudomesh/disaster-radio-website.

Page content is determined by markdown files and twig templates (see README).

Before merging, I think it would be helpful if someone would git checkout this branch, follow the readme to try to build it, and compare the built website to the existing peoplesopen.net. Test links, etc. I think I've been pretty thorough, but this kind of thing always benefits from having more than one tester.

Important! This PR breaks existing URLs. https://peoplesopen.net/some_page.html is now located at https://peoplesopen.net/some_page/index.html. I think this is a more modern (blech modernity) url scheme, because your browser's url bar will show https://peoplesopen.net/cool-page instead of https://peoplesopen.net/cool-page.html.

BUT! We obviously need to make sure old links still work. Probably the way to do this is by telling the webserver to send HTTP 301s that direct clients to the correct new URLs. I'm not familiar with what is being used to serve this front-end, but would be happy to look into it with someone who is!

ALTERNATIVELY, if we don't want to use these new modern urls, we can also just change the build process to spit the htmls out exactly where they used to live. I think I like this idea less at the moment, but am definitely open to it.

the how to update instructions at the bottom of the readme are definitely broken with this setup. this is another thing to look at w/ someone who knows more about the existing deployment process / webserver

Other notes:

• I replaced the old gumby.css with disaster-radio-website's _gumby.scss. Both of these files contained site-specific styles, so I tweaked _gumby.scss to make peoplesopen.net look the same as before. In future work, we should probably put all future style changes in _custom.scss and remove any site-specific styles from _gumby.scss.
• I modified the navbar typeface slightly to make it more legible.

Question: Is the gh-pages functionality still important for the peoplesopen.net repo? Or is that a remnant of a former life?

[paidforby]

Awesome work @bennlich It looks great! One thing, you forget to change the internal links on pages to point at /cool-page instead of /cool-page.html. I'll merge your commit since we won't intermediately rebase the server, but you should open another PR to fix those links and remove the old html pages (though I also noticed you didn't migrate workshop.html to markdown).

To answer a few of your questions: gh-pages is not used whatsoever, anymore. We are using nginx on a digitalocean droplet to serve up our websites. I'm happy to test out the 301 redirects with you sometime this weekend.

Thanks for doing this! It's a much needed update!

[bennlich]

One thing, you forget to change the internal links on pages to point at /cool-page instead of /cool-page.html.

I also noticed you didn't migrate workshop.html to markdown

Are you sure? I thought I made those changes. Maybe you were looking at an older commit? Or maybe you were looking at the gh-pages branch of the fork instead of the master branch?

To answer a few of your questions: gh-pages is not used whatsoever, anymore. We are using nginx on a digitalocean droplet to serve up our websites. I'm happy to test out the 301 redirects with you sometime this weekend.

Cool!

Thanks for doing this! It's a much needed update!

Woo! Thanks @paidforby !

[jhpoelen]

fwiw - I'd prefer 302 redirects instead of 301.

[bennlich]

@jhpoelen 302 works for me. I don't have much experience with redirects in practice. I think I read that 301 is permanent and 302 is temporary? What's cool about 302?

[paidforby]

Good point about 302 redirects. 301s are "permanent," meaning sticky. People's browsers will cache the redirect for eternity, so it is a lot harder to undo a 301 if you decide you no longer want the redirect to exist.

[paidforby]

@bennlich you're right I was looking at an old commit some how, darn sticky redirects...

[bennlich]

People's browsers will cache the redirect for eternity, so it is a lot harder to undo a 301 if you decide you no longer want the redirect to exist.

Aha. Makes sense.

Btw it looks like there's currently some kind of peoplesopen/ -> peoplesopen/.html redirect in place. Maybe we should look out for this when examining nginx config.

[paidforby]

i don't think there a general rule like that, you probably noticed becuase peoplesopen.net/workshop happens to redirect to peoplesopen.net/workshop.html, this is merely coincidence. That redirect pointed to a dead eventbrite page until @maisutton created a new workshop landing page, that happened to be named workshop.html

[jhpoelen]

@paidforby Actually, I put that redirect in place, 'cause it was still pointing to the eventbrite.

[paidforby]

was wondering who changed it. I'd forgotten switch it after that page was created. Regardless, that can be refixed again after we rebase the site.

[bennlich]

I added this to peoplesopen.net nginx conf:

# redirect from /*.html -> /* so old links don't break
location ~ ^/(join-the-network|about|how-to-help|developer|documentation|map|swag|workshop|node-request)\.html$ {
    return 302 /$1;
}