Bootstrap.css, CodeIgniter, and MacPorts - oh my!
This has been an interesting week in JAX, development-wise.
I have been volunteering with a start-up company out of Atlanta for quite some time now. Recently, we decided to change hosting providers (hello, Bluehost!) and, during the move, to add a couple of new domain names. Since we are essentially moving our old content to the new domains, this would be a great time to "clean up" our websites as well.
And what a cleanup effort it is turning out to be! One of our websites appears to have been produced with a "site-builder". Its structure could best be described as "archaic", with its heavy dependence on multiple embedded tables for spacing, and images to get the look-and-feel that was desired. Some of our other sites are based on WordPress - nothing wrong with that, really, if you are producing lots of "story oriented" content. However, we are using it to produce basic pages, and as a result have too many custom page templates - essentially, one per page! (Let's be clear: I'm not finding fault. It is often better to have a page set up any-way-you-can than to have nothing! It's just time for some clean up.)
In order to create a more modern set of sites - with less run-time and development overhead, I have chosen to use the CodeIgniter PHP framework for the back-end. (Note: You're going to want to have their GitHub - more on git below - link.) The look-and-feel is based on Twitter Bootstrap with some elements of HTML5 Boilerplate added in. As a result, IE6 will no longer be directly supported. (IE6 users MAY choose to use the Google Chrome Plugin, if they wish, to continue to use the site(s).)
Since my background is in software development for LARGE companies, I have a growling-need-in-my-gut for source control. There is nothing worse than cleaning up late in the day only to suddenly realize that you just deleted all the changes from the last two weeks. With no backup. ARGH!! With all the HUGE changes I am attempting, I needed the comfort a source control system provides. Recent reading and testing has convinced me that git is certainly the way to do source control today. Indeed, if your hosting provider supports git, it is an excellent way to manage the deployment of your site(s) as well. (You're going to need a link to and/or an account on GitHub at some point if you work with git. If you follow the links in this article, you'll find many of them wind up at GitHub.) If you are new to git version control, this article describes my general approach.
Initial setup with the new hosting provider was accomplished a couple of weeks ago. The git-based deployment system mentioned above is so sweet! This week, then, found me working on converting the previously WordPress-based site(s). I first extracted the site(s) with SiteSucker as HTML. The process of creating generic headers and footers came next. This was aided by the "generated" nature of the WordPress sites. While it was a lot of cut-and-paste, at least it was fairly consistent cut-and-paste.
With a basic backend structure for the pages in place, it was time to "modernize".
My first attempt was to use Sass to "consolidate" all the CSS from the WordPress theme and our considerable customizations into one file. (Hence, one of the things I dislike about using WordPress for "pure webpages": Every page not only needs custom HTML, but CSS as well!) While I was able to consolidate the myriad of CSS files and many of the selectors contained in them, applying Bootstrap proved futile. In the end, "redeveloping" the pages proved to be the easier.
(This is where I get to tell you that if you aren't using LESS or Sass to "do" your CSS, you're wasting time and energy. If you STILL think CSS is the only way to go, don't read this article!)
"Redeveloping" without "making the same mistakes" is a challenge - you certainly cannot do it in a hurry! My process began with isolating generic headers and footers, and continued with specific page changes.
The footers were relatively easy. I had done much of the work on them for one of our other sites. The headers, though, were more complicated because they are, well, complicated (they contain two navigation bars), and because I am still learning Bootstrap. Here is where spending a little extra time really paid off. After searching on Google for a while, I wound up back at Bootstrap's excellent documentation site. My mindset was similar to when I first started using a Mac - I thought, "It can't be that simple." A few hours and some patient thinking about the general look-and-feel later, I found that indeed it is that simple. I even spent a little additional time and added cute icons (from Glyphicons - included in Bootstrap) to the first navigation bar. Sweet!
In the process of working with the headers and footers, I realized I wanted to adjust the mechanism that included them into each page. I had already decided to create "thinner" controllers than most CodeIgniter tutorials show. In essence, my controllers are only the smallest of conduits between a model (when one is required) and views. Views, then, become a bit "heavier". They are entirely responsible for how the data is presented. For example, our views actually nest three "sub-views". The first level is the major content presentation. It then includes the header and footer sub-views. Because of the two navigation bars, the header sub-view includes them as sub-views. Once I got my head around where to put the actual HTML tags (in which files), this was really easy. And it afforded me the practical luxury of working on one thing at one place at one time. Sweet!
Here is where I get to talk about another high point of the week - Bootstrap customization. After a couple of false starts, I finally settled on including Bootstrap into my project as a git submodule. This will allow me to update Bootstrap without the messiness of re-applying my changes. Also, I was (after quite a bit of reading) able to use LESS (the "CSS language" Bootstrap is written in) to very simply apply the customizations our sites require. Essentially, I created a "less" file in a folder in my project. In that file, I used @import to bring in bootstrap.less (both the main file and its "responsive" counterpart). Then, I added the "overrides" I desired for our sites. To add further ease to the process, I am using the LESS.app on my Mac. This app "watches" a set of "less" files and, when they change, automatically invokes the "lessc" compiler to produce corresponding "css" files. Sweet!
As of this writing, the process of redeveloping pages continues. I have hampered my own efforts, somewhat, by working on the CSS (or more properly, LESS) for pages as I encounter them. While the result is highly satisfying - and generally helpful, since several pages "resemble each other", I am shifting over to the mode of "getting all the pages changed".
Distractions also "hamper" development efforts. Being a geek, one of the happy distractions I encountered this week was an attempt to update GIMP via MacPorts. The MacPorts team decided to update one of the components gimp is based on - webkit-gtk. Since I prefer to NOT use X11 as much as possible, I helped discover a couple of build anomalies in webkit-gtk. Aside from the process of waiting for HUGE builds to run, the experience of interacting with the MacPorts team was quite enjoyable. If you are a developer, on a Mac, and don't use MacPorts, why not? Highly recommended.
More development is on tap for the coming week:
Finish the rough conversion to Bootstrap
Setup a "test" subdomain so that the team can "oooh and aah" over my hard work :)
Write another of these updates! I forget how much fun it is to write.
On a personal note... As much fun as it is to write, it is a LOT more fun when you respond. Please consider retweeting, posting a comment, or linking back to this article. When you DON'T do that, it is like talking to someone who never responds - no change of expression, no head nods, no questions or comments. Actually, when I think about it, THAT'S terrifying! So... Please... SAY SOMETHING! Thanks.
