long term: separate the site code from the board code

[oakmac]

The code that powers the website really should be it's own repo and this repo should just have the code and content for this component.

ie: this repo shouldn't contain any PHP

[kernc]

actually, the code for the site can be in gh-pages branch, reliably served by GitHub.

oh, you use PHP. how awkward.

what is the dynamic nature of the site?

[oakmac]

GitHub pages does not support dynamic content (to my knowledge).

The dynamic nature of the site can be found in the PHP pages, unless they are too awkward for you to inspect yourself ;)

[kernc]

Indeed. Sorry. It actually completely escaped my mind to look at the files. I only visually inspected the site.

But I must confess to the latter, what does the PHP code do that can't be trivially achieved in a purely static, client-side environment?

Is there a reason to not having a single, complete documentation page, written in well-maintained markdown, styled as is, and dynamized with JavaScript as is, other than you (perhaps) not yet having the beautiful experience of doing so? :smiley:

This is a page describing one essential feature of Jekyll, the static site generator GitHub uses. This is the page's source file as it looks in production. In contrast to that page, I think you could maintain your tables as tables.

Well, it was just a suggestion anyway.