Figure out how to decouple public facing side with admin side.

[brianloveswords]

If people want to deploy this on their own, they have to hack on stuff that's in the repo to remove all of the webmaker branding. Everything under /views/public/ should be removed from the repository and included in some other way, maybe via (ugh) git submodules. We also have to think about how to include static resources from the them, so we should probably also add another static middleware handler that points to /views/public/static so the themes can be fully local.

Copying @stenington for more thoughts on this.

[stenington]

It might be nice to provide a generic set of pages for the basic stuff we anticipate people wanting to do. We could extract some stuff into config, and use Bootstrap so that the lazy or uninterested could just set some variables, pick a Bootswatch skin and be on their way.

An alternative to git submodules might be to maintain two forks of the project (one generic, one Mozillified) but I don't know if github will let us do that under one user.

[rossbruniges]

Regarding the multiple forks it won't - you click the fork button and it says something along the lines of 'this project is already forked to Mozilla'

On Thursday, January 31, 2013, Mike Larsson wrote:

It might be nice to provide a generic set of pages for the basic stuff we anticipate people wanting to do. We could extract some stuff into config, and use Bootstrap so that the lazy or uninterested could just set some variables, pick a Bootswatch http://bootswatch.com/ skin and be on their way.

An alternative to git submodules might be to maintain two forks of the project (one generic, one Mozillified) but I don't know if github will let us do that under one user.

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/openbadger/issues/41#issuecomment-12957825.

[jdotpz]

What is your feeling on performing surgery on this to get in our current working deploy/dev methodology, versus spending that effort on the AWS-ification of it alongside this. Thus, we could include different repos to strip out what we want, different debian packages to apt-get deploy, etc.

[rossbruniges]

I might have missed some of the context here but it feels like a problem that might be able to be fixed with some separation/organisation of our assets?

Or is the problem more along the lines of dev set-up and deployment?

On Friday, February 1, 2013, JP Schneider wrote:

What is your feeling on performing surgery on this to get in our current working deploy/dev methodology, versus spending that effort on the AWS-ification of it alongside this. Thus, we could include different repos to strip out what we want, different debian packages to apt-get deploy, etc.

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/openbadger/issues/41#issuecomment-12988505.

[cmcavoy]

@rossbruniges If they (a user who wants to white label deploy) does it now, they can't pull updates, at least not without a bunch of hassle. If we make the styling a full blown skin (or submodule...or whatever) it makes it easier to get updates overtime.

[rossbruniges]

Sorry - now I'm seeing the whole issue (a luxury I didn't have with the email updates on my phone I see the context set by @brianloveswords)

This is something that WordPress is quite good at - while I don't know if actually this has much benefit over a submodule in reality we could maybe try and emulate WordPress' ability to have theme files at a location different to the core code?

http://codex.wordpress.org/Determining_Plugin_and_Content_Directories#Constants

Maybe some ENV variable for theme directory/url?