Skip to Content

Planet Drupal

Syndicate content - aggregated feeds in category Planet Drupal
Updated: 2 days 21 hours ago

Drupal Watchdog: VIDEO: DrupalCon Amsterdam Interview: Cathy Theys

5 May 2015 - 9:09am

CATHY THEYS (Drupal Community Liaison, Blackmesh) runs sprints. She also mentors young Drupal sprinters. Go, Cathy!

Tags:  DrupalCon Amsterdam DrupalCon Video Video: 
Categories: Drupal

Drupal Watchdog: Protecting Your Drupal 8 Resources

5 May 2015 - 7:05am

Drupal 8 incorporates a Modular Authentication System which, given a request, attempts to identify a Drupal user by inspecting the HTTP request headers.

Authentication comes in handy when we want to restrict access to a resource in Drupal. It can be applied to any route, although the method to implement it may differ. It is most commonly used to identify requests when we are exposing data through an API from our Drupal site.

Authentication and Authorization

Imagine you are going through airport security. The security agent asks to see your ID – a passport or driver’s license, say. The act of showing your ID is what we call Authentication. In Drupal – as in almost all websites – your authentication credentials are your username and password.

Next, the security agent checks your boarding pass to verify that you are in the right place and have clearance to get on a plane. That’s called Authorization. In Drupal your role (and therefore the permissions assigned to that role) are your Authorization credentials.

To summarize: authentication means who are you?; authorization means may you proceed?.

Enjoy your flight!

Authentication in Drupal 8

In Drupal 8, Authorization is handled by the Access System and won't be covered in this article; there is an internal system to handle Authentication, so let's start with the following statement:

Thanks to the Modular Authentication System, different Authentication Providers may extract a $user out of a given $request object.

There are a few keywords in that statement. Let's dissect them briefly:

Categories: Drupal

ThinkShout: Monkeying Around with D8

5 May 2015 - 2:00am
Leading the Charge

I have used A LOT of email marketing service providers over the years and my opinion of them was twofold: they were all similar and none of them were particularly great. Was it possible that this was just a category of business that would never be exciting or innovative? Was I destined to be a project manager who half-heartedly recommended whatever email service provider I was using most at the time to clients?

Enter the chimp...

Despite its playful name, MailChimp made a serious shift in a category that had always had potential but lacked a champion. My first thought when I used the tool was that even if the feature set was identical to all its competitors, MailChimp’s user interface alone set it apart. But once I dug into its capabilities, I became a bona fide fan (dare I say ambassador) of the brand. From automated email workflows and slick segmentation capabilities, to the Chimpadeedoo tablet app that facilitates email sign-ups without an internet connection, MailChimp became the new king of the jungle.

Fast forward a few years, and here I am working at ThinkShout, MailChimp’s Drupal partner. We built and maintain the MailChimp Drupal module, which is used by nearly 22,000 websites.

If you are familiar with MailChimp’s motto - listen hard and change fast - (or if you just read the first couple paragraphs of this blog post), then it should come as no surprise that innovation is at the heart of MailChimp’s culture. With the release of Drupal 8 looming this Fall, MailChimp and ThinkShout saw a unique opportunity to lead the charge by porting one of the most popular email modules to be D8 compatible.

The Only Way Through it is Through it

Being a trailblazer isn’t easy, and MailChimp understood that pushing the envelope on D8 development would require an investment of time and resources. While the core MailChimp module is relatively simple, the bundled submodules are feature-rich and technically complex.

Let’s recap what the MailChimp module allows you to do:

  • Any “object” in Drupal that has an email address, say a User, Contact, or even a Comment, can be automatically subscribed to a list and segmented based on other attributes, like their zip code.
  • Display a list subscription status on an entity or a subscription form.
  • Map Drupal Data, such as name and address, to merge fields in MailChimp.
  • Create forms to allow site visitors to sign up for any Mailchimp List or combination of Lists.
  • Create Pages, Blocks, or both to display forms.
  • Create campaigns containing any Drupal entity, or entities, as content.
  • Send campaigns created in Drupal through MailChimp or Drupal.
  • View campaign statistics and email activity for all list subscribers.

Luckily, one of the greatest aspects of our partnership with MailChimp is our shared passion for recognizing opportunity in challenges and giving back to the community. With that spirit, a couple of ThinkShout engineers dove in head first with the goal of porting the majority of the popular D7 module’s features over to D8 in time for a beta release at DrupalCon LA. During the process, they realized that the available Drupal 8 documentation wasn’t keeping up with the speedy pace of D8 development. Over the course of several weeks, our engineers updated documentation and created examples to make life (or at least development) a little easier for the next developer looking to create something similar.

It’s a Sprint, Not a Marathon

With the conference approaching, it was time to call on the ThinkShout village to help put the polish on the new module. Since nine heads are better than two when it comes to user testing and QA, we scheduled a sprint to focus our engineering department on providing that critical perspective needed at the end of a large development project.

During our afternoon sprint, our engineering department ran a battery of tests (both human and automated) to document and resolve bugs. Our engineering staff has grown quite a bit recently, so the sprint also provided an opportunity for knowledge sharing about MailChimp and D8 development across the team. As a non-engineer fly on the wall, it was exciting to witness the energy at the sprint table, as bugs were closed and high-fives were thrown.

The Future is Now

So far, I’ve focused on what some of the challenges of early D8 development have been, and you’re surely wondering by now “So, what do you think about D8?” Short answer: we’re excited, and we think you should be, too.

Drupal 8 standardizes module development by enforcing PSR-4 compliant namespaces. Whereas D7 allows developers to dictate where a form or entity is placed, for example, D8 loads files in the correct path automatically. What does this mean for developers? Well, it means time saved by not having to search an entire codebase to find where the developer before you placed a form. And because this structure is more in line with general engineering practices, it will be easier for any developer to ramp up for Drupal development.

But the benefits aren’t just for developers. We are also excited about the efficiencies that will be created for our nonprofit clients. Not only do they stand to benefit from the streamlined development approach, but that shift in approach will also make it easier to find resources to maintain and enhance their sites.

Learn More About the New MailChimp Module

Come and see us at DrupalCon LA, where our very own Lev Tsypin will be giving a lightning talk about the evolution of MailChimp's support for Drupal, the basics of how the integration works, and a hint at what's to come for Drupal 8. Don’t worry if you can’t make it to the talk because we’ll also be hanging out in the MailChimp booth. And if you spot one of us (you’ll recognize us by our ThinkShout hoodies), stop us! We’d love to chat about what we’ve learned about D8 and why were are excited for its release. Also, be sure to check out past blogs we've written about our work on the MailChimp module.

Categories: Drupal

Drupal core announcements: Drupal 7 core release on Wednesday, May 6

4 May 2015 - 10:39pm
Start:  2015-05-06 (All day) America/New_York Online meeting (eg. IRC meeting) Organizers:  David_Rothstein

The monthly Drupal core bug fix/feature release window is this Wednesday, May 6. Although there was a release just last month, it's a good time for another one, to fix a regression introduced in Drupal 7.36 that affected some sites as well as to get a few other fixes in. Therefore, I plan to release Drupal 7.37 this Wednesday.

The final patches for 7.37 have been committed and the code is frozen (excluding documentation fixes and fixes for any regressions that may be found in the next couple days). So, now is a wonderful time to update your development/staging servers to the latest 7.x code and help us catch any regressions in advance.

The primary purpose of this release is to fix a regression caused by Drupal 7.36 which caused content types on some existing sites to become disabled after the update (see the 7.36 release notes and the issue for further information). The fix is intended to work for sites that already upgraded to Drupal 7.36 (it should restore content types that were erroneously disabled) as well as for those that did not. More testing of this issue in particular is welcome.

You might also be interested in the tentative CHANGELOG.txt for Drupal 7.37 and the corresponding list of important issues that will be highlighted in the Drupal 7.37 release notes.

If you do find any regressions, please report them in the issue queue. Thanks!

Upcoming release windows after this week include:

  • Wednesday, May 20 (security release window)
  • Wednesday, June 3 (bug fix/feature release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Drupal

DrupalCon News: Accessibility at DrupalCon

4 May 2015 - 2:49pm

Inclusivity is incredibly important to us at the Drupal Association. As part of our organizational value of respect, we state: “We respect and value inclusivity in our global community and strive to recognize, understand, and respond to its needs."

But we believe that actions speak louder than words, and that’s why we’re pleased that DrupalCon will be so friendly to our community members who may require assistance or have certain accessibility needs during the events.

Categories: Drupal

Drupal Easy: DrupalEasy Podcast 151: Shirtless at Drupalcon (Brett Meyer and Stephanie Gutowski - Drupal Watchdog/DrupalCon Los Angeles preview)

4 May 2015 - 11:22am
Download Podcast 151

Brett Meyer, Director of Strategy at ThinkShout, and Stephanie Gutowski, Community Engagement Organizer/Manager at ThinkShout, join Ted, Ryan, and Mike to talk about video games. Specifically, Dragon Age: Inquisition. Seriously - Brett and Stephanie have an article in the upcoming issue of Drupal Watchdog where they relate content strategy in web sites to content strategy in content-heavy videos games. We also focus on DrupalCon Los Angeles including what we're looking forward to, if sessions are still necessary, community vs. business networking, and if it's possible to only pack a single shirt.

read more

Categories: Drupal

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

4 May 2015 - 10:12am

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
Categories: Drupal

Acquia: Jumpstart Your Drupal Project with a Technical Project Manager

4 May 2015 - 8:46am

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
Categories: Drupal

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

4 May 2015 - 8:00am

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 "

Categories: Drupal

NEWMEDIA: How to Prevent SQL Injections in Drupal

4 May 2015 - 6:04am
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.

Categories: Drupal

Drupalize.Me: Help Drupal 8 and Win!

4 May 2015 - 6:02am

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.

Categories: Drupal

Chromatic: Working with Vim: Never Leave Your Terminal

4 May 2015 - 5:56am

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!

Categories: Drupal

Deeson: Deeson is an official G-Cloud 6 agency

4 May 2015 - 2:48am

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.


Categories: Drupal

Triquanta Web Solutions: SEO and CDN

4 May 2015 - 2:12am

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.

Categories: Drupal

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

3 May 2015 - 8:01pm

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.

Categories: Drupal

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

3 May 2015 - 5:00pm

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:...
Categories: Drupal

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

3 May 2015 - 10:00am
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...
Categories: Drupal

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

3 May 2015 - 6:39am
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:
Categories: Drupal

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

2 May 2015 - 7:10am

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.

Categories: Drupal

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

1 May 2015 - 4:27pm

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 »
Categories: Drupal

about seo