Jekyllify the site

[dlindahl]

This PR converts the static content that @haileypate wireframed into a standard Jekyll site structure.

• Updates the Jekyll config to include only the settings we care about
• Adds site-wide metadata to Jekyll config for easy inclusion into other pages (site name, tagline, contact info, etc)
• Adds a blog page that displays excerpts and links to the last 5 posts based on the contents of _posts
• Adds a projects page that displays all of the projects defined in _data/current_projects.yml that I stubbed out
• Adds stubbed out Markdown versions of pages that contain pure content (About Us, etc)
• Adds stubbed out HTML versions of pages that will contains forms, 3rd party integration (Contact Us, Calendar, etc.)
• Moves JS, CSS, and fonts to assets/ to keep things a bit more organized
• Adds README.md file with local development instructions
• Adds basic CONTRIBUTING.md file with guidelines for contributing to the site

[dlindahl]

Because of your merge of #7, I had to rebase my branch on top of your changes. In the process, I managed to jack up my local repo. I am going to close the PR, delete the branch, and re-open it.

[dlindahl]

@haileypate Bootstrap and Jekyll are really two completely different things. Jekyll is a static site generation tool and Bootstrap is an HTML framework. So there is really nothing preventing you from using both.

I would recommend checking playing around with what I have done in this PR so you can see a bit better as to how a Jekyll site is organized and compiled.

Long term, I don't see much of demand for styling or functionality contributions. I would imagine that once the site is up, it will be up. I imagine most contributions would come in the way of content. I have set the site up to use Markdown for most content-driven pages so that outside contributions can be made without needing much technical ability.

If that is indeed the case, I think you should feel free to pick whichever HTML framework you'd like and not worry about the learning curve for others. And really, none of the major frameworks are really that difficult to learn, especially once most of the boilerplate is done. Plus, contributions can be code-reviewed before being merged to master and deployed which should give us an opportunity to help people learn the "right" way to work within the framework.

[haileypate]

I'm sorry I jacked up your repo.

For what it's worth, I jacked mine up too! But I got to practice my stash command?!

And hey... I realize now that there's something in your branch that my local apache server didn't like... because when I looked at your branch last week the styles weren't rendering!

When I use jekyll to serve your branch, I can see the site with the styles. So... I regret not doing more troubleshooting after receiving your first pull request.

Made you an admin now, so please feel free to push your good work directly to master. Grateful for your patience with me =)

Hailey

On Wed, Mar 26, 2014 at 8:59 PM, Derek Lindahl notifications@github.comwrote:

Because of your merge of #7https://github.com/code4sac/code4sac.github.io/pull/7, I had to rebase my branch on top of your changes. In the process, I managed to jack up my local repo. I am going to close the PR, delete the branch, and re-open it.

Reply to this email directly or view it on GitHubhttps://github.com/code4sac/code4sac.github.io/pull/3#issuecomment-38767034 .

Hailey Pate | 2haileypate@gmail.com | @haileypatehttp://twitter.com/haileypate

[dlindahl]

No worries, the mistake was mine and it was easier to just resubmit the PR :smile:

Are you still having an issue with apache and the site? I generally don't use Apache as a front-end when developing because its usually overkill. I also like being able to know what is running and what isn't.

If you are still having issues, let me know and I can look into it.