Comic Relief Technology Blog: Why we made our platform product open-source

Planet Drupal - Fri, 2017/07/07 - 8:35am
Drupal 8 at Comic Relief Over the last year a key objective for the Technology team at Comic Relief has… Read More
Categories:

Erik Erskine: DrupalCamp Bristol 2017

Planet Drupal - Fri, 2017/07/07 - 1:00am

Drupal has a thriving community in Bristol and the south-west, and they've put on some excellent events over the last few years. Last weekend they had their third DrupalCamp Bristol, and I was fortunate to be able to attend and speak.

Read more

Categories:

Mediacurrent: DrupalCon Baltimore 2017 - SEO, i18n, and i18n SEO

Planet Drupal - Thu, 2017/07/06 - 8:09pm

DrupalCon Baltimore 2017 was, without a doubt, a great event. The first DrupalCon to hit the US East Coast since DrupalCon DC in 2009 so this (ex-) New Englander was happy to have just a day's drive to get there.

Categories:

ThinkShout: Upgrading MailChimp eCommerce and an Introduction to Drupal 8's Event System

Planet Drupal - Thu, 2017/07/06 - 6:00pm

If you’ve ever built a Drupal 7 module, then you’ll be familiar with hooks: functions that allow modules to react to things happening in other modules. The hook system is functionally fine but, with so many hooks to implement, .module files often become bloated and difficult to manage.

Drupal 8’s event system does a lot to reduce the clutter of hooks. Now, instead of using a hook, you can create an event subscriber that will execute your code every time a module triggers an event. This is similar to the hook system only in the effect; the execution is very different.

Porting our popular MailChimp eCommerce module to Drupal 8 gave me the perfect opportunity learn about the event system. I use the word “opportunity” to disguise the fact that I was forced to learn how events work because it was impossible to port the module without doing so.

The MailChimp eCommerce module depends on the Commerce module, naturally, and in Drupal 8, the Commerce module makes heavy use of events.

First, let’s look at an event. I’m using an example ripped straight from Commerce.

The Commerce submodule, Commerce Cart, contains a class named CartEntityAddEvent. You can find it here.

The class itself is simple; it’s designed to store a few values - the cart, the item being added to the cart, and the quantity of that item. The class also has a few getter functions for convenience.

Most importantly, this class represents an event that’s triggered every time a user adds an item to their shopping cart. This is done using just two lines of code:

$event = new CartEntityAddEvent($cart, $purchased_entity, $quantity, $saved_order_item); $this->eventDispatcher->dispatch(CartEvents::CART_ENTITY_ADD, $event);

The event class is created with all the relevant values, then “dispatched” to any event subscribers configured to pay attention to it. When dispatched, the event is identified by a constant - CartEvents::CART_ENTITY_ADD. This constant is used by event subscribers, which we’ll take a look at now.

This is a cut-down version of an event subscriber used by our world famous MailChimp eCommerce module.

/** * Event Subscriber for Commerce Carts. */ class CartEventSubscriber implements EventSubscriberInterface { /** * The Cart Handler. * * @var \Drupal\mailchimp_ecommerce\CartHandler */ private $cart_handler; /** * The Order Handler. * * @var \Drupal\mailchimp_ecommerce\OrderHandler */ private $order_handler; /** * CartEventSubscriber constructor. * * @param \Drupal\mailchimp_ecommerce\CartHandler $cart_handler * The Cart Handler. * @param \Drupal\mailchimp_ecommerce\OrderHandler $order_handler * The Order Handler. */ public function __construct(CartHandler $cart_handler, OrderHandler $order_handler) { $this->cart_handler = $cart_handler; $this->order_handler = $order_handler; } /** * Respond to event fired after adding a cart item. */ public function cartAdd(CartEntityAddEvent $event) { /** @var \Drupal\commerce_order\Entity\Order $order */ $order = $event->getCart(); /** @var \Drupal\commerce_order\Entity\OrderItem $order_item */ $order_item = $event->getOrderItem(); $product = $this->order_handler->buildProduct($order_item); $this->cart_handler->addCartLine($order->id(), $order_item->id(), $product); } /** * {@inheritdoc} */ public static function getSubscribedEvents() { $events[CartEvents::CART_ENTITY_ADD][] = ['cartAdd']; return $events; } }

Here’s the complete version, if you’re interested.

So what does it do, exactly?

Let’s start with the getSubscribedEvents() function. This is where we define which events we want to subscribe to, and assign each event a processing function. Here we are subscribing to just one event, the “cart entity add” event, and assigning the cartAdd() function as a processor.

Note that the cartAdd() function takes one argument, an instance of the CartEntityAddEvent class. That’s the same class we looked at earlier - the event class defined in the Commerce Cart module. This is where our module reacts to that event being triggered.

The cartAdd() function itself extracts the order and item information from the event and uses an instance of the CartHandler class, provided by the MailChimp eCommerce module, to send updated cart information to MailChimp’s API.

One final thing:

Event subscribers won’t work unless they are defined as a service. Services are defined in a module’s *.services.yml file, which you can learn more about here.

The service definition for the CartEventSubscriber looks like this:

mailchimp_ecommerce_commerce.cart_event_subscriber: class: '\Drupal\mailchimp_ecommerce_commerce\EventSubscriber\CartEventSubscriber' arguments: ['@mailchimp_ecommerce.cart_handler', '@mailchimp_ecommerce.order_handler'] tags: - { name: event_subscriber }

We identify the class using its namespace, inject the “cart_handler” and “order_handler” services, then, finally, tag the service as an “event_subscriber”. Check out the full file here. Just for completeness, the two injected services are defined in here.

I’m a big fan of how Drupal 8 has shifted towards a more object-oriented way of doing things. It’s more organized, promotes consistency between modules, and, best of all, finally signals an end to massive .module files.

Categories:

Advomatic: Using Configuration Split to have dev-only configuration in Drupal 8

Planet Drupal - Thu, 2017/07/06 - 5:07pm

The problem If you are using Drupal’s Configuration Management subsystem to deploy configuration out to the production environment, you’ll run into a problem where the configuration .yml files contain your development settings.  To avoid this you’ll need to use the Configuration Split module.  I couldn’t find any good documentation for this, so I had to... Read more »

The post Using Configuration Split to have dev-only configuration in Drupal 8 appeared first on Advomatic.

Categories:

Zivtech: Drupal vs. WordPress for Higher Education Websites

Planet Drupal - Thu, 2017/07/06 - 4:32pm

You’re about to begin a huge overhaul of your higher education website and one of the first steps is choosing a content management system. It’s likely that Drupal and WordPress have come up in your research, and you may be trying to decide between the two.

Drupal and WordPress are often compared to one another because they’re both open source content management systems. Both are capable of creating clean, responsive websites that are easy to manage for content editors. The functionality of both can be extended using third party code. And the code for both is openly available for anyone to use, change, and distribute, meaning there are no licensing fees like those required by closed source options. 

There are a significant number of higher education websites on Drupal; Harvard, Brown, and Oxford University all use the CMS, to name a few. According to Drupal.org, 71% of the top 100 universities use Drupal. And there’s some sound reasoning behind that.

Both WordPress and Drupal have strengths and are well suited for a diverse range of projects. WordPress was primarily built for standalone websites or blogs with minimal variation in content types. Drupal was built for more complex, feature rich websites that require significant interconnectivity between pages or site sections, like those required by higher education. 

Here are some factors to consider when choosing between the two content management systems. 

Read more
Categories:

Flocon de toile | Freelance Drupal: The 13 mythical (or not) defects of Drupal 8

Planet Drupal - Thu, 2017/07/06 - 12:00pm
Having had the opportunity to read a recent comparative study between Drupal 8 and SPIP, I discovered a Drupal perception that is not mine. Far be it from me to want to compare Drupal and SPIP. Indeed, I know very badly SPIP, at least only as a basic user, and much less than Drupal, and so I will not venture on such a comparison. Also, I wanted to share these mythical, real or perceived defects of Drupal 8, which I recently discovered and which I think deserve a counterpoint.
Categories:

clemens-tolboom commented on issue jas-chen/atom-live-server#74

On github - Thu, 2017/07/06 - 10:57am
Jul 6, 2017 clemens-tolboom commented on issue jas-chen/atom-live-server#74

Thanks for the XREF!

heykarthikwithu: Setup Multiple Drush version's on your machine, make Drupal maintenance easier

Planet Drupal - Thu, 2017/07/06 - 10:36am
Setup Multiple Drush version's on your machine, make Drupal maintenance easier

How to setup Multiple Drush's in your machine, to manage the drupal 6, drupal 7 and drupal 8 sites..

heykarthikwithu Thursday, 06 July 2017 - 14:06:12 - IST, Asia/Kolkata
Categories:

Dropsolid: Drupal 8 on Google Cloud with Kubernetes

Planet Drupal - Thu, 2017/07/06 - 8:53am
06 Jul Deploying Drupal 8 onto Google Cloud using Kubernetes Nick Veenhof

A month ago I received the honour to present at DrupalJam 2017. What a wonderful event! I had been invited to talk about deploying Drupal 8 onto kubernetes, which can be found as a hosted service in Google Cloud.


Our move to Google

Recently, we made the decision at Dropsolid to move from regular virtual machine instances in Gandi towards instances and services in Google Cloud, as we believe that the capabilities of such a cloud provider offer possibilities that are unprecedented. GC is not only offering affordable virtual machines (instances) but also affordable and competitive offerings regarding hosted MySQL. But that’s not all... Since we like our R&D environment and are looking for achieving greater and bigger goals, it is in our interest to see that Google is publishing new AI and data-analysis APIs at a pace that we don’t see anywhere else.


In practice

So... Back to the technicalities. I wanted to run an experiment on how I could run Drupal on an infrastructure that did not need any humans behind the wheel, nor any maintenance. I found this in the way of three components:

An overview of Kubernetes and the setup can be seen in the following video:

 One component that I found to be missing, was a shared filesystem between the two ‘Pods’ (Containers). Drupal relies on user files or images and these should be stored somewhere. We do not want to alter the behaviour of Drupal or get into the application itself, as that introduces risk. Not all the websites that we would like to host, are modifiable.

  • We could map the folder to an AWS S3 bucket or Google Cloud Storage bucket, but that would be too slow for our needs. What we actually wanted is a competitor of AWS EFS, but unfortunately Google Cloud did not have this available.
     
  • We can work our way around it by setting up a NFS server or Gluster server in kubernetes, but that drives us away from our initial goal - less maintenance, so we can focus on building awesome experiences, which is the Drupal application.

If you are interested how I did the setup of the NFS, the slides go into deep detail how to set up this NFS cluster. The code is also available at https://github.com/nickveenhof/drupal-docker-with-volume

I recorded a video how this deployment works. Caution, I did speed it up quite a bit.

Key findings

Now, what is the key take-away from all this? That I moved the particular website back to regular hosting, eg a shared space with a human behind the wheels here at Dropsolid. The reason was that for a single site, the cost outweigh the benefits and even though it is claimed to be fault-tolerant, I had numerous occasions where my pod did not want to recover, since the ‘failed’ one refused to be deleted. This ate up precious CPU space - on a server that barely had enough CPU. This can be solved with throwing more money at it, but that was not the intent.

I also discovered that constraining a pod to a fixed amount of CPU is not very useful when sharing a single server between multiple Drupal sites. Websites can have variable load and for small to medium sites with little traffic it is hard to justify the cost of pre-allocating those resources. I am curious to explore and test the Vertical Pod Autoscaling once they are finished, as this could certainly help applications with burstable workloads.

Having said that, I did learn a lot about what the future could hold. Going towards a system like this gets us really close to the 12-factor app ideology and I am completely in favour of a future like that.

 

Comments, questions? I'm curious to find out your take on this. Let me know in the comments box below or reach out directly on Twitter via @Nick_vh

Make sure to check out my the slides from this presentation here: 
https://www.slideshare.net/nickvh/drupaljam-2017-deploying-drupal-8-onto-hosted-kubernetes-in-google-cloud

Categories:

Amazee Labs: Make your plans for DrupalCon Vienna

Planet Drupal - Thu, 2017/07/06 - 8:47am
Make your plans for DrupalCon Vienna

DrupalCon Vienna is approaching quickly and if you haven’t done so far, it’s a good time to book your travels and accommodation. Even for an insider it is hard to keep track of everything that is going on, so in this post I would like to share an overview of what’s planned so far to keep in mind when planning your stay in Vienna.

Josef Dabernig Thu, 07/06/2017 - 08:47

Until Sunday, 24 September - Cyclists will be gathering again on the way to DrupalCon as part of Tour de Drupa Vienna. The Danube river allows for scenic flat rides from the west (Germany - Linz - Krems - Tulln - Vienna) or east (Budapest - Bratislava - Vienna). On Sunday 11am we will be meeting at the webshapers office in Tulln and in the afternoon cycle the last 40 kilometres together along the Donau to reach the Riesenrad in Vienna at 6pm. Join the conversation on g.d.o to get all the details.

Tour de Drupal Amsterdam 2014 from SchnitzelCopter on Vimeo.

Monday, 25 September - Drupal Austria together with the global Drupal Community are organizing summits and trainings. Those who have been to the DrupalCamps in 2013 or 2015 will remember FH Technikum Wien being supporter and host of these community organized activities. In terms of summits, we are planning for a great variety: Community Summit, Publishing Summit, Business Summit, Open Social Summit.

On the trainings side we are currently planning for a Docker workshop and a Drupal 8 module development course. Finally, there will be room for sprints thanks to sponsorship from Acquia and a CXO Dinner in the evening. Here’s some more information about the Monday program.

Tuesday, 26 September - The day kicks off the official DrupalCon program with the keynote by Dries Buytaert, Drupal Project Founder and will start 3 days of sessions, BoFs and social events. In the evening there will be the Open Minds Award (a regional open source award) and a ball celebrating Open Source as the official community party.

Wednesday, 27 September - Together with the keynote, other sessions and BoFs, there will also be the Drupal Association Public Board Meeting as well as the Women in Drupal social event and a CEO Dinner.

Thursday, 28 September - So far confirmed is that there will be Drupal Trivia Night. More details to follow as soon as it’s available.

Friday, 29 September - This is the last day of the conference and it’s all about Sprints: Join the community to learn how you can contribute to Drupal.

This sums up the main activities planned so far for DrupalCon Vienna. Alongside of the official important dates, hopefully this helps you to plan and organise your visit. Speaking from my own experience, DrupalCon with thousands of community members attending is a very special event: basically a week full of events. The above is only what we are aware of so far, you can be sure that various other individual events will be organized along the way.

Apart from the conference, Vienna has a lot to offer. If your schedule permits, I would definitely recommend adding a few days to explore the city. Some suggestions and ideas can be found on the official DrupalCon Vienna travels page. See you in Vienna.

Categories:

Agiledrop.com Blog: AGILEDROP: Most popular Drupal Modules

Planet Drupal - Thu, 2017/07/06 - 7:51am
Modules. You practically cannot master Drupal without them. They extend and customize Drupal functionality. It's true that some are still not converted properly to the newest version and some are poorly or not maintained at all. But there are many who solve your everyday problems efficiently. Therefore, we will look at the most popular Drupal modules according to the official website of Drupal. Chaos tool suite (ctools) is the most popular Drupal module, with almost nine hundred thousand sites using it, making it the most installed Drupal module. This module is a set of tools to improve the… READ MORE
Categories:

Zyxware Technologies: Drupal 8 Render Pipeline for Newbies

Planet Drupal - Thu, 2017/07/06 - 7:28am
<

Authors: Adrian McDonald Tariang, Anish M.M.

Drupal 8 Render Pipeline is the sequence of steps through which Drupal 8 generates a response to an HTTP request. ie, it’s what’s going on under the hood of Drupal 8.

Drupal 8Drupal PlanetSymfony
Categories:

Boby Aloysius Johnson | GSoC Blog: The evaluation week -- week 5

Planet Drupal - Thu, 2017/07/06 - 6:39am
The evaluation week -- week 5 boaloysius Thu, 07/06/2017 - 00:39

 

The first phase evaluation of GSoC'17 is over. I had been working on integrating Google Cloud ML Engine to Drupal. Till now we have worked on creating a demo with Census example to illustrate that we can make predictions for our data in Drupal with ml-engine. Please check my first evaluation blog for details. After the evaluation, we worked on integrating standard pre-trained Tensorflow models to Drupal.

Pre-trained models are machine learning models trained on some dataset. As data is the key to classification accuracy, most of the standard pre-trained models available are trained on huge datasets. Our primary source of research was tensorflow/models. This repo had around 30 models but most of them needed training. In my inquiry, we found that Tensorflow lacks a gallery of trained models. Let me provide the link to some of the pre-trained models found. 

 

 Name  link   study  Inception  gz file Inception is an image recognition model trained on imageNet (a hierarchical classification of millions of images). It classifies the image into thousands of classes. Users have to do transfer learning to get their custom classes.  VGG  tar.gz file VGG(Visual Geometric Group) is a deep CNN developed by Oxford for image classification based on ImageNet. It is a model similar to inception. https://www.quora.com/What-is-the-VGG-neural-network   Syntaxnet 

zip

Syntaxnet identifies the grammatical structure of the sentence. Please check these two blogs (blog1 and hblog2) for details.  Facenet

20170511-185253

 20170512-110547

 This model uses CNN for face recognition. It can be used to recognize human faces (detect if two faces are the same). It is trained on two data sets, MS-Celeb-1M and CASIA-WebFace. Please check this report for details.

 

Finding lack of good pre-trained Tensorflow models is a serious drawback. Most of the natural language models we found needs training. For example, Syntaxnet is a highly accurate language parser. But we need to train on top of this to create a custom model for text summarizer and models useful for the end users. We don't have many ready-to-use natural language models suitable for Drupal.

To use standard models for our project, we have to do transfer learning. It is learning on top of what is already learned. In the Tensorflow for poets example, we remove the last softmax classification layer and train a layer on our own, for custom classification. Please refer to this in-depth video on how to create a custom image classifier. 

The major challenge we face is to create an abstraction to transfer data, train model, and to do the prediction for a variety of data types. We have to give the user flexibility to use any type of data (image, nominal, ordinal, numeric, ...) for training and prediction with ml-engine. For that, we have to create an abstraction that handles all data types. In the coming week, we will be exploring on how to create this abstraction.

Thank you

Categories:

Valuebound: Things to know about Drupal 7’s Database API

Planet Drupal - Thu, 2017/07/06 - 3:22am

The new drupal database API (known as DB:TNG) is built atop PHP's native PDO engine. The main objective behind Drupal’s database API is to allow developers to write one query that will work across different types of databases. So instead of writing specific queries for MSSQL, PostgreSQL, MongoDB, you can write one query. Then, a plugin is written to translate that query into native style and write the query in the initial language which is Database Abstraction layer. 
 
What are the new changes in Drupal 7’s new database API?
 
One of the biggest changes is Drupal 7's new database API, an object-oriented system which change  the way most developers will build…

Categories:

Tameesh Biswas | Blog: GSoC17 : Client Side File Encryption : Week 5

Planet Drupal - Wed, 2017/07/05 - 7:35pm
GSoC17 : Client Side File Encryption : Week 5

This blog post summarises my fifth week of working with Google Summer of Code 2017 with Drupal.

Sandbox to implement the file encryption

This week I created a sandbox page in the router to test standalone file encryption. It utilised the HTML5 FileReading API to get the contents of the selected file that needs to be encrypted.

var reader = new FileReader();

An alternative would be:

var reader = new FileReaderSync();

tameeshb Wed, 07/05/2017 - 23:05 Tags GSoC Google Summer of Code 2017 Drupal Drupal Blog
Categories:

Lullabot: Common Pitfalls When Configuring Entity Browser in Drupal 8

Planet Drupal - Wed, 2017/07/05 - 6:55pm

One of Drupal’s biggest strengths is its flexibility and extensibility, allowing developers to create, for example, custom-tailored editorial workflows. In this article, we will examine Entity Browser, a powerful component of Drupal’s contributed ecosystem of modules for managing digital media assets.


To make it easier to follow along with the article, let’s consider two fictional characters: Bob, who works as a copy editor for a big news website, and Sylvia, the Drupal developer in charge of the website Bob uses to do his job.


Bob is not very happy with the current solutions he has when editing an article, because:

  • When uploading an image, he is unable to re-use an image uploaded in another article.
  • When uploading an image to a gallery field, he has to upload them individually, and he wishes he could bulk-upload several images at once.
  • When Bob needs to relate articles, he uses an auto-complete field which only accepts the title, forcing him open a new tab to search for articles by author, category or date, because he doesn't remember all past articles' titles by heart.
  • Sometimes Bob wants to relate an article to a “quote” content type that doesn't exist yet, but he is going to create. Now he needs to stop his work, open a new tab, create the quote content, come back to the article, and then reference the quote. It bothers him a little bit having to switch so often between tabs and contexts.
  • Other things (Bob always wants more).

Sylvia knows how to solve all those needs, but she is not satisfied because the solutions she previously used in Drupal 7 were not standardized, sometimes “overkill," and often difficult to maintain and extend. However, she heard that the Entity Browser module solves all these needs (and more) in a generic and powerful way.

undefined

Sylvia already discovered that this module was deliberately created with a very abstract, flexible and “pluggable” architecture. While this allows for powerful tools and workflows to be implemented, the price is often an increased learning curve about how to properly configure it for the different user needs.

This article is intended to help Sylvia (and you) discover Entity Browser. Here you will find:

  • A brief description of the architecture of the module and the central concepts with which you need to be familiar.
  • A list of “browser” examples that can help you understand what is possible.
  • A step-by-step tutorial for configuring a browser from scratch, identifying common pitfalls that often occur in that process.
The basics


If this is your first contact with the Entity Browser module or if you are still wrapping your head around its configuration, there are some key concepts that you should start familiarizing yourself with, indicated below.

Note: The following description uses concepts and terminology not very easy to understand at first sight. It’s OK if not everything is 100% clear after the first read. The configuration steps below will certainly help you confront this challenge. In any case, I would highly recommend you take the time to go over the documentation indicated in each of the links below and check the examples there. It's always easier to grasp the concepts with some images and real examples.

The “browser” is a configuration entity that can be created through the UI by the site-builder, or imported from a configuration YAML file. This config entity will base its behavior on the settings defined by the following four plugins:

  • The Display plugin, which is responsible for presenting the entity browser to the end user (editor), in different contexts. Examples of this are “iFrame” or “Modal.
  • The Widget plugin, which is the tool the editor will use to effectively browse/search/select or create the piece of content they are looking for. Examples of this plugin that ship with the module is “File Upload” or “Views.
  • The Widget Selector plugin, which as the name suggests, is responsible for providing a mechanism for the end user to select a specific widget, among a set of available ones. Selector examples could be “Tabs” or “Dropdown.
  • The Selection Display plugin, which allows a “temporary storage area,” where the editor will be able to have visual feedback about the entities they've selected. 


Once all these are plugins, other contributed modules (and also your custom code!) can easily provide new ones. So don’t be surprised if at some point you encounter more options than the ones listed above.

Check some existing examples…

Many modules and distributions showcase what is possible to build using Entity Browser. The following video is based on the File Entity Browser module, which provides a pre-configured browser, along with some nice front-end adjustments.

Videos require iframe browser support.


This is an excellent way to become familiar with the module and the different use cases. These are some of the existing examples you can explore:

Modules that provide pre-configured browsers:

Full-featured Drupal distributions that showcase entity browsers:

…or create your own brand new Entity Browser!

Even if you are using one of the pre-packaged solutions mentioned above, it’s always good to understand how things work behind the scenes. For that, there’s no substitute for creating an entity browser from scratch and seeing for yourself all of the details involved. Doing this will help you discern whether a packaged solution or a custom browser will best address the particular use case involved in your project.

To create a browser from scratch, the first thing to do, after enabling the module, is to navigate to:

Configuration -> Content authoring -> Entity browsers

or go directly to the URL /admin/config/content/entity_browser and click “Add Entity browser

undefined

Common pitfall 

The module does not depend on the Ctools module to work. However, the multi-step wizard that helps you create and edit entity browsers using the UI does. This means that in order to create a browser as shown here you need to have Ctools enabled on your site. It’s not necessary to leave it enabled afterward though.  Once your browser is finished, and no modifications are foreseen, if you don’t need Ctools you can safely disable it in your production environment.

The wizard will walk you through five steps, each of them intended to define the configuration options for the different plugins we saw before.

Step 1 - General browser configuration undefined

In this step, you define the basic configuration of your browser, and depending on what you choose here, some of the subsequent steps may not need any configuration or will ask for different information.

If you are in doubt on what to choose here, the default values suggested may be just fine for many use cases. In our case, to make the most of the example, we will select:

  • Modal display
  • Tabs selector
  • Multi-step selection display

Common pitfall 

If you plan to use this browser as part of an embedding workflow using the Entity Embed module, you must choose the iFrame display plugin.

Step 2 - Display configuration undefined

This step will ask you for some information that refers to the display type you selected in the first step.

In our case, we are asked to indicate the width and height of the modal window, the label of the link/button to launch the browser, and an option to automatically open the browser, when possible (not always recommended).

For our example, we will leave the defaults.

Step 3 - Widget selector configuration undefined

Because we are using the “Tabs” widget selector type, there's no additional configuration needed.

Common pitfall 

Note that when using the multi-step wizard, the config values won’t be effectively saved until you go to the last step and click “Finish”. Even if some steps have no configuration, or you just want to edit the configuration of a single step, for now, you always need to go to the last one and click “Finish”. You can refer to this issue if you want to help to improve this.

Step 4 - Selection display configuration undefined

Because we selected “Multi-step” in a previous step, we have some configuration to do.

In our case, we will define that we'll be working with “File” entities (images), and this “work-in-progress zone” for the entities selected (the Selection display) should show the images as Thumbnails, using the “Thumbnail (100 x 100)” image style.

Step 5 - Widgets configuration undefined


This is the final and most important step to configure our browser. Here we will add as many widgets as we want to expose to the user when they are using the browser.

In our example above, we have added two widgets:

  • Upload: which will allow the user to upload a new image to the site
  • View: allowing the editor to select a pre-existing image from a gallery (which is a view you can customize as well)

Common pitfall 

When using a view as a widget, not all views can be selected here. You must have created beforehand a view with the following characteristics:

- It shows entities of the type being selected by this browser

- It has a display of type “entity_browser"

- It has at least one field of type “Entity browser bulk select form.” This is what will make the checkboxes appear and allow the entities to be selectable.

As long as these traits are present, the view can do any additional filtering and show any information you want to make the selection process easier.

Common pitfall 

View widgets have an additional setting “Automatically submit selection” intended to save the user one click when sending the entities to the “work-in-progress selection area.” Note though that this option should only be used when the Selection Display is set to “Multi-Step.” Failing to do so may produce an error on your site such as:

Drupal\Core\Config\ConfigException: Used entity browser selection display cannot work in combination with settings defined for used selection widget. in Drupal\entity_browser\Form\EntityBrowserForm->isFunctionalForm()

You can refer to this issue if you want more information or are interested in helping the site-builder experience here.

Browser created. Now what?

Now you can use it! As mentioned before, there is a lot of abstraction involved so that the browser can be used in many different contexts. Maybe one of the most common scenarios is to use the browser as a field widget to populate entity field values, but the same browser could also be used to support embedding workflows, in a custom form that you build yourself, or other scenarios you can think of.

Moving on with our example, let’s consider we have a node content type (let’s say the “Article” content type) with an image field where we want to stop using the default core upload widget and start using our brand-new browser instead. All we need to do is head over to:

Structure -> Content types -> Article -> Manage form display

or go directly to /admin/structure/types/manage/article/form-display to change the field widget settings.

undefined

Click on the dropdown, select “Entity browser” and then click on the cog on the right to open the browser widget options.

undefined

Different browsers may have different options here. In any case, the most important operation you want to perform here is to select from the dropdown list the entity browser you want to use.

Once done, your node creation form should have been updated to use the new field widget!

undefined

When you click on “Select entities”, your browser will open:

undefined undefined

Note that, as expected, we have two widgets (labeled here “upload” and “view”), displayed as Tabs, presented to the user in a Modal window.

Common pitfall

As seen above, the browser is a “piece” you configure and then plug into other parts of your site. Once it is very abstract, sometimes you can still plug it into some places, but it won’t work if the configuration you created for the browser is incompatible with the context you want to use it in. The following are two examples of this:

Misconfiguration scenario 1

Widgets don’t enforce entity types based on the context they are used in. This means that you could potentially use a widget to select an entity of a type incompatible with the field where that widget is being used, resulting in an error such as “The entity must be of type <type>”. You can refer to this issue for more information on this situation.

Misconfiguration scenario 2

Field widgets have a setting that allows you to define how the selection should be handled during the update process. This is called “Selection mode” and you can choose between the options “Append to selection,” “Prepend selection,” and “Edit selection”. As somewhat expected, if you choose an option like “Edit selection,” your browser must have been configured to have a “selection” available, which currently is only possible with the “Multi-step Selection Display” plugin. For example, if you choose the “No selection” plugin in the browser configuration while leaving this “Edit selection” setting on the field widget, you will end up with an error such as “Used entity browser selection display does not support pre-selection.” You can refer to this issue for more information on this.

As you can imagine by now, there are many opportunities to add variations to the process and to the final result. Your view can have other filters, show the elements in a grid instead of a table, etc. The definite best way to understand all capabilities of this tool is to play around with it yourself and explore some examples provided by others.

There are however two ingredients you can add to the mix that are worth mentioning here: the integration with DropzoneJS and Inline Entity Form.

Enhance your upload widgets with DropzoneJS

DropzoneJS is a very nice open-source library that improves the user-experience for file uploading. You can replace the standard Drupal upload widget…

undefined

... with a more user-friendly drop zone area:

undefined

At the moment of this writing, the module DropzoneJS only provides the widget shown above to be used inside entity browsers or other module integrations. After this issue is solved, you’ll be able to use it stand-alone in normal Drupal fields too, if you don’t want to have an entity browser around.

Did you know that…

In Drupal 8 the standard file upload widget can handle multiple files and drag-and-drop out of the box?

undefined Create entities “on the fly” with the integration with Inline Entity Form

One very powerful integration of the Entity Browser module is with the Inline Entity Form contributed solution. This will allow you to use the very same entity creation form as a widget in your browser.

Please refer to the documentation for more details on how to configure the two ways in which this integration can be implemented on your site. The important thing to keep in mind here is that this can open the door for creating related content without having to leave the main context!

Videos require iframe browser support. Conclusion

I hope this article helped you (and Sylvia!) in identifying the possibilities behind Entity Browser, and some of the most common issues when configuring it.

Do you have anything else you wish you knew when you first tried it out? Join the conversation! Please leave a comment below and let’s reduce the learning curve together.

Acknowledgements

Thanks to Seth Brown, David Burns and Juampy NR for their help with this article.

Other articles in this series

Hero Photo by Barn Images

Categories:

Acquia Lightning Blog: Choosing an Image Style when embedding with CKEditor

Planet Drupal - Wed, 2017/07/05 - 6:16pm
Choosing an Image Style when embedding with CKEditor Adam Balsam Wed, 07/05/2017 - 12:16

Editors have always been able to choose a specific Image Style to use when embedding images in content with CKEditor, but it required quite a bit of setup by the site builder. Specifically, the site builder needed to create a view mode for each image style and then configure the view modes so that they would display the appropriate image style. Those view modes were then exposed as display plugins to Entity Embed. So the site builder then needed to configure the Media Browser embed button to allow those display plugins.

Once this was all done, editors would see a select list in the Entity Embed dialog that allowed them to choose which View Mode should be used for the embed:

In 2.1.6, Lightning introduced a new display plugin that allows editors to select an image style, alt text, and other settings each time you embed an image with CKEditor, rather that needing to rely on view modes.

When Lightning detects that an image is being embedded, it will automatically select this new display plugin (Media Image). The embed dialog, using the new display plugin, looks like this:

New installs of Lightning will also hide the "Diaplay as" select list and the manual update instructions for 2.1.6 suggest that existing sites do the same. We created an option to leave the existing behavior though for sites that have an established workflow that includes selecting view modes for embedded images.

See the 2.1.6 Release Notes for more information.

Categories:

clemens-tolboom commented on issue jas-chen/atom-live-server#74

On github - Wed, 2017/07/05 - 4:49pm
Jul 5, 2017 clemens-tolboom commented on issue jas-chen/atom-live-server#74

apm rebuild did not help. With or without atom-live-server package only