A while back I wrote the Part I of how we built the Estonian Government web platform. I had all the intentions to quickly follow that up with Part 2 and 3, but as always, things got busy. The good news is, however, that all the sites are now live for several months and I can use live examples to illustrate my text here.
Part II is about some of the functionality we built and the technical solutions used for it. The development phase lasted throughout the second half of 2013 and first months of 2014 – 7 months of development means a lot of different stuff was built. Instead of trying to cover it all, I will try to focus on the parts that I feel characterize this project the best.
In April 2013, Wunderkraut Estonia was tasked to build a website platform for the Government of Estonia. The platform would be used to run the Goverment Office website, all of the 11 main public sites for the Estonian Ministries, and the central “Government site” called valitsus.ee (government.ee in Estonian).
We took our weapon of choice, Drupal, and decided to develop the platform as a Drupal distribution. It did end up having most of the characteristics of a Drupal distribution – installation profile, theme, a bunch of modules; but it also has some differences – it’s not (yet) publicly available, and it ships as a ready-to-go website, with most of the settings already configured.
I’ve been leading Drupal web projects for some years now and yet have never heard a frontend developer say: “This design is meant for Drupal. It is so easy to implement it, the designer totally gets how Drupal works. I’m totally having coffee with this guy later today, we’re pals.” Instead, it’s often about how the designers only goal in life must be to think of ways how to drive the devs into insanity and ultimate extinction. What seems to be the problem?
This post explains which Drupal URL’s you would want to hide from visitors, what should not get indexed by search engines, and how to avoid duplicate paths and other URL confusion. The main tools used to accomplish this are the robots.txt file and the Global Redirect, Pathauto and Rabbit Hole modules.
By default, Drupal generates a lot of URL addresses. Taxonomy creates a page for each tag, each node usually gets at least 3 different ways to access it, not to mention all the custom and contrib stuff. All this can result in messy search results, confusion for the user, and unwanted pages being public. In one of Mekaia’s projects, our motivation to clean this mess up came from using the Google Site Search engine as the page search – this needed a very clean URL structure to make sure the user got exactly those results for his queries that we wanted to give him. The motivation to use the methods described here can come from a lot of different places – but this post is about the solutions, not the problems.
There is a small nagging issue with Drupal that we have to deal with in many Drupal projects. Well, had to.
By default, Drupal gives us a language switcher tool in the form of a Block. This block displays all the languages you use in your Drupal installation, and allows users to change between them at any given page. Or does it?
Some good articles about using the Google Search with your Drupal site have already been written, for example here. Most of the standard process involved is not that hard to figure out anyway. So this post tries to focus on a certain deeper, maybe a bit less discussed part of the topic, specifically on Google Site Search and how to turn that into filtered search for Drupal.
The background of this is that we had to build a complex in-site search functionality for a client, including such lovely stuff as cross-domain, predictions, lemmatizing (with support for Estonian language), indexing documents, and search filters. We chose to use Google Search, more specifically the paid Google Site Search (GSS). Its main advantages for us over the free Google Custom Search were search results in raw XML format and, therefore, custom interface for the results display. Trying to stay agile, we didn’t worry too much about analyzing how to implement all the needed functionality on GSS, but just counted on the raw XML data to provide us enough flexibility to implement pretty much anything.