Podcast No. 58: Drupal Console
Blog postThis week on the podcast, Amber Matz chatted with Jesus Manuel Olivas about the Drupal Console project. What is Drupal Console? The Drupal Console is, at this time, a suite of tools that you run on a command line interface (CLI) to generate boilerplate code and interact with a Drupal 8 installation.
Responding to Events in Drupal
Blog postEvents in Drupal allow various system components to interact and communicate with one another while remaining independent, or decoupled. The event system is built on the Symfony event dispatcher component, and is an implementation of the Mediator design pattern. This post takes an in-depth look at how module developers can subscribe to events in Drupal.
More Drupal 8 Insights
Blog postLast month, we posted a survey regarding your plans for learning Drupal 8. This was a follow-up to a similar survey we posted back in May, 2014. The responses we received in both instances were remarkably consistent, which is reassuring as we begin to publish our Drupal 8 tutorials. Here are a few big take-aways from our Drupal 8 surveys and some insight into our plans for Drupal 8 tutorials.
Last year was big for Drupalize.Me. We made a lot of changes to our website, and we increased the number of video tutorials we publish each week. In December 2014, our team met in Atlanta to celebrate these successes and outline a few high-level goals for 2015. The big goal to share is that we want to communicate with you more! We want to hear your suggestions for improvements, and we want to know you as individuals. We look forward to meeting and chatting with you at events like DrupalCon, but we also want to open new channels of communication. We have lots of ideas for this, and we're excited to get started.
This tutorial covers writing a "Hello World" test for Drupal 7 using the SimpleTest framework that comes with Drupal core, and is based on the free video Learning Test Case Basics by Writing A Hello World Test.
February Tech Update
Blog postIt's February, so it's time for another tech update. And it's a big one! Here's what we've been working on...
In this podcast Kyle Hofmeyer gets together with fellow Lullabots Joe Fender and Carwin Young to chat about their book, why they wrote it, and what it covers. From book writing, to favorite frameworks, take a listen to learn more about the book, Front-End Fundamentals.
Panels, Blocks, Layouts, and Drupal 8
Blog postOver the years of Drupal 8 development we've heard a lot of talk about "Panels in core" or "Blocks everywhere" or "Layout all the things!" and even SCOTCH(?). What does it all mean? Is Panels actually in core? Well, no, but there are some cool improvements in Drupal 8. I decided to follow the breadcrumb trail to figure out what this initiative was really about and how it ended up, now that Drupal 8 is in beta. Join me for a little bit of a trip back through the life of the Blocks and Layouts Everywhere (SCOTCH) Initiative.
Guide to Drupal 8 at DrupalCon Bogotá
Blog postAre you lucky enough to attend DrupalCon Latin America in Bogotá, Colombia? Excited to learn more about Drupal 8 in particular? If so, put these Drupal 8-related sessions on your radar. If you'll be watching from home, keep an eye on the Drupal Association's YouTube channel for session recordings. Here's the Drupalize.Me guide to Drupal 8 at DrupalCon Latin America 2015.
This week we have a veritable cornucopia of video demonstrations and tutorials for your learning pleasure. In this week's release, Joe Shindelar takes you through Drupal's PHP coding standards as well as covering essential tools to help you adhere to these standards. Also this week, we have for you several videos to complement Lullabot's Module Monday coverage of Honeypot, Node Revision Delete, and TableField modules, presented by Addison Berry.
Drupal's custom fields allow site builders to tweak out their content types with all kinds of data: phone numbers, file uploads, maps, and more. When it comes to tabular information, though, most of us fall back on simple HTML tables in the body field. The TableField module aims to fix that by storing and editing data tables with a single consolidated Drupal field type. In this tutorial we'll give you an overview of how to use the TableField module. This tutorial is based on a Lullabot Module Monday article.
Additional resources
Drupal's revisioning system is really powerful. Out of the box we can keep track of changes in our content and restore to a previous version with just a couple clicks. However, on large sites with a lot of activity in their content, revisions can grow exponentially up to a size that it can compromise performance and disk storage. The Node Revision Delete module can help us to keep this under control. In this tutorial we'll walk through an overview of this helpful module. This tutorial is based on a Lullabot Module Monday article.
Additional resources
Lullabot.com Node Revision Delete article
Node Revision Delete module
Honeypot module helps you stop spammers in a different way than the typical spam modules that put up barriers, like captchas. Spambots will typically hit a form like the user registration page, fill in all the fields, and submit the form. Honeypot adds a hidden field to the form that users won't see, but spambots will. If that form is filled in, you know you've found a bot and the submission is discarded. This tutorial will give you an overview of the Honeypot module, including the configuration and seeing how it works. This tutorial is based on a Lullabot.com Module Monday post.
Additional resources
Podcast Episode 56: Drush and Composer
Blog postThis week's podcast, episode 56, has Greg Anderson and Juampy Novillo Requena join Addison Berry to discuss Drush and the PHP dependency manager, Composer. We talk about what Drush and Composer are, why and how Drush is using Composer now, as well as a look down the road at further integration.
This week we're going to wrap things up in our testing Drupal 7 with SimpleTest series. And it's a doozy. We'll cover, submitting AJAX forms, uploading files, writing unit tests, and the SimpleTest 7.x-2.x contributed module.
So far all the tests that we've written are testing the functionality of our module in the context of a fresh Drupal install. However, in the real world we're also going to want to have tests that test the content of our application. As well as other things that it's unrealistic to assume we'll also have the time and resources to write a complete installation routine to replicate. Instead, it would be nice if we could test against a clone of our site rather than a from scratch installation of Drupal.
The SimpleTest module included with Drupal 7 core doesn't support this feature. However, the 7.x-2.x version of the module in contrib has a DrupalCloneTestCase
class that we can extend instead of the usual DrupalWebTestCase that operates on a clone of the database from our existing site. Allowing us to test things like, "Does the about page exist.", and other mission critical features of our site. In this lesson we'll take a look at installing the SimpleTest module from contrib, and writing some new tests using the 2.x version of the API in order to test an existing website.
Note that after you install the 2.x version of the SimpleTest module none of the tests we've written so far, or any of the tests from core will be in the list of available tests to run. This is because each tests needs to explicitly declare that it is compatible with the 2.x version of the test suite. This is done in the .info file of the module that provides the tests.
Add this to your .info file:
testing_api = 2.x
As of the time that this video was recorded you also need to apply the patch in this SimpleTest issue. The current version of the patch to use is https://www.drupal.org/files/issues/983266-10-simletest-clone.patch. Without it the DrupalCloneTestCase setup method won't properly clone the tables from your existing site. You should always use whatever the latest working patch is from that issue.
Here's how I patched it:
curl -O https://www.drupal.org/files/issues/983266-10-simletest-clone.patch
patch -p1 < 983266-10-simletest-clone.patch
Additional resources
Patched with patch from issue #983266
There's another set of really useful helper methods that we haven't looked at yet which are geared towards creating dummy content for testing. Including simple tasks like generating random strings, or random names of a specified length, and more complex things like creating nodes, or even new content types. In this lesson we'll take a lot at the various helper methods in DrupalWebTestCase that assist in the creation of dummy content by creating various pieces of random content and then testing functionality based on that content.
In order to demonstrate these tools lets look at writing some tests for the core statistics module which amongst other things tracks page views for content. In order to perform these tests we're going to need a piece of content that we can view, and then view again to ensure that the statistics are properly updating.
Creating random strings can be done with DrupalWebTestCase::randomName()
and DrupalWebTestCase::randomString()
. Both methods take an argument that allows you to set the number of characters that should be returned, or you can just leave out to get the default. The difference between the two is that DrupalWebTestCase::randomName()
will only use alphanumeric characters and the returned string will always start with a letter. This is useful for things like generating random usernames or email addresses, or other things that don't allow for special characters.
The DrupalWebTestCase::drupalCreateNode()
helper can be used to create nodes. While you could navigate to and fill out the form using SimpleTest this is much quicker and requires far less code. Here's an example of creating a node:
$title = $this->randomName();
$settings = array(
'type' => 'page',
'promote' => 1,
'title' => $title,
'body' => array(LANGUAGE_NONE => array(
array(
'value' => 'Copy goes here',
'format' => filter_default_format(),
),
)),
);
$node = $this->drupalCreateNode($settings);
This will create a new page node with a random title and the string "Copy goes here" in the body field. The array of values passed to DrupalWebTestCase::drupalCreateNode()
should mirror the structure of a node object. If you're unsure what that structure is one easy way to figure it out is to use node_load() to retrieve an existing node and inspect the returned object.
Additional resources
One element of interacting with a web application that we haven't looked at yet is uploading files. How does the DrupalWebTestCase browser attach a file to the the image field when filling out an article form? In this lesson we'll look at the helpers that DrupalWebTestCase has for handling file interactions including how to use the sample files provided in core, attaching files to a file upload input element, and submitting a form with files attached. In order to demonstrate this we'll be writing a test that creates a new article node with an image attached by filling out the article node creation form and submitting it.
You can get a list of the dummy/test files that come with SimpleTest using the DrupalWebTestCase::drupalGetTestFiles()
method. Whenever possible I recommend making use of the provided files.
$files = $this->drupalGetTestFiles('image');
$this->verbose(print_r($files, TRUE));
You'll need to tell SimpleTest what type of files you're interested in, and it'll then return an array of the available files of that type. Valid types are: 'binary', 'html', 'image', 'javascript', 'php', 'sql', 'text'. Check out the DrupalWebTestCase::drupalGetTestFiles documentation for more information.
Once you've got the list of files you can attach files to a form element using DrupalWebTestCase::drupalPost()
by specifying the full path to the file as the value for the file or image field in the $data array.
$images = $this->drupalGetTestFiles('image');
$image_realpath = drupal_realpath($images[0]->uri);
$edit = array(
'title' => 'Test Article With Image',
'files[field_image_und_0]' => $image_realpath,
);
If SimpleTest doesn't contain a suitable file you can use your own by including the file with your module, and then using the full path to that file in your tests.
$custom_file = drupal_get_path('module', 'helloworld') . '/tests/test.csv';
$realpath = drupal_realpath($custom_file);
This lesson also covers the use of DrupalWebTestCase::drupalPostAJAX()
, which allows for the simulation of an AJAX request using the SimpleTest browser. The primary difference between it and the drupalPost method is you need to specify the name of the element that triggers the AJAX request.
$this->drupalPostAJAX('node/add/article', $edit, 'field_image_und_0_upload_button');
Additional resources
Due to the tightly coupled nature of much of Drupal 7's code most of the test suite is based around functional tests and not unit tests. However, there are a handful of unit tests in core as well as the DrupalUnitTestCase
class that we can extend to write our own unit tests. Since unit tests are an important part of a complete test suite lets take a look at how we can extend the DrupalUnitTestCase
class and add some unit tests to our module. While functional tests do a good job of telling us that something is broken and we should fix it they often are not very helpful for locating the exact problem. Unit tests on the other hand are much more specific and can generally tell us both that something is wrong, and what is wrong.
Unit tests don't have access to the database or the file system since they are not run in the context of a fully bootstrapped Drupal environment. Note that calling any Drupal functions which attempt to access the database will result in an exception being thrown and cause your tests to fail. This includes functions like watchdog()
, and module_implements()
. However, because Drupal doesn't have to be bootstrapped, and we don't have to create an entirely new environment, unit tests are a whole lot faster to execute than functional tests.
In this lesson we're going to take a look at writing a unit test for a function in our module that is used to convert a length of time in seconds to a string like 1 hour 6 minutes. We'll start by looking at the code that does the conversion, and then come up with a list of known inputs and their expected outputs. Finally, we'll write a unit test by adding a new .test file that contains our unit tests and bombarding our conversion function to make sure it's working properly.
Additional resources
It might come as a shock to some of our members that we not only create the curriculum for our tutorials, but we also record, edit, and publish our own video. Besides training, my responsibilities include editing video and managing the production of our head-shots and screencasts. I also supervise the publication process from start to finish. I thought I'd share what that means, and give an overview of our video editing and publication process.