Recreate / Improve the GitHub Pages Hosted CFG Website
Closed this issue · 14 comments
This repo (repository) controls the content of the https://codeforgreenville.org website and it's hosted through GitHub Pages.
There are a lot of files in this repo which are note used / old / hidden because when it was created by Wryen he setup it up as a larger blog. I believe that was using Jekyll.
The blog only saw a few updates and became stale and I had trouble figuring out Jekyll at the time, so I just manually modified the HTML and CSS files in the repo to workaround the lack of knowledge and to remove out of date stuff.
In any case, Hugo is a Jekyll alternative and either could be used to recreate / revamp this repo.
@theklopex @JayhawkGreencape this is an example of a new issue that's related to this specific repository of code.
If you wanted to play around with Hugo or Jekyll, then I think @oliviasculley @ramonaspence and I could guide the way.
Here's Bogdan's proposal for a new CFG site (posted in the HG Slack)
David in our Slack group has made progress on turning that mockup above to code and @cetully12 is a new member who is interested to help with that task too.
We have a screenshot above, but was that screenshot from a design file or was it actually from a site you generated?
Thanks
I just want to add with experience in both Jekyll and Hugo i can greatly recommend using hugo over jekyll, I've had so many more issues with jekyll's ruby gems versus getting hugo working
At this point, we'll take a working HTML file, CSS, and images, which is what we've had for years after we deleted a bunch of stuff and didn't take the time to figure out the Jekyll overhead.
If someone wants to convert it into Hugo, then that's icing in my book.
I just looked up Jekyll and Hugo because I hadn't heard of either of them .. I can work on the front-end stuff, but would require help with the fancy back-end things 😁
@cetully12 I'll ping you in the Slack with a link to Dave's public-facing domain showing what he's done so far.
We don't have a branch for the new website, but at this point it's a single HTML, CSS and a few images so let's not let that stop anybody from downloading Dave's work locally and tweaking it until we get a proper branch setup.
If only one person is working on the changes, then they could create a pull request against the master branch and we simply merge those changes in.
Though, if more than one person want to commit and iterate on it then we can't push to master until there's a reasonable version of the new site, since the master branch is THE source of the live website.
I'm thinking I could checkout the repository, remove unnecessary old files, and push a "new-site" branch. Then, others could fork (if they haven't already), git pull, switch to new-site branch, and create PRs against that branch until we're ready to merge it into master.
Funny enough, I either never saw, or forgot, the Jekyll source for the original site (from 9 years ago) is in the source branch in the same repo, complete with Wryen's (the group's short-lived founder) notes.
There's a lot of overhead to using Jekyll paradigms for a one page site, so I'm still of the mind we just focus on improving our current one page site with raw HTML, CSS and if/when there's more ambition for more pages we could consider Hugo or similar site generator tooling.
It's pretty easy to convert a regular html site to a Jekyll/Hugo site later, so there's definitely no issue using plain html/css/js and expanding it with hugo to add more pages later!
@allella, looks like Dave made a PR for the redesign, but I can't tell how far along he got on that version. Seems like his http://dev.bamatech.org/ is further along, but I'm not entirely sure.
I like your idea of creating a "new-site" branch that folks could work on until we can merge it into the master.
Alright, I'll work on setting up a new site branch.
@cetully12 the new https://github.com/codeforgreenville/codeforgreenville.github.io/tree/new-website should show up on your local copy when doing a git branch -a after doing a git fetch, as below.
From there, the Step 5 under the Traditional Dev Environment on the Chapter docs will most apply to make changes and send over a PR with those changes.
- git fetch upstream (or if you called the remote upstream something else, then git fetch whatever-you-called it).
- git branch -a (and the new-website branch should now be in the list)
- git checkout new-website
- git checkout -b create-a-new-branch-to-do-whatever-you-want
- make changes and one or more commits with your proposed changes to the local create-a-new-branch-to-do-whatever-you-want branch
- git push origin create-a-new-branch-to-do-whatever-you-want
- Then, back on GitHub on your forked repo, you can create a pull request, being sure to select the "new-website" as the branch to which to merge against, not main.
Also, I've archived some of the old blog pages.
The only content that still exists in this new-website branch, besides the homepage (index.html), is the about/code-of-conduct/index.html
I'd propose we convert that to the same template because it probably will look terrible now that I deleted the screen.css file that styled it.
@cetully12 Thanks. I'll take a look in the next day or so.
For color palette, we don't have one for CFG. Given the overlap between HackGreenville and CFG I'd just assume work with the same styling as in https://hackgreenville.com/styles , at least until we come up with time to do something for CFG.
The Code For Greenville domain has been redirect to Code For The Carolinas.
Olivia is planning to work some of the redesigned CFG elements into a new "Labs" page on the HackGreenville site. So, closing this in favor of hackgvl/hackgreenville-com#138
Thanks for those who contributed. Please check out the newly rebranded HackGreenville Labs repos, including the hackgreenville.com site Laravel repo