Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 43 min 9 sec ago

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

Code Enigma: Better UX in your forms, the easy way

Fri, 28/11/2014 - 12:19
Entity References are cool. Prepopulating them is even cooler. You've seen it already, but if you are not working with Field API, you're on your own... until now, at least.
Categories: Elsewhere

Deeson: Extending EntityDrupalWrapper

Fri, 28/11/2014 - 10:33

We'd all like to be writing better OO code with Drupal 7, wouldn't we?

It's always been a best practice of ours to use the entity_metadata_wrapper() function when programming the additional logic that inevitably comes when constructing complex content types. But a pain point of this is that the code usually ends up in one hook_ implementation or another and any shared code tends to get arranged into functions in the .module file.

In an ideal world, Drupal would have provided us with entity classes that we could extend at the bundle level to allow us to add feature-specific functionality. I had a bit of a eureka moment the other day, when I realised that we’re already quite close to this, and that it's actually quite trivial to extend the EntityDrupalWrapper class provided by entity_metadata_wrapper() with functionality specific to each entity type.

Indeed, as I think about it, I'm wondering if this should be a new best practice?

An overly simple example

Let’s imagine that we have a content type that is tied up with Organic Groups and that we use it as a way of grouping members into different organisations on our site. We’ll call it “company”.

Let’s also imagine that we would like to send an email to each of the members of a company whenever one of them posts a comment.

For the convenience of this example, let's forget that Rules exist for a moment!

Firstly, a quick note about autoloading

Drupal 8 takes advantage of the wonderful PSR-4 autoloading standard so that we no longer have to define includes in our module's .info file. The brilliant X Autoload module provides just the same functionality for Drupal 7. Since we’re going to be writing a lot more classes from now on, I’d recommend using it, especially as what we’re doing supports PHP 5.3 namespaces. My example below assumes that you're using it.

The old way

So you’d probably start with a hook_comment_insert, and in there you’d probably grab the user, load the company that they belong to and start looping.

The problem with this approach is that everything is inside of the hook implementation and if you take it out of the hook implementation, you’ll just be littering the code base with API-like functions. Your modules are soon going to get messy. Additionally, if you need to do something else non-related in hook_comment_insert() things are going to get even more messy.

The new way(?)

What if in your hook_comment_insert, instead you just called a function on an entity wrapper?

$author_wrapper = new UserWrapper($comment->uid); $author_wrapper->emailColleagues([...]);

Then, in my_module/src/EntityWrapper/User/UserWrapper.php (Drupal\my_module\EntityWrapper\User\UserWrapper.php) you’d make your class:

<?php /** * @file * Firm Profile wrapper class. */ namespace Drupal\my_module\EntityWrapper\User; use \EntityDrupalWrapper; use Drupal\my_module\EntityWrapper\Node\CompanyWrapper; /** * Wraps nodes of type firm_profile with additional functionality. */ class UserWrapper extends EntityDrupalWrapper { /** * Wrap a user object. * * @param int|object $data * A uid or user object. */ public function __construct($data) { parent::__construct('user', $data); } /** * Send an email to all colleagues of this user. * * @param mixed $some_args * Whatever is needed here. */ public function emailColleagues($some_args) { foreach ($this->getColleagues() as $colleague) { $colleague->email($some_args); } } /** * Send an email to this user. * * @param mixed $some_args * Whatever is needed here. */ public function email($some_args) { // Call something like drupal_mail() here; } /** * Get a list of colleagues in the same company as this user. * * @return UserWrapper[] * An array UserWrappers. */ public function getColleagues() { $colleagues = array(); foreach ($this->getCompany()->getEmployees() as $employee) { if ($employee->getIdentifier() !== $this->getIdentifier()) { $colleagues[] = $employee; } } return $colleagues; } /** * Get the company for this user. * * Note that we can cleanly wrap relationships between entities. * * @return CompanyWrapper * A company wrapper object. Check it with ->value() if you * need to make sure it has data. */ public function getCompany() { return new CompanyWrapper($this->field_company->raw()); } }

How simple is that?! Look at all those reusable functions that we've placed directly against the relevant class. You’ll call getCompany() all the time and if you add functionality to the CompanyWrapper class then that will be ready to use as well.

I’m quite convinced that my code is going to start looking very different from now on!

Categories: Elsewhere

Flocon de toile | Freelance Drupal: Drupal SA-CORE-2014-005, perspective and lessons

Fri, 28/11/2014 - 10:28

On Wednesday, October 15, 2014, the Drupal Security Team published an highly critical security advisory (reference SA-CORE-2014-005 (CVE-2014-3704)) in regard of a vulnerability discovered in the database abstraction API that allows to automatically sanitize the parameters of an SQL query and, therefore,prevent SQL injection attacks. In short, this vulnerability allows an anonymous attacker to compromise any Drupal 7 site by a SQL injection attack. Let's go back on the chronology of the event and try to learn some lesson from the discovery and the management of this security breach.

Thème Drupal planet
Categories: Elsewhere