Submit your Site Building Session to DrupalCon Vienna

Posted by Amazee Labs - 20 Jun 2017 at 12:19 UTC
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 DrupalCon Session

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.

Help Drupal help your configuration

Posted by ComputerMinds.co.uk - 20 Jun 2017 at 12:00 UTC

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.

On Being Human at DrupalCon Vienna - Call for Papers closes in a week

Posted by Cheppers blog - 20 Jun 2017 at 11:09 UTC

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

Posted by Appnovation Technologies - 20 Jun 2017 at 10:43 UTC
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...

AGILEDROP: DrupalCon sessions about DevOps

Posted by Agiledrop.com Blog - 20 Jun 2017 at 08:55 UTC
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

Drupal Commerce integration with Square payments released

Posted by Commerce Guys - 19 Jun 2017 at 19:41 UTC

Drupal Commerce and Square

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!

Introducing Reservoir, a Distribution for Decoupling Drupal

Posted by Acquia Developer Center Blog - 19 Jun 2017 at 17:51 UTC
A reservoir

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

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

Posted by Drupal core announcements - 19 Jun 2017 at 04:32 UTC
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 tester: docker image for testing Drupal projects

Posted by fluffy.pro. Drupal Developer's blog - 18 Jun 2017 at 10:19 UTC
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 »

Migrating Content Translated with "Content Translation" from Drupal 7 to Drupal 8

Posted by Evolving Web - 17 Jun 2017 at 15:55 UTC
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

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

    Posted by Evolving Web - 17 Jun 2017 at 15:39 UTC
    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

    Sprint with the migrate team at DrupalCamp Montreal

    Posted by Drupal core announcements - 16 Jun 2017 at 18:42 UTC
    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.

    Why Amazon.com Just Bought Whole Foods and What That Means for Drupal

    Posted by Ben's SEO Blog - 16 Jun 2017 at 16:21 UTC

    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.

    Amazon, Whole Foods, and Drupal logoOpportunities for Drupal from a mega merger of Drupal community companies.Planet Drupal, amazon.com, whole foods, drupal news

    Drupal Texas Camp Presentation: Harnessing Human Connection to Achieve Marketing Success

    Posted by Promet Source - 16 Jun 2017 at 14:16 UTC
    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

    La Drupalera brings you the most refreshing Drupal events of the summer

    Posted by La Drupalera (en) - 16 Jun 2017 at 06:39 UTC
    La Drupalera brings you the most refreshing Drupal events of the summerLa Drupalera brings you the most refreshing Drupal events of the summer

     

    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

    Better PHP === Better Drupalists: The PHP Track at Drupalcon Vienna

    Posted by OhTheHugeManatee - 15 Jun 2017 at 15:19 UTC

    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.

    How to manage page layout using Display Suit module in Drupal 8

    Posted by Valuebound - 15 Jun 2017 at 15:12 UTC

    The Contributed module Display suite (“DS”) allows you to take control on How do you want to render them using interface. admin has ability to arrange nodes, comment,user data, views etc. provides drag and drop after as we do for managing field section.

    If you want to build a drupal custom page and really don't have any drupal technical knowledge or coding skill or, you don’t want to write custom templates, and  for smaller stuff then you can go ahead with this Display Suite module. Is really helpful when it comes to replacing the default view of an entity to user defined view using application interface. It’s straightforward…

    3 Tips for Client Friendly Paragraphs in Drupal 8

    Posted by Texas Creative - 15 Jun 2017 at 14:30 UTC

    Drupal’s Paragraphs module is a big part of what makes it easy for our clients to manage their site content. These three tips are how we make the user experience even better.

    Read More

    The Secret to a Great Web Design RFP

    Posted by Promet Source - 15 Jun 2017 at 14:03 UTC
    A recent prospect responded to my inquiry about the project budget with this:  "We can't release budget information as we need all vendors to bid their best price. If they know the budget they just bid right up to it."  

    Introduction to PHP type-hints for Drupal 8 development

    Posted by Blair Wadman - 15 Jun 2017 at 10:44 UTC

    When you are calling a function or method that has an argument(s), you don’t always know what type (array, object, string etc) of argument to pass to the function. And if you end up passing in the wrong type, you’ll get a less than helpful error.

    Pages

    Subscribe with RSS Subscribe to Drupal.org aggregator - Planet Drupal