Long-term plan for the website
Posted: Sun Dec 28, 2014 4:36 am
When I last tried to hack on the website, people didn't care for patches that included libraries because they made for really ugly Git commits and Phelix didn't like the idea of using PageSpeed or other server-side optimization solutions.
I am also concerned about multilingual content. The current PHP based site would require that we roll our own solution. Moving to a CMS would require a DB and break the Github workflow.
The Github workflow and maintenance concerns clearly point to the use of a static site and I would like to convert the main site into a Jekyll site. This would modularize the structure, simplify reviews of new content, bring blog posts into our Github workflow, and ease the creation of multilingual content.
The main repo would contain only the precompiled Jekyll site, ensuring clean Git commits. The deployment server would use jekyll-hook to compile the site using a webhook. This would ensure we have control over the site, our TLS keys, and enable us to use plugins. If we chose to fork Bitcoin's excellent developer guide, we will need the ability to use plugins.
For the initial reimplementation, I would try to match the style, content, and layout of the current site. I think I can even remove the jQuery dependency. WRT i18n, there are multiple solutions for creating multilingual content with Jekyll and I want to wait until I've (re)created the site before deciding which is the best.
I am also concerned about multilingual content. The current PHP based site would require that we roll our own solution. Moving to a CMS would require a DB and break the Github workflow.
The Github workflow and maintenance concerns clearly point to the use of a static site and I would like to convert the main site into a Jekyll site. This would modularize the structure, simplify reviews of new content, bring blog posts into our Github workflow, and ease the creation of multilingual content.
The main repo would contain only the precompiled Jekyll site, ensuring clean Git commits. The deployment server would use jekyll-hook to compile the site using a webhook. This would ensure we have control over the site, our TLS keys, and enable us to use plugins. If we chose to fork Bitcoin's excellent developer guide, we will need the ability to use plugins.
For the initial reimplementation, I would try to match the style, content, and layout of the current site. I think I can even remove the jQuery dependency. WRT i18n, there are multiple solutions for creating multilingual content with Jekyll and I want to wait until I've (re)created the site before deciding which is the best.