A few years ago, I built a website for Medicus Insurance, which was bought out by Norcal Mutual. Since I had created the site for Medicus, they wanted me to create the site for Norcal. Though I work full time at Jackson River, I do some freelance work in the evenings and on weekends. This project was done over the course of about 4 months, with the goal to launch at the end of the year. The design team at Norcal created the mockups (which I implemented), and did help with some of the CSS and form creation. The site turned out well, and has some really great features.
One of the first challenges I hit was dealing with source code control and the server workflow. Due to company policies, the internal staging and dev sites had to be hosted inside the company firewall, while the production site was located on an external hosted account. I had hoped to use Aegir to manage the sites, but problems with the firewall and network domain settings made that impossible. In the end, I opted for just creating a standard vhost for the dev and staging servers.
I also set up GitLab, which is a Ruby-based, open source git repository manger and interface. It is very similar in many ways to Beanstalk. In addition to being lovely to look at, its quite powerful. I was also wanted to use this because it allows you to manage/edit files in the UI and have those changed reflected in the repository. This made it easier for the designers to potentially make minor modifications without having to learn Git. Finally, I created a script to deploy the code to dev and staging based on webhooks and the branch. Very slick.
Panels vs. context… the perennial question! While I have seen some great Panels-based sites, I am usually pretty reluctant to use it myself because while it gives you alot of power and flexibility, it also adds alot of complexity and can be troublesome. So, I opted for Context. This combined with some nice regions in the Adaptive Themes base theme gave us most of what we needed. It also helped that the site is organized into sections, and each section has the same sidebar of blocks. In order to keep things clean, I “disabled” the default block control form to force using context.
One little problem was that some of the pages had some specific blocks that ONLY show on those pages. While we could create a context for each page, thats messy and not really easy for content managers. Luckily, I found the awesome Node-Level Blocks module. This allows you to an optional block form to any content type, specify which regions you can place blocks into, AND which types of blocks to allow – very flexible. In this case, I was able to allow content managers to add blocks to the sub-content and sidebar regions on any page they create. This gave them the flexibility they needed without allowing them access to Context (which is more complex).
Based on the design and the future roadmap, I knew that they would need quite a few custom blocks of content that could be reused. In order to keep the workflow as simple as possible, I used the NodeBlock module. This allows users to create and manage blocks AS nodes. This meant that adding blocks was no different than adding events, pages, states, etc. For the content managers, the experience was the same. The difference was that each of these node blocks were then available to be used in the site. This was especially helpful when combined with the Node-Level Blocks module above – they could simply create the blocks they needed and assign them per page.
We also needed a way to organize complex state-specific information, and allows the content managers an easy way to create and update it. For this, I simply created a content type with lots of fields for all of the info. This is one time that Panels would have come in handy, as it will automatically “chop up” the content and let you quickly pull it into different regions. In this case though, it was a relatively simple matter to just create a View that displayed a single field (or section) as a block, with variations for each field that needed to be displayed. Then, I simply hid those fields on the node display. Finally, I created a context for the state pages that used the views blocks to display those items as needed in different regions. Pretty easy, and very lightweight.
We still had the issue of navigation, and we handled this quite cleanly in two different ways:
1) State map – they were tired of a static image for the state maps, so we found and used a jQuery State Map that has some nice features and a smooth interface. It is easy to use, and easy to extend. I was also able to tie the generation of the code into the status of the state content types, so that as the states are made active, the color changes automatically.
2) State Jump menu – one very nice feature is the state jump menu. This was created as a basic jump menu in Views, and then modified in the theme layer to replace the state title. So, when you go to a state page, the title of the page is *actually* the select for the jump menu. Changing this will send you to another state quickly. This was a very clever and simple technique that I will surely use again!
Talk to Us – popout
On of the features that was decided early on was the “Talk to Us” popout feature on the front page. This isn’t too complex on its own, but they did need to be able to manage it in a fairly easy way. To accomplish this, I created a custom module that actually adds a region for the popup, and allows blocks to be placed within. The style and theming are fairly locked down, but the contents can be any blocks that are necessary. I also created an admin UI to allow setting the height, width, position, status, and which pages to show the region on. It was a bit tricky to figure out exactly how to get it to work properly, but the results are solid and I’m quite pleased with it.
While there are several other nifty features and modules used, this pretty much counts for the most interesting. I really liked the combination of Context + Node-Level Blocks + NodeBlock for managing the blocks and content. The Talk to Us feature was fun to work on, and the States section had some very nice advanced implementations that didn’t require too much custom code. I still remain convinced that going with a lighter-weight solution like Context is going to be better than Panels most of the time, but then again, there is a right use for most every tool.