Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 31 min 29 sec ago

3C Web Services: Creating custom Contextual links in Drupal 7

Tue, 02/12/2014 - 15:46
How to add your own, custom context links to Drupal Views and Nodes using the Custom Context Links module.
Categories: Elsewhere

NEWMEDIA: Coming Soon to a Hacked Drupal Site Near You: Stolen Credit Card Data

Tue, 02/12/2014 - 04:59
Coming Soon to a Hacked Drupal Site Near You: Stolen Credit Card DataSix weeks ago, the Drupal Security Team disclosed one of the most critical vulnerabilities in the history of the project. Today we're still seeing usage statistics that indicate tens of (if not hundreds of) thousands of Drupal sites are still at risk. Given that approximately 10% of all reported Drupal installations have an eCommerce component enabled, it's only a matter of time before we start seeing reports of stolen credit card data.

I’ve been closely watching the fallout of the SA-CORE-2014-005 Drupal core security advisory, which is sometimes referred to as “Drupageddon” to emphasize the severity of this security issue. If this is the first time you’ve heard of this, then I highly encourage you to read this comprehensive overview before continuing below. My goal is not to rehash what has already been stated in this and the many other recap articles out there. As a member of the Drupal security team and co-author of the Drupal PCI Compliance White Paper, I’m much more interested in the repercussions of SA-CORE-2014-005 on the eCommerce community, which (in my honest opinion) hasn’t been sufficiently addressed.

It’s important to state for the record that it’s not my intention to spread FUD or come off as an alarmist. Had that been the goal, I would have published this article immediately after the disclosure and the numbers I would have had to report at the time would have been purely speculative. Six weeks later, we can have an honest and open discussion about what is left in front of us.

The Good News

The exploit was responsibly disclosed to the Drupal security team rather than keeping it a secret, selling this information to the highest bidder, or leveraging it as a zero-day exploit. Any one of these alternative scenarios would have given the community zero preparation in what could have been a catastrophic attack against every known Drupal site. While clearly not everyone was spared, the damage was significantly reduced (see below).

In terms of preparation, I’m very impressed with Acquia, Pantheon, and, each of which deployed system wide protections that significantly reduced (and in some cases outright eliminated) the vulnerability for any Drupal 7 site hosted within their infrastructure. This was huge win for the community as a whole because large, high visibility websites tend to gravitate towards hosting with these companies and as a result (due to the protection that these services offered for this specific vulnerability) the damage was further mitigated.

For others in the community, there are many anecdotal reports of individuals immediately applying the one line patch on all of the websites they manage. I believe this rapid roll out was in large part due to the quantity of announcements to the community letting them know that something big was about to happen.

The Bad News


  • Not every site was hosted with Acquia, Pantheon, and/or (due to cost, preference, requirements, etc).
  • Not everyone has the ability or capacity to roll out patches within X hours of every security release.
  • Penetration tests across all known Drupal sites began within 7 hours of the vulnerability (see the recap for more details).
  • Anecdotal evidence within the community indicates that backdoor exploits have been added to virtually all sites that were not patched.
  • Hundreds of thousands of Drupal websites are reporting that they are still running an older (and therefore vulnerable) version of Drupal core.
  • Thousands of eCommerce websites are still reporting that they are still running an older (and therefore vulnerable) version of Drupal core.
  • I’ve personally seen two Drupal eCommerce sites that were already hacked by the time I was asked to review them within days of the disclosure.

Anyone exploiting this vulnerability is essentially able to gain admin access to the Drupal application. With admin access, stealing credit card data is a fairly straightforward process for most payment gateway configurations. One of the most obvious attack vectors is to enable the php module in order to drop a keylogger within a custom block on the payment page. Beyond that, there are several other creative ways to access, log, and extract customer information from a hacked Drupal site.

Tempering the Bad News

It’s important to note that the usage numbers are not a 100% accurate representation of what’s out in the wild. Many websites were updated using a hotfix patch versus upgrading Drupal core to 7.32, which results in an underestimation of the percentage of sites that are protected. However this is countered by the fact that not all Drupal sites report their usage statistics back to Also, there are sites that may simply have an eCommerce module enabled, but they are not setup to the point where they can accept payment.

Here are some other factors that may reduce the damage to the Drupal eCommerce community:

  • Not all sites containing a backdoor haven’t been exploited further in any obvious way. This means that merchants still have time to cleanup the mess.
  • Not all payment solutions are easy to attack. If a website is configured to use a hosted payment page, one has to either swap out the payment gateway completely or create a man in the middle attack. Both of these attacks are more likely to get caught quickly instead of going undetected for days/weeks/months.
  • Not all sites are large enough to make the headlines. A breached website that only manages a couple transactions a month will still get caught, but will not make the front page of any major tech news site. However, the merchant itself will have to deal with the fallout (including fines and the cost of a forensic analysis of the breach).

While this does reduce the overall pain caused by this vulnerability, we cannot ignore the reality that it’s only a matter of time before at least one Drupal website (and possibly many more) will report that they had credit card numbers stolen. And when this happens, it will be a black eye for the community regardless of how many of the 100,000+ other eCommerce sites were protected. All it will take is one significant breach and merchants evaluating Drupal against alternatives may think twice due to a perception that it’s not as secure (regardless of whether or not that determination is true or not).

The Silver Lining(s)

What’s done is done and it won’t do the community any good to dwell on the past. Rather, we should focus on the positive as well as what we can do in the future to make the most out of this experience. I know is easier said than done because there are segments of the community that are still feeling the sting. That said, here’s my list of silver linings to this experience:

  • This vulnerability is now fixed and all future Drupal installations will no longer be subject to this exact attack. This is one of the many benefits of open source software—we all reap the benefits from code contributions from the community.
  • This vulnerability was so severe that it has sparked many conversations within the community on how to further harden Drupal and even roll out critical patches automatically. While this attention may wane, the fact is that this will have a permanent impact in how much importance we place on security as a community.
  • For being a volunteer organization, I would argue that the Drupal security team handled the situation as best as it could. The exploit could have been leaked, the disclosure botched, etc. While there are areas that can be improved moving forward, it was a privilege to work with the other members of the team to mitigate the damage as much as possible.
  • It’s possible (although highly improbable) that we may not see any reports of credit card data stolen as a direct result of this vulnerability. Only time will tell…

My final advice to anyone building, maintaining, or operating a Drupal eCommerce site: read the Drupal PCI Compliance White Paper (to learn more about ways to reduce risk) as well as read this article by Greg Knaddison to learn what to do in case you ever discover that a Drupal site’s been hacked.

Categories: Elsewhere

PreviousNext: The DrupalCI results component

Tue, 02/12/2014 - 02:35

The DrupalCI initiative is geared towards developing tools for the next generation of testing on In the following video I will demonstrate the "Results" component responsible for providing build feedback.

Categories: Elsewhere

Pivots recommendations: Recommender API for Drupal: 2014 Relaunch

Mon, 01/12/2014 - 22:52

I am pleased to announce the release of Recommender API 7.x-6.x for Drupal, whose goal is to enable content recommendations on any Drupal site in order to boost site engagement and increase revenue. The new release is relatively stable and many of its helper modules have already supported it (see the full list here).

According to my survey last year, most sites that were using or planned to use Recommender API were small- to medium-sized. Their priorities were: 1) ease-of-use, 2) security, and 3) good recommendations. The new release is the answer to the calls. A few features to emphasize here:

  1. RecAPI runs out-of-the-box if you use its PHP recommendation engine for small site. As your site grows, you can choose to use the more powerful and more complex Java recommendation engine.
  2. RecAPI fully integrates with Views and EntityAPI so you can customize easily.
  3. RecAPI now has better documentation and an example module to teach you how to write helper modules for your particular needs.

For the rest of this article, I'll show you how to set up and use the Browsing History Recommender module, which uses RecAPI to provides two types of content recommendations based on users' browsing history: "users who viewed this also viewed..." and "personalized recommendations".

Read more
Categories: Elsewhere

Mediacurrent: Major Sports League Moves to Drupal

Mon, 01/12/2014 - 22:27

Another major sports league has joined the NBA, Major League Soccer, NASCAR and others on Drupal with the launch of a platform that will power each of its team sites.

Categories: Elsewhere

Evolving Web: Required Alt Text for Images in Drupal

Mon, 01/12/2014 - 21:17

Drupal 7 gives us the option to include an 'alt text' for each image field. The alt text is used by screen readers or when the image file isn't available. For some organizations with lots of authors, it's hard to get everyone actually using this alt text field. So, sometimes you want to make it required.

read more
Categories: Elsewhere

Achieve Internet Blog: Learning from Philae

Mon, 01/12/2014 - 20:43
How to Plan, Execute & Succeed in Your Drupal Development Projects

Categories: Elsewhere

cs_shadow: Google Code-In 2014 starts now

Mon, 01/12/2014 - 19:47

Google Code-In (GCI) just started. For those of you who are not aware of this program, its a contest where students (ages 13-17) work on tasks for Drupal (and other open source open source organizations).

In case you want to get involved with GCI, join #drupal-google on Freenode and we'll help you out after that. If you're a high school student of age 13-17, lots of interesting tasks await you at Drupal ( If you want to sign up as a mentor, register at and request Mentor role from Drupal.

Post from Google kicking off GCI 2014 @ Original post by Matthew Lechleider (Slurpee) on gdo:

Tags: Drupal PlanetGoogle Code-In
Categories: Elsewhere

Code Karate: Drupal Shared Hosting: Deciding if shared hosting is right for your Drupal site

Mon, 01/12/2014 - 19:36

Over the summer I was able to attend three different Drupal Camps (Drupal Corn Camp, Twin Cities

Categories: Elsewhere

Blue Drop Awards: Sponsorship Packages & Early Bird Discount for 2015 Blue Drop Awards

Mon, 01/12/2014 - 17:24

Click to enlarge image

As we’re coming to the end of another year, the Blue Drop Awards has set their "sites" on 2015. We’re extremely excited about the direction of the project but we believe, with your help, the Blue Drop Awards can be bigger and better. 

This past year we’ve received nearly 60,000 visitors to the Blue Drop Awards website which represents a 28% increase over 2013 and a 46% increase over 2012. For the coming year, we’re aiming to receive over 100,000 visitors to the Blue Drop Awards. 

Over the last few weeks, we’ve been working to determine the best possible sponsorship packages for 2015. While you may sign up for a sponsorship package at any time, we’re offering a 20% discount for all 2015 sponsors who sign up before 12pm CST on January 23, 2015.

I’ll take a moment to highlight some of the changes; for a detailed decription, check out our Sponsorship page. For 2015 we have four different types of sponsorship packages. 

The Freelance - $500:

  • At $500 this package is meant for freelancers who are one to two man shops. The ultimate value here is that your brand will be in front of 100,000 people in 2015. We will display your logo in the right side bar on every page on the website. After 2015, the website is archived, but still accessible. Even today, still receives a significant amount of traffic everyday meaning continued exposure for a one-time $500 investment. You’ll also be recognized as a sponsor at the awards presentation at Drupalcon LA. 


Silver - $2,000:

  • One step up from Freelance. This package is specifically meant for emerging companies. In addition to having your logo displayed on every page of the 2015 Blue Drop Awards website, we have added some additional advertising at Drupalcon LA. Your logo and booth number will be displayed at the Blue Drop Awards booth. Additionally, we will link to your website within the winners announcement email blast to provide additional traffic opportunities.


Gold - $3,000:

  • In addition to having your logo on the right sidebar of the Blue Drop Awards’ website, you will also have your own branded and customizable landing page complete with a contact form with the gold package. Your company will have the ability to log into the Blue Drop Awards website to edit your page. We will include your logo on the 2015 Blue Drop Awards t-shirts and on the winner awards. 


Platinum - $3,500:

  • The Platinum package is for companies who want to take full advantage of the lead generation opportunities available through the Blue Drop Awards. As with all packages, your logo will be included on all webpages. You will have your own customizable landing page, but in addition to having your logo, contact form and a description of the company, you will also be able to advertise downloadable content and current job openings. When someone downloads your content, we will notify you and give you their contact information. For a direct marketing approach, we’ll send out a sponsored email blast to the Blue Drop Awards subscriber list. To top it off, you will also be mentioned in tweets, blogs, case studies, and more. 


To see the full details on the Blue Drop Awards’ sponsorship package, please view the full pricing sheet below. Remember, you have until 12pm CST on 1/23/15 to lock in for the early-bird discount rate for the 2015 sponsorships. 

Not sure about which package to choose? Contact me at

Categories: Elsewhere

Appnovation Technologies: Speeding up manual image cropping

Mon, 01/12/2014 - 17:14

Images are an important part of any website and for some media companies they are the most important part. Sites need to take big images and display them in different sizes throughout the site.

var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Categories: Elsewhere

Dries Buytaert: Business model innovation beats technical innovation

Mon, 01/12/2014 - 16:33
Topic: DrupalBusinessOpinionStartup lessons

Business model innovation is usually more powerful than technical innovation; it is more disruptive and harder to copy than technical innovation. And yet, so many companies are focused on technical innovation to compete.

Consider Airbnb. What makes them so successful is not a technical advantage, but a business model advantage that provides them near-zero marginal cost. For a traditional hotel chain to increase its capacity, it needs to build more physical space at significant cost. Instead of shouldering that setup cost, Airbnb can add another room to its inventory at almost no cost by enabling people to share their existing houses. That is a business model innovation. Furthermore, it is extremely difficult for the traditional hotel chain to switch its business model to match Airbnb's.

The same is true in Open Source software. While it is true that Open Source often produces technically superior software, its real power may be its business model innovation: co-creation. Open Source software like Drupal or Linux is a co-created product; thousands of contributors build and enhance Drupal and everyone benefits from that. A large Open Source community produces vastly more software than a proprietary competitor, and shares in the production and go-to-market costs. It disrupts proprietary software companies where the roles of production and consumption are discrete and the production and go-to-market costs are high. While established companies can copy key technical innovations, it is extremely difficult to switch a proprietary business model to an Open Source business model. It affects how they build their software, how they monetize the software, how they sell and market their software, their cost structure, and more. Proprietary software companies will lose against thriving Open Source communities. I don't see how companies like HP, Oracle and SAP could change their business model while living quarter to quarter in the public markets; changing their business model would take many years and could disrupt their revenues.

Take Amazon Web Services (AWS), one of the most disruptive developments in the IT world the past decade. While AWS' offerings are rich and often ahead of the competition, the biggest reason for the company's success is its business model. Amazon not only offers consumption-based pricing ('pay as you consume' vs 'pay as you configure'), it's also comfortable operating a low-margin business. Almost 10 years after AWS launched, at a time that vast amounts of computing are moving into the cloud, HP, Oracle and SAP still don't have competitive cloud businesses. While each of these companies could easily close technical gaps, they have been unable to disrupt their existing business models.

If you're in a startup, innovating on a business model is easier than if you're in a large company. In fact, an innovative business model is the best weapon you have against large incumbents. Technical innovation may give you a 6 to 18 month competitive advantage, but the advantage from business model innovation can be many years. Too many startups focus on building or acquiring innovative or proprietary technology in order to win in the market. While there is usually some technical innovation around the edges, it is business model innovation that makes a successful, long-standing organization -- it tends to be a lot harder to copy than technical innovation.

Categories: Elsewhere

Code Enigma: Git Hooks for happy Drupal developers - (post-merge)

Mon, 01/12/2014 - 10:50
A practical use of the post-merge git hook for distributed teams.
Categories: Elsewhere

Drupal core announcements: No Drupal 6 or Drupal 7 core release on Wednesday, December 3

Mon, 01/12/2014 - 06:17

The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, the last bug fix release was a month ago, and there haven't been enough changes to the development version since then to warrant a new release.

Upcoming release windows include:

  • Wednesday, December 17 (security release window)
  • Wednesday, January 7 (bug fix 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: Elsewhere

Metal Toad: Drupal 8 Migrations, part 2: Migrating users from a Drupal 7 site

Sun, 30/11/2014 - 23:22
Drupal 8 Migrations, part 2: Migrating users from a Drupal 7 site November 30th, 2014 Keith Dechant

In this article, we will be building a custom migration which will import users from a Drupal 7 site into a Drupal 8 site. The migration will include the standard user profile fields like username and email address, plus a few custom fields added to the user profile.

The Drupal 8 Migration system is very flexible and can be used to migrate many types of data. For an overview of its capabilities and architecture, see Part 1 of this series.

Try this at home!

If you want to try this code yourself, you will need to set up the following:

A clean install of Drupal 7, with the following customizations:

In Admin -> Configuration -> People -> Account Settings -> Manage Fields, add the following fields:

  • "First Name" - Text
  • "Last Name" - Text
  • "Biography" - Long text (summary is not necessary)
  • The default widget and settings are OK for all fields

Once the field configuration is complete, you will need to create a few users so you have some data to migrate.

A clean install of Drupal 8, with the following:

In Admin -> Configuration -> People -> Account Settings -> Manage Fields, add the following fields:

  • "First Name" - Text (plain)
  • "Last Name" - Text (plain)
  • "Biography" - Text (formatted, long)
  • The default widgets and settings are OK for all fields
Create the custom migration module

Migrations are contained within Drupal 8 modules. All migration modules depend on the core "Migrate" module, which provides the migration framework. In addition, for our custom migration here, we are depending on the core "Migrate Drupal" module (which provides Drupal 6 to Drupal 8 migrations) for some base classes.

To begin, we will create our own custom module called "migrate_custom" and add the following information to the file "":

name: Custom Migration description: Custom migration module for migrating data from a Drupal 7 site. package: Migrations type: module core: 8.x dependencies: - migrate - migrate_drupal The migration definition

For our migration, we need to create a YAML file containing the source, destination, and field mappings (called "process").

Source and destination

These configuration parameters inform the Migrate module how to get the data and where to save it. In our example, "source" will refer to a custom plugin we define, and "destination" will refer to the built-in "entity:user" plugin defined by the core Migrate module.

To start our migration definition, create a new file within your module, in the location {module root}/config/install/migrate.migration.custom_user.yml with the following contents:

id: custom_user source: plugin: custom_user destination: plugin: entity:user process: # Field mappings and transformations will go here. We will get to this in a minute. Creating the source plugin

Our definition above will request data from a source plugin called "custom_user". (Note that this name does not need to be the same as the name of the migration itself.) So, we need to create a new PHP class to contain the source definition.

Create a new file with the path {module root}/src/Plugin/migrate/source/User.php with the following contents:

<?php /** * @file * Contains \Drupal\migrate_custom\Plugin\migrate\source\User. */   namespace Drupal\migrate_custom\Plugin\migrate\source;   use Drupal\migrate\Plugin\SourceEntityInterface; use Drupal\migrate\Row; use Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase;   /** * Extract users from Drupal 7 database. * * @MigrateSource( * id = "custom_user" * ) */ class User extends DrupalSqlBase implements SourceEntityInterface {   /** * {@inheritdoc} */ public function query() { return $this->select('users', 'u') ->fields('u', array_keys($this->baseFields())) ->condition('uid', 0, '>'); }   /** * {@inheritdoc} */ public function fields() { $fields = $this->baseFields(); $fields['first_name'] = $this->t('First Name'); $fields['last_name'] = $this->t('Last Name'); $fields['biography'] = $this->t('Biography'); return $fields; }   /** * {@inheritdoc} */ public function prepareRow(Row $row) { $uid = $row->getSourceProperty('uid');   // first_name $result = $this->getDatabase()->query(' SELECT fld.field_first_name_value FROM {field_data_field_first_name} fld WHERE fld.entity_id = :uid ', array(':uid' => $uid)); foreach ($result as $record) { $row->setSourceProperty('first_name', $record->field_first_name_value ); }   // last_name $result = $this->getDatabase()->query(' SELECT fld.field_last_name_value FROM {field_data_field_last_name} fld WHERE fld.entity_id = :uid ', array(':uid' => $uid)); foreach ($result as $record) { $row->setSourceProperty('last_name', $record->field_last_name_value ); }   // biography $result = $this->getDatabase()->query(' SELECT fld.field_biography_value, fld.field_biography_format FROM {field_data_field_biography} fld WHERE fld.entity_id = :uid ', array(':uid' => $uid)); foreach ($result as $record) { $row->setSourceProperty('biography_value', $record->field_biography_value ); $row->setSourceProperty('biography_format', $record->field_biography_format ); }   return parent::prepareRow($row); }   /** * {@inheritdoc} */ public function getIds() { return array( 'uid' => array( 'type' => 'integer', 'alias' => 'u', ), ); }   /** * Returns the user base fields to be migrated. * * @return array * Associative array having field name as key and description as value. */ protected function baseFields() { $fields = array( 'uid' => $this->t('User ID'), 'name' => $this->t('Username'), 'pass' => $this->t('Password'), 'mail' => $this->t('Email address'), 'signature' => $this->t('Signature'), 'signature_format' => $this->t('Signature format'), 'created' => $this->t('Registered timestamp'), 'access' => $this->t('Last access timestamp'), 'login' => $this->t('Last login timestamp'), 'status' => $this->t('Status'), 'timezone' => $this->t('Timezone'), 'language' => $this->t('Language'), 'picture' => $this->t('Picture'), 'init' => $this->t('Init'), ); return $fields;   }   /** * {@inheritdoc} */ public function bundleMigrationRequired() { return FALSE; }   /** * {@inheritdoc} */ public function entityTypeId() { return 'user'; }   } ?>

Pay attention to the docblock immediately preceding the class definition. The lines

* @MigrateSource( * id = "custom_user" * )

set the ID of the plugin. This ID must match the ID we used in the migration definition above. Failure to keep these the same will result in a "source plugin not found" error.

Also noteworthy here are a few required methods:

query() defines the basic query used to retrieve data from Drupal 7's `users` table.

prepareRow() will be called once for each row, at the beginning of processing. Here, we are using it to load the related data from the field tables (first name, last name, and biography). Any property we create using $row->setSourceProperty() will be available in our "process" step. Notice that the biography is slightly different from the other fields, because it is a formatted text field. In addition to the contents, its field table also contains a formatting setting, which we want to import.

baseFields() contains an array of the basic fields within the `users` table. These are used by query() and also are used by the Migrate Upgrade contrib module to describe the fields. The field descriptions are not used by the Drush "migrate-manifest" command.

The destination plugin

The destination: setting in custom_user.yml informs the Migrate module where to store your data. In our case, we are using the "entity:user" plugin, which is built in to the core Migrate module. For importing other content, there are several other built-in destination plugins, such as "entity:node", "entity:user_role", "entity:taxonomy_term", "url_alias", and more. For the complete list, inspect the files in your Drupal 8 site at core/modules/migrate/src/Plugin/migrate/destination.

You can define your own destination plugin if you require, but the built-in ones are sufficient to handle the most common Drupal content.

Process plugins and field mapping

The "process" section contains instructions to map fields from the source to the destination. It also allows for many different types of transformations, such as replacing values, providing a default value, or de-duplicating machine names.

Back in our custom_user.yml file, we now add our process settings:

id: custom_user source: plugin: custom_user destination: plugin: entity:user process: uid: uid name: name pass: pass mail: mail status: status created: created changed: changed access: access login: login timezone: timezone langcode: language preferred_langcode: language preferred_admin_langcode: language init: init field_first_name: first_name field_last_name: last_name 'field_biography/value': biography_value 'field_biography/format': plugin: static_map bypass: true source: biography_format map: 1: plain_text 2: basic_html 3: full_html 4: full_html

The simplest process mappings take the form of destination_field: source_field. The source field can be anything your source plugin defines. The destination fields must match the fields available in the destination plugin.

In our example, most of the fields in the source match fields of the same name in the destination. A few fields have been renamed from Drupal 7 to Drupal 8, for example "language" is now "langcode". The process field mappings reflect this.

The Biography field is a special case here. It contains both a value and a format. So, we need to supply values for both of these. Also, the "field_biography_format" field in Drupal 7 contains integers, where in Drupal 8 it contains the machine names of the formats. To convert the old values to the new, we are using the "static_map" process plugin.

If specified in the process field mappings, the UID field will cause migrate to preserve the UIDs in the imported data. This may cause migrate to overwrite existing users. It should be used with care.

The core Migrate module includes several useful process plugins which are not covered here. See the official documentation at for a complete list. You can also write your own process plugins if your data requires custom processing. Any custom process plugins can be saved in the directory modules/{module name}/src/Plugin/migrate/process.

Uninstall hook

While developing a migration module, you will often need to make changes to your migration definitions. Because these are configuration entities, you will need to reinstall your module for any changes to take effect.

Additionally, since Drupal 8 beta 2, Drupal modules no longer delete their configuration when they are uninstalled. Therefore, you will need to write a quick uninstall hook to handle this.

In the file migrate_custom.module, add the following function:

/** * Implements hook_uninstall(). * * Cleans up config entities installed by this module. */ function migrate_custom_uninstall() { db_query("DELETE FROM {config} WHERE name LIKE 'migrate.migration.custom%'"); drupal_flush_all_caches(); } Running the migration using Drush 7

Now, it's time to install our new module and run the migrations. Use Drush or the Admin -> Extend page to enable the migrate_custom module, along with its dependencies, migrate and migrate_drupal.

Next, we need to create a manifest file. Create a file named manifest.yml (the location is not important) with the following contents:

- custom_user

To run the migration, open a command prompt and run the following command:

drush migrate-manifest manifest.yml --legacy-db-url=mysql://{dbuser}:{dbpass}@localhost/{dbname}

Replace {dbuser}, {dbpass}, and {dbname} with the MySQL username, password, and database name for your Drupal 7 database.

If you prefer, you can try out the Migrate Upgrade module which provides a UI to run migrations.

Log in to your Drupal 8 site, clear the cache, and view the users list. You should see your imported users from the Drupal 7 site.

Next steps

This migration omits a few things for brevity, including user roles and signatures. As an exercise, you could expand the migration to include the "signature" and "signature_format" fields. Migrating the user roles would require a second migration, with its own definition and source plugin.

Categories: Elsewhere

There is a module for that!: Printing debugging info for forms

Sun, 30/11/2014 - 22:23

During development, it's useful to quickly find information about form elements. Quickly is the key word here, and adding a dpm in a hook_form_alter then removing it becomes tedious.

Here's a very simple module to add debug information to the title attribute of all form elements:

Categories: Elsewhere

Liran Tal's Enginx: Drupal Performance Tip – replace views blocks with vanilla blocks

Sat, 29/11/2014 - 19:57
This entry is part 2 of 2 in the series Drupal Performance Tuning for Better Database Utilization

In the spirit of the computer video game Doom and its skill levels, we’ll review a few ways you can improve your Drupal speed performance and optimize for better results and server response time. These tips that we’ll cover may be at times specific to Drupal 6 versions, although you can always learn the best practices from these examples and apply them on your own code base. Doom skill  levels: (easiest first) 1. I’m too young to die 2. Hey, not too rough 3. Hurt me plenty 4. Ultra-violence 5. Nightmare!   This post is rated “I’m too young too die” difficulty level.   When we start out building Drupal websites, we gradually build functionality and a common use case is creating a view, then you might want to create some blocks, very much related to the view, so you create a block view using the Views module. Then you maybe combine it with Panels or Context, it doesn’t really matter, but essentially you’ve been using the UI tools which are for ease of use, and the overhead for that lies in quite a bit of abstraction layer which later may cost in performance. Replacing the quicklinks and help and support blocks that were used in our theme’s sidebar from being a view based block to a simple programmatiaclly created block implementation proved to reduce a sizzling amount of ~200ms to ~2ms of server time spent on doing the same operation. That accounted for about ~200ms of page load time redduction for each page load, as this item was featured in many pages consistently on our theme.

(adsbygoogle = window.adsbygoogle || []).push({});

The post Drupal Performance Tip – replace views blocks with vanilla blocks appeared first on Liran Tal's Enginx.

Categories: Elsewhere

Drupal core announcements: This Month in Drupal Documentation - November 2014

Sat, 29/11/2014 - 05:00

Here's an update from the Documentation Working Group (DocWG) on what has been happening in Drupal Documentation in the last month or so. Sorry... because this is posted in the Core group as well as Documentation, comments are disabled.

If you have comments or suggestions, please see the DocWG home page for how to contact us. Thanks!

Notable Documentation Updates

Work continues to progress on the Drupal 8 Theming Guide, and providing better documentation of the release policies for Drupal 8 and future versions of Drupal has been a topic of much discussion recently. In general, documentation for Drupal 8 continues to get better as more and more people start making use of the current beta version and are ironing out the details.

If you're interested in helping out with documentation now is a great opportunity to install Drupal 8 and walk through the documentation related to various tasks and verify that it's clear, concise and accurate.

There was also a considerable amount of work put into updating various handbook pages for the Chart module, the Charts module, and various other Drupal charting solutions. This demonstrates one of my favorite ways to get involved with documentation. When you're working on a project that requires you to do some research into a module you've never used before take some time to jot down a few notes about what you've learned, or to help improve existing documentation. It doesn't take long to do and if nothing else your future self will probably thank you for the work you did next time you come across this same problem.

See the DocWG home page for how to contact us, if you'd like to be listed here in our next post!

Thanks for contributing!

Since Oct. 28th, 2014 (our previous TMIDD post), 260 contributors have made 1135 total documentation page revisions, including 6 people that made more than 30 edits (Pierre.Vriens, kreynen, tvn, annagaz, peterx, and ashish_nirmohi) -- thanks everyone!

In addition, there were many many commits to Drupal Core and contributed projects that improved documentation -- these are hard to count, because many commits combine code and documentation -- but they are greatly appreciated too!

Documentation Priorities

The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.

If you're new to contributing to documentation, these projects may seem a bit overwhelming -- so why not try out a New contributor task to get started?

Upcoming Events
  • Global Sprint Weekend is coming up soon, and if you haven't done so already now would be a great time to find some other people that are interested in sprinting on documentation issues and make plans to get together.
  • Although we don't have anything specific lined up at the moment DrupalCon Bogotà (Feb. 10-12) and DrupalCon LA (May 11-15) are both coming up soon and there will undoubtably be talk about documentation at both.
  • Got any events you know about that we should add to this list? Let us know!
Report from the Working Group

At our last meeting on Oct. 28th, the Documentation Working Group discussed possible options for curated documentation on and what it would take to make that happen, as well as what the potential downsides might be. In general, we're in favor of the idea but realize that doing so will require putting a lot of thought into making it sustainable. We'll continue to discuss this in future meetings and are open to suggestions. We also discussed options for better handling of SPAM documentation pages, and a somewhat mysterious documentation search block that shows up on a few pages and how to proceed with that.

Right now, figuring out how to best proceed with hook_help() and getting it updated for Drupal 8 are on our radar and likely to be a topic of conversation at our next meeting.

Finally, our next meeting will be December 17th. We normally meet using Google Hangouts; if you'd like to join us, contact Boris (batigolix).

Categories: Elsewhere

Metal Toad: Migrating Content into Drupal 8

Sat, 29/11/2014 - 03:04
Migrating Content into Drupal 8 November 28th, 2014 Keith Dechant

Drupal 8 includes a powerful built-in migration system for importing content into your site. It is designed to handle data from Drupal 6 or 7, and much more. It is built around a plugin-based architecture, which allows importing of data from any external data source if you write your own source plugin.


When Drupal 7 was released, it came with an upgrade script that would convert a Drupal 6 database into a Drupal 7 database. For Drupal 8, the core team decided against this approach, in favor of creating a more flexible migration module.

Also, Drupal 7 has the Migrate and Migrate D2D contrib modules, used for importing data into a Drupal 7 database. This effort has been moved into Core in Drupal 8.

The team developing the Migrate modules maintains a group on For more information about the status of these modules, visit the IMP project on

Migrations in Core

Drupal 8 includes two core modules:

Migrate - A base module for creating your own custom migrations. This module provides the core migration architecture, but does not define any usable migrations itself.

Migrate Drupal, a module containing migration definitions and source plugins for migrating content from Drupal 6 to Drupal 8. This will eventually support Drupal 7 as well.

Other components

The Migrate and Migrate Drupal modules do not currently provide a UI for running migrations. You will need an external component to run migrations.

Drush You can create a migration manifest (a YAML file) and execute it using the "drush migrate-manifest" command. Drush 7 is required.

Note: The previous Drush command, "drush migrate-import", used with the Drupal 7 Migrate module, has been removed from Drupal 8.

Also note: As of Drupal 8 beta 2, the "drush migrate-manifest" command does not work with managed files, because it does not yet have a parameter for specifying the source directory where the files should be copied from.

Migrate Upgrade - A contrib module which provides a user interface for migrations. As of this writing, the module is still under development.

Migrating from Drupal 6

The Migrate Drupal module is being built to help with migrating from Drupal 6/7 to Drupal 8. Its aim is to import many components of Drupal like content types, fields, users, nodes, and more.

Migrate Drupal comes out-of-the-box with many of these migrations already built. It can even query CCK to determine the list of available fields to use when importing field data. To run these built-in migrations, you simply need to define a migration manifest. The following example would import Drupal 6 users and taxonomies:

- d6_user - d6_taxonomy_vocabulary - d6_taxonomy_term

To run the migration, open a command prompt and run the following command:

drush migrate-manifest manifest.yml --legacy-db-url=mysql://{dbuser}:{dbpass}@localhost/{dbname}

Replace {dbuser}, {dbpass}, and {dbname} with the MySQL username, password, and database name for your Drupal 6 database.

Migrating from Drupal 7

The Migrate Drupal module in Drupal 8 beta 3 does not yet include support for migrating from Drupal 7. Developers migrating from Drupal 7 to 8 will need to write their own custom migration scripts or pursue other options.

At the 2014 Pacific Northwest Drupal Summit, several presenters and participants mentioned that the Drupal 7-8 migration path is not expected to be completed by the release of Drupal 8.0.0. It is expected that this will be completed in a future core release.

For an example of writing a custom migration from Drupal 7 to Drupal 8, see the next installment in this series, Migrating Users from Drupal 7.

Categories: Elsewhere

Wunderkraut blog: Ref debug, an alternative for dpm

Fri, 28/11/2014 - 20:34

I looked for a simple debugger to use in the fronted, and discovered PHP-ref.

I like to keep things simple and clean. I like devel when using simple debugging on the frontend (for more advance debugging I am using xdebug), put devel adds a lot of overhead - like many drupal modules it tries to cover a lot of issues, and therefore it adds a lot of things you maybe not need. So I tested some of the debuggers you could use with php in the frontend, and I really like PHP-ref - simple and clean, just the way I liked it. So now I have wrapped it out to a moudle - Ref debug. With it you could do debugging on entities and direct in code as an replacement for devels dpm() - instead you use r(), and to that you could add functions, variables, classes etc. You could check it out over att   
Categories: Elsewhere