Mediacurrent: Evaluating the security of Drupal contrib modules

Planet Drupal - Wed, 2016/06/15 - 5:01pm

At Mediacurrent, we take website security very seriously. Drupal has some security best practices baked into its APIs that let developers create their own modules, hopefully with secure code, to contribute back to the community. You contribute back, don’t you?


InternetDevels: Live and learn: why Drupal is the best choice for university websites

Planet Drupal - Wed, 2016/06/15 - 3:06pm

Drupal web development has many benefits.
Discover why Drupal is cool for university websites,
and see a nice website example by InternetDevels.

Read more

PreviousNext: Ensuring Drupal 8 Block Cache Tags bubble up to the Page

Planet Drupal - Wed, 2016/06/15 - 9:33am

Whilst working on a Drupal 8 project, we found that cache tags for a Block Content entity embedded in the footer weren't bubbling up to the page cache.

Read on to find out how we debugged this and how you can ensure this doesn't happen to you to.


ActiveLAMP: 10 Things Every Jr. Drupal Web Developer Needs to Know

Planet Drupal - Wed, 2016/06/15 - 4:00am

Jonathan provides a list of 10 things that he feels every Jr. Drupal Web Developer needs to know


DrupalCon News: The artist formerly known as Development and Operations

Planet Drupal - Tue, 2016/06/14 - 11:13pm

So, we've all heard of the word DevOps, we've all heard of the word FullStack developer. But what are you really? You might question yourselves every day whether or not you are working in one of those roles. Or do you prefer to call yourselves just an engineer?


Miloš Bovan: Mail sender authentication

Planet Drupal - Tue, 2016/06/14 - 10:00pm
Mail sender authentication

This article is part of the Google Summer of Code blog series.

As mentioned in the previous blog post, the Mailhandler prototype for Drupal 8 has been finished. The prototype has already one of the main features implemented - processing mail messages and creating nodes. However, processed messages could be created by anyone which is not really nice for a module aiming to be used in production. To solve this problem, I've been working on user authentication implementation for almost a week.

The goal was to authenticate a user (sender of an email) before doing any mail processing. The meta issue with its child issues formalizes the requirements.

An obvious way to identify a mail sender is by checking the From field from the mail header. As this field is required to be present in mail headers (RFC 2822) we can assume we will always be able to identify the sender's mail address.
While writing a blog post about building a prototype, I acquainted you with Inmail. This is the module we are going to rely on to process mail messages. Inmail has a nice concept of plugins separated into deliverers, analyzers, and handlers. Deliverers are used to specify where a mail is coming from, analyzers to identify different types of messages and handlers to do some actions with mail messages and analyzer results. Last week, I already added a handler plugin and here I am going to talk about analyzers.

I started implementing an Inmail analyzer plugin and named it MailhandlerAnalyzer. It inherits AnalyzerBase from Inmail and currently has only one method - analyze() which accepts $message (represents a mail message entity) and processor_result (collects outcomes of a single mail processing pass) parameters. To preserve analyzer results, MailhandlerAnalyzerResult is created with $sender, $user and $body properties. The $sender will represent a sender's mail address (obtained from From mail header field), $user is a user entity in the current system and the $body is analyzed message body. After populating those fields in the analyzer, the job of MailhandlerNode is to authenticate and authorize the sender. If the conditions are met (user is validated) the handler will process the message and do the actions (create a node). This gives us a basic level of security.

However, From mail handler field can be faked by a malicious user. To bridge this obstacle, we introduced support for digitally signed emails. By its definition: digital signature is a mathematical scheme for demonstrating the authenticity of digital documents and it provides:

  • Authentication - since the secret (private) key is bound to a specific user, successful signature verification will show the identity of the sender
  • Integrity - it guarantees the message was not changed during transmission. Any change of the message content after signing it invalidates the signature
  • Non-repudiation - a user can not deny sending and signing the message

Handling digital signature is not supported in PHP by default and we had to find the tools to do it. We decided to use GnuPG implementation of the OpenPGP (Pretty Good Privacy) standard defined by RFC 4880 and gnupg PHP extension. If you are not familiar with the concept of digital signature I would recommend you looking into this ~2 minutes read.

As a starting point, we have to add mailhandler_gpg_key field to store GPG Key for each user. I wanted to preserve public_key and fingerprint properties for each key and decided to go with custom field type. documentation provides a nice explanation how to create a custom field type, corresponding widgets and formatters in Drupal 8.

Mailhandler GPG Key field

The next thing in our PGP journey is to extend analyzer and handlers to deal with signed messages. Usually, when handling emails, you will have to deal with regular expressions a lot. This case is not an exception. A new method called isSigned() is added to MailhandlerAnalyzer which analyzes the message and returns a boolean value. While we are dealing with messages at the low level, isSigned() populates the context data in case of signed messages. Context consists of:

  • PGP Type - the signed message could be inline-signed (clear-text signature) or as nowadays standard PGP/MIME.
  • Signed text - extracted the actual body without PGP signature
  • Signature - PGP signature

Populating the general result properties of the analyzer result instance (In case of signed messages MailhandlerAnalyzerResultSigned), the analyzer finishes its job. At this point, we can analyze the signed message and be sure if we are dealing with signed or unsigned mail messages.

Next, we have to adapt our handler to support signed messages too. That looks easy, as all the hard work is completed by the analyzer. The only thing we have to do is to verify the signature. We do that by getting the signed text and signature from the analyzer result and pass them to gnupg_verify() function. If the signature is valid and the corresponding user's GPG key is not disabled, revoked or expired we will continue the handling process. One last step to check before creating a node is to assert the user is authorized for that action.

To summarize, implementing support for digitally signed emails certainly provides an acceptable level of security for Mailhandler module. Keep in mind, that you will need to have GnuPG PHP extension enabled on your server to get GPG support. In either way, you will benefit from Mailhandler's default authentication system. The interesting thing about last week is that authentication support produced more than 1,2k new lines of code in the Github pull request

Next week, I am going to work on footer detection in a mail message. This will allow us to remove any unnecessary and unintended content from a node body. To support all those features, most of the work will be done in the analyzer. The mid-term evaluation period starts in less than a week which means the next week will be used to do preparation for it as well.

Over and out.



Milos Tue, 06/14/2016 - 22:00 Tags Google Summer of Code Drupal Open source Drupal Planet Add new comment

The Jibe: Applying BEM inspired classes to your Drupal 8 theme

Planet Drupal - Tue, 2016/06/14 - 8:18pm
Applying BEM inspired classes to your Drupal 8 theme Leah Wagner June 14, 2016 11:18am

NEWMEDIA: PCI Compliance & Drupal Commerce: Which Payment Gateway Should I Choose?

Planet Drupal - Tue, 2016/06/14 - 3:18pm
PCI Compliance & Drupal Commerce: Which Payment Gateway Should I Choose? When version 3.0 of the Payment Card Industry Data Security Standard (PCI-DSS) became mandatory in 2015, many eCommerce merchants were ill prepared to meet the more stringent security requirements with the existing modules available for Ubercart and Drupal Commerce. Thankfully, several of the more popular payment processors on the market rose to the challenge and have provided solutions that significantly reduce this complexity. Better yet, there are several contributed modules with stable releases that leverage these new technologies.
Rick Manelius Tue, 06/14/2016 - 13:18

One of the main driving forces for writing the community supported Drupal PCI Compliance White Paper was to help developers and merchants to make smart choices that balance functionality with security. At the time, there were dozens of payment gateway modules available and knowing what risks were involved with each was no easy task. Ultimately, many of them posed a significant risk to the merchant because they were requiring Drupal to temporarily store and transmit card data.

For those wishing to better understand these nuances, I highly recommend reading the white paper because you need to be able to defend your choices, especially if you’re trying to pass an audit or have to deal with the fallout of a data breach. That said, if I do nothing else but help you pick a sane default, I’ll rest better at night.

My (Current) Recommendations

Historically, Hosted Payment Pages (HPPs) were the preferred solution because they fully offload the entry of the card to a service like Paypal, SIM, or Recurly. This greatly reduces the number of potential attack vectors (thereby increasing security) and is the easiest way to get to a PCI SAQ A status (thereby reducing your costs to obtain and maintain compliance). From a security perspective, HPP are always a good choice. The challenge has always been to convince clients to opt for this because they lose control of the customer experience when customers are redirected to an external site.

Fortunately, for those who want the best of both worlds, there is the inline iframe option. The beauty here is that the customer is kept on the website the entire time and (usually) unaware that the credit card entry is being submitted through the form within the iframe loaded directly from the payment gateway itself. Unfortunately, throughout much of 2014 and 2015, only one module provided this option (Hosted PCI). While I originally recommended this option, the setup and ongoing fees were prohibitive and it generally took several days to get an account provisioned.

Since that time, two major players have created inline options: Commerce Braintree and Commerce Stripe. I highly recommend these two modules because they have extended the checkout inference in a straightforward way and allow users to get either one installed and configured in less than an hour. The only caveat for the Stripe module is site-builders MUST remember to enable the correct rule (the module provides two). If you enable the direct post rule, it still will fall within SAQ A-EP because direct post solutions can be attacked by on-page keyloggers. It’s a subtle but important detail.

Finally, remember that these recommendations are current as of the publishing of this article on June 14, 2016. The PCI-DSS standard will continue to evolve as will the payment gateways that are trying to provide the best solutions for their customers. Still, if you’re looking for two solid solutions to start using immediately, you’ll get a lot of mileage out of the Stripe and Braintree modules.


The Sego Blog: Enhanced Drupal 8 Contact Forms with Contact Storage

Planet Drupal - Tue, 2016/06/14 - 2:51pm
06/14/2016Enhanced Drupal 8 Contact Forms with Contact Storage

Drupal 8’s improvements to contact form management and creation is one of my favorite site building upgrades that has been added to Drupal 8’s core.

We now have the ability to field contact forms in the same familiar way as many other entities and can have multiple form variations living at different urls on the same site.


Arpit Jalan: Third week of Google Summer of Coding

Planet Drupal - Tue, 2016/06/14 - 2:38pm
TL;DR Safe Search detection of the Google Cloud Vision API allows the end users to avoid any explicit content or violence in images to be uploaded on the site. I worked on integrating this feature to the module as a constraint to those image fields which have the “Safe Search” feature enabled.
Let me first give a brief summary about the current status of the module Google Vision. In the earlier weeks, I had implemented the services and wrote tests for the module, which are now committed to the module.Now, coming to the progress of this week.Initially, I implemented the Safe Search detection as a function which worked in the same way as the Label detection.However, my mentors suggested that this feature should rather be a Constraint on the image fields, which would be validated if the feature is enabled for the field. It depends on the user whether to keep safe search on their site or not, and they can implement it any time they want by just enabling/disabling the configuration of the image field. Hence, now it is a user choice, rather than the developer’s choice whether to implement this feature or not.Presently, the code is under review by my mentors whether it needs changes or is ready for commit.Constraints and Validators are wonderful features of Drupal 8. Constraints, as the name goes, are certain restrictions which we pose on the various fields. Validators are used to implement the logic to create the situation under which the constraints are to be applied.This week had a lot of new things stored for me. I had no idea about the constraints and validators when I was asked to implement them at the first place. I spent hours on them, learning about them and seeking guidance from my mentors on the issues I faced. I developed gradually on it, and by the end of the week, I was able to implement them for the safe search detection feature.
Categories: Drupal 8 Event Subscribers - the successor to alter hooks

Planet Drupal - Tue, 2016/06/14 - 2:00pm

In Drupal 7 if you wanted to tweak the functionality of an existing function then an alter hook was your best friend, but in Drupal 8 it's "all change!"

With the introduction of Symphony, your new BFF is an Event Subscriber. Alter hooks still exist, but it is recommended that we all move towards Events to fall in line with Symphony.

If you are interested in the comparison between alter hooks and events then I recommend this article from PreviousNext.


Code Enigma: Doing more with Drush sql-sanitize

Planet Drupal - Tue, 2016/06/14 - 1:38pm
Doing more with Drush sql-sanitize Language English Doing more with Drush sql-sanitize

Support team lead Dan Smith shows us how to anonymise personal data in Drupal using Drush.

Tue, 2016-06-14 12:38By galooph


The sites that we build very often end up containing large amounts of user data, much of which allows individual people to be identified. Not just names, but social media accounts, telephone numbers, addresses, occupation details etc. In the UK, user data comes under the Data Protection Act, particularly personal data, which the Act defines as "data which relate to a living individual who can be identified".

So, your site contains lots of personal data, but you want to give a database dump to a Drupal developer so that she can code some new feature for you. How can you handle this without getting on the wrong side of the Information Commissioner's Office (ICO)? You could manually delete all the personal data before you created the database dump, but then your developer won't have any realistic data to work with. Fortunately, there are ways of sanitising the personal data, a process that the ICO refers to as anonymisation. The ICO has a useful code of practice that is worth reading – Anonymisation: managing data protection risk code of practice.

The Drupal command line tool, Drush, comes with a command to sanitise the users table, drush sql-sanitize. While this is better than nothing, it only sanitises user passwords and email addresses. Obviously, it doesn't know about all of the additional fields storing personal data that you added when you built your site.

Note: Drush sql-sanitize will sanitise data in the current database – you do not want to play with this on a live or production server!

With that caveat out of the way, assume I have a site with profile fields set up for a user to enter a LinkedIn url (field_profile_linkedin_page), a telephone number (field_profile_telephone_number), and a twitter username (field_profile_twitter_handle). How can I tell Drush to sanitise these fields too?

Thankfully, Drush is kind enough to provide a hook, hook_drush_sql_sync_sanitize(), which makes this straightforward. Assuming you’ve got a custom module that you’re using already, my_module, you would add a drush include file, /my_module/, containing:

/** * Implements hook_drush_sql_sync_sanitize. */ function my_module_drush_sql_sync_sanitize($source) { // The query to sanitise field_data_field_profile_linkedin_page $linkedin_page_query = "UPDATE field_data_field_profile_linkedin_page SET field_profile_linkedin_page_value = CONCAT('', FLOOR(100000 + (RAND() * 900000)));";   // The query to sanitise field_revision_field_profile_linkedin_page $linkedin_page_query .= "UPDATE field_revision_field_profile_linkedin_page SET field_profile_linkedin_page_value = CONCAT('', FLOOR(100000 + (RAND() * 900000)));";   drush_sql_register_post_sync_op('sanitise_linkedin_page', dt('Sanitise field_profile_linkedin_page'), $linkedin_page_query);   // The query to sanitise field_data_field_profile_telephone_number $telephone_number_query = "UPDATE field_data_field_profile_telephone_number SET field_profile_telephone_number_value = CONCAT('+44', FLOOR(1000000000 + (RAND() * 100000000)));";   // The query to sanitise field_data_field_profile_telephone_number $telephone_number_query .= "UPDATE field_revision_field_profile_telephone_number SET field_profile_telephone_number_value = CONCAT('+44', FLOOR(1000000000 + (RAND() * 100000000)));";   drush_sql_register_post_sync_op('sanitise_telephone_number', dt('Sanitise field_profile_telephone_number'), $telephone_number_query);   // The query to sanitise field_data_field_profile_twitter_handle $twitter_query = "UPDATE field_data_field_profile_twitter_handle SET field_profile_twitter_handle_value = SUBSTRING(MD5(RAND()) FROM 1 FOR 8);";   // The query to sanitise field_revision_field_profile_twitter_handle $twitter_query .= "UPDATE field_revision_field_profile_twitter_handle SET field_profile_twitter_handle_value = SUBSTRING(MD5(RAND()) FROM 1 FOR 8);";   drush_sql_register_post_sync_op('sanitise_twitter_handle', dt('Sanitise field_profile_twitter_handle'), $twitter_query); }

The hook works by allowing you to specify database queries that will be run as part of the Drush sql-sanitize process.

The first query added is used to sanitise the LinkedIn url:

$linkedin_page_query = "UPDATE field_data_field_profile_linkedin_page SET field_profile_linkedin_page_value = CONCAT('', FLOOR(100000 + (RAND() * 900000)));";

The database table storing the LinkedIn field data is field_data_field_profile_linkedin_page, and the column containing the actual url string is field_profile_linkedin_page_value. The query will step through each entry and replace the url with the output of CONCAT('', FLOOR(100000 + (RAND() * 900000))).

CONCAT is the SQL command to concatenate strings together, RAND returns a random floating point number between 0 and 1, and FLOOR returns the largest integer value not greater than the value it’s passed. Putting that together, the real LinkedIn urls are replaced with ‘’.

LinkedIn seem to use a few different url formats, and this is just the one that I picked as an example.

Don’t forget that Drupal stores revisions of data, so as well as sanitising the field_data_field_profile_linkedin_page table, we need to repeat the query on the field_revision_field_profile_linkedin_page table too. This is easy to overlook!

Now that we have a query built to sanitise both of the LinkedIn tables, we let Drush know about it by calling drush_sql_register_post_sync_op().

drush_sql_register_post_sync_op('sanitise_linkedin_page', dt('Sanitise field_profile_linkedin_page'), $linkedin_page_query);

The first parameter isn’t actually used for anything at the moment. The second parameter is the text that Drush will display when the the sql-sanitize command is run, and the third parameter is the SQL query that you want to run.

Moving on to the telephone number field, we need a new sanitisation query:

$telephone_number_query = "UPDATE field_data_field_profile_telephone_number SET field_profile_telephone_number_value = CONCAT('+44', FLOOR(1000000000 + (RAND() * 100000000)));";

This is very similar to the LinkedIn query above, replacing all user telephone numbers with ‘+44’. Again, don’t forget to do the same on the corresponding revision table before calling drush_sql_register_post_sync_op().

The final example is the twitter username field. This one is a little different as instead of a random number, I’ll generate a random 8 character string. One way to do this is to use the SUBSTRING, MD5 and RAND SQL functions.

$twitter_query = "UPDATE field_data_field_profile_twitter_handle SET field_profile_twitter_handle_value = SUBSTRING(MD5(RAND()) FROM 1 FOR 8);";

This generates an MD5 hash of a random value, which we then take the first 8 characters from. Yet again, don’t forget to do the same thing on the corresponding revision table!

With our hook_drush_sql_sync_sanitize() implementation complete, we can try running it with Drush sql-sanitize. Don’t forget – you do not want to be running this on a production server!

$ drush sql-sanitize   The following post-sync operations will be done on the destination: * Reset passwords and email addresses in users table * Truncate Drupal's sessions table * Sanitize field_profile_linkedin_page * Sanitize field_profile_telephone_number * Sanitize field_profile_twitter_handle   Do you really want to sanitize the current database? (y/n):

All being well, you should see a new item in the bullet list for each call to drush_sql_register_post_sync_op() that you made in your hook.

After answering ‘y’, I checked my database. For the LinkedIn tables, I had entries like:

For the telephone values, I had entries like:

  • +441007009394
  • +441058298812
  • +441070465880

And for the twitter values, I had entries like:

  • 8845fb7e
  • 9af12ccd
  • 43df577c

Not the best twitter usernames in the world, but adequate for testing.

Now that you’ve got a sanitised database, you can export it using Drush sql-dump. Before you do that, though, you should be aware that Drupal’s cache tables in the database can also potentially leak information. To protect against this, you can instruct Drush sql-dump to export just the structure of certain tables, omitting the actual data.

You can specify these structure-only tables directly on the command line, using the --structure-tables-list option (see the sql-dump documentation for more information). Alternatively, you can add a list of tables to the $options['structure-tables'][‘your_ref’] array in your drushrc.php file. That way, you don’t have to type the list each time, just use the --structure-tables-key=your_ref option with sql-dump.

So, with the addition of a small chunk of code, we can generate a completely anonymised database dump very easily. If you keep this in mind during development and add a sanitisation query every time you add a new field which stores personal data, it’s even easier.


Main image by Mike Mozart, released on under the Creative Commons Attribution 2.0 Generic license.

BlogDenial of Service, what you need to know BlogDesign and build a website in a day FAQMy site doesn't load for me, is it down? BlogDrupal Migrate Tricks: Disabling rules before running a migration.

Into my Galaxy: GSoC’ 16: Port Search Configuration module; coding weeek #3

Planet Drupal - Tue, 2016/06/14 - 9:56am

Google Summer of Code (GSoC’ 16) is entering into the mid-Term evaluation stage. I have been working on the porting search configuration module for Drupal for the past three weeks.

Search configuration module helps to configure the search functionality in Drupal. This is really an important feature when it comes to a content management system like Drupal. I am almost mid-way in the port process as indicated in the timeline of Google Summer of Code.

It is really a great feeling to learn the Drupal concepts this summer. I would like to take this opportunity to share with you some key aspects I had to deal with in the past week.

Once a module is installed and later on if some changes are amended, we need not rewrite the Drupal code. Instead, Drupal gives up the option to make use of a hook, function hook_update_N which helps us to write the update needed and the database schema gets updated accordingly. Currently, since my module is just going into its first release after this port process, I need not write an update function. I just have to make this update in connection with the earlier code. The same hook works for both Drupal 7 and 8.

Another feature is the hook_node_insert, this hook is invoked to insert a new node into the database. So, here we are writing into the database a drupal record. In Drupal 7, this insertion was done by the drupal_write_record(). But,in D8, it has been replaced by the merge query and the entity API. The merge queries support the insert and update options to the database.

In connection with the nodes, another hook function is the hook_node_update. This functionality updates the node contents which has been inserted into the Drupal record (database). This takes in an argument, obviously,  the node has to be passed, for which the updating is intended.

The hook_uninstall gets invoked as the name suggests, in the uninstall process of the modules. The hook removes the variable used by the module so as to free the memory. It also modifies the existing tables if required. The D7 version of Drupal used the  variable_del for removing the variables.

For instance,


// Drupal 7 code

This has been replaced by the delete() of the configuration API.



search_config.settings is the default configuration file.

I will post the updates on this port process regularly. Please wait for the future posts.


OpenLucius: Don’t ask what the blockchain can do for you…. Ask what you can do for the blockchain!

Planet Drupal - Tue, 2016/06/14 - 9:50am

The title is the abstract. The article is aimed at current reputable CMS web-based frameworks like Drupal, Wordpress, Joomla, Hippo, Rails, Django, etc.

Why this blog post?

Dries Buytaert creator of Drupal raised a simple, yet extensive question on twitter (‘@Dries’):

“What could the Blockchain mean for a CMS like Drupal? #brainstorm”

Let us analyse this question step by step. And then come to a surprising conclusion: it is much more interesting for Drupal to change the question.


Talha Paracha: GSoC’16 – Pubkey Encrypt – Week 3 Report

Planet Drupal - Tue, 2016/06/14 - 2:00am

The basic idea behind my project Pubkey Encrypt is to encrypt data using users’ login credentials. A tight integration with the Key module is one of the most important parts in my project. So I started the week analyzing that module’s architecture. It deals with administering keys which could be used for the purposes of encryption, authentication etc. Anyone can modify the key handling logic as per the business needs since the module allows for much extensibility via these three plugin systems:


Hook 42: Montreal or Bust! Hook 42 is going to Drupal North!

Planet Drupal - Tue, 2016/06/14 - 12:39am
Monday, June 13, 2016

The fabulous duo of K2 (Kristin Bradham) and Lindsay (Lindsay Gaudinier) are off on another trip to get their Drupal on! After having such a great time meeting up with other Drupalers and listening to ghost stories at DrupalCon in New Orleans, K2 and Lindsay are heading up north to the gorgeous multilingual city of Montreal.

Kicking things off, K2 will present her “Conversational Drupal” session that was a hit at BADCamp and Stanford Drupal Camp. Grab a coffee and bagel, and enjoy the eye-opener session on Friday morning.  This session is aimed for new Drupalers, although not necessarily new web developers.  K2 will give clear and simple explanations of frequently used Drupal terms. This session is great to start off a Drupal Convention because it will familiarize you with Drupal and encourage you to meet a few other attendees.

Later on Friday, Lindsay and K2 will lead a session on Drupal and SEO. Search Engine Optimization (SEO) is vital to websites that want to increase their visibility and get to the top rank on search engines. Navigating the sea of Drupal SEO modules can be daunting when all you want to do is get the basics covered effectively. They will go over SEO terms and terminology, modules and their default configuration, and tips and tricks on how to make your Drupal site rank higher with the search engines.   

But K2 and Lindsay aren’t just there to present, they’re also looking forward to learning from other Drupalers. They look forward to collaborating with friends and peers at Evolving Web, Lingotek, Kafei Interactive, and Digital Echidna. K2 is looking forward to Cathy Theys’ keynote speech: “Thoughtfulness and Drupal”.  Other great sessions K2 is looking forward to attending include: “Embracing Open-source Thinking for Better Sustainability”, “Object Oriented Programming Design Patterns in Drupal 8”, and “One Drupal to Rule Them All” just to name a few.

Lindsay is excited about attending the following sessions: “Speed up your front-end drupal development using partials”, “Planning a real-life D8 migration”, and “Lessons Learned: Drupal 8 Module Porting”.

So why should you go? Be a part of the Drupal community. Let's make Drupal great now and in the future. Music, culture, bagels, smoked-meat, coffee, and poutine?! If you can’t go, Sprints are being held on Thursday and Sunday - you can join and contribute remotely.  Check the Drupal North website for information.

We hope to see you there! Montreal or bust!

Kristin Bradham - K2 Lindsay Gaudinier Topics: Services:

DrupalCon News: Drupal: Faster & Stronger Than Ever

Planet Drupal - Tue, 2016/06/14 - 12:39am

When trying to resolve an issue in Drupal, the most common question you’ll hear is, “Have you cleared the cache?” The question is so ubiquitous that we often forget that caching – and more importantly performance – has been an important part of Drupal for a long time. As Drupal has matured, many sites have started to employ additional performance and scaling techniques: utilizing CDNs for additional caching, making optimizations in the theme layer for faster interaction and automating infrastructure to respond to changing demands.


Drupal @ Penn State: Building conversational interfaces in Drupal

Planet Drupal - Mon, 2016/06/13 - 10:56pm

I know Dreis caused a lot of smiles when he used Amazon Echo and Drupal 8 to be notified about “Awesome Sauce” going on sale. The future is bright and requires increasingly more ways of engaging with technology. But what if you wanted to start to have a conversation without Echo to do it? What if we wanted to progressively enhance the browser experience to include lessons learned from conversational input technologies.


Chapter Three: The Slice Template

Planet Drupal - Mon, 2016/06/13 - 8:17pm

For the past two to three years, we’ve been evolving a flexible design solution for marketing pages. We call it the Slice Template.

What is the Slice Template?

The Slice Template is kind of like a layer cake. It’s  a design structure that enables site authors  to create web pages out of modular, horizontal components that span the width of the browser. Popularized by responsive design, this pattern has become a web standard. That’s because it can support a myriad of content.

Our team started calling these components slices early on. You could call them that too. We can make it our little thing :)


Pantheon Blog: Performing Drupal Content Migrations on Pantheon

Planet Drupal - Mon, 2016/06/13 - 8:11pm
As a developer or site builder, there will come a time when you have a lot of content to import into your Pantheon site—a need that will go beyond Feeds and will perhaps have related content, entity references and the like—that will make importing content a challenge. This path will lead you to Drupal’s Migrate module. In Drupal 8, this module is in core.