Drupal code: Drupal hints and tips

  • Language lessons: What are you translating?

    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.

  • A fully-automated testing rig #8

    Part 8: CasperJS debugging tips

    You're getting desperate. Your CoffeeScript / Javascript syntax looks OK, but CasperJS doesn't like what you're giving it.

    Try going through this checklist for a selection of sensible sanity checks and more:

  • A fully-automated testing rig #7

    Part 7: When this.mouse.click doesn't work

    mouse.click and mouse.move are a really helpfuls function in CasperJS, but we have at times found that they just don't work. Mostly, that's been because the element isn't there to click on. Do make sure that it's actually there! Make sure you're using the right selector, too. Try a casper.capture() to see whether it's there, but be wary of timings to ensure that you get a capture for the moment that you want to be performing the mouse action.

  • A fully-automated testing rig #6

    Part 6: Manually fail a test, but continue script execution

    We set up an event to take screenshots of failed test pages, by hooking into the onFail event. This made for a problem when we wanted to pass or fail a test based on whether there were entries in the Drupal Watchdog table. Failing a test also would normally stop script execution, but we explicitly need our post script to finish its work!

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

Pages

Subscribe to Drupal code: Drupal hints and tips