Drupal code

  • A fully-automated testing rig #5

    Part 5: Fun with viewports, and THEN some

    As I described previously, we nicely externalised our list of viewport sizes, making it really easy to set our viewports for mobile, tablet and desktop tests. Our content appearance tests put this to good use, taking screenshots of the content at mobile, tablet and desktop resolutions. The problem we very quickly ran into was that we frequently ended up with empty screenshots, or sometimes no screenshot at all. This is where the asynchronous fun began.

  • A fully-automated testing rig #4

    Part 4: When TrueType doesn't fix everything

    Two fonts walk into the bar, and the barman says, “Sorry lads, we don’t serve your type.”

    It was a good day. I'd finished writing up the basic appearance tests for the first batch of content types, I'd road-tested them on my machine, we'd set up Jenkins… all was ready to go for our first run on the server. When we ran it, however, all the tests failed against the baseline.

    Every single one.

  • A fully-automated testing rig #3

    Part 3: Using other scripts, datasources and directories

    Earlier I described a bit about the scope of the project and how careful planning would be needed to keep the project growing smoothly. One result of this is our test template - a basic test script outline which most scripts should stick to - which makes test scripts easier to update because they all follow the same structure (yay standardisation!).

  • A fully-automated testing rig #2

    Part 2: Setting up for a large project

    When you take on a project it's a good idea to make sure you plan ahead. Testing platforms only remain useful as long as they're considered dependable - if it becomes too difficult to write tests which don't reliably execute you might as well not bother.

    Here are a few key things I set up at the start to help the project along, which have all been hugely worthwhile investments:

  • A fully-automated testing rig #1

    A quick introduction

    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.

  • Language lessons: Default language

    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)?

  • Language lessons: Think first!

    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.

  • Language lessons: Getting started

    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!

  • Where is my content coming from?

    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.

  • Drupal 8: Creating a custom field - Part 3: Field formatter

    This is part 3 in my series of articles about creating a custom field. I recommend reading Part 1: Field type and Part 2: Field widget first, if you have not done so already.

    After creating the field type and field widget it is now time to complete the set by creating the field formatter.

Pages

Subscribe to Drupal code