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?
Sometimes as a module developer you need to have some code execute periodically, like maybe every day or even once a week. This might be to optimise an external system, or pull in some external data or to compute some statistics every day etc. Drupal provides a very simple way of doing this: hook_cron but if you want your code to only execute say once a day or after 6pm only, then you have to add extra logic to your implementation. However, the Job Scheduler module provides a nice framework for setting up and running these periodic functions.