Airport Citizen - space for frequent flyers

URL: http://www.airportcitizen.net
I like to do my own stuff. Let that be research, or hobby projects, I can put tremendous effort in it if I find it interesting. In the past month the people of #drupal-support were witness of this, me having bombarding them with questions 0-24. For their patience I thank them.

How it happened

My present occupation was the creation of a flyer website, called the Airport Citizen. The idea first manifested itself as a blog in the hungarian blogosphere. After a sudden burst of visitors thanks to picking my first article introducing a hardly known airport in Hungary, and heavily criticising Ryanair (a cheap-flight company in Europe) I received many visitors, from among I gained several co-writers. The wave quickly worned off, as it can be expected, however I got an inspiration. What if there were a platform for those who travel often, by airplane could share their experiences. Due to long check-in time, and occasional flight cancellation one can spend from hours to half a day (or longer) at an airport, and it is often really useful to know some details about it.

I was just in my learning period in Drupal, I am to start my Summer of Code project soon, therefore I thought why not combine learning and developing, after all there is no better teacher than life itself, and I begun to explore the potential modules, site structure, underlying database structure.

I decided I will put a google map on the front page - easy navigation for those who just come to check out information about an airport.

Main page

On the main page you can see the airport nodes, gmap view filtered by views. The gmap module has been hacked a bit so it displays more than just the title. In the bubble you can see the top rated reviews from all the languages - it will have to be probably redesigned in order to handle larger amount of articles.

Obstacles

The first problem I faced was having multiple nodes for one location. Having locative information for each node would be a waste of resource because of the overlapping coordinates. Avoid redundancy, and fear the easy path. One location where all the nodes refer to, that sounded way better. To ensure that for new articles, new reviews such a location node (the airport node) will be automatically created I wrote the autonode module, that handles automatic node creation if the referred node does not yet exist, and reference if the node exists.

Other problem was the reference itself, I created a new CCK widget within autonode, that asks for the three letter IATA code to have an airport identified. I luckily stumbled upon a free airport database by Arash Partow, thanks to that it was possible to quickly assign
geographical coordinates to certain airports.

(node: the transformed mysql database of airports is available, just drop me an email until I find a place to upload it)

Multi language

Being European means the first thing I have to face in a project is using many languages, developing a solution that can be extended to any language without problems, while still having the flexibility to enhance content. The aim was to represent the best reviews from all languages when someone clicks on an airport icon on any of the localized websites. Unfortunately I found that Drupal is not up to the task on this point.

I18n module

While the i18n module is promising, the problems are more basic. These problems have been addressed by others, and come from the User Interface of Drupal. Imagine a website has two main menus (like mine). Now multiple that with the number of languages you want to handle with the menu translation function of i18n, and you'll quickly find yourself lost on a page with a huge list of menuitems.

Moreover i18n determines language based on a suffix (or prefix, depends from where we determine that) in the url, whereas I was planning to deploy the site on the native url (e.g. repterilakos.hu for hungarians, meaning airport citizen). Probably this could've been solvable by hacking the module, but hacking the module is generally a bad idea if someone is not doing it well, since custom changes will not be put into the module by the maintainers, hence I would've too update every time i upgrade. Not a good approach.

Other point of my plan was to give custom themeing, blocks for native sites - something that is also not possible with i18n (for handling blocks the same UI problem emerges than for menus. tried.).

I have read promising mails about this aspect of Drupal on the devel list, and also Gabor's work seems to improve it a great deal, but for now I had to chose a different path.

Shared database

Oh boy this was fun. Because of the custom url's I had to use distinct variable tables for the sites - gmap api code is assigned to url. I slowly experimented with different database setups, what to share, what not. The aim was to limit the shared areas to sharing review nodes to the localized versions, and all that comes with them. User table, location table, voting tables and all related tables became shared. Having distinct menu and block tables allowed me to translate content without overpopulating my menu and block administration interface.

Along the process I discovered the bug in cache module regarding shared modules, unfortunately my bugreport was a month late, as it turned out. And I did not even notice that there was a report on that previously. The bug was also apparent in VotingApi module, so at least there I could help out giving more information.

Install profiles

For the whole multisite population and initial installation I created an install profile that populates initial content, layout, variables.

Theme

The theme is a modified bluemarine theme, with some additional colouring and decoration. I found this theme a very nice, clean one, naturally the altered one is available. The artwork was created by xaralx, a wonderful free vectorgraphic program, and later reworked with gimp. They were inspired by my unnecessarily long stay of two days at Stansted airport.

Statistics

Until there is a decent tracking system within Drupal (until a certain someone provides users with a nice graphic API to do that) one has to use external tracking. So AirportCitizen uses the newly googlified FeedBurner, and the good old google analytics.

Kydos to the developers

Although I had to develop some minor modules for this website (autonode, compact login, a special module to handle the all lang. review listings) it could not have been done without the following contributed modules of developers:

• blogger
• buddylist
• cck
• copyright
• fckeditor
• feedburner
• fivestar
• gmap
• google_analytics
• i18n
• imce
• invite
• location
• privatemsg
• userpoints
• views
• vote_up_down
• voting_actions
• votingapi

Notes

My further plans - don't worry my dear mentors, only after the GSoC project ;) - are to somehow incorporate travel routes and to develop and integrate Facebook API to boost the social networking aspect of the site.

Surely the website is flawed. It is possible that you will experience slowdowns, since the hardware beneath is my own, a junk PC, with not much RAM onboard. I am sorry for these, hosting is expensive :(