Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 21 hours 37 min ago

Texas Creative: Basic Migration of File Fields to Media Entities Fields in Drupal 8

18 October 2019 - 10:10am

The Migrate File to Media module provides an easy way to migrate old file fields like images, files, videos, etc, into the media entities with a few drush commands.

So you can have an understanding of how the migration process works, In this tutorial, we will run through a few quick step-by-step instructions on how to migrate specific image field types to image entity reference fields.

Media Module

The core media module is what creates the “media” entity types. If you haven’t set this up yet, or if you are not too familiar with media entity setup, I highly recommend following this tutorial “Drupal 8 Basic Media And Media Browser Setup For Beginners”, before you continue with this tutorial. 

Read More
Categories: Drupal

Srijan Technologies: Integrating Marketing Automation With Drupal Can Drive Faster Response Time To Customers

18 October 2019 - 4:39am

In this digitally altered scenario, where every millisecond is crucial for the marketing industry to deliver customer responsiveness and enhance productivity, enterprises should start leveraging the marketing automation system earnestly & in a full-fledged manner to take their game to the next level.

Categories: Drupal (Organic) Groups in Four Voices

17 October 2019 - 10:00pm

This post is going to be somewhat unusual, as it’s being written by four people. It’s going to be on a single topic (kind of) of having groups functionality, under a single code base and database.

It’s notably about Organic groups for Drupal 8, but not just. In fact, I think that at this point in time, my story about it, is just one out of three. Pieter Frenssen and Maarten Segers, the co-maintainers have their own voice.

But to make this one even more complete (and interesting), we should hear also Kristiaan Van den Eynde’s voice – the author of Group – a competing/complementing module.

Coincidently and apart from me, all those people heavily invested in group functionality are Flemish. So, if you ever wondered how does the story of “Three Flemish and an Israeli walk into a Bar,” goes… Here’s your chance.

Continue reading…

Categories: Drupal

Jacob Rockowitz: Deploying an enterprise Drupal website with minimal downtime

17 October 2019 - 5:00am

When it comes to slow and broken digital user experiences, none of us has any patience. When someone can't access a website to get the information they need, they click the browser's back button and move on to the next link in their search results. Drupal has continually improved performance by adding a powerful cache management layer to Drupal 8. Meanwhile, any time database changes are deployed to a Drupal website, the recommended and default behavior is to display the below maintenance page across the entire website including the homepage.

There are technical reasons why Drupal's maintenance page exists - end-users don't care about the technical reasons behind a maintenance page. End-users come to a website to get information. To their minds, if they can't get this information immediately (from their perspective) the website is broken. Sure, the maintenance page can provide some more information and reasons why the website is unavailable. Still, a website's digital door is temporarily shut. The expectation is that the internet superhighway is available 24/7, yet in the Drupal community we are okay with a little downtime every week or so.

Why does maintenance mode exist?

The best metaphor as to why Drupal needs to display a maintenance page when deploying code and database changes is…

Putting a Drupal site in maintenance mode is part of the steps to updating core, modules, and themes. Drush, Drupal's command-line interface, automatically switches a site into maintenance mode when deploying database changes.

Drupal's maintenance mode has been around since Drupal...Read More

Categories: Drupal

Spinning Code: Drupal Salesforce Suite Custom Field Mapping Types

17 October 2019 - 4:00am

The Drupal 8 Salesforce Suite allows you to map Drupal entities to Salesforce objects using a 1-to-1 mapping. To do this it provides a series of field mapping types that allow you to select how you want to relate the data between the two systems. Each field type provides handling to help ensure the data is handled correctly on each side of the system.

As of this writing the suite provides six usable field mapping types:

  • Properties — The most common type to handle mapping data fields.
  • Record Type — A special handler to support Salesforce record type settings when needed.
  • Related IDs — Handles translating SFIDs to Drupal Entity IDs when two objects are related in both systems.
  • Related Properties — For handling properties across a relationship (when possible).
  • Constant — A constant value on the Drupal side that can be pushed to Salesforce.
  • Token — A value set via Drupal Token.

There is a seventh called Broken to handle mappings that have changed and need a fallback until its fixed. The salesforce_examples module also includes a very simple example called Hardcoded the shows how to create a mapping with a fixed value (similar to, but less powerful than, Constant field).

These six handle the vast majority of use cases but not all.  Fortunately the suite was designed using Drupal 8 annotated plugins , so you can add your own as needed. There is an example in the suite’s example module, and you can review the code of the ones that are included, but I think some people would find an overview helpful.

As an example I’m using the plugin I created to add support for related entities to the webform submodule of the suite (I’m referencing the patch in #10 cause that’s current as of this writing, but you should actually use whatever version is most recent or been accepted).

Like all good annotated plugins to tell Drupal about it all we have to do is create the file in the right place. In this case that is: [my_module_root]/src/Plugins/SalesforceMappingField/[ClassName] or more specifically: salesforce_webform/src/Plugin/SalesforceMappingField/WebformEntityElements.php

At the top of the file we need to define the namespace, add some use statements.

<?php namespace Drupal\salesforce_webform\Plugin\SalesforceMappingField; use Drupal\Core\Entity\EntityInterface; use Drupal\Core\Form\FormStateInterface; use Drupal\salesforce_mapping\Entity\SalesforceMappingInterface; use Drupal\salesforce_mapping\SalesforceMappingFieldPluginBase; use Drupal\salesforce_mapping\MappingConstants;

Next we need to provide the required annotation for the plugin manager to use. In this case it just provides the plugin’s ID, which needs to be unique across all plugins of this type, and a translated label.

/** * Adapter for Webform elements. * * @Plugin( * id = "WebformEntityElements", * label = @Translation("Webform entity elements") * ) */

Now we define the class itself which must extend SalesforceMappingFieldPluginBase.

class WebformEntityElements extends SalesforceMappingFieldPluginBase {

With those things in place we can start the real work.  The mapping field plugins are made up of a few parts: 

  • The configuration form elements which display on the mapping settings edit form.
  • A value function to provide the actual outbound value from the field.
  • Nice details to limit when the mapping should be used, and support dependency management.

The buildConfigurationForm function returns an array of form elements. The base class provides some basic pieces of that array that you should plan to use and modify. So first we call the function on that parent class, and then make our changes:

/** * {@inheritdoc} */ public function buildConfigurationForm(array $form, FormStateInterface $form_state) { $pluginForm = parent::buildConfigurationForm($form, $form_state); $options = $this->getConfigurationOptions($form['#entity']); if (empty($options)) { $pluginForm['drupal_field_value'] += [ '#markup' => t('No available webform entity reference elements.'), ]; } else { $pluginForm['drupal_field_value'] += [ '#type' => 'select', '#options' => $options, '#empty_option' => $this->t('- Select -'), '#default_value' => $this->config('drupal_field_value'), '#description' => $this->t('Select a webform entity reference element.'), ]; } // Just allowed to push. $pluginForm['direction']['#options'] = [ MappingConstants::SALESFORCE_MAPPING_DIRECTION_DRUPAL_SF => $pluginForm['direction']['#options'][MappingConstants::SALESFORCE_MAPPING_DIRECTION_DRUPAL_SF], ]; $pluginForm['direction']['#default_value'] = MappingConstants::SALESFORCE_MAPPING_DIRECTION_DRUPAL_SF; return $pluginForm; }

In this case we are using a helper function to get us a list of entity reference fields on this plugin (details are in the patch and unimportant to this discussion). We then make those fields the list of Drupal fields for the settings form. The array we got from the parent class already provides a list of Salesforce fields in $pluginForm[‘salesforce_field’] so we don’t have to worry about that part.  Since the salesforce_webform module is push-only on its mappings, this plugin was designed to be push only as well, and so limits to direction options to be push only. The default set of options is:    

'#options' => [ MappingConstants::SALESFORCE_MAPPING_DIRECTION_DRUPAL_SF => t('Drupal to SF'), MappingConstants::SALESFORCE_MAPPING_DIRECTION_SF_DRUPAL => t('SF to Drupal'), MappingConstants::SALESFORCE_MAPPING_DIRECTION_SYNC => t('Sync'), ],

And you can limit those anyway that makes sense for your plugin.

With the form array completed, we now move on to the value function. This is generally the most interesting part of the plugin since it does the work of actually setting the value returned by the mapping.

/** * {@inheritdoc} */ public function value(EntityInterface $entity, SalesforceMappingInterface $mapping) { $element_parts = explode('__', $this->config('drupal_field_value')); $main_element_name = reset($element_parts); $webform = $this->entityTypeManager->getStorage('webform')->load($mapping->get('drupal_bundle')); $webform_element = $webform->getElement($main_element_name); if (!$webform_element) { // This reference field does not exist. return; } try { $value = $entity->getElementData($main_element_name); $referenced_mappings = $this->mappedObjectStorage->loadByDrupal($webform_element['#target_type'], $value); if (!empty($referenced_mappings)) { $mapping = reset($referenced_mappings); return $mapping->sfid(); } } catch (\Exception $e) { return NULL; } }

In this case we are finding the entity referred to in the webform submission, loading any mapping objects that may exist for that entity, and returning the Salesforce ID of the mapped object if it exists.  Yours will likely need to do something very different.

There are actually two related functions defined by the plugin interface, defined in the base class, and available for override as needed for setting pull and push values independently:

/** * An extension of ::value, ::pushValue does some basic type-checking and * validation against Salesforce field types to protect against basic data * errors. * * @param \Drupal\Core\Entity\EntityInterface $entity * @param \Drupal\salesforce_mapping\Entity\SalesforceMappingInterface $mapping * * @return mixed */ public function pushValue(EntityInterface $entity, SalesforceMappingInterface $mapping); /** * An extension of ::value, ::pullValue does some basic type-checking and * validation against Drupal field types to protect against basic data * errors. * * @param \Drupal\salesforce\SObject $sf_object * @param \Drupal\Core\Entity\EntityInterface $entity * @param \Drupal\salesforce_mapping\Entity\SalesforceMappingInterface $mapping * * @return mixed */ public function pullValue(SObject $sf_object, EntityInterface $entity, SalesforceMappingInterface $mapping);

But be careful overriding them directly. The base class provides some useful handling of various data types that need massaging between Drupal and Salesforce, you may lose that if you aren’t careful. I encourage you to look at the details of both pushValue and pullValue before working on those.

Okay, with the configuration and values handled, we just need to deal with programmatically telling Drupal when it can pull and push these fields. Most of the time you don’t need to do this, but you can simplify some of the processing by overriding pull() and push() to make sure the have the right response hard coded instead of derived from other sources. In this case pulling the field would be bad, so we block that:

/** * {@inheritdoc} */ public function pull() { return FALSE; }

Also, we only want this mapping to appear as an option if the site has the webform module enabled. Without it there is no point in offering it at all. The plugin interface provides a function called isAllowed() for this purpose:

/** * {@inheritdoc} */ public static function isAllowed(SalesforceMappingInterface $mapping) { return \Drupal::service('module_handler')->moduleExists('webform'); }

You can also use that function to limit a field even more tightly based on the mapping itself.

To further ensure the configuration of this mapping entity defines its dependencies correctly we can define additional dependencies in getDependencies(). Again here we are tied to the Webform module and we should enforce that during and config exports:

/** * {@inheritdoc} */ public function getDependencies(SalesforceMappingInterface $mapping) { return ['module' => ['webform']]; }

And that is about it.  Once the class exists and is properly setup, all you need to do is rebuild the caches and you should see your new mapping field as an option on your Salesforce mapping objects (at least when isAllowed() is returning true).

Categories: Drupal

DrupalCon News: Proposal Tips

17 October 2019 - 3:26am

A note from our fabulous DrupalCon Minneapolis program committee:

Categories: Drupal Blog: Microcopy: What is it and why is it important

17 October 2019 - 2:28am

In this post, we'll take a look at what is meant by microcopy (or UX writing), how it differs from traditional, marketing-oriented copywriting, and what are some best practices for writing microcopy.

Categories: Drupal

Nonprofit Drupal posts: October Drupal for Nonprofits Chat

16 October 2019 - 7:45am

Our normally scheduled call to chat about all things Drupal and nonprofits will happen Thursday, October 17, at 1pm ET / 10am PT. (Convert to your local time zone.)

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc:

We have an hour to chat so bring your best Drupal topics and let's do this thing!

Some examples to get your mind firing: how do I recreate [feature] on my Drupal 7 site in Drupal 8? I need to explain [complicated thing] to a non-technical stakeholder -- any advice? How can I get Drupal and my CRM to play nicely?

This free call is sponsored by but open to everyone.

View notes of previous months' calls.

Categories: Drupal

Srijan Technologies: How Integrating Drupal With CRM Can Enhance Your Customers’ Experience

16 October 2019 - 6:48am
Integrating CRM into web technology has come as a turning point in business process automation. Well, enterprises can now easily evaluate and manage their contacts, existing clients, and leads or prospects generated through the marketing campaigns on social media platforms without any nuisance.
Categories: Drupal Migrating a career website to Drupal 8: simple case study

16 October 2019 - 6:03am
The best way to prepare for Drupal 9 is to upgrade to Drupal 8 now. See why, and also discover our case study migrating a career website to Drupal 8 performed by our team.
Categories: Drupal

InternetDevels: Boost e-commerce sales with Ubercart to Commerce migration

16 October 2019 - 5:12am

Every online store owner is looking to boost e-commerce sales. A lot here depends on the platform the website is built with — some of them are able to give you more than others.

Read more
Categories: Drupal