Planet Drupal

Subscribe to flux Planet Drupal - aggregated feeds in category Planet Drupal
Mis à jour : il y a 50 min 12 sec

Acquia: Build Your Drupal 8 Team - Skills for Tech, Non-Tech, and "Bridge" Members

lun, 04/05/2015 - 19:12

Getting your hands on new technology is the best part of being a developer -- playing around with it, and trying out cutting-edge concepts is challenging.

But trying to meet deadlines with new tech, especially if you don't understand it fully? That can mean lots of late nights and weekend work when you'd rather be doing something else.

Fortunately, working with Drupal 8 builds on core skills your team already has. Augmenting their existing knowledge with additional skills to use the new functionality of Drupal 8 will help your team deliver that first project successfully.

The new release of Drupal integrates technology that's become industry-standard, so developing skills in these areas will have benefits beyond the Drupal ecosystem.

How to think about your Drupal 8 team: Tech, Non-Tech, and "Bridge."

Skills for the Tech Team Members

Even if you've worked with Drupal previously, upcoming architectural changes in Drupal 8 mean you'll need to spend some time to get up to speed.

For the tech folks, here's the bulletin: bone up on PHP, Symfony, and object-oriented development.

PHP underlies Drupal 8's event-listener, which is what makes its functionality work. Understanding PHP namespaces is important to coming up with a clean way of organizing your code modules and sub-modules.

Symfony is a PHP framework that's being incorporated into Drupal 8. It will help provide the routing, sessions and services container functionality. Features like dependency injection will help you develop reusable code.

Drupal 8 implements its fields, views, entities and nodes in an object-oriented fashion. This brings the benefits of object-oriented development, like inheritance and encapsulating functionality, but means you need to understand concepts like polymorphism. Focus on understanding key design patterns like dependency injection -- you'll want to leverage those patterns in speed-building your site.

That sounds like a lot of learning, but you don't need to become experts in all of it -- you just need to get a deep enough understanding of the concepts and how to use them to speed your Drupal 8 development.

Skills for the Non-Tech Team Members

The non-tech members of the team don't get a free pass while developers hit the books.

Everyone on the team should understand the capabilities of Drupal 8 so they know what they can reasonably ask you to develop.

Finally, your team needs a "bridge member" -- a team lead or project manager who understands both the technical capability of Drupal 8 and the needs and wants of the business to mediate when there is a conflict between them.

A bridge member who is fluent in technology and business is key to making sure project commitments are realistic and achievable, allowing you to get the project done while having weekends to yourself.

Next: We'll drill down into the technical roles and required skills your team needs for Drupal 8.


Tags:  acquia drupal planet
Catégories: Elsewhere

Acquia: Jumpstart Your Drupal Project with a Technical Project Manager

lun, 04/05/2015 - 17:46

Is your Drupal project stalled?

Perhaps you don't know exactly what's wrong, but for some reason the project is just stuck.

You're eager to take the next step -- if only you knew what that was. If you find yourself in this situation often enough, you might want to consider hiring a technical project manager.

What is a Technical Project Manager?

Simply put, a technical project manager is your liaison between your technical team and the non-technical people you are working with. Technical managers are familiar with technical jargon and processes, and most importantly, they understand the culture of IT professionals. Thus, they can communicate well and help motivate members of the IT team that aren't performing at their maximum capacity, help managers delegate work appropriately and jump-start project leadership.

Technical project managers do a whole host of things on any given day to help move projects into the next stage of completion. For example, they might:

  • Write emails to members of the IT team to assign tasks, check in on project completion or resolve problems.
  • Discuss the project one-on-one with technicians to make sure they are staying on track and are moving towards project completion.
  • Write status reports
  • Lead IT team meetings
  • Help technicians brainstorm solutions to severe technical problems.
How to Work With a Technical Project Manager

The key to working with a technical project manager is to communicate often about the project. Here's some specifics to keep in mind:

  • Share your vision for the project. Technical project managers are as prone to assumptions about what the project entails as other IT team members are. It's important to begin by ensuring everyone's on the same page. When the technical project manager is brought on board, have a team meeting where everybody shares what they think the project is meant to accomplish and what their role is. That way, the technical project manager understands what's needed and can make sure that everybody on the team knows what they are supposed to be doing.
  • Collaborate on a timeline. One of the biggest problems with IT projects involves timelines. It can be tempting to get sucked into side projects when researching or working on the main project, and this can push deadlines back -- especially if those deadlines aren't clear to begin with. Sit down with the technical project manager to discuss the timeline for the project, including deadlines for each step. Together, the team can come up with a timeline that feels comfortable for everybody and the technical project manager can more easily help everybody stay on task.
  • Have regular check-ins. Now that there's a technical project manager on board, IT team members can talk about technical difficulties or problems with completing their tasks as scheduled because the project manager will understand what they're talking about. Team members should get in the habit of checking in regularly with the technical project manager and sharing any concerns or technical problems that are interfering with progress.
  • Use technology for check-ins and discussion. Reporting tools should be updated, and internal social media, instant messaging and conference calls should be utilized to quickly provide status updates for each member of the team.

Bringing a technical project manager on board can help bridge the gap between IT professionals and management.

Technical project managers have an IT background as well as a management background, so they are in a unique position to help projects get off the ground and moving towards completion.

Tags:  acquia drupal planet
Catégories: Elsewhere

J-P Stacey: Unicode, accented characters, Drupal Views Data Export and Excel

lun, 04/05/2015 - 17:00

If you need to assemble listings of content in Drupal, Views is what you use. And if you need to export such a listing, into offline formats like CSV, Views Data Export is a definite contender for how to do it. However, when you open the output in Microsoft Excel, you can end up—intentionally or otherwise—learning a great deal about the internals of Unicode encoding.

Read more of "Unicode, accented characters, Drupal Views Data Export and Excel "

Catégories: Elsewhere

NEWMEDIA: How to Prevent SQL Injections in Drupal

lun, 04/05/2015 - 15:04
How to Prevent SQL Injections in DrupalDrupal is an incredibly powerful open source CMS that allows you to create, manage, and serve content. Unfortunately, so can others if you don't properly sanitize all user input in order to prevent a malicious attack! Here are some tips on how to stop one of the most common vulnerabilities: SQL injections.Motivation: Why CMS Security Matters

Regardless of whether your site is a simple blog or a top 50 web property, they all represent an investment of time, money, and creative energy. And, just like any investment of value, it’s important to secure it in order to maintain its integrity.

Now, imagine a situation where all of your hard work can be compromised from a single, well-crafted attack. As a member of the Drupal security team, I can assure you that we’re still receiving email reports every week regarding websites that were hacked from the now infamous “Drupageddon”. Notonly was such an attack possible, it was exploited worldwide within hours of the published disclosure. Of course, this is a particularly extreme example that happened to affect Drupal core. It’s far more common to find vulnerabilities in custom code written by individuals that did not have the time and/or expertise to address.

That’s the doom and gloom. Now let’s imagine a different scenario in which you can sanitize all user input to ensure that you’re protected how a user tries to interact with your website. This is exactly what we’re about to go over for one of the most common forms of attack: a SQL injection.

What is a SQL Injection?

A SQL Injection is similar to “riders” in the US Federal government. A “rider” is a somewhat frustrating legislative procedure where an unrelated provision is attached to another piece of legislation. This tactic is often used to sneak in something unpopular or controversial onto an otherwise legitimate piece of legislation.

Similarly, a SQL injection is where a legitimate operation (e.g. insert a piece of content) has a malicious instruction added to it (e.g. create a new user and give it root access).

Here is a basic example that could theoretically come from a form submission:

$user_input = “JohnDoe”; $SQL = “Select * FROM {users} WHERE username = ” . $user_input; // Resulting query = “Select * FROM {users} WHERE username = JohnDoe”;

Now most users submitting the form would cause no harm. However, it doesn’t take much for a knowledgeable individual to create a malicious payload.

$user_input = "JohnDoe"; $SQL = "Select * FROM {users} WHERE username = " . $user_input; // Resulting query = "Select * FROM {users} WHERE username = JohnDoe";

Notice that the hacker can essentially create any arbitrary command by following this pattern. All an attacker needs to do is place any arbitrary command after the semicolon and they are off to the races. And because a CMS like Drupal relies heavily on the database, an attacker is then able to change just about anything (content, users, configuration, etc).

Sanitizing Data

The key principle to follow in preventing SQL attackes is to not trust user input. Instead, all user input should be sanitized such that no additional or unintentional database changes can be introduced.

With Drupal, there are a few ways to achieve this:

  • Manually Sanitize
  • Drupal’s Database Abstraction Layer (db_query())
  • Drupal Query Builder (DBTNG)

Let’s review each.

Manually Sanitize

Even though this is the first approach we discuss, it is not a recommended approach. In this scenario you are either going around Drupal’s database abstraction layer; OR, you are creating queries as strings of text and performing your own sanitation to remove riders (e.g. additional commands appended to the end of a legitimate command) as well as changes in logic (e.g. alterations to the existing query’s logic to make it pass or fail).

The challenge here is you’re essentially replicating what Drupal provides out of the box with its database abstraction layer. Worse, if you haven’t thought through all the possible attack vectors, you may miss something important.

Bottom line, proceed at your own risk if you decide to go it alone.

Drupal Database Abstraction Layer

Here we use placeholders that properly escape portions of the user input that could add an additional payload/rider or change its intended logic. Returning to our previous example:

$user_input = “JohnDoe; UPDATE {users} SET pass = qwerty WHERE uid = 1”; db_query(“SELECT * FROM {users} WHERE username = :name”, array(“:name” => $user_input)); // Resulting query = “Select * FROM {users} WHERE username = ‘JohnDoe; UPDATE {users} SET pass = qwerty WHERE uid = 1’“;

You’ll notice a major difference in that last line. Now the user input is no longer appending a new query to the end of an existing query. Instead, Drupal is ensuring the entirety of the user input is being used where it’s supposed to be used (i.e. as a comparison to find a record within the user table). And since there is no username that matches this arbitrary SQL command, the query will return NULL. More importantly, it will do nothing more than what it was designed to do.

It’s also important to note that it is still possible to introduce vulnerabilities when using commands from the database abstraction layer. If one doesn’t use placeholders, the malicious code can be easily reintroduced. For example:

$user_input = “JohnDoe; UPDATE {users} SET pass = qwerty WHERE uid = 1”; db_query(“Select * FROM {users} WHERE username = ” . $user_input); // Resulting query = “Select * FROM {users} WHERE username = JohnDoe; UPDATE {users} SET pass = qwerty WHERE uid = 1”;

The takeaway message is to always use placeholders when passing in variables into a query regardless of if they came from user input or from the system. Not only will it ensure consistency within your code, but it will significantly reduce the risk of a SQL injection.

Drupal Query Builder (DBTNG)

One of the new features in Drupal 7 core is the introduction of DBTNG (Database The Next Generation). In this new feature, placeholders are essentially mandatory based on how they are constructed. Let’s rework the example we’ve been using:

$user_input = “JohnDoe; UPDATE {users} SET pass = qwerty WHERE uid = 1”; $query = db_select(‘users’, ‘u’); $query->condition(‘name’, $user_input); $results = $query->execute(); // Resulting query = “Select * FROM {users} WHERE username = ‘JohnDoe; UPDATE {users} SET pass = qwerty WHERE uid = 1’“;

By using DBTNG we are getting user input sanitizing out of the box (SA-CORE-2014-005 aside). And similar to using the existing database abstraction layer, this can be used to ensure a consistent, secure codebase.

Detecting Trouble Spots

Reviewing an existing codebase for vulnerabilities can be a daunting task. Luckily, the coder review module can make that process a lot easier. It scans for common patterns and flags them by severity. This includes db_query() statements that attempt to insert variables directly into the query parameter instead of using placeholders.

If you don’t already use the coder review module as part of your workflow, I can’t recommend it enough. The module also scans for other vulnerabilities (e.g. XSS), coding standards, comment standards, and more. At a minimum, it will help you keep your codebase tidy. If used consistently, it will make you a better developer!

Finally, if you ever find a potential issue in a contrib module in your CMS, please file an issue with the Drupal security team! Or, if you need help with your Drupal, don’t hesitate to contact the newmedia team for a Drupal security audit.

Catégories: Elsewhere

Drupalize.Me: Help Drupal 8 and Win!

lun, 04/05/2015 - 15:02

We're kicking off a campaign to help the Drupal 8 Accelerate Fund. If you donate $50 or more to the community fund, you have a chance to win a free annual membership and if you donate $100, you can choose a new video for us to create.

Catégories: Elsewhere

Chromatic: Working with Vim: Never Leave Your Terminal

lun, 04/05/2015 - 14:56

Recently, Ryan blogged about a few CLI utilities that can really help improve your productivity. If I had to add one additional utility to his list, it’d be Vim. Vim is, the notoriously difficult-to-use, but remarkably powerful text editor that runs in a terminal (and of course the famous rival of Emacs).

Everything you’ve heard about Vim is true: it’s very difficult to learn, and it’s insanely powerful. These two characteristics almost balance each other out. You can probably do anything with Vim that you can do with another editor and do it faster and more efficiently. But you’ll need to take the time to learn it.

I can’t teach you much about Vim in a blog post. But there’s another reason for developers and programmers to bother with Vim: if you use it, you can almost work the whole day in your terminal. Most of the tools I need excepting browsers and other communications tools run in the terminal, so the more time I can spend in the terminal, the more efficiently I can work. Here’s how I do it.

Browsing files with NERDTree

I use Janus--a "Vim distribution"--to set up Vim. Janus provides a huge number of useful tools and a lot of default configuration on top of stock Vim (line numbers, commenting utilities, and much more), but the one I want to draw attention to here is NERDTree, a file browser for Vim (which, of course, can be installed without Janus).

For me this is an essential feature, and it really helped with my adoption of Vim. With it enabled, opening a project is as simple as navigating to a directory and typing vim .. As with conventional editors, this file browser can be configured to toggle on or off. And as with everything else in Vim this functionality is accessed and used via the keyboard. What’s more, NERDTree offers a one-keystroke menu (just type m) for creating, moving, deleting, and copying files.

Running terminal commands from inside Vim

The editor is where I spend most of my time, so running Vim in a terminal is a first step. But sometimes we have to run perform tasks on the command-line such as, for example, using drush to clear a Drupal site’s caches. Vim provides a neat little solution that you can use to do this without even leaving Vim. Type :! plus the command you need to run:

:! drush cc all

This will run the drush command in a shell, display the output of the command, and prompt you to type ENTER to resume editing.

Leaving and returning to Vim without losing your place

Sometimes while you’re working, you need to run multiple commands or do something more involved than running a single command. Fortunately, there is a way to do this in the bash shell:


This will actually move the Vim process into the background, returning you to your prompt to run whatever commands you need. To return to Vim--exactly as you left it--type:


This returns Vim to the foreground so you can continue working.

Opening files

Everything else I’ve mentioned in this post should work on Linux systems of all sorts, but OSX has one nice command that I haven’t encountered elsewhere. The "open" command can be used to open files with the application of your choice. So if you’re working on a file that you need to try out in a browser, you can type something like:

open -a Firefox test-document.html Transferring files with SCP

Since Git has become so popular not only as a way to manage, but also to deploy code, I find I transfer a lot fewer files than I used to. Nevertheless, it still happens that we need to move the occasional file up or down to a remote server. For this, I like to use SCP (SFTP is a good option for this too, but avoid FTP, it’s insecure).

Again, a full tutorial on SCP is far too involved for a blog post, but the basic syntax is like this:

scp path/to/local/file server:/path/to/remote/file

There are two things that make scp tricky to use (and which might take you away from your terminal!): the file paths and the authentication. I can’t help with the file paths, but you can stay in the terminal getting your work done by using SCP without usernames and passwords.

Authenticating SSH without passwords

This will change your life. It is possible to set up safe, secure SSH authentication without passwords. Even more exciting, once you have done this, it’s no longer necessary to use usernames and passwords with SCP. Once you’ve set up passwordless SSH access to a client server (under the host name e.g. ‘clientserver’), you can SCP a file to it as follows:

scp /path/to/local/file clientserver:/path/to/remote/file

No passwords or usernames required!

Editing files on remote servers

Last of all, we come to the reason that I decided to start using Vim in the first place. Simply put, Vim, or its predecessor Vi is installed on virtually every web server running Linux anywhere in the world.

This means that, on those occasions where it’s necessary for me to edit a remote file, I can usually use something similar to my usual editor. The version of Vi(m) on the remote server is usually much more stripped-down than my local development environment, but if you know how to use Vim, you usually find an editor installed on the server that you can use instead of having to SCP/SFTP transfer files up and down. Combine this with the passwordless SSH authentication, and it’s not only convenient, but very, very fast.

Is it worthwhile?

It can be. If you already use many command-line tools, and if you find that constantly needing to switch applications, or switching back and forth from mouse to keyboard interferes with your productivity, then Vim might be worth a shot. Conversely, if you already use Vim in the terminal and you’re not using command-line tools for almost everything else you can think of, you might want to start.

Now back to your terminal!

Catégories: Elsewhere

Deeson: Deeson is an official G-Cloud 6 agency

lun, 04/05/2015 - 11:48

It's official, Deeson is a G-Cloud approved agency (and have been for some time!) 

This means we're formally recognised as one of the partners working with the public sector to develop user-centered digital services. 

What's it all about? 

The government's G-Cloud framework contract aims to provide an easy way for public sector bodies to access digital services across a whole host of fields.

It does this through providing a number of pre-vetted suppliers, so there's no need for a lengthy pitch or procurement process. 

You can find out all about the services we provide under G-Cloud in the Digital Marketplace (previously the Cloudstore) - a digital procurement resouce for the public sector. 

Our work under G-Cloud

We're a Drupal-led digital agency and we've built all sorts of sites, big, beautiful and complicated- from online communities to searchable art collections.

But that's not all we do. We have an established user experience and creative practice too.

That means we also deliver discovery and scoping projects under the G-Cloud framework too - helping you understand more about your users and what it takes to develop a digital experience that they'll really want to use.

Getting started with G-Cloud

The G-Cloud set-up aims to make life easier if you work in the public sector, yet it may be daunting to some who are unfamiliar with how things work.

We've put together five handy tips to help you make the most of G-Cloud: 

  1. Be open and willing to try a different approach: to take full advantage of G-Cloud, it helps to have a more ‘open’ attitude - and be open to experimentation. Make sure you're familiar with the Service Design Manual (we love it!) and what it means for your project.  
  2. Clearly identify and understand your user or audience: this will drive what your needs are - what you want to achieve and what ‘success’ looks like. This in turn will help lead to the best solution, and help you deliver a meaningful product.  
  3. Establish who your key business owners are: make them central to the project; they are the enablers, the advocates and the ones that will drive the projects forward.  
  4. Use a natural opportunity to try G-Cloud: often it's best to outsource a small piece of work to test the water and help build your organisation's understanding of how to buy digital services under G-Cloud and how to work collaboratively with digital partners.  
  5. Network like there's no tomorrow. There's a thriving and supportive network of people working with digital in the public sector - get out there and meet them at events and meet-ups to boost your knowledge and see what's going on across the sector.

 Want a bit more help?

Find out more about all the G-Cloud services we offer here or just drop us a line - we're always happy to provide friendly advice and have a chat.


Catégories: Elsewhere

Triquanta Web Solutions: SEO and CDN

lun, 04/05/2015 - 11:12

So you decided to start using a CDN provider for your website. A good idea! But a lot of CDN providers use a custom URL that you should CNAME when everything is set up properly.

For instance Fastly and Cloudfront two big CDN providers.

When I want to add this website to Fastly they will give me the URL:
For Cloudfront it will be something like:

Once you CNAME'd these people will most likely not see these. But it can happen that these domains are going to be indexed by search engines.

And there you have it.... Duplicate content.
This means that your CDN provider is concurring the actual main domain. You don't want this, because it is a bad thing for your Search Engine Optimization (SEO)

To prevent this use the Canonical meta tag for all of your content pages. ( see for more info)
In Drupal this can be done using the metatag module this module can add the canonical and a lot of other desired meta-tags (see for the full list).

Now your content is okay but what about your files (images, pdf, word, etc).....
Since 2011 Google (and the rest followed Google) also support the canonical when it is used in the response headers. The next step is to add the header to the files. This can be done on your own server.
Apache .htaccess example with mod rewite and mod headers enabled.

  1. <FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf|webp|html)(\.gz)?(\?.*)?$">
  2.     <IfModule mod_rewrite.c>
  3.        RewriteEngine On
  4.        RewriteCond %{HTTPS} !=on
  5.        RewriteRule .* - [E=CANONICAL:{REQUEST_URI},NE]
  6.        RewriteCond %{HTTPS} =on
  7.        RewriteRule .* - [E=CANONICAL:{REQUEST_URI},NE]
  8.     </IfModule>
  9.     <IfModule mod_headers.c>
  10.        Header set Link "<%{CANONICAL}e>; rel=\"canonical\""
  11.     </IfModule>
  12.  </FilesMatch>

Ngnix example.

  1. location ~ \.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf|webp|html)(\.gz)?(\?.*)?$ {
  2.   add_header Link "<$scheme://$request_uri>; rel=\"canonical\"";
  3. }

When a file is being accessed using the CDN URL it will add the proper Canonical headers,  and you will not have any duplicate content issues.

Catégories: Elsewhere

Four Kitchens: API Design: The Musical - Live from Drupalcon LA

lun, 04/05/2015 - 05:01

We are just a few sweet days away from the power that is Drupalcon, Los Angeles. If you’re going I hope you are ready for another great conference.

Catégories: Elsewhere

Chen Hui Jing: Drupal 101: Creating an iTunes podcast feed

lun, 04/05/2015 - 02:00

Podcast listenership has been steadily increasing in recent years, and some are even predicting that we’re on the verge of a podcasting explosion. With that being said, it’s pretty likely you’ll get tasked with creating an iTunes podcast feed. Luckily, it’s quite simple to create one on your Drupal site with Views.

Required modules

Create/Modify content type for feed
  1. Install and enable the required modules. drush en views views_ui views_rss views_rss_core views_rss_itunes libraries getid3 -y
    • Create a new folder in your libraries folder like so:...
Catégories: Elsewhere

DrupalOnWindows: Drupal: Fields or Properties (or something else)

dim, 03/05/2015 - 19:00
Language English

Making Drupal scale is hard. It is even harder if you application is big and complex. And one of the main problems is that usually not enough attention is paid to data storage. But let me tell you that the storage model you pick is the backspine of your application, its heart, its soul. 

No fancy UI is ever going to compensate for a slow, unmaintainable and crappy engineered piece of software. 

More articles...
Catégories: Elsewhere

orkjerns blogg: Drupal and IoT. Code examples, part 1

dim, 03/05/2015 - 15:39
Drupal and IoT. Code examples, part 1 Body

As promised, I am posting the code for all the examples in the article about Drupal and the Internet of Things. Since I figured this could be also a good excuse to actually examplify different approaches to securing these communication channels, I decided to do different strategies for each code example. So here is the disclaimer. These posts (and maybe especially this one) would not necessarily contain the best-practices of establishing a communication channel from your "thing" to your Drupal site. But this is one example, and depending on the use-case, who knows, this might be easiest and most practical for you.

So, the first example we will look at is how to turn on and off your Drupal site with a TV remote control. If you did not read the previous article, or if you did not see the example video, here it is:

Overview of technology and communication flow

This is basically what is happening:

  • I click the on/off button on my TV remote.
  • A Tessel microcontroller reads the IR signal
  • The IR signal is analyzed to see if it indeed is the "on/off" button
  • A request is sent to my Drupal site
  • The Drupal site has enabled a module that defines an endpoint for toggling the site maintenance mode on and off
  • The Drupal site is toggled either on or off (depending on the previous state).
See any potential problems? Good. Let's start at the beginning Receiving IR and communicating with Drupal

OK, so this is a Drupal blog, and not a microcontroller or javascript blog. I won't go through this in detail here, but the full commented source code is at github. If you want to use it, you would need a tessel board though. If you have that, and want to give it a go, the easiest way to get started is probably to read through the tests. Let's just sum it up in a couple of bullet points, real quick:

  • All IR signals are collected by the Tessel. Fun fact: There will be indications of IR signals even when you are not pressing the remote.
  • IR signals from the same button are rarely completely identical, so some fuzzing is needed in the identification of a button press
  • Figuring out the "signature" of your "off-button" might require some research.
  • Configure the code to pass along the config for your site, so that when we know we want to toggle maintenance mode (the correct button is pressed), we send a request to the Drupal site.
Receiving a request to toggle maintenance mode

Now to the obvious problem. If you exposed a URL that would turn the site on and off, what is to stop any random person from just toggling your site status just for the kicks? Here is the part where I want to talk about different methods of authentication. Let us compare this to the actual administration form where you can toggle the maintenance mode. What is to stop people from just using that? Access control. You have to actually log in and have the correct permission (administer site configuration) to be able to see that page. Now, logging in with a micro controller is of course possible, but it is slightly more impractical than for a human. So let's explore our options. In 3 posts, this being the first. Since this is the first one, we will start with the least flexible. But perhaps the most lo-fi and most low-barrier entry. We are going to still use the permission system.

Re-using your browser login from the IR receiver

These paragraphs are included in case someone reading this needs background info about this part. If this seems very obvious, please skip ahead 2 paragraphs

Web apps these days do not require log-ins on each page (that would be very impractical), but actually uses a cookie to indicate you are still trusted to be the same user as when you logged in. So, for example, when I am writing this, it is because I have a session cookie stored in my browser, and this indicates I am authorised to post nodes on this site. So when I request a page, the cookie is passed along with it. We can also do the same passing of a cookie on a micro controller.

Sending fully authenticated requests without a browser

So to figure out how to still be authenticated as an admin user you can use your browser dev tools of your choice. Open a browser where you are logged in as a user allowed to put the site into maintenance mode. Now open your browser dev-tools (for example with Cmd-Alt-I in Chrome on a Mac). In the dev tools there will be a network tab. Keep this active while loading a page you want to get the session cookie from. You can now inspect one of the requests and see what headers your browser passed on to the server. One of these things is the header Cookie. It will include something along the lines of this (it starts with SESS):


Since I am a fan of animated gifs, here is the same explanation illustrated:

This is the session cookie for you session as an authenticated user on your site. Since we now know this, we can request the path for the toggle functionality from our microcontroller, passing this cookie along as the header, and toggle the site as we were just accessing it through the browser.

The maintenance_mode_ir module

As promised, I also posted the Drupal part of the code. It is a module for Drupal 8, and can be found on github

So what is happening in that module? It is a very basic module actually mostly generated by the super awesome Drupal console. To again sum it up in bullet points:

  • It defines a route in maintenance_mode_ir.routing.yml (
  • The route requires the permission "administer site configuration"
  • The route controller checks the StateInterface for the current state of maintenance mode, toggles it and returns a JSON response about the new state
  • The route (and so the toggling) will never be accessible for anonymous users (unless you give the anonymous users the permission "administer site configuration", in which case you probably have other issues anyway)
  • There are also tests to make sure this works as expected
When do you want to use this, and what is the considerations and compromises

Now, your first thought might be: would it not be even simpler to just expose a route where requests would turn the site on and off? We wouldn't need to bother with finding the session cookie, passing that along and so on? Legitimate question and of course true in the sense that it is simpler. But this is really the core of any communications taking place between your "things" and Drupal (or any other backend) - you want to make sure they are secured in some way. Of course being able to toggle the maintenance mode is probably not something you would want to expose anyway, but you should also use some sort of authentication if it only was a monitoring of temperature. Securing it through the access control in Drupal gives you a battle tested foundation for doing this.

Limitations and considerations

This method has some limitations. Say for example you are storing your sessions in a typical cache storage (like redis). Your session will expire at some point. Or, if you are using no persistence for redis, it will just be dropped as soon as redis restarts. Maybe you are limited by your php session lifetime settings. Or maybe you just accidentally log out of the session where you "found" the cookie. Many things can make this authenticated request stop working. But if all you are doing is hooking up a remote control reader to make a video and put on your blog, this will work.

Another thing to consider is the connection of your "thing". Is your site served over a non-secure connection and you are sending requests with your "thing" connected through a public wifi? You might want to reconsider your tactics. Also, keep in mind that if your session is compromised, it is not only the toggling of maintenance mode that is compromised, but the actual administrator user. This might not be the case if we were to use another form of authentication.

Now, the next paragraph presented to you will actually be the comments section. The section where you are encouraged to comment on inconsistencies, forgotten security concerns or praise about well chosen gif animations. Let me just first remind you of the disclaimer in the first paragraph, and the fact that this a serie of posts exploring different forms of device authentications. I would say the main takeaway from this first article is that exposing different aspects of your Drupal site to "the physical world", be it remote controlled maintenance mode or temperature logging, requires you to think about how you want to protect these exposed endpoints. So please do that, enjoy this complementary animated gif (in the category "maintenance"), and then feel free to comment.

admin Sun, 05/03/2015 - 13:39 Image Tags:
Catégories: Elsewhere

OhTheHugeManatee: How to Build a New Source for Drupal Migrate 8

sam, 02/05/2015 - 16:10

This week I wanted to accomplish a task in Drupal 8 that would be simple in Drupal 7: Import several CSV files, each one related to the others by taxonomy terms. Most importantly, I wanted to do it with Migrate module.

Migrate in Drupal 7 is a fantastic piece of code. It is not designed to be used from the GUI, rather, it provides a framework of “source”, “destination”, and “migration” classes so that even the most convoluted migration is 90% written for you. To create a migration in Drupal 7, you create a custom module, declare your migrations in a hook_info, and then extend the built in “migration” class. You instantiate one of the given classes for the source material (is it a CSV? JSON? Direct connection to a custom DB?), then one of the classes for the destination (is it a content type? Taxonomy term?). Then you add one simple line of code mapping each field from source to destination. If you know what you’re doing, the task I had in mind shouldn’t take more than 15 minutes per source.

It’s not quite so easy in Drupal 8. First of all, with Migrate in core, we had to greatly simplify the goals for the module. The version of Migrate that is really functional and stable is specifically and only the basic framework. There is a separate migrate_drupal module to provide everything you need for migrating from Drupal 6 or 7. This has been a laser-tight focus on just the essentials, which means there’s no UI, very little drush support, and definitely no nice extras like the ability to read non-Drupal sources.

My task this week became to write the first CSV source for Drupal 8 Migrate.

Drupal 8 Migrate Overview

Drupal 8 Migrations, when you’re using classes that already exist, are actually even easier than Migrate 7. All you do is write a single YAML file for each kind of data you’re transferring, and put it in a custom module’s config/install directory. Your YAML file gives your migration a name and a group, tells us what the source is for data, maps source fields to destination fields, and tells us what the destination objects are. Here’s an example Migration definition file from core. See if you can understand what’s being migrated here.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 id: d6_system_site label: Drupal 6 site configuration migration_groups: - Drupal 6 source: plugin: variable variables: - site_name - site_mail - site_slogan - site_frontpage - site_403 - site_404 - drupal_weight_select_max - admin_compact_mode process: name: site_name mail: site_mail slogan: site_slogan 'page/front': site_frontpage 'page/403': site_403 'page/404': site_404 weight_select_max: drupal_weight_select_max admin_compact_mode: admin_compact_mode destination: plugin: config config_name:

You probably figured it out: this migration takes the system settings (variables) from a Drupal 6 site, and puts them into the Drupal 7 configuration. Not terribly hard, right? You can even do data transformations from the source field value to the destination.

Unfortunately, the only sources we have so far are for Drupal 6 and 7 sites, pulling directly from the database. If you want to use Migrate 8 the way we used Migrate 7, as an easy way to pull in data from arbitrary sources, you’ll have to contribute.

Writing a source plugin in Migrate_plus

Enter Migrate Plus module. This is the place in contrib, where we can fill out all the rest of the behavior we want from Migrate, that’s not necessarily a core requirement. This is where we’ll be writing our source plugin.

To add a source plugin, just create a .php file in migrate_plus/src/Plugins/migrate/source . Drupal will discover the new plugin automatically the next time you rebuild the cache. The filename has to be the same as the name of the class, so choose carefully! My file is called CSV.php . Here’s the top of the file you need for a basic :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <?php /** * @file * Contains \Drupal\migrate_plus\Plugin\migrate\source\csv. */ namespace Drupal\migrate_plus\Plugin\migrate\source; use Drupal\migrate\Plugin\migrate\source\SourcePluginBase; /** * Source for CSV files. * * @MigrateSource( * id = "csv" * ) */ class CSV extends SourcePluginBase {

I’m calling this out separately because for newbies to Drupal 8, this is the hard part. This is all the information that Drupal needs to be able to find your class when it needs it. The @file comment is important. That and the namespace below have to match the actual location of the .php file.

Then you declare any other classes that you need, with their full namespace. To start with all you need is SourcePluginBase.

Finally you have to annotate the class with that @MigrateSource(id=“csv”). This is how Migrate module knows that this is a MigrateSource, and the name of your Plugin. Don’t miss it!

Inside the class, you must have the following methods. I’ll explain a bit more about each afterwards.

  • initializeIterator() : Should return a valid Iterator object.
  • getIds() : Should return an array that defines the unique identifiers of your data source.
  • __toString() : Should return a simple, string representation of the source.
  • fields() : Should return a definitive list of fields in the source.
  • __construct() : You don’t NEED this method, but you probably will end up using it.

An Iterator is a complicated sounding word for an Object that contains everything you need to read from a data source, and go through it one line at a time. Maybe you’re used to fopen(‘path/to/file’, ‘r’) to open a file, and then you write code for every possible operation with that file. An iterator takes care of all that for you. In the case of most file-based sources, you can just use the SplFileObject class that comes with PHP.

Any arguments that were passed in the source: section of the YAML file will be available under $this->configuration. So if my YAML looks like this:

1 2 3 source: plugin: csv path: '/vagrant/import/ACS_13_1YR_B28002_with_ann.csv'

My initializeIterator( ) method can look like this:

1 2 3 4 5 6 public function initializeIterator() { // File handler using our custom header-rows-respecting extension of SPLFileObject. $file = new SplFileObject($this->configuration['path']); $file->setFlags(SplFileObject::READ_CSV); return $file; }

Not too complicated, right? This method is called right at the beginning of the migration, the first time Migrate wants to get any information out of your source. The iterator will be stored in $this->iterator.


This method should return an array of all the unique keys for your source. A unique key is some value that’s unique for that row in the source material. Sometimes there’s more than one, which is why this is an array. Each key field name is also an array, with a child “type” declaration. This is hard to explain in English, but easy to show in code:

1 2 3 4 5 6 7 public function getIDs() { $ids = array(); foreach ($this->configuration['keys'] as $key) { $ids[$key]['type'] = 'string'; } return $ids; }

We rely on the YAML author to tell us the key fields in the CSV, and we just reformat them accordingly. Type can be ‘string’, ‘float’, ‘integer’, whatever makes sense.


This method has to return a simple string explanation of the source query. In the case of a file-based source, it makes sense to print the path to the file, like this:

1 2 3 public function __toString() { return (string) $this->query; } fields()

This method returns an array of available fields on the source. The keys should be the machine names, the values are descriptive, human-readable names. In the case of the CSV source, we look for headers at the top of the CSV file and build the array that way.


The constructor method is called whenever a class is instantiated. You don’t technically HAVE to have a constructor on your source class, but you’ll find it helpful. For the CSV source, I used the constructor to make sure we have all the configuration that we need. Then I try and set sane values for fields, based on any header in the file.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration) { parent::__construct($configuration, $plugin_id, $plugin_definition, $migration); // Path is required. if (empty($this->configuration['path'])) { return new MigrateException('You must declare the "path" to the source CSV file in your source settings.'); } // Key field(s) are required if (empty($this->configuration['keys'])) { return new MigrateException('You must declare the "keys" the source CSV file in your source settings.'); } // Set header rows from the migrate configuration. $this->headerRows = !empty($this->configuration['header_rows']) ? $this->configuration['header_rows'] : 0; // Figure out what CSV columns we have. // One can either pass in an explicit list of column names to use, or if we have // a header row we can use the names from that if ($this->headerRows && empty($this->configuration['csvColumns'])) { $this->csvColumns = array(); // Skip all but the last header for ($i = 0; $i < $this->headerRows - 1; $i++) { $this->getNextLine(); } $row = $this->getNextLine(); foreach ($row as $key => $header) { $header = trim($header); $this->getIterator()->csvColumns[] = array($header, $header); } } elseif ($this->configuration['csvColumns']) { $this->getIterator()->csvColumns = $this->configuration['csvColumns']; } } Profit!

That’s it! Four simple methods, and you have a new source type for Drupal 8 Migrate. Of course, you will probably find complications that require a bit more work. For CSV, supporting a header row turned out to be a real pain. Any time Migrate tried to “rewind” the source back to the first line, it would try and migrate the header row! I ended up extending SplFileObject just to handle this issue.

Here’s the YAML file I used to test this, importing a list of states from some US Census data.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 id: states label: States migration_groups: - US Census source: plugin: csv path: '/vagrant/import/ACS_13_1YR_B28002_with_ann.csv' header_rows: 2 fields: - Id2 - Geography keys: - Id2 process: name: Geography vid: - plugin: default_value default_value: state destination: plugin: entity:taxonomy_term

You can see my CSV source and Iterator in the issue queue for migrate_plus. Good luck, and happy migrating!


I learned a lot this week. Big thanks to the Migrate Documentation, but especially to chx, mikeryan, and the other good folks in #drupal-migrate who helped set me straight.

Catégories: Elsewhere

The Cherry Hill Company: Easily Update Site Colors with Flexible Colors

sam, 02/05/2015 - 01:27

At Cherry Hill we have begun to use the Flexible Colors module extensively in our client sites. The idea behind Flexible Colors is that color presets can be created for a site so that users or administrators can easily switch between them without touching the theme CSS.

The Challenge

We have a number of sites that are variations on a base theme and color changes are the only customizations that clients often want. It has become tedious to create new Git repositories and add themes or subthemes to them for each new site that only wants simple changes.

We needed a way to make these simple changes without having to commit code.

The Solution

Luckily, Ashok Modi (also known as BTMash), our CTO created and maintains the Flexible Colors module. We started a 2.x branch of the module to address some of our new...

Read more »
Catégories: Elsewhere

DrupalCon News: Learn through contribution. Come sprint with us.

ven, 01/05/2015 - 21:30

DrupalCon is where you can make contributions to the Drupal project. Each convention is filled with inspiration, networking, and fun — and while cutting-edge sessions are the meat of DrupalCon, sprints are the beating heart.

Catégories: Elsewhere

Red Crackle: How to add an Ubuntu apt-get key from behind a firewall

ven, 01/05/2015 - 19:00
Have you ever tried to install an apt package from a third-party repository from behind a firewall? If you run apt-key command with a key server, firewall will block it. Read this post to find out how to get past the firewall to import key for a third-party apt package.
Catégories: Elsewhere

SitePoint PHP Drupal: Automated Testing of Drupal 8 Modules

ven, 01/05/2015 - 18:00

In this article we are going to look at automated testing in Drupal 8. More specifically, we are going to write a few integration tests for some of the business logic we wrote in the previous Sitepoint articles on Drupal 8 module development. You can find the latest version of that code in this repository along with the tests we write today.

But before doing that, we will talk a bit about what kinds of tests we can write in Drupal 8 and how they actually work.

Simpletest (Testing)

Simpletest is the Drupal specific testing framework. For Drupal 6 it was a contributed module but since Drupal 7 it has been part of the core package. Simpletest is now an integral part of Drupal core development, allowing for safe API modifications due to an extensive codebase test coverage.

Right off the bat I will mention the authoritative documentation page for Drupal testing with Simpletest. There you can find a hub of information related to how Simpletest works, how you can write tests for it, what API methods you can use, etc.

By default, the Simpletest module that comes with Drupal core is not enabled so we will have to do that ourselves if we want to run tests. It can be found on the Extend page named as Testing.

Once that is done, we can head to admin/config/development/testing and see all the tests currently available for the site. These include both core and contrib module tests. At the very bottom, there is also the Clean environment button that we can use if any of our tests quit unexpectedly and there are some remaining test tables in your database.

Continue reading %Automated Testing of Drupal 8 Modules%

Catégories: Elsewhere

Lullabot: Lullabot Named Top Development And Design Agency

ven, 01/05/2015 - 17:01

Clutch is a research firm that analyzes and reviews software and professional services agencies, covering more than 500 companies in over 50 different markets. Like a Consumer Reports for the agency sector, they do independent research. They publish their results at Recently, they reviewed Lullabot, interviewing our clients; they created a profile of Lullabot with the results. Lullabot received top marks across the board.

In January, Clutch published a press release listing Lullabot first overall on its international list of web development agencies. We've always been very proud of our work, but it's really amazing to be recognized like this by an independent research firm. In March, Clutch sent out another press release that lists Lullabot as top in Boston-area web design and development agencies. We'll take it!

Clutch also provides matrix-based research results comparing agencies based on focus and ability to deliver. Lullabot floats to the top of both the Top Web Development Companies and the Top Web Design & Development Firms in Boston showing high-focus and the most proven ability to deliver of any agency in the listings.

Since 2006, we've built an incredible team at Lullabot and I'd like to thank all of our employees for their contributions. We've also partnered with scores of magnificant clients over the years. We'd like to thank them all for their trust and collaboration. Of course, Clutch's listings are dynamic and ongoing. We can't sit back and expect to remain in the top position. We will continue to strive to be the best agency we can be, providing superlative results for our clients while continuing to provide a rewarding work environment for our talented team of expert developers, designers, and strategists.

Catégories: Elsewhere

Drupal Association News: They’re back! Personalized membership certificates are here.

ven, 01/05/2015 - 14:44

We all like to show our love for Drupal, and over the past few years, we’ve let Drupal show it loves you! Due to popular demand, we are bringing back a fun gift to Drupal Association members -- personalized certificates of membership. In 2014, we delivered these downloadable certificates to over 600 members and we hope to break this record during the months of May and June this year.

Join as a member or renew your current membership anytime before June 30 and you’ll receive a personalized certificate of membership.

Sign me up

This is a token of our gratitude for your support of Drupal and the community. Thanks for everything you do for Drupal.

Personal blog tags: Membership
Catégories: Elsewhere

BlackMesh: DrupalCon LA has 5 dedicated sprint days. Should you be there? YES!

ven, 01/05/2015 - 14:18
What is a Sprint? Sprints are times dedicated to focused work on a project or topic. People in the same location (physical space, IRC, certain issue pages) work together to make progress, remove barriers to completion, and try to get things to "done". The goal is to get an issue to Reviewed and Tested By the Community (RTBC), and keep it there. (Keeping it there means quickly addressing feedback, like when a someone moves an issue back from RTBC to Needs Work, or Needs Review.)

Instead of a person working by themselves on many things, we work together, with others, on a few things to get them done. We do not measure success by the number of patches posted. We measure success by the reviews we do, issue summaries we update, change records we post, and the number of issues we get to RTBC.

DrupalCon is a supportive environment to begin contributing Though sprints might sound intimidating, the sprints at DrupalCon have a history of both informal and formal ways for integrating new contributors in this process. If you have experience with Drupal, then you have the skills we need to help with contribution to the Drupal project. And, DrupalCon is the most supportive environment to start your contribution journey. Who? We welcome project managers, bug reporters, site builders, themers, QA testers, writers to help with documentation, accessibility specialists, usability specialists, developers, and contributors to other open source projects to help fix upstream bugs. When?
  • Extended sprints begin Saturday, May 9 and Sunday, May 10 at an off-site location: IndieDesk.
  • Monday, May 11, sprints at the conference venue in room Room 408AB run concurrently with the community summit and other trainings.
  • There is a lounge for work all throughout the event at the venue in Room 408AB, and off-site which is open 24 hours at the Westin Bonaventure Hotel in the Ballroom on 3rd floor.
  • Then Friday, May 15 is the most awesome sprint day which you should not miss an hour of.
  • Followed by more extended sprints at IndieDesk Saturday, May 16 and Sunday, May 17.
Why should you sprint? Sprinting with others allows barriers to contributing to be removed in real time. You will learn a lot just by sitting at a table with others and seeing how they work. Having others see how you work, might result in them giving you time saving tips that will help you contribute and... might also help when you return to your regular routine after the sprint. It is fun. You will get to network and meet the real human people who work on Drupal itself. Sprints include some down time. We have to eat! Conversations at lunch and dinner can be both enjoyable and eye opening. Finally, trust that you do have skills that will be appreciated at the sprints. We are really good and finding ways for everyone to contribute. Topics In addition to generally "contributing", there are some specific topics in Core, Contrib modules, themes, and infrastructure with people organizing work in those areas and gathering others to collaborate with them. Core Some of the focus for Core during the DrupalCon sprints will be:
  • Getting D8 done
  • Multilingual
  • Front-end United
Getting D8 done For getting D8 done, there are different ways of being involved. One way, is working on D8 criticals. Read the page on helping with Drupal 8. Angie Byron (webchick) is also giving a session to update people on the status of the current criticals. We are also looking for experienced contributors join a group of people who will triage issues with the priority of Major. (We are still working on instructions for doing the major triage. Join us at the event!) Multilingual The best way to get involved with the Drupal 8 Multilingual Initiative (D8MI) is to start on the D8MI website. And then look at the issues we are currently focusing on. Jump right in, or come by our weekly meeting in IRC in the #drupal-i18n channel. The next meeting is May 6th at 4pm UTC. Front-end United Front-end United people will be working on: CSS, JavaScript, Twig, UX, themes, the theme system, markup, and stuff! Contrib Some of the focus for Contrib during the DrupalCon sprints will be:
  • Content Staging in D8
  • Media in D8
Content Staging in D8 Information about content staging in Drupal 8 is on the deploy project page. Media in D8 Current focus for media is on entity_embed, entity_browser, media_entity and fallback_formatter. Work is happening in the drupal-media project on github. The presentation by Chandan Singh has a recent update. is running on Drupal 7. If you are familiar with Drupal 7 and do notwant to dive into Drupal 8 yet, you can still really help with the release of Drupal 8, by working on itself. has a lot of projects where it tracks issues. There are 42 related projects which each have their own issue queue. searching for the d.o hitlist tag (across all projects) yields a list of issues that are relevant for the sprint. Infrastructure The big push for infrastructure right now, includes blockers to Drupal 8. Issue: [meta] (websites/infra) blockers to a Drupal 8 release has lots of details, but can be a little overwhelming to dive into. Confersations happen in IRC in the #drupal-infrastructure channel. One of the blockers is the new testbot Continuous Integration system (testbot CI 2.0). There are 7 projects related to DrupalCI. DrupalCI: Modernizing Testbot Initiative is the main overall project. And updates and confersations happen in the Testing Infrastructure group and in IRC in the #drupal-testing channel. Sign-up Signup to help with a topic, or lead a topic in the DrupalCon LA sprint spreadsheet.

Photo credit: Jeremy Thorson

Catégories: Elsewhere