Github based content management

[hmaurer]

Because we all love github I feel it would be fun (and deliciously experimental) to store all the pages as files in a git repository. The markdown would be annotated with some attributes such as the nav title and the website would pull the content from the repo (either through an admin button or a github hook).

I can do the implementation :)

[R2ZER0]

Hmm, it's a possibility, however we would still need a facility for editing without access to git. Currently pages are stored in the database, which ties in very nicely with everything else.

What would be the benefit of this system versus an in-database system? Also, we (i.e. angusp) are currently working on decoupling the navbar and page store, how would we do this with a git-page based system? Also, we currently use a synchronous database cluster to ensure any changes propagate to every instance of the website simultaneously, we would have to think about how to do that - and how to make the web servers update when they are supposed to?

[CraigSnowden]

Not keen on this

[Sunstrike]

Well, Github has a very capable web editor for files that can even create new files. But I agree, this doesn't offer us much benefit except "backup built-in".

[hmaurer]

I agree it doesn't provide tremendous benefits but it would be technically interesting. It does, however, provide a few advantages (ss Sunstrike pointed out):

• capable web editor
• built-in versioning
• edit the website from command line (vim, emacs etc)

An in-database system is definitely easier to build but it would be a fun experiment in the long-run.

[R2ZER0]

Hmm, actually those are some nice advantages. How would you implement this? There is a minor deployment issue, as we would have to define a directory for the pages repo - i suppose actually this can simply be set via environment variable. Then there is just keeping the webservers all in sync, a way to make them all pull at the same time.

[hmaurer]

Keeping the server in sync shouldn't be much of an issue. We can set up a github hook, in which case we just need to have an route on the website that triggers the content update when called (i.e. comp-soc.com/pull-content). I think we could even set it up such that the website doesn't sync at every push but only when a new version is tagged. It might be a bit challenging but that's a good thing, eh

[hmaurer]

Not sure how to smoothly integrate it with https://github.com/compsoc-edinburgh/website-django/issues/12 though.

[AngusP]

This could actually be really great as a pseudo api: If you had bash scripts/ programs running on the server and other compsoc computers (DICE...?) they could write to JSON files or something that then get synced to the server... But as a CMS it's fairly limited.

[CraigSnowden]

Still feel like you're reinventing the wheel here— Sent from Mailbox for iPhone

On Thu, Jan 30, 2014 at 10:18 AM, Angus Pearson notifications@github.com wrote:

This could actually be really great as a pseudo api: If you had bash scripts/ programs running on the server and other compsoc computers (DICE...?) they could write to JSON files or something that then get synced to the server... But as a CMS it's fairly limited.

Reply to this email directly or view it on GitHub: https://github.com/compsoc-edinburgh/website-django/issues/16#issuecomment-33675274

[hmaurer]

Fair enough. Issue closed then.

[Sunstrike]

Maybe not for the direct page store, but using Git for backup could be a hell of a lot better than database dumps; it also means we can keep things versioned, if it syncs to a backend Git store.

[hmaurer]

+1 Sunstrike, the other way around would be interesting,