Back in 2007 we were fed up with looking for client work through conventional job boards and bloated employment platforms like monster.com and, in thinking that a lot of people working with Drupal would feel the same, created a site called the Drupal Developers Network.
The site was running just as we built it back in 2007 up until today - we've just flipped the switch on an entirely new version of the site (http://www.drupaldevelopers.net) running up-to-date code that will let us roll out some cool community features over the coming weeks.
Microsoft recently launched a new cloud hosting platform called Azure and have been pretty active in promoting its inter-operability, reaching out to Open Source software projects to explore its suitability for hosting all sorts of software. We got in touch with them and the founders of a Canadian event called GovCamp to build the event a website using Drupal 7 on Azure and see what we could learn along the way. This post will introduce the project and relate our methods - for any of you reading this who may want to try your hand at deploying Drupal on Azure.
Founded in 2010, GovCamp takes a page from the 'unconference' movement in bringing together various groups of people to promote non-partisan dialog - specifically relating to the changing role of Government. For its second-ever event this summer, organizers were aiming to bring 100s of people together in Toronto representing the grassroots, Government and Industry to spark dialog which could be communicated outside the physical event using the Internet and then into the future - with at at least annual sessions of GovCamp being held in Toronto.
In its first year, the event had used a simple Wordpress website (hosted on a standard Linux-based virtual hosting environment) and hadn't gone through any identity-defining exercise - its site didn't necessarily relate what the event was about but primarily allowed organizers to easily publish blog posts.
For 2011, the organizers were certain that they would welcome more attendees than the previous year and anticipated hundreds of people around the country (and internationally) wanting to clue into the day's happenings, despite physical separation. They needed a website that featured a blog of event-related news, could be used to relate scheduling information as well as detail on who was presenting sessions in the schedule, and stream live video from the event. After assessing the needs and wants of the project it was clear that Drupal would be an excellent platform for it - which we could use to build a robust dynamic website that would be easy to use whilst scalable and thus relevant after the event and again when next sessions of the event were held.
So, we decided to build a website using the latest available version of Drupal 7.x, with the newest versions of contributed modules that would offer the feature-set we needed. Alone this would be an arduous task as this meant dealing with not-yet-stable code, but we further stressed the case by attempting (for the first time ever) to get it all working on Windows Azure.
* The site's design was bespoke and kept simple - developed in 1 week from a visual identity for the event which we created.
About Windows Azure
Already used by Volvo, General Mills, 3M, Bing, The Associated Press and hundreds of other world-class brands, Azure is a cloud platform for building web applications using Microsoft's international network of data-centers which leverages that network to ideally remove the concerns of hosting infrastructure from app developers' responsibilities.
Because Azure is essentially a distributed hosting platform for Windows software, we needed to setup a virtual host using Windows IIS Server that would then have PHP and MySQL installed, with a small suite of tools to let us work with the Drupal file system and database we finally had to install. So, though working in the cloud is supposed to remove headaches of working with hosting infrastructure, we were faced with essentially kitting out a new server.
After some poking around through discussion forms and Microsoft's own helpful blog posts discussing PHP on Azure it became apparent that there was a pretty straight-forward method to setting up all of this software with just a few clicks > we used a package installer called Azure Companion, which we loaded into our hosting instance with instructions on what software we wanted installed. The instructions were sourced online via a handy XML script and once the hosting instance was configured with our software set, we could focus on building the site!
Here are the steps we followed to get Azure up and running with the Azure Companion:
Login to Azure's Management Portal (with a Windows Live account)
Create a new Storage Account
Create a new Hosted Service
Choosing a URL to access the host via the Web,
Choosing to deploy the Hosted Service to a 'Production Environment' (and ticking to start the deployment after setup),
Selecting the installation package file we found online,
Editing the configuration file for that installation package to reflect the Storage Account information we just setup and then choosing it for the new Hosted Service
After waiting for a little while the Hosted Service was up and running and we popped over to the URL we had chosen (at port :8080 in our browser) to take a peek at the Azure Companion.
Basically, there are three things we wanted the Azure Companion to install for us (+ anything it needed in order for them to run):
Drupal (We chose to install it in the '/drupal' sub-directory)
PHPmyAdmin (We chose to install it in the '/phpmyadmin' sub-directory)
Extplorer (We chose to install it in the '/explorer' sub-directory)
After selecting the Applications to install and clicking Next, Azure Companion set about installing the software +MySQL etc... and our fresh Drupal 7 install was available at the URL/drupal we set the Hosted Service up at.
Here are some resources came accross in our prelimenary research:
Now, along the way we made a couple of errors because we hadn't learned the following - but bearing these things in mind, it should be somewhat straight-forward to get a Drupal install up and running on Windows Azure:
This whole processes uses a Windows IIS server - so apache .htaccess (and age-old Drupal-standard URL re-write rules don't work on Azure), and instead - such rules are written into web.config files which work in a similar way to .htaccess - Drupal 7 now comes with a Windows-friendly web.config file in root but it needs to be edited in order for direct-access to subdirectories off-root.
The main way to access the site's file system (and that of PHPmyAdmin and extplorer) was using the 'extplorer' tool we installed via the Azure Companion - there is no SSH or FTP when using Azure (as your files are literally spread out between all sorts of machines and geographic regions). This is important to remember because if you mess up the URL rewrite rules in the root web.config file it can be difficult to fix the problem!
Through the Azure Companion you can edit files one at a time - so even if you mess up your web.config in the root and can't access 'extplorer,' you can still go to the Companion at xxx.cloudapp.net:8080, look to the 'edit file' field and type in '../web.config' (or whatever file you know you need to fix which you can't otherwise access) and the Companion will load up an editing screen where you can make changes and save the new file with edits.
You can edit the php.ini file for your Hosting Service through the Azure Companion - click Admin and then Configure Runtime
The database server location is simply 'localhost.'
Through these steps we had setup our Drupal install and could continue onto actually building our website.
* Of course, if you're reading this and have already built a Drupal website and just want to move it onto Azure, you don't need to install Drupal through the Companion - just extplorer and phpmyadmin;
Create a new database via PHPmyAdmin and upload/import the database for your already-developed Drupal site/application,
Then use extplorer to upload and unpack your site's file system tarball - editing the web.config (and sites/default/settings.php file) as needed to reflect the rewrite rules and database location.
Drupal as Application Toolkit - Building govcamp.ca
Many of you reading this will be well familiar with Drupal, and likely have already explored what makes Drupal 7 tick. To give you a sense of how the actual event website came together, here's some information on the 3rd party/contrib modules we used to build the site; asides from Azure, this is a great model for any event website. Also - for any of you attempting to use Azure, you can be sure the modules we used work using the methods using Azure described in this post.
As CCK is in core for Drupal 7, we just needed to install a couple of field modules, a wysiwyg editor, Panels and Views plus some tools for improving overall user interface. Our site theme was a derivative of Zen which we installed as normal; placing it into the sites/all/themes/ sub-directory.
Here is a list of all the modules we used on the site:
User Interface Tools:
Admin_menu - We used this classic tool to replace the new-in-d7 Overlay and Shortcut modules, saving wait time during development.
IMCE - With its CKEditor file-browser integration, this makes for a good solution to allow users to upload and embed media in their posts (until d7's media module becomes more usable.)
Menu_position - This lets us define what content types are automatically child to specific menu items in the main menu - so that when someone clicks into a session detail post, for example, it will show within the highlighted 'schedule' page linked to in the menu, though the schedule is actually of 'Page' type.
Flag - Admins can flag session details and speaker bios for instant archival; archives are displayed listed in a View accessible from the main menu. This allows for data to be temporal but still saved for future reference, with non-changing URLs (re: SEO)
References - Used to provide an auto-populating pull-down to admins when editing Session Leader posts - allowing them to dynamically relate the bios to Session detail posts (which we then created a themed embedded-in-content View for, to cross-reference both content types where defined).
Views - For dynamic lists (such as the schedule-per-room on the Video Stream Panel).
Opengraph_meta - Extending Drupal's native meta tagging to be Facebook-friendly and auto-generate per-post.
Pathauto - To write automatic semantic URL rules (so that all schedules are at '/sessions/sesstiontitle' for example)
Tweetmeme - To automatically include a widget on posts allowing site visitors to share a link to that post on Twitter.
Search404 - To automatically trigger a search for whatever term a site visitor attempted to use as a URL on the site. This helps to direct visitors to content they are interested in, if its location has changed... (especially useful since we moved from last year's basic Wordpress install)
Backup_migrate (In addition to Azure Companion's ability to backup the whole server snapshot, this can automatically backup the site database)
As anyone familiar with Drupal will know, out-of-the-box, it affords very simple functionality for publishing just two kinds of content setup by-default for more static kinds of posts - we had to install the above modules in order to acquire the functionality needed for this specific project. As well, we replaced the default theme with a derivative of the Zen theme framework which we created specifically for GovCamp. (Using Zen significantly speeds-up development time and ensures some base x-browser operability.)
We chose to create a site whereby organizers can create bio posts per-speaker and then link them to session-detail posts they also submitted to the site. Initially this meant defining custom content types (a native feature to Drupal 7), then creating the dynamic Views and Panels to display content and overall site config + user role/permission definition.
Through themeing, we made the site print references (using a View-block leveraging the Reference module) between speakers and their sessions onto each post so visitors can click through content and be lead through the schedule of events - which was entered into the site as a 'page' with a hand-coded HTML table representing what was happening when. (Originally we created a View for the schedule but it couldn't be displayed in a way that Event Organizers expected so we opted to just code the table.)
During the day of the event, a Panel was published which had some plain-page content describing each Auditorium's topical theme with links to pop-up a video-stream player for that Auditorium. The panel used three columns in each there was a View-block per-Auditorium to display the sessions upcoming through the day (they were linked node titles with the date-field from each node, displaying just the time and not date using Custom Date Display). This was the main launch-area for live-video stream content, which was served from the Streaming Network, a sponsor handling the video feeds directly.
Final Notes & Source Downloads
Using the Azure Companion, getting Drupal up and running on Windows Azure is pretty straight-forward. Its not the quickest environment (due to lack of SSH/FTP) to develop a site in - so we recommend porting a pre-developed Drupal website to Azure if you need to use it for hosting.
As Windows Azure will let you setup your site at a sub-domain (something like http://xyz.cloudapp.net) you'll probably want to mask it with your own domain name. Unfortunately their hosting setup doesn't do custom DNS - so edit your existing domain and add a CNAME entry for the cloudapp subdomain > once thats working, you'll be able to access the site at your domain as well as the Microsoft-given one.
Attached to this post are some files we thought you might find useful - the root web.config file we created to get Drupal's URL re-writing working whilst enabling access to sub-directories (e.g. '/phpmyadmin') and a compressed archive of the site's database and file-structure.
If you use the attached, remember:
You'll want to edit the web.config file to change the drive letter from 'f:/' to whatever is displayed in the path to your php.ini file via the Azure Companion's default phpinfo.php file, which gets installed into the root when Companion installs
Edit the sites/default/settings.php file to include the password to the database once its setup in your (Azure) Hosting System.
(Written by Qasim - Principal/Founder @ Design Guru)
I had to do some digging to get a solution for this today and thought to clue you all in; for a while now we've been writing custom time-stamps on nodes yet always kind of left comments alone - so I didn't have a PHP snippet handy to bung into a project I was just working on... the trick was in replacing '$node->posted' with '$comment->timestamp' ... example below:
Drupal by nature doesn't allow for markup to be included in node titles - which had me scratching my head when a large multi-national client of ours requested the ability to use superscripted characters in page titles on some of their content.
After much research, it seemed to me that there were a couple of sketchy approaches people use with 3rd party modules such as Page Title and Automatic Node Title; the idea being that those modules might let markup be entered in alternative fields to the standard Drupal title field, and then display that markup whilst hiding the title field. Well, I tried these methods and they just seemed too convoluted - plus I don't think they really get by the display of HTML issue.
In the end, it turns out that some simple CCK'n'theming goodness can make a powerful solution very very easily. All you have to do is:
Create a cck field for an alternative title,
Hide the display of that field from nodes of the type(s) which feature it,
Version a page.tpl.php for the node type you are replacing the titles on and include some custom php statements to optionally display the alternative title when one has been filled in for that node being displayed.
A great thing about using CCK of course is that you can display the HTML title in Views and Panels and so on as needed.
I called my new field 'alttitle' - here's the code I used. Note: you can get creative with the php such that you have a conditional statement in just the main page.tpl.php of your theme which only uses the alternative title per node type using it and so on...
(Written by Qasim - Principal/Founder @ Design Guru)