Drupal Feeds

Blaze CSS

Latest Drupal Themes - Mon, 2017-06-19 08:32
Categories: Straight From Drupal

Donation Button Block

Latest Drupal Modules - Mon, 2017-06-19 05:52

This is a module for accepting donations via Paypal.

Donation settings form:
Go to "admin/config/user-interface/donation" and set your values.

This module provide a "donation button block". so you can assign this block where you want on site.

Categories: Straight From Drupal

Auto Assets

Latest Drupal Modules - Mon, 2017-06-19 04:40
Categories: Straight From Drupal

SuperFeature

Latest Drupal Modules - Mon, 2017-06-19 04:38
Categories: Straight From Drupal

Locked Content

Latest Drupal Modules - Mon, 2017-06-19 04:34

Locked Content satisfies a specific access control use case: you want users to be able to see teasers, links, and search results for locked materials, but want them to log in before actually visiting the full page view. It's useful for situations where keeping the existence of information secret isn't critical, but making sure users are logged in before they actully view the complete contents is important.

Categories: Straight From Drupal

Drupal core announcements: Drupal core security release window on Wednesday, June 21, 2017

Planet Drupal - Mon, 2017-06-19 04:32
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.

Drupal core announcements: Drupal core security release window on Wednesday, June 21, 2017

Feeds from Drupal.org - Mon, 2017-06-19 04:32
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.

Categories: Straight From Drupal

Taxonomy Entity Queue

Latest Drupal Modules - Sun, 2017-06-18 19:22

This module is like a smart queue! You should use this module when you want to create an entityqueue based on a taxonomy. Dont mislead this module with Queue of taxonomy terms. Lets see when you should use module.

Categories: Straight From Drupal

Svg Image

Latest Drupal Modules - Sun, 2017-06-18 14:21

This module changes default image field widget and formatter to allow use SVG image with the standard Image field.

Using SVG Image module you will not need to use another field to use SVG image instead of the already created Image field.

Don't forget to add a svg file extension into the list of the allowed image extensions in the field settings.

Other modules:

  • SVG image field - Provides another field type used for SVG image uploading.
Categories: Straight From Drupal

TOC API Node

Latest Drupal Modules - Sun, 2017-06-18 12:03

This module use the TOC API module for generating a Table of content for a whole node.

The table of contents is available as an extra field and can be placed anywhere in the node template.

The TOC options are provided by the TOC API module.

You can enable per content type the node's TOC, and for each content type select the TOC type to use.

Categories: Straight From Drupal

fluffy.pro. Drupal Developer's blog: Drupal tester: docker image for testing Drupal projects

Planet Drupal - Sun, 2017-06-18 10:19
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 »

fluffy.pro. Drupal Developer's blog: Drupal tester: docker image for testing Drupal projects

Feeds from Drupal.org - Sun, 2017-06-18 10:19
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 »
Categories: Straight From Drupal

Message Thread

Latest Drupal Modules - Sun, 2017-06-18 07:47

Message thread is part of the Message stack. It's purpose is to enable messages to be grouped into threads or conversations. It does not do anything by itself and needs to be used in conjunction with another message stack module such as Private Messages.

Categories: Straight From Drupal

Headless Ninja REST

Latest Drupal Modules - Sat, 2017-06-17 17:39

This module provides a REST endpoint that returns structured data for scalable use in a front-end library like React or Angular.

Categories: Straight From Drupal

Evolving Web: Migrating Content Translated with "Content Translation" from Drupal 7 to Drupal 8

Feeds from Drupal.org - Sat, 2017-06-17 15:55
Languages

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:

    • nidThere 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 8Article 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 + more awesome articles by Evolving Web
    Categories: Straight From Drupal

    Evolving Web: Migrating Content Translated with "Content Translation" from Drupal 7 to Drupal 8

    Planet Drupal - Sat, 2017-06-17 15:55
    Languages

    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:

      • nidThere 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 8Article 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 + more awesome articles by Evolving Web

      Evolving Web: Migrating Content Translated with "Entity Translation" from Drupal 7 to Drupal 8

      Feeds from Drupal.org - Sat, 2017-06-17 15:39
      Languages

      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 + more awesome articles by Evolving Web
      Categories: Straight From Drupal

      Evolving Web: Migrating Content Translated with "Entity Translation" from Drupal 7 to Drupal 8

      Planet Drupal - Sat, 2017-06-17 15:39
      Languages

      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 + more awesome articles by Evolving Web

      Image Approval

      Latest Drupal Modules - Sat, 2017-06-17 12:25
      Synopsis

      Image approval module allows the moderator to view the recently uploaded images by the users for their account.The moderator can either approve or disapprove the images based on the site policy.The approved image will be published in the user's account across the site.

      Categories: Straight From Drupal

      Colorbox Zoom

      Latest Drupal Modules - Sat, 2017-06-17 06:00

      Zoom in on an image that has been loaded through Colorbox. This is great if you have a high resolution image that'd you'd like to show more detail.

      Demo & more info:
      This integrates Jack Moore's jQuery Zoom plugin with Drupal Colorbox.
      http://www.jacklmoore.com/zoom/

      Zoom is triggered on hover by default and can be changed to grab, click, or toggle - zooming over the part of the image where the mouse is at. Override options in the module's js/options.js file.

      Categories: Straight From Drupal

      Pages

      Subscribe to My Drupal aggregator