Openlayers has a Drupal module which enables you to add maps to your site. We added locations and categories to the events on CoventryMotoFest.com, and wanted to be able to show maps of certain event categories - or just all of them.
We've done a fair bit of reading around lately, thinking through different ideals on content construction. There's a fine balance to be struck between atomic units of content, vs. an enormous amorphous blob of formatted HTML, and articles like this by Wim Leers and sessions like this provide great food for thought.
In recent months there has been much hype over the newest addition to Apple’s product portfolio: the Apple Watch. It’s undoubtedly an impressive looking piece of kit and Apple have been quick to show off its many features in an attempt to get developers thinking up weird and wonderful applications to make the most out of this whole new approach to how users both consume and interact with their content. But what does the Apple Watch mean to us as web developers? How do we leverage Content Management Systems like Drupal to make use of this recent trend towards wearable tech?
On April 21st, Google updated their mobile search algorithms to boost the rankings of mobile-friendly web pages, whilst conversely decreasing rankings for pages that have been designed only for large screens. This change is likely to have a big impact on many Drupal sites, and ComputerMinds have seen a surge in requests for retrofitting responsive themes onto existing Drupal sites.
Queues are a wonderful way of separating different parts of a system. Once you have separated those parts you can do lots of interesting things, like be more fault tolerant or have a more responsive front end for your users.
For example, lets suppose that we have a website on which we can book a holiday. We can choose lots of different options and at the end of the process when we've booked the holiday we'd like to send the customer a nice PDF detailing all the options they've chosen.
To complete my series on multilingual Drupal, here are some mini-lessons I've learnt. Some of them are are to improve the experience for administrators & translators, others cover obscure corners of code. The first few don't require any knowledge of code, but the later ones will be much more technical.
Content (node-level) translation or entity (field-level) translation?
It seems an obvious question to ask, but what are you translating?
The tools exist to translate just about anything in Drupal 7*, but in many different ways, so you need to know exactly what you're translating. Language is 'a first-class citizen', in the sense that any piece of text is inherently written by someone on some language, which Drupal 7 is built to recognise. Sometimes you want to translate each & every individual piece of text (e.g. at the sentence or paragraph level). Other times you want to translate a whole page or section that is made up of multiple pieces of text.