A few months ago I started my first project with CasperJS and PhantomCSS, and what an interesting experience it has been working through that to now our second, larger, automated testing setup. Being young projects, there are some fun quirks and niggles in CasperJS and PhantomCSS that I wish the world could have warned me about.
When you are going to have multiple language set up on your Drupal site, it's important to set the default language appropriately before creating content. Once that is set, content will normally be set to be in that language, and any translations made on the site will be assumed to be from the default language as the source. So changing it is not a good idea, as there's no way to differentiate between translations made before and after the switch in Drupal 6 or 7! (This has been resolved in Drupal 8.)
So, once you've thought first about what is necessary for your multilingual site, the next step is to pick the right default language, ideally before setting up anything else, as everything is 'in' a language in some way. It's usually an obvious choice, but did you know that the Drupal software itself and associated modules (i.e. the codebase, referred to as the 'interface') is all written in U.S. English (as per the coding standards)?
Architecture has to be carefully thought through before implemented, or it could all come crashing down at an unexpected moment. You may not realise it, but language is a piece of architecture in all websites. Site builders will be used to thinking about how best to model content, usually in terms of content types, fields and vocabularies on Drupal sites. Every piece of text is modelled somehow - and every piece of text is written in some language. As soon as it matters which language that is - so that translations can be associated with each other and shown beside or instead of one another - that content model needs to incorporate language.
I recently got the chance to implement Drupal's multilingual capabilities on a major client site. Drupal has some of the best functionality around for localizing & translating a site, but it does take quite a lot to understand & configure. We will host a series of articles on this, entitled 'language lessons', starting on ... how to get started!
I was asked at Drupalcamp London how to identify where parts of a panel come from. Whether you need to change something on a site you inherited, are looking to trace your steps back on something you created long ago, or need to understand how to fix a colleague's mistake, it can be helpful to have a toolkit of methods to find out what produces all sorts of mystery content - not just for panels, but also views, blocks, fields, and the like.
Having written articles on how to create a Drupal 8 field type, field widget and field formatter I thought that now is the time to explain why you might want to create a custom field type. More specifically, why I have created a custom field.
Do you want to show a standard piece of content (we use the bean module for enhanced content in blocks) to be placed on all content of a certain type, perhaps explaining about products on a brochure site or how to use webforms?
Would you like to show lists of links (perhaps as menu blocks) on user profiles as helpful links to common destinations?