This guest blog post is from Drupal Moldova's Association (not affiliated with Drupal Association). Get a glimpse of what is happening in Moldova's community and how you can get involved.

Drupal Moldova Association’s mission is to promote Drupal CMS and Open Source technologies in Moldova, and to grow and sustain the local community by organising Events, Camps, Schools, Drupal meetups and various Drupal and Open Source related trainings, and by establishing partnerships with Companies, the Government, and NGO’s.

Come and share your expertise in Moldova at our events! We're looking for international speakers to speak about Drupal and open source.

Among DMA’s (short for Drupal Moldova Association) numerous commitments, the following are of special importance:

• to gather the community around Drupal and Open Source technologies;

• to train students and professionals who want to learn and work with Drupal;

• to organise events to keep the community engaged and motivated to improve, learn, and share experience;

• to make sure Drupal is accessible to everyone by offering scholarships to those who can't afford our programs;

• to elaborate a well defined program that helps students learn Drupal, acquire enough knowledge to get accepted for internships by IT companies, and be able to build Drupal powered websites;  

• to assist new IT companies in establishing a local office, promote themselves, collaborate with other companies, and connect with the local Drupal community by giving them the opportunity to support our projects.

Over the last 5 years, we have been dedicated to achieving our goals! DMA have organized over 20 projects and events, including Drupal Global Training Days, Drupal Schools, and the regional DrupalCamp -- Moldcamp. Our projects have gathered over 700 local and international participants and speakers, and more than 15 International Companies that have supported us during these years (FFW, Adyax, IP Group, Intellix, Endava and many others).

Moldova is rich in great developers and people driven to take initiative and to grow and place the country on the world map. We are aiming to go beyond our limits and have a bigger impact in the year (‘17-’18), therefore we have created a yearly plan that contains projects similar to those we have done in the past years, as well as new and exciting ones:

• Drupal School (3 step program), starting with Drupal School 8 plus PHP (step 1):  Drupal School is an educational program - split into 2 months, 25 courses of different levels (Beginner, Intermediate, Advanced).Drupal School aims to introduce people to Drupal 8 and PHP, and help them become Drupal professionals;

• Moldcamp 2017: Sep - Oct 2017. A regional DrupalCamp that gathers around 150 Drupal professionals, enthusiasts, beginners and any-Drupal-related-folk in one place for knowledge-sharing, presentations, networking, etc. We will announce the event soon and allow speaker registration. Please follow us and don’t miss out on the opportunity;

• Drupal Global Training Day: Dec 1-2. A one-day workshop that has the purpose of introducing people to Drupal, both code and community.

• Drupal Meetups: These are organized each month and they allow our community to be active and share knowledge.

• Tech Pizza: - Jun, Aug, Oct, Dec. A bi-monthly event, where the ICT community can gather in a casual and an informal environment around a pizza and  soda and discuss the latest IT trends and news. The core of this event is a speaker / invitee from abroad with a domain of expertise;

• Moldova Open Source Conference: March 2018. It is a regional conference for over 200 participants that aims to gather all the Open Source Communities (Wordpress, Laravel, Ruby on Rails, JavaScript, etc.) under one roof, where they will attend sessions that enhance the expertise of existing experts in various Open Source technologies and allow them to mix their technologies into new ideas.

The proposed program “Drupal and Open Source in Moldova 2017 - 2018” is made possible through the support of USAID and the Swedish Government. Thanks to these organizations we can focus on the quality of our projects make sure they happen as planned. Also, we have a very important partnership with Tekwill / Tekwill Academy, which helps us even more in our quests.

We start with School of Drupal 8 plus PHP program, which will be held on 19th of June 2017. So far we have 3 sponsors--IPGroup, Adyax and Intellix--and two trainers.

We, The DMA, believe in pushing the limits! Our long term goal is to build and maintain big an active Open Source community by attracting more local and International participants to our Projects and Events, and continuously improve our sessions. This will make our presence felt in the global Drupal and Open Source communities and markets. Find us on Twitter @drupalmoldova, or on our Facebook page. If you are interested in speaking in Moldova, contact us at info@drupalmoldova.org.

One of the more interesting products to hit the spotlight at this year's Percona Live Open Source Database conference was ProxySQL.

This open source MySQL proxy server has been around for a couple of years now and keeps adding more features. The current release (1.3.6) has the usual features that you would expect from a proxy server, like load balancing and failover support, but ProxySQL also has database specific features like a query cache and query routing.

Tags: acquia drupal planet

GSoC 2017 Week 3 : Creating methods for SocialAuthUserManager and SocialPostManager himanshu-dixit Tue, 06/20/2017 - 17:52

Submit your Site Building Session to DrupalCon Vienna

DrupalCon Vienna will be taking place end of September this year. The site building track is about letting Drupal do the hard work without needing to write code. By assembling the right modules and configurations we can create rich and complex features, without worrying about reinventing the wheel and write complex logic and code.

Josef Dabernig Tue, 06/20/2017 - 14:19

Sounds great, right? As excited as I am for helping to put together the program for the site building track, I would like to share a few session ideas, which might be worth submitting. If you have never submitted a session for DrupalCon, this might be a good opportunity to give it a try:  

Showcases will let others learn from how you built your last exciting Drupal 8 project. Talking points can include which approaches you took, lessons you learnt from working on the project, and what fellow site builders should know when tackling similar problems.

Module presentations are a great way to explain and highlight best practice solutions. How do you choose from the various competing site building tools available to address problems like layout management, workflows or content modelling? Are the same solutions from Drupal 7 still valid, or what are the latest experiences you've had whilst building Drupal 8 sites and how could this be further developed and enhanced in the future?

Process descriptions are welcome to help us figure out how site building can best fill the gap between end users, content editors, developers, UX designers and anyone else involved in Drupal web projects. How do you involve your customers and explain site building to them? What does a developer need from a site builder and where do those practices blend? 

Outside perspectives are also welcomed to learn how problems can be solved the site builder’s way in related web technologies.

Together with Hernâni Borges de Freitas and Dustin Boeger, we are looking forward to reviewing your exciting and interesting applications. If you aren’t sure what to present, feel free to get in touch via the contact form on my Drupal.org profile or Twitter.

Thanks for submitting your session by June 28, 23:59 CEST.

Define a schema for any bespoke configuration, it's not too hard. It's needed to make it translatable, but Drupal 8 will also validate your config against it so it's still handy on non-translatable sites. As a schema ensures your configuration is valid, your code, or Drupal itself, can trip up without one. Set up a schema and you avoid those problems, and get robust validation for free. Hopefully my example YAML shows how it can be quite simple to do.

Around two years ago, when the launch of Drupal 8 was just around the corner and the main topic of concern was the status of the issue queue, the Drupal community slowly started murmuring about a topic outside of technical solutions and patches. As a result, a brand new DrupalCon track was introduced - Being Human. Our COO, Zsófi is the Being Human local track chair at DrupalCon Vienna - this is her Call for Papers.

PHP Speakers Wanted For DrupalCon Vienna 2017 On 28th June (23:59 Vienna local time (GMT +2)) session submissions will close for DrupalCon Vienna 2017 and we're looking for more great speakers. After volunteering on the Core Conversation track team last year, I am now helping the PHP track team find and select sessions for this year's European conference. As PHP the foundation for...

Last time, we gathered together DrupalCon Baltimore sessions about Front End. Before that, we explored the area of Site Building, Drupal Showcase, Coding and Development, Project Management and Case Studies. And that was not our last stop. This time, we looked at sessions that were presented in the area of DevOps. 100% Observability by Jason Yee from Datadog In this session, the author broke down the expansive monitoring landscape into 5 categories and provided a framework to help users ensure full coverage. He also touched why these categories are important to users business and shared the… READ MORE

Square's pitch is pretty straightforward: accept payments anywhere, no coding required. They nailed this first through their simple phone based card readers and their slick in-store tablet interface. They also made it easy to process all major credit cards, guaranteeing deposits as soon as the next business day.

They're now rolling out their same great support for merchants online with the steady release of open APIs for eCommerce applications. With our recently released Commerce Square module for Drupal 7 and Drupal 8, you can now pitch Drupal Commerce to existing Square customers in your area.

Thus far we integrate their payment APIs for full checkout and administrative support in Commerce 1.x and 2.x. We're working with Square to integrate new APIs as they become available in pursuit of our vision to enable the turnkey creation of online stores for Square merchants using Drupal Commerce.

Among the module's primary benefits, especially when used in conjunction with Square for retail sales, are:

• You can sell online, and in person, with all of your sales in one place. Integrating your physical and online retail operations will ultimately simplify the management of your business.
• Accept all major cards, (including Apple Pay and Android Pay in-store) and pay one simple rate per tap, dip, or swipe. (Note: Square also offers custom rates for qualifying stores processing over $250k annually.)
• Integration is simple and seamless for Drupal Commerce on both Drupal 7 and Drupal 8. (Look for new features to come into the D8 branch first and be backported, as additional contributed modules may be required to make up for core features that were added in Commerce 2.x.)

Square’s eCommerce API is on the bleeding edge of integration technology, making PCI compliance easy; customer credit card information never touches your website, so you don’t need to worry or complete a single checklist. Each component of the payment method form is an embedded iframe hosted on Square's server and returns a payment token identifier used to capture payment. We actually designed the Commerce 2.x checkout form to treat these types of payment methods as first class citizens, so expect the integration to just work.

Sign up for Square and get free processing on your first $5,000 in sales.

As part of our module launch effort, Square has teamed up with us to offer free processing on your first $5,000 in sales. If you or one of your customers are interested in learning more, review the offer details here and hit us up in the issue queue if you run into any problems!

Reservoir is an experimental Drupal distribution that is an exceptional starting point for any decoupled Drupal implementation. It is also designed to on-board developers of all backgrounds: a decoupled Drupal distribution and optimal back end for every developer.

Tags: acquia drupal planet

Start:  2017-06-21 12:00 America/New_York Organizers:  xjm Event type:  Online meeting (eg. IRC meeting)

The monthly security release window for Drupal 8 and 7 core will take place on Wednesday, June 21.

This does not mean that a Drupal core security release will necessarily take place on that date for any of the Drupal 8 or 7 branches, only that you should watch for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix or stable feature release on this date. The next window for a Drupal core patch (bug fix) release for all branches is Wednesday, July 05. The next scheduled minor (feature) release for Drupal 8 will be on Wednesday, October 5.

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.

Cómo instalar y configurar Redis en Drupal 8

Voy a explicar cómo instalar y configurar Redis en Drupal 8. 

Redis es una base de datos popular basado en key-value.

En el caso de Drupal se usa como sistema de cache para la parte (backend) de gestión de contenidos, donde el sistema de cachea "estático" de las paginas no es suficiente.

Con Redis notaremos rápidamente la fluidez y rapidez con la que se puede gestionar toda la parte que requiere de usuarios autenticados.

1. Instalar Redis:
   

   sudo apt-get install redis-server

   También puedes ver Dockerfile

2. Instalar soporte de Redis para PHP:
   

   sudo apt-get install php7.0-redis
   sudo a2enmod php7.0-redis

   También puedes ver Dockerfile

3. Instalar el modulo redis de Drupal:
   

   composer require drupal/redis

   o

   drush dl redis

4. Configurar redis para Drupal:

En el settings.php o mejor en el drush añadir lo siguiente:

<?php

/**
 * Set redis configuration.
 */
/** @see: https://docs.platform.sh/frameworks/drupal8/redis.html */
if (extension_loaded('redis')) {

  // Set Redis as the default backend for any cache bin not otherwise specified.
  // $settings['cache']['default'] = 'cache.backend.redis';
  $settings['redis.connection']['interface'] = 'PhpRedis'; // Can be "Predis".
  $settings['redis.connection']['host'] = 'redis';
  $settings['redis.connection']['port'] = '6379';
  // $settings['redis.connection']['password'] = "mypassword"; // If you are using passwords, otherwise, omit

  // Apply changes to the container configuration to better leverage Redis.
  // This includes using Redis for the lock and flood control systems, as well
  // as the cache tag checksum. Alternatively, copy the contents of that file
  // to your project-specific services.yml file, modify as appropriate, and
  // remove this line.
  $settings['container_yamls'][] = 'modules/contrib/redis/example.services.yml';

  // Allow the services to work before the Redis module itself is enabled.
  $settings['container_yamls'][] = 'modules/contrib/redis/redis.services.yml';

  // Manually add the classloader path, this is required for the container cache bin definition below
  // and allows to use it without the redis module being enabled.
  $class_loader->addPsr4('Drupal\\redis\\', 'modules/contrib/redis/src');

  // Use redis for container cache.
  // The container cache is used to load the container definition itself, and
  // thus any configuration stored in the container itself is not available
  // yet. These lines force the container cache to use Redis rather than the
  // default SQL cache.
  $settings['bootstrap_container_definition'] = [
    'parameters' => [],
    'services' => [
      'redis.factory' => [
        'class' => 'Drupal\redis\ClientFactory',
      ],
      'cache.backend.redis' => [
        'class' => 'Drupal\redis\Cache\CacheBackendFactory',
        'arguments' => ['@redis.factory', '@cache_tags_provider.container', '@serialization.phpserialize'],
      ],
      'cache.container' => [
        'class' => '\Drupal\redis\Cache\PhpRedis',
        'factory' => ['@cache.backend.redis', 'get'],
        'arguments' => ['container'],
      ],
      'cache_tags_provider.container' => [
        'class' => 'Drupal\redis\Cache\RedisCacheTagsChecksum',
        'arguments' => ['@redis.factory'],
      ],
      'serialization.phpserialize' => [
        'class' => 'Drupal\Component\Serialization\PhpSerialize',
      ],
    ],
  ];

  /** @see: https://pantheon.io/docs/redis/ */
  // Always set the fast backend for bootstrap, discover and config, otherwise
  // this gets lost when redis is enabled.
  $settings['cache']['bins']['bootstrap'] = 'cache.backend.chainedfast';
  $settings['cache']['bins']['discovery'] = 'cache.backend.chainedfast';
  $settings['cache']['bins']['config'] = 'cache.backend.chainedfast';

  /** @see: https://github.com/md-systems/redis */
  // Use for all bins otherwise specified.
  $settings['cache']['default'] = 'cache.backend.redis';

  // Use this to only use it for specific cache bins.
  $settings['cache']['bins']['render'] = 'cache.backend.redis';

  // Use for all queues unless otherwise specified for a specific queue.
  $settings['queue_default'] = 'queue.redis';

  // Or if you want to use reliable queue implementation.
  $settings['queue_default'] = 'queue.redis_reliable';

  // Use this to only use Redis for a specific queue (aggregator_feeds in this case).
  $settings['queue_service_aggregator_feeds'] = 'queue.redis';

  // Or if you want to use reliable queue implementation.
  $settings['queue_service_aggregator_feeds'] = 'queue.redis_reliable';
}

Ver https://gist.github.com/keopx/7d5fe4d7a890c792c43bb79cf56718e0

Una ves hecho esto ir a la pagina de estado (/admin/reports/status) para comprobar que todo esta bien.

NOTA: si veis que cualquier parametrización es mejor, por favor comentadlo. Gracias.

Referencias:

• https://gist.github.com/keopx/7d5fe4d7a890c792c43bb79cf56718e0
• https://docs.platform.sh/frameworks/drupal8/redis.html
• https://pantheon.io/docs/redis/
• https://github.com/md-systems/redis
• https://github.com/keopx/docker-lamp

 

 

keopx Dom, 18/06/2017 - 17:25 Categoria Drupal 8.x Redis Drupal Drupal Planeta Tag Drupal Drupal 8.x Redis php Añadir nuevo comentario

Recently I set out to make a simple instrument for running simpletest tests without having LAMP stack installed on your local environment. I needed this for two reasons:

1. for running tests locally
2. for running tests on CI server

I've decided to use Docker and create monolith container with Drupal and all the LAMP stuff inside and here what I've got: docker-tester.
Read more »

Since the release of Drupal 8 with a standardized way of managing translations, many sites running Drupal 7 are making a switch to Drupal 8. In Drupal 7 there are two ways to translate content:

1. Using the content_translation module. The D7 core way of translating content, where every translation is a separate node.
2. Using the entity_translation module. Maintains one node with a unique nid, while translations take place at the field level.

In this article we will discuss how to migrate content translations created with the content_translation module from Drupal 7 to Drupal 8. You can find our tutorial about migrating translations that use Entity Translation here.

This article would not have been possible without the help of my colleague Dave. ¡Gracias Dave!

The problem

We have a Drupal 7 database containing article nodes, which might have translations in English, Spanish and French. Some of these nodes are language-neutral, i.e. non-translatable. Our target is to migrate the Drupal 7 nodes into a Drupal 8 website, preserving the translations.

Before we start

• Since this is an advanced migration topic, it is assumed you already know the basics of migration. If are new to migrations in Drupal 8, I recommend that you read about migrating basic data to Drupal 8 first.
• If you'd like to run the migrations in this example yourself, see the quick-start documentation in our drupal migration i18n example repository.
• The source website used in this example is Drupal 7.54.
• The destination website used in this example is Drupal 8.3.x. However, an alternative solution for earlier versions is included towards the end of the article.

The module

To write the migrations, we create a module - in our case, migrate_example_i18n. There's nothing special about the module declaration, except for the dependencies:

• migrate_plus and migrate_tools provide various features for defining and executing migrations.
• migrate_source_csv: Will be used for demonstrating migration of translated content from non-Drupal sources in an upcoming article.
• migrate_drupal: This module provides tools for migrating data from older versions of Drupal. It comes with Drupal 8.x core. Since this migration uses a Drupal 7 site as a source for its data, we need the migrate_drupal module.

How do translations work?

Before jumping into writing these migrations, it is important to mention that Drupal 7 and Drupal 8 translations work very differently. Here's the difference in a nutshell:

• Drupal 7: When we translate a node, a new node is created with a different ID. This translated node has a property named tnid, which stores the ID of the original node, linking the two nodes together. For language-neutral or untranslated content, the tnid is set to 0.
• Drupal 8: When we translate a node, no new node is created! The translation is saved in the fields of the original node, but with a different language code.

So just like we do when migrating translated content from Drupal 6 to Drupal 8, we create two migrations:

• The example_dog_base migration will migrate the original content of each node, untranslated.
• The example_dog_i18n migration will migrate only translations and associate them with original content created by example_dog_base.

We group the two migrations using the example_dog migration group to keep things clean and organized. Then we can execute both migrations with drush migrate-import --group=example_dog --update.

Step 1: Base migration

We start with example_dog_base to migrate all base data or non-translations. Described below are some noteworthy parameters:

Source

source:
  plugin: d7_node
  node_type: article
  key: drupal_7_content
  constants:
    uid_root: 1
    node_article: 'article'

• plugin: Since we want to import data from a Drupal installation, we need to set the source plugin to d7_node. The d7_node source plugin is introduced by the migrate_drupal, module and it helps us read nodes from a Drupal 7 database without having to write queries manually. Since Drupal 8.3.x, this plugin supports translations created with the content_translation module. If you are using an older version of Drupal 8, then check the alternative solution provided towards the end of this article.
• node_type: This tells the source plugin that we are interested in just one particular Drupal 7 node type, namely article.
• key: Our Drupal 7 data doesn't come from our main Drupal 8 database - instead it comes from a secondary database connection. We choose a key to identify each such connection and we need to tell the source which such key to use. The keys themselves are defined in the $databases variable in our settings.php or settings.local.php. See the example settings.local.php file to see how it's done.
• constants: We define some hard-coded values under this parameter.
• translations: Notice there is no translations parameter here. The default value (false) tells the source plugin that we're only interested in migrating non-translations, i.e. content in the base language and language-neutral content.

Destination

destination:
  plugin: 'entity:node'

• plugin: Since we want to create node entities in Drupal 8, we specify this as entity:node. That's it.
• translations: Again we do not define the translations parameter while migrating base data. Omitting the parameter tells the destination plugin that we are interested in creating fresh nodes for each record, not translations of existing nodes.

Process

type: constants/node_article
langcode:
  plugin: default_value
  source: language
  default_value: und
uid: constants/uid_root
title: title
body: body
field_one_liner: field_one_liner
sticky: sticky
status: status
promote: promote

This is where we map the old node properties to the new node properties. Most of the properties have been assigned as is, without alteration, however, some noteworthy properties have been discussed below:

• nid: There is no nid parameter here, because we don't care what nid each new node has in Drupal 8. Drupal can just assign a new nid to each node in the normal way.
• type: We specify that we want to create article nodes.
• langcode: The langcode parameter was formerly language in Drupal 7, so we rename it here. Also, if a Drupal 7 node is language-neutral, the language property will have no value. In that case,  we default to und.

This takes care of the base data. If we run this migration with drush migrate-import example_hybrid_base --update, all Drupal 7 nodes which are in base language or are language-neutral will be migrated into Drupal 8.

Step 2: Translation migration

We are halfway through now! All that's missing is migrating translations of the nodes we migrated above. To do this, we create another migration with the ID example_dog_i18n:

source:
  plugin: d7_node
  node_type: article
  translations: true
  # ...
destination:
  plugin: 'entity:node'
  translations: true
process:
  nid:
    plugin: migration
    source: tnid
    migration: example_dog_base
  langcode: language
  # ...
migration_dependencies:
  required:
    - example_dog_base

• source:
  • translations: We set this to true to make the source plugin read only translations.
• destination:
  • translations: We set this to true to make the destination plugin create translations for existing nodes instead of creating fresh new nodes.
• process:
  • nid: In this case, we do care what the Drupal 8 nid is for each node. It has to match the nid for the untranslated version of this content, so that Drupal can add a translation to the correct node. This section uses the migration (migration_lookup) process plugin to figure out the right nid. It tells Drupal to check the previously-executed example_hybrid_base migration for a D6 node that has the same tnid as this D6 node. It will then then reuse the resulting nid here.
  • langcode: We define the language in which the translation should be created.
• migration_dependencies: Since we cannot add translations to nodes that do not yet exist, we tell Drupal that this migration depends on the base migration example_dog_base. That way, the base migration will run before this migration.

That's it! We can run our translation migration with drush migrate-import example_dog_i18n --update and the translations will be imported into Drupal 8. Alternatively, we can use the migration group we defined to run both these migrations at once - the base migration will automatically be executed first and then the i18n migration. Here's how the output should look:

$ drush migrate-import --group=example_dog --update
Processed 7 items (7 created, 0 updated, 0 failed, 0 ignored) - done with 'example_dog_base'
Processed 7 items (7 created, 0 updated, 0 failed, 0 ignored) - done with 'example_dog_i18n'

You can check if everything went alright by clicking the Translate option for any translated node in Drupal 8. If everything went correctly, you should see that the node exists in the original language and has one or more translations.

Article migrated from Drupal 7 to Drupal 8

Alternate Solution for Drupal 8.2.x and Older

The example code for this article works out of the box with Drupal 8.3 or higher. However, it will not work with earlier versions of Drupal 8. For Drupal 8.2 or older, we need to use a custom source plugin (inspired by the d6_node plugin). All we have to do is use the D7NodeContnentTranslation source plugin included in the code for this example, like source: d7_node_content_translation. This custom source plugin adds support for the translations parameter, which in turn makes the migration of content translations work correctly.

Next Steps

• View the code for the migrate_example_i18n project on GitHub.
• Read about migrating entity translations from Drupal 7 to Drupal 8.
• Read about migrating translated content from Drupal 6 to Drupal 8.
• Read about migrating translations from CSV, JSON or XML to Drupal 8.
• New to Drupal 8 migrations? Start with Drupal 8 migration basics.

+ more awesome articles by Evolving Web

Since the release of Drupal 8 with a standardized way of managing translations, many sites running Drupal 7 are making a switch to Drupal 8. In Drupal 7 there are two ways to translate content:

1. Using the content_translation module. The D7 core way of translating content, where every translation is a separate node.
2. Using the entity_translation module. Maintains one node with a unique nid, while translations take place at the field level.

In this article we will discuss how to migrate content translations created with the entity_translation module from Drupal 7 to Drupal 8. You can find our tutorial about migrating translations that use Content Translation here.

This article would not have been possible without the help of my colleague Dave. Merci Dave!

The problem

We have a Drupal 7 database containing article nodes, which might have translations in English, Spanish and French. Some of these nodes are language-neutral, i.e. non-translatable. Our target is to migrate the D7 nodes into a D8 website, preserving the translations.

Before we start

• Since this is an advanced migration topic, it is assumed you already know the basics of migration. If you are new to migrations in Drupal 8, I recommend that you read about migrating basic data to Drupal 8 first.
• This article assumes that you have read our previous article on how to migrate content translations from Drupal 7 to Drupal 8 or have the relevant knowledge.
• To execute the migrations in this example, you can download the drupal migration i18n example repository from GitHub. The module should work without any trouble for a standard Drupal 8 install. See quick-start for more information.
• To see the example migrations in action, you need:
  • A Drupal 8 site.
  • The relevant D7 database, since we are migrating data from a Drupal 6 site.
  • Drush will be required to execute migration commands.

The module

To write the migrations, we create a module - in our case, it has been named migrate_example_i18n. Just like migrating content translations from D7 to D8, we create 2 YML files to define:

• The example_creature_base migration will migrate all base data or non-translations.
  • The source/translations parameter is omitted or set to false.
  • The destination/translations parameter is omitted or set to false.
• The example_creature_i18n migration will migrate all translations.
  • The process/nid is configured to use the migration plugin to lookup the node in the base language.
  • The source/translations parameter is set to true.
  • The destination/translations parameter is to true.
  • The migration_dependencies parameter declares example_creature_base as a dependency.

We group the two migrations using the example_creature migration group to keep things clean and organized. Then we can execute both migrations with drush migrate-import --group=example_creature --update.

How to migrate Entity Translations?

Entity translations! Drupal 7 content translations are supported since Drupal 8.3. At the point of writing this, there is no standard method for migrating entity translations to Drupal 8. In this example, we will migrate D7 nodes translated with the entity_translation module, however, the procedure should be similar for other entity types as well. Before we start, here are some notes about what's so different about entity translations:

• All translations have the same entity_id. So, for a translated node, the entity_translation module will result in only one entry in the node table.
• Translation information, certain metadata and revision information for entities is stored in the entity_translation table.

So if an English node with ID 19 has translations in Spanish and French, the entity_translations table has the following records:

An extract from the entity_translation table. entity_type entity_id revision_id language source uid status translate created changed node 19 1 en   1 1 0 1485800973 1487198982 node 19 1 es en 1 1 0 1485802336 1487199003 node 19 1 fr en 1 1 0 1487185898 1487198969

The above data structure is significantly different from the content translation structure. In fact, Drupal 8 handles translations much like the entity translation module! Hence, to handle entity-translations, we must take the entity_translation table into consideration, which the core d7_node source plugin does not do at the time of writing this article. Hence, we override the d7_node source with a custom source plugin named d7_node_entity_translation.

class D7NodeEntityTranslation

This is where we jump into code! We override certain methods of d7_node source to add support for the entity_translation table.

class D7NodeEntityTranslation extends D7Node {
  // Determines if the node-type being translated supports entity_translation.
  protected function isEntityTranslatable() {}
  // Depending on the "source/translations" parameter, this method alters
  // the migration query to return only translations or non-translations.
  protected function handleTranslations(SelectInterface $query) {}
  // This method has been overridden to ensure that every node's fields are
  // are loaded in the correct language.
  public function prepareRow(Row $row) {}
  // This method is called by the prepareRow() method to load field values
  // for source nodes. We override this method to add support for $language.
  protected function getFieldValues($entity_type, $field, $entity_id, $revision_id = NULL, $language = NULL) {}
  // Since all source nodes have the same "nid", we need to use a
  // combination of "nid:language" to distinguish each source translation.
  public function getIds() {}
}

Here's a quick look at the changes we need to make:

• function getIds() tells the migrate API to use one or more source properties which should be used to uniquely identify source records. When working with entity translations, all translations have the same entity_id, but they have a different language. We override this method to tell Drupal to consider both the entity_id and the language properties to uniquely identify source records. So, the source records are uniquely identified something like 19:en, 19:es, 19:fr instead of using just 19.
• function handleTranslations() is the method which adds support for the translations parameter we use in the source plugin. The translations parameter tells Drupal whether to migrate entities in their base language or to migrate translations. We override this method to:
  • See if the node type being migrated supports entity translations.
  • If the node type supports entity translations, then we INNER JOIN entity_translation and read translation data and some entity metadata, like date of creation, date of updation, etc from that table.
• function prepareRow() as the name suggests, prepares a row of source data before it is passed to the process plugins. At this stage, field data is also attached to the source data. However, it does not load field data in the language specified in the source row. To overcome this problem, we override the getFieldValues() method and make sure it loads the field data in the same language as specified in the source row.

That's it! You should now be able to run the migration with drush migrate-import --group=example_creature --update. The output should look something like this:

$ drush mi --group=example_creature --update
Processed 9 items (9 created, 0 updated, 0 failed, 0 ignored) - done with 'example_creature_base'
Processed 9 items (9 created, 0 updated, 0 failed, 0 ignored) - done with 'example_creature_i18n'

Note: Keep an eye out for Drupal core updates. If the drupal_migrate module adds support for entity translations, migrating entity translations might become much easier.

Next Steps

• View the code for the migrate_example_i18n project on GitHub.
• Read about migrating content translations from Drupal 7 to Drupal 8.
• Read about migrating translated content from Drupal 6 to Drupal 8.
• Read about migrating translations from CSV, JSON or XML to Drupal 8.
• New to Drupal 8 migrations? Start with Drupal 8 migration basics.

+ more awesome articles by Evolving Web

Start:  2017-06-15 (All day) - 2017-06-18 (All day) America/Toronto Event type:  Sprint

Several key contributors to the Migrate Initiative will be at the sprint at DrupalCamp Montreal on Sunday (and to some degree on earlier days as well). Join contributors Adam G-H (phenaproxima), Maxime Turcotte (maxocub) and Dave Vasilevsky (vasi) in person. Initiative coordinator Mike Ryan (mikeryan) is also planning to join remotely on Sunday.

Among the most important Migrate critical issues on the table that are planned to be worked on is auditing for potential ID conflicts before upgrading from older versions. This is the most thorny outstanding issue for the initiative. Use cases and feedback in general is welcome. Further migrate issues are categorized and tracked in the Migrate triage spreadsheet (update regularly). These include handling import of private files, adding back support for incremental migrations, redirecting for obsolete content translations when they are merged in the migration, etc. All of those need helping hands and this is a great time to get experienced with help from the most well versed people in the field.

If you cannot join the sprint this time, your involvement is more than welcome anytime. The migrate team has weekly meetings on every Thursday at alternating meeting times. See https://www.drupal.org/node/2735059#meet for the upcoming meetings.

Two of the biggest retailers in the world are getting together. This morning, Amazon.com, the juggernaut that continues to put massive pressure on brick-and-mortar retailers, announced that it is buying Whole Foods, the popular, high-end organic foods grocer.

Both companies are major stakeholders in the Drupal ecosystem: Amazon made an investment in Acquia in 2014, and much of Acquia’s hosting infrastructure relies on Amazon Web Services. Whole Foods, for its part, has used Drupal for its web presence for at least five years—if not much longer—and holds Acquia as a key partner. Acquia Drupal is a significant part of the Whole Foods DevOps story. (I can just imagine that email from the Whole Foods Accounts Payables department to Acquia: “Send the bill to Amazon.”)

From a presentation at an Acquia event:

So why would Amazon jump out and make this purchase? The answer is complex and multi-faceted.

For Amazon, it's all about the data.

First, Amazon is, at its core, a data company. They use shopping history and patterns to sell us things we need before we even know that we need them. With all the newly acquired data from Whole Foods upper-end clientele, Amazon can make more efficient stock decisions in both the retail and physical stores. In February, Whole Foods Chief Executive John Mackey said that they would retain the services of Dunnhumby, a customer data and insights company, to inform merchandising and services (in other words, help us stock our shelves and get our prices down). I can’t help but think that Amazon could do even better.

Distribution

Second, this acquisition gives Amazon access to a grocery distribution network that enhances their own. It creates more markets for home grocery delivery. Nomura Instinet analyst Anthony DiClemente recently said that the grocery industry remains one of the largest and most under-penetrated markets for Amazon. Well, that just changed.

How convenient could Whole Foods home delivery be? As Dries has demonstrated in recent keynotes (blog post: http://buytaert.net/cross-channel-user-experiences-with-drupal), I can envision a future where I ask my Echo Dot for some free-range chickpeas and organic shampoo and a Whole Foods van shows up at my door an hour or two later with my products (and as of today, with a sizable charge on my debit card).

The Whole Foods brand - a trip down memory lane

Third, it gives Amazon a very strong brand that is associated with organic groceries and high-end shopping experience.

I’m from Austin, and I’ve been shopping at Whole Foods since there was a single store in the early 80s. My family lived in nearby Temple so once a month we’d drive to Austin so Mom could shop at Whole Foods while us kids ran around the nearby Book Stop (Look it up. It was ahead of its time.), and eat at a fancy restaurant called Chilis.

So, maybe my brand recognition and a lifelong love of the grocery chain is stronger than most. There's no denying that it looms large over the health-food industry and is super-popular with upper-middle class soccer moms and those avocado-on-toast loving millennials we hear so much about (joke). How will Amazon leverage that loyalty? Could we see Amazon Fresh become “Whole Foods from Amazon”?

It's Go time.

The fourth and perhaps most compelling upside for the acquisition lies with Amazon Go, a recent experiment with automated retail stores.

Go is a frictionless shopping and checkout experience for physical stores. According to their website, you just “browse and shop like you would at any other store. Then you’re on the way: no lines, no checkout.”

Convenient.

It's currently only open to Amazon employees in a single Seattle store but the idea is as simple as the implementation is complicated: use advanced scanners and trackers to automate checkout. But what does this do to labor cost? In their commercial, the lone store employee is making sandwiches. That's hyperbole, but it makes that point: this is what Amazon wants. Any labor that doesn’t directly enhance the customer experience is suspect and should be eliminated as soon as possible.

Yesterday, outgoing CEO of GE Jeff Immelt scoffed that robots were not going to take over factory jobs in the next five years. Perhaps, but in retail, it has already begun. Many retailers from grocery stores to Home Depot offer self-checkout. If Amazon leads the way to friction-free checkout in supermarkets, retailers that do not follow in their footsteps will find that they’re the next Borders, CompUSA, or Radio Shack.

The Go technology isn't ready for real world use yet but let's say it's at most 36 months away from being ready for prime time. That means that in relatively short order, Amazon can dramatically reduce one of the biggest expenses Whole Foods carries today: labor. They'll still have the cheese guy and the bread lady—those personal interactions are why people shop at a high-end grocer after all. Still, no more jockeying for the shortest checkout lines. It's hugely convenient, and it will happen.

With Go, Amazon can now tackle Whole Foods’ biggest issue for most people: price. As much as I love it, my family doesn’t do our grocery shopping at Whole Foods. I have a great experience, but I need a second job just to pay the bill. In fact, I walk around with my iPhone out looking up pricing and even placing one-click orders on Amazon. Now, if I could get that Whole Foods experience at Amazon prices? Sign me up.

Amazon will continue to do what they do best: leverage technology to remove inefficiencies in established industries, give customers the best possible experience along the way, and provide a shortcut to the things I want to do. This combination is their killer app.

The Drupal Opportunity

The opportunity for Drupal companies could be limited or could be huge. It seems unlikely that Amazon will continue to use Drupal to power their Whole Foods infrastructure in the long run. In the short run, however, Whole Foods will continue to operate as an independent, wholly-owned subsidiary—just with a lot more coverage and support from the most technically-savvy retail company around.

Outside of the immediate timeframe, it could open opportunities to build closer ties to Amazon through the use of headless Drupal for backend data storage, retrieval, and integration. As much as retailers suffer from Amazon’s dominance, manufacturers benefit from frictionless distribution and additional sales channels that will be created. That gives us, the Drupal community, more opportunities to do what we do best with Drupal 8 and beyond. We can continue toward building voice interactions that tie into Amazon’s Alexa infrastructure in unique ways; Tech stacks that better integrate e-commerce platforms into Amazon’s listings and sales engine; and possibly even recruiting opportunities for top Drupal talent that may be winding down their tenure with Whole Foods.

And that’s not even to mention the retailers that want to compete with Amazon head-on. They need what Drupal has: vision, community, and a platform for building world-class, sustainable, and expandable solutions. They need technology that allows them to meet and beat the Amazon at their own game. They need a shortcut to success, and that’s Drupal 8.

Opportunities for Drupal from a mega merger of Drupal community companies.Planet Drupal, amazon.com, whole foods, drupal news

This blog post is transcribed from the session "More Social, Less Media: Harnessing the power of Human Connection to Achieve Marketing Success" presented by Molly Nelson at Drupal Texas Camp in Austin, TX - June 2017 More Social, Less Media

 

We know that you don’t want to lose news of Drupal. For that reason, and although it has officially started beach season, here you have the most interesting events of this summer.

June 15

• Drupaleada in San José (Costa Rica)

  Read more

One of the best parts of Drupal 8 is our shift to enterprise PHP coding structures. With tools like composer and Symfony’s structures like Events and Dependency Injection, Drupalists are learning to be great PHP developers, and vice-versa. Today, the fastest route to becoming a rock star Drupalist is through PHP.

I’m one of the PHP track chairs for Drupalcon Vienna, and this year our focus is better PHP === better Drupalists. How can better PHP make your life as a Drupal developer easier?

Do you like PHP 7? We want to hear about the technicalities of types, throwing all the things, and your favorite operators (mine is null coalesce, but full respect for you spaceship operator fans).

Have you seen the light of functional programming? Tell us why we should love higher orders with lambda functions and closures. Let’s hear the finer points of first class functions.

Do your tests bring all the bugs to the yard? We want to talk about it. Every method is a promise, and your tests make sure you keep your promises. We want sessions about test driven development in a drupal context, choosing the right test framework and scope, and how your real-world tests are saving you real-world time.

Have you written a composer library wrapper module yet? Submit a session about how composer is saving you lines of code.

Is your development environment fine-tuned for drupal excellence? Tell us how, and why.

We have only two weeks left until session submissions close! Get your session in now and help us make Drupal code something to be proud of.