A major upgrade to the Greaserag Website


I've been working on this site off and on for over a year now, and I think it's finally to a point that I can be proud of it and show it off a bit. It's now responsive and using a combination of ProEvents and Google Calendars integrated with the multiple user blog system.   The other huge thing was internal links - they didn't get mapped to pages on the actual site. 

It's taken a long time even from the first deplonment, but I think it's done. 

Upgrading The Calendar System

A few months ago, the people over at Greaserag said that they wanted to upgrade from Items Calendar to something different. There's not a whole lot out there for calendar systems in concrete5. There was a block in the marketplace for a bit that was using google calendars, but it was withdrawn when I went to look for it, never passing. We were already using Items Calendar, and really it was not user friendly at all. The core team's calendar system is more of a sketch saying 'this is how you might want to think about a calendar system' so I knew it wasn't something I wanted to work with.

I ended up trying to integrate ProEvents with the UserBlogs thing that I have going. The blog stuff is based off of ProBlog, so it's a similar architecture. But really, it was incredibly hard to integrate the two so that blog posts with events showed up on calendars. Also, I saw that it integrated with google calendars and they wanted to publish feeds from google calendars to the site, so that seemed like it would be good. In reality, it only let you show calendar feeds globally on all your calendars. They needed to show them on a per page basis. So I built that functionality in, too.  Now when you add an event list block, you can add different xml feeds and choose background and text color for each. 

If I had it to do over again, I would have simply written my own event system. I just did another google integration that was a lot smoother that didn't use any advanced system at all. Of course, I wrote that maybe 5 months after I started in on the project. It was still a few weeks to do, but I was able to integrate a lot of the stuff I've learned into it. What I did in 3 weeks on that project was simply beyond what I could do at all when I started on the Greaserag stuff.

Getting Dirty

One thing that I liked a lot when I did the patch for the event list block to allow multiple feeds was that I um, well, I ah...

I actually...

Took a shortcut.

I know, it's way out of character. Normally I'm really anal about what I write. Not every line of code, but if there's a 'right' and a 'wrong' way and I know the difference, I'll choose the right one. Even if it's more effort. Even if it takes more time. Usually it runs faster, and is easier to upgrade, and to re-use, but that isn't usually the goal of production code. 

But for this, I didn't want to have to refactor all the stuff in the block. I just added one large text field to the database table, and on save it serializes an array of google calendar feed objects. 

OK, that's a lie, too. They weren't objects. They were arrays. Just nothing more than arrays.

They should have been objects, right?  Each one of them with an "assign properties from array" method, and then getters and setters for the variables. But no, I just did arrays. 

It just felt so wrong.

Improving on the idea, doing it right

When I did the integration with google calendars for our new site, the feeds are actual objects. They're managed from the dashboard, so admins can add feeds. Then the blocks have a dropdown list where you can add a feed. When it's added, The feeds on the front end are managed by a list object, which allows pagination. Instead of a calendar view (which really only works well on desktop, and with small titles and no content) it shows in list view. Clicking on a title expands the event with the description.

I learned a fair amount about parsing an xml feed from it. And it kind of seems like the system could be modified to work quite easily to use any RSS feed.

Oh, and when it is displayed, it even goes to another layer of abstraction. When I loop over the list of objects from the item list, each one is passed in to a package element. The element handles the formatting. So when I want to change the view, it's not a big long view file that's hard to understand. It's a simple loop, and then the file included is also super simple and easy to understand, almost pure html.

I really like being able to work on code like that where each step is a further refinement, where the code gets simpler, more concise, more reusable at every turn. One site's code leading to the next, each one better than the last. 

Converting the Theme To Be Responsive

This had been an issue for awhile. When I first started in on the site, we didn't have a designer to work with. So I directed them to look at concrete5's marketplace or Theme Forest for templates that seemed like they would work. The Edge Magazine Theme that they decided on was actually designed for Wordpress to begin with, so it took quite a bit to convert it to concrete5. A lot of stuff for outputting categories, archives, etc is not really standardized into concrete5, so it had to be manually written. And it didn't really run well, or fast.

It was also kind of before the 'responsive revolution' hit. A few people asked about mobile, but it was a pretty low volume site and I was pretty busy so I didn't really put it as a priority. But over the course of trying to do the upgrade to the calendar on nights and weekends, I ended up learning a lot about responsive design. And also doing a lot of research into how different people do it. 

The framework that it's built on is the 960 Grid System which is not actually responsive.  As I looked into what others were doing, I thought a lot about grid systems. When I first started doing themes at Hutman, I really got into Blueprint. But really, most of the time now that I think about it, it was just the idea of columns and the reset that I was actually using. After a few themes that were responsive without a grid system and looking at how several others were set up using frameworks like skeleton, I thought that it should theoretically be possible to make the grid responsive. I kind of played with moving around the browser window a bit and adjusting row css and the overall blocking flowed pretty well.

I didn't really realize exactly how much extra work would be needed in order to do that, though.

Github To The Rescue

I did some googling and eventually found adapt.960.gs over on github. It wasn't exactly what I needed, but it was close. I really didn't want to have to rely on javascript in order to change the theme. I also don't like using exact pixel breakpoints, either. It doesn't flex as you zoom in when you do that.  Actually, there's a bit more that you have to do for it to work under chrome when you zoom:

// I use this to help target IE specific stylesheet adjustments
<!doctype html>
<!--[if lt IE 7 ]> <html lang="en" class="no-js ie6"> <![endif]-->
<!--[if IE 7 ]>    <html lang="en" class="no-js ie7"> <![endif]-->
<!--[if IE 8 ]>    <html lang="en" class="no-js ie8"> <![endif]-->
<!--[if IE 9 ]>    <html lang="en" class="no-js ie9"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html lang="en" class="not-ie no-js"> <!--<![endif]-->

// this needs to be in the head, but doesn't need any rules defined
<style type="text/css" id="stylesTest"></style>

// There might be a better way to specify that this only runs under chrome
<script type ="text/javascript">
    $(document).ready(function() {
         $(window).bind('resize', function() { 
              $('.not-ie #stylesTest').html('#noShow { width:' + $(window).width() + 'px }');

It also affects safari and I think all the webkit browsers. I learned about it a few sites ago at work when I first started doing em based breakpoints. I noticed it didn't work in chrome and spent a lot of time looking for an answer online. I finally found it here. I've put it into the sites that I've built from ground up for responsive. I think there has been one or two that we were supplied html/css for that I didn't do that, but it was mostly because there wasn't really budget or requirements to really move things around and 'fix' the supplied design. 

Honestly, most people wouldn't even consider it broken. You look at something like the Grey Goose Vodka site, and it's there. And that's a site that obviously cost at least 5 figures, if not 6. But it's really hard to test everything, and little things like this slip through the cracks. It's entirely possible that if I hadn't of been doing all the research and comparing different systems that I wouldn't have learned about it. 

Truly Being Device Agnostic

That's really where I started thinking about zooming, different browsers, etc. Also, the site that I first started with doing a responsive design from scratch didn't really fit with 'standard' breapoints for devices. The navigation needed to adjust at different points, some things like columns had to move around a lot. Really every time that I searched for what screen sizes you were supposed to target, I found myself more intrigued by articles like this one over on Codrops - the smart people are not designing things thinking about iphone, or a tablet, kindle, whatever. You need to set your design up to adjust where the design needs to adjust. You will almost NEVER really know how your code will be viewed. 

Another thing that is good about device agnostic code is that it's a lot more future proof. When I see someone bring in a static, desktop only design, I feel kind of bad for them. The end client is paying for a new site, but they're going to have to re-do it in a few years or be missing out on a lot of traffic in the future. The writing is on the wall, and desktop only won't cut it any more. If you are making websites and not trying to master responsive design, you are basically asking to become obsolete and lose business. It's as simple as that. It's pretty much the same as if you were in print shop 10-15 years ago saying 'oh yeah, we're just going to use film, digital doesn't offer enough benefits to spend the money to upgrade.'

You can't do that. You have to be able to display nicely on all devices. And learning to do it well as opposed to just saying "I'm going to do whatever the grid system does" will do a whole lot better for yu in the long run. Spending the time to learn about it now and get ahead of everyone else will put you in a really good place in the next couple years.

Personally, I like the idea behind responsive design a lot more than doing different versions for each device. In some ways, it makes sense to have mobile and tablet apps for your site. But you shouldn't count on that being the main way that you are accessed. Not everyone is going to want to install an app. You can also serve up a different site on a different domain, doing something like 'mobile.whatever.com' but that's also not an ideal way to go about it. What happens when someone shares that link from mobile to facebook or twitter? People clicking on it from full desktops end up with the mobile version of your site. Not really ideal either.

It may be a bit more markup to download, but if you're using modern code and making sure that you optimize stuff properly, you shouldn't have too many issues. I'm not entirely sure, but I think that if you have images only for certain media queries, then it won't be downloaded on the others. I'd have to check that for sure, I could be wrong. It does seem that a lot of the html5 markup really makes things simpler to write and requires a lot less code than a few years ago. A responsive design really gets back to the original idea of html. Describing the document, not forcing it to look a certain way.

And yeah, I guess that was kind of a tangent. Back to the matter at hand.

How Greaserag Was Modified

I wasn't able to 100% do that on greaserag.org. Since it was already set up for a grid system and that really influenced a whole lot of the code in both the css and the markup. What I did was to take the javascript grids and put them into different links in the header for each media query. When I was doing the final testing, I started seeing some things where there were weird things happening in chrome. It would zoom way, way in and it wouldn't go away until you not only closed the tab, but opened the site in a different window. Seriously wacked. This was with the cache disabled. 

At our last concrete5 user group meeting we talked a lot about how people were approaching responsive design. I had started on the last two sites keeping all of my adjustments in different files according to size. And then using @import to place them in the main.css file. One developer mentioned that he'd had a lot of trouble with using multiple files. I'd been meaning to research it, but hadn't ever seen an issue or had one reported by a client on the ones I'd done, so i didn't put a high priority on it.

When I saw the issue on greaserag, I just moved everything to @imports and since then I haven't seen the issues at all.   I think it also has the added bonus of less files to download from the server, but I'm not sure. I got a boost from PageSpeed tests, so I'm going with it. I'm pretty happy with a lot of the speed improvements over the last several months, actually. I think when I first started testing things, the score from pagespeed was below 30. Now on the individual post pages, it's 78. There are a few more things I can do, but it has gone from 8-10 seconds per load down to 2-4 for the home page and less for posts. That's pretty huge, especially when you are thinking about delivering to multiple devices with different bandwidth capabilities.

The nice thing about doing the design in different files for each breakpoint is honestly the ease of editing. When I've done other sites, everything was vertical in the same css file. That makes you scroll up and down a whole lot. It also makes for a lot more bloated code. You go to copy from one section of the document to the new breakpoint, and when you start to modify, you forget what things need to be overridden.

Doing it in different files, you can put them vertically next to each other in your IDE (I'm quite partial to Netbeans, if you ignore the files and .git directories it speeds up a lot for c5 php projects) and copy only what is needed. You don't use !important as much. I've also been using big headers that match up to the major sections of the DOM. So jumping back and forth is super easy.

There were a whole lot of adjustments to the theme. A few new icons were needed in the sprites. The header had to go from background replacement for the logo to using a real image, so that it could scale as the outer container's dimensions did. Even little things like the pagination had to be adjusted. The individual page buttons disappear so that it fits on a smaller screen. Though honestly, looking at SEO warnings, it seems like the 100+ links generated out by the pagination as the page is crawled are really bad for page ranking. So I might make a custom pagination helper and use that instead of the built in one so that there is only older and newer navigation.

The dates had to be modified. There are two areas with the sharethis icons, because you want the larger ones on desktop and smaller on mobile. The dates move around and change display. The sizing of the flickr images in the sidebar is different. 

I also upgraded several things. I fixed the archive navigation's javascript, then modified the location pages to work without blocks in the calendar area. I hadn't tried it without a block there since I put the tab code in the calendar itself. That was necessary in order to call the refresh method on the calendar when that tab was displayed. But if no block was there, no javascript, no showing that tab, so no adding another block, so no tab action. Yay! That page now displays the results from the directions search for the google calendar in the main content area instead of the sidebar, and hitting enter submits the form instead of just having to click on the button. 

The navigation is just a stock one from the marketplace called Autonav Pro. So that was fairly simple, but did take some adjustments to the css to get it working 100%. I think that was more removing greedy styles from that area that were already in the theme for the last nav. The slider at the top is also different. The original was caroufredsel, which is how I ended up deciding to make Attributes Slider. I've made a few thousand off that in the last year, but it's not responsive and sales have been dropping off quite a bit. I used a modified version of Elastislide that obeyed some media query rules to go down to 4 instead of 5 items. The markup had to stay the same, which took a bit of messing with, too. Elastislide doesn't display a set number of items, just a width, so it kind of had to be tricked into working right. I tried to get it to go down to just one at a time on the 'phone' views, with only title and description instead of all the fancy stuff. But that was pretty buggy and caused issues so I ditched and just hid it altogether at that size. I might come back to that later and update it.

Honestly, I can't really remember all the little things. But it seemed like every time I adjusted one thing, I found others that needed to be changed. It took a lot longer than I was initially expecting.

That's another thing that people should be thinking about with responsive, actually. Don't expect it to take the same amount of time to do it right and not have broken stuff on some devices. You should probably budget 2, maybe 3 times as many hours to it. I know that sounds crazy, but it's true. Not all of it is dev time, but as this market is pretty new a lot of bugs don't have well documented answers. It can take a lot of time just researching why certain things happen.

Also testing takes much, much longer. Even when you're not verifying on individual devices (you must do that - just because it looks right and works on desktop doesn't mean that links, css or javascript will be the same on mobile) you are checking multiple sizes at once. I use tools that show multiple sizes at once, so you can look and see where it breaks. It's a lot like the way I'm doing the css files now, actually. But when you load, you're loading up 6 or 7 versions of the page into iframes. That takes time, no matter how powerful your machine is. Even on my desktop accessing local sites only, it can take 15 seconds for all the iframes to fill in to the point that I can start scrolling through and verifying things. That's not a lot of time, but you do that 200 times in a day, and that's nearly an hour. You can save a bit of time by just right clicking and reloading each frame individually as you make small adjustments for just that breakpoint. I should probably just put in a refresh button for that. I tried doing just one frame with drag-n-drop resizing, but that didn't work too well, it was really clunky and hard to adjust and drag it smoothly because of the resize events firing on the actual site page.

But yeah, if you are hiring someone to do a quality responsive design and not a hack job, you should expect to pay a lot more. You could do it on a budget and / or do something really simple, but if you want it done right, it will take a lot longer.

Fixing the Wordpress Links

Yeah, this was the big thing. Way too big for a post already this long. 

Suffice it to say:




So, um, yeah, that.  A lot of regex and it will take quite a bit to make it fairly foolproof, but I'm pretty happy with it. The final thing that I need to do is to write out a file or just some text that can be used for an .htaccess redirect to the new URLs if you are doing something like moving from wordpress.com

But, I was able to run through and find every link that was relative or full for the old site and replace it with the correct page on the concrete5 site using {CCM_FID:5} or whatever the syntax was. The same with all the old images. I also fixed all broken links that didn't have http:// at the beginning of them.

So, yeah, I think that will be pretty huge. 

I ran the import and replacement of URLs today, and I think it went 100% fine. There were something like 120,000 links in all the different content blocks, or maybe it was just the way that it counted. But it output a whole lot of results to parse through. I know that a couple of image URLs did not transfer, but most of those were on pages that weren't part of the new site layout.

In conclusion

This was a pretty huge undertaking, but I'm really happy that it all worked. Being able to shut down the old site and redirect it properly will probably have a huge impact on SEO and should bring traffic up a lot. So will being able to display on a bunch of different devices. The calendar integration might help with that, too. I'm hopeful that it will help out their organization a lot.

I'm also hopeful that I can take a break from working on it for a bit ;)