Drupal Hospex Features

[[Wiki.trustroots.org]] is an independent wiki with information for people who are actively exchanging hospitality.
Jump to: navigation, search

Drupal is a versatile free software content management system. It has quite a bit of social network functionality in the form of modules.

On BeWelcome there have been some calls to explore the possibilities of Drupal as an alternative to the home-grown BW-Rox platform that the network currently runs on. More generally speaking, Drupal is a possible option for any initiative to set up a new social network.

This page is adapted from [1], but unlike the source page, this article should be less about BeWelcome and more about the general idea of using Drupal for hospex purposes.

While a lot can be done with existing modules, it will be interesting to see where it makes sense or is necessary to have dedicated new modules built for hospex purposes.

Some of this article will be puzzling for people who don't know Drupal lingo. If you (yes, you!) feel like it, you can add links and explanations where they make sense.


We'd like to have user profiles, (location-based) member search, messages between members, trust links between members (references, friend links etc), and general community features such as groups, events, wiki-like editing etc.

Nice to have would be decentralization features, where different sites can interact with each other. Or even P2P, but that would better be solved by something else (not Drupal).

Other nice-to-haves are couch/location objects that are independent from member profiles: One member can have more than one couch/location, and a group of members can share the responsibility for a couch/location (such as, in a shared flat. The pros and cons of that can be debated, but it's nice to have the technical possibility.

User profiles and couches/locations

Drupal has a built-in user and profile system that allows for arbitrary custom fields, user avatar images etc. If that is not enough, the Content Profile module allows to unleash the full powers of the famous Content Construction Kit ("CCK").

A separate node type "couch" or "location" or "shared place" could be created and connected to user profiles via node reference or user reference.

Location features

Drupal has a bunch of location modules working with CCK, Google Maps, etc.

See also http://www.openstreetmap.org (have not checked this link, it was in the wiki page on BW)

Searching members and couches

Drupal core has a built-in search that searches everything (users, nodes, etc). More powerful and customized things are possible with Views in combination with one of the location modules - but still needs to be explored.

It can make sense to write a custom search module, for a better performance and flexibility, and so that site owners don't have the trouble of customization. This custom module could even define a custom view (based on Views module)

Messages between Members

Need to check existing modules.

Menu / Navigation

Basically, I don't see any technical limitations for this. The Drupal menu system + Menu Blocks module are usually sufficient, and some custom functionality can be implemented where this is not enough.

Admin links: The nice thing with Drupal's menu system is that it filters out links to pages that you are not allowed to see. So, admin links can simply be added in the normal menu.

Multi-language features

Drupal has a lot of language features already built-in (core locale module). You can get more with the Internationalization ("i18n") module and a bunch of other extra modules.

Translated content (nodes)

If you want to translate a node, Drupal creates a new node for each language version.

Translated text

Drupal, similar to WordPress, has a translation function used inside core and module code, used this way:

 t('Please translate this piece of text');

Consequence: If you change one letter of this text, all the translations need to be re-done. And, if two texts are the same in the code, the translations will also be the same - even if the context is different.

The BW system works differently, because the translation function does not get the English string as an argument, but a keyword. In some way this is more flexible, because you can have different keywords for two texts that might be the same in English, but different in Russian. And, you can change the English translation without flushing all other translations, and without changing the code. On the other hand, if you implement a new page you always have to add some english translations, otherwise it will look horribly broken.

Interface for translators

The current platform running BeWelcome has some nice features for translators, where translation links are placed directly in the content. The BW system does work even if the text to translate is in a html tag attribute (such as, an image alt attribute, or a link title attribute - the link is placed somewhere where it doesn't break the layout.

Drupal has some similar features, but I have not checked out how they work exactly. Would be a good idea to do some research.

Trust links / Friend links / References

Modules to check for friend links:

References could be modeled as comments, but maybe it's better to have a dedicated custom module for that.

Other features


Check the "organic groups" module.


Ideally this should work together with "groups".. or for smaller sites it can make sense to have one big forum.

Check the "Advanced Forum" module.


Check http://drupal.org/project/wikitools and a bunch of other wiki-related modules.


Check out the different available modules

Blog (for users and groups)

Site-wide blogs are easily possible with Drupal. User blogs are possible with the blog module (shipped with core). I'm sure that group blogs are possible with some contrib module..


Usually you will make each picture node with filefield, and with any number of extra fields you want, plus comments. OR you can make each node have a collection of pictures, using flexifield or just multiple imagefields. Or make a custom data structure for that (but why?)

There is a bunch of modules to make this easier for you and that provide different ways to browse these pictures. Some of them based on Views. And if that is not enough, a custom module can make everything possible.

Customized pages and forms

Sometimes we want to have a page or a form (such as, user profiles, or a signup form, etc) almost exactly like it is delivered by Drupal + contributed modules, but we want to change some tiny bits: For instance, add an option to the signup form to sign up for specific groups, etc. Or disable some fields. Or, split the profile page up to several different pages.

Luckily, this is all possible by creating custom modules! You can grab the data for generating a form or a page, modify it, and let Drupal render the modified form. Or you can intercept the usual process of rendering a page, do your modifications, and give back to Drupal to do the rest. The nice thing is, you only implement what you want to change, and leave the rest to Drupal core + contrib.

And of course, you can theme every bit of a Drupal page. You can even do a lot of the above mentioned customizations with themes alone, but beware! This can bloat your theme and makes it hard to provide alternative themes.

Migration (Import / Export)

Drupal does have various import and export features to import data from other platforms.

Release Management

(written from a BW-Rox perspective - please adapt)

Right now release management in BW is based on SVN. Most changes live in the code, so it's easy to track things via SVN, and a release is mostly code.

DB changes are done via dbupdate.php - which is not the nicest way to do it, but it keeps things more or less transparent by only looking at SVN.

Problem: How to deploy configuration changes?

Drupal works quite differently, as a lot of things happen in the DB, and will thus not show up on SVN. Releasing a new version will mean both changes to the code (CSS files, theme templates, modules), and changes in the DB via the admin backend. This makes things a bit more difficult and less transparent for developers who want to keep track of things via SVN.

And quite often you get heavy dependencies of DB and code - for instance, if template files refer to content type names that only exist in the DB.

Solution: Custom modules instead of admin configuration

It is possible to define a lot of stuff in Drupal in the code, instead of the DB, via custom modules. I would very much vote for this option. It requires some Drupal expertise, though.