Planet Drupal

Subscribe to flux Planet Drupal - aggregated feeds in category Planet Drupal
Mis à jour : il y a 41 min 40 sec

Unimity Solutions Drupal Blog: Drupal Board Staff Mixer

lun, 24/10/2016 - 13:28

During our Board Retreat, the Staff Board mixer gave us a chance to meet the staff members and the staff members to meet the Board. The staff's commitment and involvement to the project is amazing and definitely needs a pat on the back!

Catégories: Elsewhere

OSTraining: Upload PDF, Excel, Word Files to Drupal Content

lun, 24/10/2016 - 12:17

An OSTraining member asked how he could attach files such as PDFs, Excel Documents, Word Documents to his content. 

There are many ways to do this in Drupal, but the easiest approach is to use the "File" field.

  • Login to your Drupal site.
  • Go to Structure > Content types.
  • You either add the field to an existing content type, or you can create a new one for specifically adding the files:
Catégories: Elsewhere

Liip: Drupal SearchAPI and result grouping

lun, 24/10/2016 - 09:17

In this blog post I will present how, in a recent e-Commerce project built on top of Drupal7 (the former version of the Drupal CMS), we make Drupal7, SearchAPI and Commerce play together to efficiently retrieve grouped results from Solr in SearchAPI, with no indexed data duplication.

We used the SearchAPI and the FacetAPI modules to build a search index for products, so far so good: available products and product-variations can be searched and filtered also by using a set of pre-defined facets. In a subsequent request, a new need arose from our project owner: provide a list of products where the results should include, in addition to the product details, a picture of one of the available product variations, while keep the ability to apply facets on products for the listing. Furthermore, the product variation picture displayed in the list must also match the filter applied by the user: this with the aim of not confusing users, and to provide a better user experience.

An example use case here is simple: allow users to get the list of available products and be able to filter them by the color/size/etc field of the available product variations, while displaying a picture of the available variations, and not a sample picture.

For the sake of simplicity and consistency with Drupal’s Commerce module terminology, I will use the term “Product” to refer to any product-variation, while the term “Model” will be used to refer to a product.

Solr Result Grouping

We decided to use Solr (the well-known, fast and efficient search engine built on top of the Apache Lucene library) as the backend of the eCommerce platform: the reason lies not only in its full-text search features, but also in the possibility to build a fast retrieval system for the huge number of products we were expecting to be available online.

To solve the request about the display of product models, facets and available products, I intended to use the feature offered by Solr called Result-Grouping as it seemed to be suitable for our case: Solr is able to return just a subset of results by grouping them given an “single value” field (previously indexed, of course). The Facets can then be configured to be computed from: the grouped set of results, the ungrouped items or just from the first result of each group.

Such handy feature of Solr can be used in combination with the SearchAPI module by installing the SearchAPI Grouping module. The module allows to return results grouped by a single-valued field, while keeping the building process of the facets on all the results matched by the query, this behavior is configurable.

That allowed us to:

  • group the available products by the referenced model and return just one model;
  • compute the attribute’s facets on the entire collection of available products;
  • reuse the data in the product index for multiple views based on different grouping settings.
Result Grouping in SearchAPI

Due to some limitations of the SearchAPI module and its query building components, such plan was not doable with the current configuration as it would require us to create a copy of the product index just to apply the specific Result Grouping feature for each view.

The reason is that the features implemented by the SearchAPI Grouping are implemented on top of the “Alterations and Processors” functions of SearchAPI. Those are a set of specific functions that can be configured and invoked both at indexing-time and at querying-time by the SearchAPI module. In particular Alterations allows to programmatically alter the contents sent to the underlying index, while the Processors code is executed when a search query is built, executed and the results returned.
Those functions can be defined and configured only per-index.

As visible in the following picture, the SearchAPI Grouping module configuration could be done solely in the Index configuration, but not per-query.

Image 1: SearchAPI configuration for the Grouping Processor.

As the SearchAPI Grouping module is implemented as a SearchAPI Processor (as it needs to be able to alter the query sent to Solr and to handle the returned results), it would force us to create a new index for each different configuration of the result grouping.

Such limitation requires to introduce a lot of (useless) data duplication in the index, with a consequent decrease of performance when products are saved and later indexed in multiple indexes.
In particular, the duplication is more evident as the changes performed by the Processor are merely an alteration of:

  1. the query sent to Solr;
  2. the handling of the raw data returned by Solr.

This shows that there would be no need to index multiple times the same data.

Since the the possibility to define per-query processor sounded really promising and such feature could be used extensively in the same project, a new module has been implemented and published on the SearchAPI Extended Processors module. (thanks to SearchAPI’s maintainer, DrunkenMonkey, for the help and review :) ).

The Drupal SearchAPI Extended Processor

The new module allows to extend the standard SearchAPI behavior for Processors and lets admins configure the execution of SearchAPI Processors per query and not only per-index.

By using the new module, any index can now be used with multiple and different Processors configurations, no new indexes are needed, thus avoiding data duplication.

The new configuration is exposed, as visible in the following picture, while editing a SearchAPI view under “Advanced > Query options”.
The SearchAPI processors can be altered and re-defined for the given view, a checkbox allows to completely override the current index setting rather than providing additional processors.

Image 2: View’s “Query options” with the SearchAPI Extended Processors module.


Conclusion: the new SearchAPI Extended Processors module has now been used for a few months in a complex eCommerce project at Liip and allowed us to easily implement new search features without the need to create multiple and separated indexes.
We are able to index Products data in one single (and compact) Solr index, and use it with different grouping strategies to build both product listings, model listings and model-category navigation pages without duplicating any data.
Since all those listings leverages the Solr FilterQuery query parameter to filter the correct set of products to be displayed, Solr can make use of its internal set of caches and specifically the filterCache to speed up subsequent searches and facets. This aspect, in addition to the usage of only one index, allows caches to be shared among multiple listings, and that would not be possible if separate indexes were used.

For further information, questions or curiosity drop me a line, I will be happy to help you configuring Drupal SearchAPI and Solr for your needs.

Catégories: Elsewhere

Dewy: 7 Of The Biggest Challenges When Drupal Grows At Your Higher-Education Institution

lun, 24/10/2016 - 08:00
Your web team has empowered your higher-ed insitution's digital presence with Drupal, and everything is awesome. But over time issues will arise that could pose significant risks to your institution. These are the biggest challenges and how they can be managed.
Catégories: Elsewhere

TheodorosPloumis blog: Should I build a career on Drupal?

sam, 22/10/2016 - 23:14

An IT university student asked me one week before in a developer meetup here in Thessaloniki - Greece:

"Senior developers say to never count on a CMS to build a career. I have heard that Drupal 8.x is more mature than ever but how risky it is to spend my time on a hard to learn CMS in order to make a living? What is your advise as a Drupal developer?"

First of all I would like to say that it is a very hard question. If you are already using Drupal the answer may be obvious but here we are talking about a young person studying IT, who doesn’t have any real experience on any CMS, and would be afraid to rely on a specific CMS. This is expected and totally fine.

Secondly, in order to be more objective I should compare Drupal with the other similar software out there like WordPress, Joomla, SiteCore, SquareSpace, Adobe AEM etc. Or, to be honest I should compare Drupal with other the alternative frameworks like Laravel, Django, Ruby on Rails etc. Since I do not have a personal experience of all the above "competitors" I will talk only about Drupal. So it's up to you, the young IT Student to investigate if similar software out there can offer what Drupal offers and how much does it cost to focus or not to Drupal.

Thirdly I would say that I make a living from Drupal for the last 8 years now as a freelancer. I work from home and I work 100% on Drupal projects.

So, here is why Drupal is a very good path to follow in order to build a long time career.


Open Source:

This may be a "hidden" advantage of Drupal but notice this: with Drupal you and your customers will never stand behind a company, a commercial license or a company strategic. Behind Drupal there are thousand of people and this is your stable ground to step. Behind any commercial software there is a company. Drupal is open source and will stay as that for ever. Remember that.


Ready for tomorrow:

Drupal is not a "static" code CMS, outdated and heavy. Drupal is always "regenerated" and stays on the edge of the technology. Current version of 8.x is built with Backbone.js, RESTful services, In Place Editor, Symfony2, Twig, CKeditor and many other things that are game-changers. It's UX is always improved. You may have difficulties to get started and the learning curve will not be easy. But it worths the effort. Drupal is a CMS that never stagnates.


Career Evolution:

Using and building experiences with Drupal is challenging. On every release you are almost forced to learn new things. That's because Drupal tries to get better and better over time even after 15 years of existence. For Drupal 8.x for example you may need to learn to use Composer, Object Oriented patterns, RESTful APIs, Symfony services and many other interesting things which were not in Drupal 7.x. Nowadays Drupal is adding new stuff in its core even on minor releases of 8.x. I can really promise, "you will never get borrowed with DrupalTM".


Companies are investing:

Huge, medium and small companies investing to Drupal. IT companies and advertisement agencies are moving to Drupal as their preferable tool to create websites or other apps. Big corporations, organizations, governments, institutes etc are using Drupal or planning to use Drupal to build their web presence. In terms of the open source CMS Drupal is by far a leader when there are security, flexibility and long term maintenance requirements. Especially for Drupal 8.x we are going to see even more "big" players to investigate on Drupal and migrate from other CMS - even paid -. Drupal creates new market opportunities and that's why demand for Drupal talent is great​.


Drupal Community:

Drupal is very proud of its' incredibly unique community. The motto of Drupal is "Come for the Code, Stay for the Community". It is the key for success of the software. The website, the unified and fully open online place where Drupal lives, is full of helpful information, extensions, themes, documentation and thousands of humans ready to help you find your way. People are giving back to Drupal and this is a win win situation. I could say so many about Drupal community and how it works but you should better see on your self.


Drupal Association:

Behind (or in front of) Drupal there is the Drupal Association, a passionate group of people elected from the community and working for the community. The Drupal Association is dedicated to fostering and supporting the Drupal software project, the community and its growth (funding, infrastructure, education, promotion, distribution, online collaboration etc). So behind the community there is the same community trying to help the community! Probably the larger online community of an open source software.



I could not avoid refer to the founder of Drupal. Dries is one of us, a humble community member, an open mind businessman, a lead developer, a Drupal evangelist, a restless leader. His thoughts are really inspiring and you feel safe when you listen him talking about the mission and strategic of Drupal.


After all these I hope you get the idea.

Good luck with your professional (Drupal) career ;-)


Further reading.

Catégories: Elsewhere

Matt Glaman: Conductor, a Composer UI

sam, 22/10/2016 - 15:30

Developers have many tools. We have version control systems, we have dependency management tools, we have build and task automation tools. What is one thing they all have in common? They are command line tools.

However, the command line can be daunting to some and create a barrier to adoption. We’re currently experiencing this in the Drupal community. People are considering Composer a barrier to entry, and I believe it’s just because it’s a command line tool and something new.

Providing a user interface

User interfaces can make tools more usable. Or at least lower the barrier to entry. I like to think of Atlassian's SourceTree. SourceTree is an amazing Git user interface and was my entry into learning how to use Git.

If you work with Java, your IDE provides some sort of user interface for managing your dependencies via Maven.

The PhpStorm IDE provides rudimentary Composer support - initializing a project and adding dependencies - but doesn’t support entire workflows. It’s also proprietary.

Here’s where I introduce Conductor: a standalone Composer user interface built on Electron. The purpose of Conductor is to give users working with PHP projects an interface for managing their projects outside of the command line.

Hello, Conductor

Conductor provides an interface for:

  • Creating a new project based on a Composer project
  • Managing projects to install, update, add, and remove dependencies
  • View dependencies inside of a project
  • Ability to update or remove individual dependencies by reviewing them inside of the project.
  • Run Composer commands from the user interface and review console output.

The project is in initial development, granted by the downtime the Dyn DDoS attack created.

The initial application is now in an above minimal viable product. It works. It can be used. But now it needs feedback from users who feel a barrier by having to use Composer, and code improvements as well.

Head over to GitHub and check out the project: Currently, there are no prebuilt binaries and you'll need to manually build to try it out.

Catégories: Elsewhere

Palantir:'s Guide to Digital Governance: Roles and Permissions

ven, 21/10/2016 - 21:17's Guide to Digital Governance: Roles and Permissions's Guide to Digital Governance brandt Fri, 10/21/2016 - 14:17 Scott DiPerna Oct 24, 2016

This is the fifth installment of’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.

In this post we will cover...
  • Why defining roles and permissions is important
  • Some common roles and associated permissions
  • Questions you should consider when defining permissions for your organization

We want to make your project a success.

Let's Chat.

We live in an era where few institutions have Websites and other Internet-based properties that are managed and maintained by one or only a few people. Where these spaces were once controlled by the few who knew how to code in HTML, content management systems have now dramatically lowered (and arguably eliminated) the need to possess extensive HTML knowledge. This means that most organizations have lots of people editing their Web properties, and without some well-defined rules for all those cooks in the kitchen, things get messy quickly.

Whether or not the platform you are using has roles and permissions built into it, a good governance plan will define roles for users and then apply specific permissions to those roles. Based on my experience, here are some common, fairly generic, roles and permissions that many Websites have (or have variations):

  • ROLE: Authenticated User
    • PERMISSIONS: Anyone who has activated an account on the Website, but has no editing or publishing permissions; authenticated users may be able to see content an un-authenticated user may not see.
  • ROLE: Contributor
    • PERMISSIONS: A user with an account who can create new and edit their existing content on the Website, but may not publish or delete any content, including their own, or edit content they have not created.
  • ROLE: Editor
    • PERMISSIONS: A user with an account who can create new and edit existing content on the Website, including content that is not their own; they may or may not publish or delete content.
  • ROLE: Publisher
    • PERMISSIONS: A user with an account who can create new, edit existing, publish, and delete any content on the Website; typically a person who approves and publishes the work of Contributors and Editors.
  • ROLE: Administrator
    • PERMISSIONS: A user with the same permissions as a Publisher, however they may administer accounts, roles, and permissions of other users on the Website, along with managing certain site-wide settings.
  • ROLE: Webmaster
    • PERMISSIONS: A user with full permissions to all aspects of managing and administering the Website, a role typically reserved to the few, most highly trained and experienced users.

These common roles can be modified easily to address the specific needs of your organization. You may also find that they are lacking certain roles you need, in which case I recommend using one of these for the basis of a new role you create to meet your specific requirements. For example, let’s say you have a microsite that is a subset of your main site, and you need to assign a user the role of Administrator ONLY for that micro-site and not the entire main site. Simply take the permissions assigned to Administrators and create a new role call Micro-Site Admin whose permissions as “Administrator” are limited to only the micro-site that role manages.

Here are some questions to consider to help you begin defining the roles your organization will need, along with the permissions each role should have.

  • Who should have an account for accessing your Website?
  • How do users acquire or activate accounts?
  • What are the policies for using accounts?
  • Is sharing an account permissible?
  • What are the conditions under which users may lose their access privileges?
Roles & Permissions
  • Who is permitted to edit content on the Website?
  • Who is permitted to create new content on the Website?
  • Who is permitted to publish content on the Website?
  • Who is permitted to delete content on the Website?
  • Who is permitted to see unpublished content on the Website?
  • Are there users who should have higher levels of administrative access to perform site-wide changes or to administer user accounts?
  • Are there sets of users who need special access to only limited parts or functions within the Website?
  • Are there limitations to the level of access different users should have?
  • Do all users have access to all content?
  • Do some users have access to only the content they create?
  • Do certain users need to approve content before it is published?
  • Does a workflow need to be established for defining how content is produced and published?


This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:

  1. Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
  2. Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
  3. Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
  4. Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
  5. Roles and Permissions – Define who should be able to do what in each system.
  6. Content – Understand how ownership and permissions should apply to content.
  7. Organization – Establish how the content in your digital properties should be organized and structured.
  8. URLs – Define how URL patterns should be structured in your websites.
  9. Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
  10. Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
  11. Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
  12. Web-Based Applications – Consider use and ownership of web-based tools and applications.
  13. E-Commerce – Determine the role of e-commerce in your website.
  14. Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
  15. Social Media – Set standards for the establishment and use of social media tools within the organization.
  16. Digital Communications Governance – Keep the guidelines you create updated and relevant.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.
Catégories: Elsewhere

Phponwebsites: Add date pop-up calendar in custom drupal 7 form

ven, 21/10/2016 - 20:48
     This blog describes how to add date pop-up calender to a custom form in the Drupal 7.

     The use case is if you want to use date pop-up calendar in a custom form, then how you can do it in the drupal 7. Actually, the drupal 7 form API provides lots of form types like textfield, checkbox, checkboxes etc to create a custom form. Similarly, the date module  also provides the form type called date_popup. We can use it in the custom form in order to display the date pop-up in the custom form.

Use date pop-up calendar with the custom form in drupal 7:
   Let consider the below code snippet:

function phponwebsites_menu() {
  $items = array();

  $items['customform'] = array(
    'title' => t('Custom Form'),
    'type' => MENU_CALLBACK,
    'page callback' => 'drupal_get_form',
    'page arguments' => array('phponwebsites_display_date_popup_form'),
    'access callback' => TRUE,

  return $items;

function phponwebsites_display_date_popup_form($form, &$form_state) {
  $form['date'] = array(
    '#type' => 'date_popup',
    '#default_value' => date('Y-m-d'),
    '#date_format'   => 'Y-m-d',
    '#date_year_range' => '0:+5',
    '#datepicker_options' => array('minDate' => 0, 'maxDate' => 0),

  return $form;
      '#date_format'   => 'Y-m-d' if you need to display only date
      '#date_format'   => 'Y-m-d H:i:s' if you need to display date & time
      '#date_year_range' => '0:+5' if you need to display only future 5 years
      '#datepicker_options' => array('minDate' => 0, 'maxDate' => 0) if you want to display only current date. We can hide the future & past dates using this option.

   Please add the above code into your module file and look into the "customform" page. It looks like the below image:

   Now I've hope you know how to add date pop-up calendar with custom form in the drupal 7.

Related articles:
Remove speical characters from URL alias using pathauto module in Drupal 7
Add new menu item into already created menu in Drupal 7
Add class into menu item in Drupal 7
Create menu tab programmatically in Drupal 7
Add custom fields to search api index in Drupal 7
Clear views cache when insert, update and delete a node in Drupal 7
Create a page without header and footer in Drupal 7
Login using both email and username in Drupal 7
Disable future dates in date pop-up calendar Drupal 7
Catégories: Elsewhere - Thoughts: DrupalCon showcase: a very British migration

ven, 21/10/2016 - 17:44

The Ixis team were out in force, exhibiting as a gold sponsor (along with a small army of Druplicon stress-balls) As well as meeting lots of other Drupal developers and businesses deploying open source infrastructure, one of the highlights of the convention was our Technical Director, Mike Carter, being given the opportunity to co-present a Drupal Showcase session, detailing our work with the British Council.

Catégories: Elsewhere blog: Nasdaq Chooses Drupal 8

ven, 21/10/2016 - 14:47

Republished from

I wanted to share the exciting news that Nasdaq Corporate Solutions has selected Drupal 8 as the basis for its next generation Investor Relations Website Platform. About 3,000 of the largest companies in the world use Nasdaq's Corporate Solutions for their investor relations websites. This includes 78 of the Nasdaq 100 Index companies and 63% of the Fortune 500 companies.

What is an IR website? It's a website where public companies share their most sensitive and critical news and information with their shareholders, institutional investors, the media and analysts. This includes everything from financial results to regulatory filings, press releases, and other company news. Examples of IR websites include http://investor.starbucks.com and -- all three companies are listed on Nasdaq.

All IR websites are subject to strict compliance standards, and security and reliability are very important. Nasdaq's use of Drupal 8 is a fantastic testament for Drupal and Open Source. It will raise awareness about Drupal across financial institutions worldwide.

In their announcement, Nasdaq explained that all the publicly listed companies on Nasdaq are eligible to upgrade their sites to the next-gen model "beginning in 2017 using a variety of redesign options, all of which leverage Acquia and the Drupal 8 open source enterprise web content management (WCM) system."

It's exciting that 3,000 of the largest companies in the world, like Starbucks, Apple, Amazon, Google and ExxonMobil, are now eligible to start using Drupal 8 for some of their most critical websites. 

Catégories: Elsewhere

Capgemini Engineering: Fun with Drupal 8 configuration management

ven, 21/10/2016 - 01:00

It has been a few years since I have had the opportunity to build a website from the absolute beginning. The most recent project I’m on continues in that vein, but it’s early enough for me to consider ripping it apart and starting all over again. The project is particularly interesting to me, as it’s my first opportunity to use Drupal 8 in earnest. As I’ve got an interest in automating as much as possible, I want to gain a better understanding of the configuration management features which have been introduced in Drupal 8.

Tearing it apart and starting again wasn’t the first thing considered. Being an arrogant Drupal dev, I figured I could simply poke around the GUI and rely on some things I’d seen at Drupalcon and Drupal camps in the past couple of years to see me through. I thought I would find it easy to build a replicated environment so that any new developer could come along, do a git clone, vagrant up, review a file and/or wiki page and they’d be off and running.


This post outlines many of the things that I examined in the process of learning Drupal 8 while adopting a bit of humility. I’ve created a sample project with names changed to protect the innocent. Any comments are welcome.

The structure of the rest of this post is as follows:

Setting up and orientation with Drupal VM

I am a big fan of Jeff Geerling’s Drupal VM vagrant project, so I created a fork of it, and imaginatively called it D8config VM. We will be building a Drupal site with the standard profile which we’ll use to rapidly build a basic prototype using the Drupal GUI - no coding chops necessary. The only contributed module added and enabled is the Devel module at the start, but we will change that quickly.

Here are the prerequisites if you do follow along:

  • familiarity with the command line;
  • familiarity with Vagrant and that it’s installed on your machine (note: the tutorial requires Vagrant 1.8.1+);
  • as well as Vagrant 1.8.1+, you need to have Ansible 2.0.1+ and VirtualBox 5.0.20+ installed;
  • have installed the Vagrant Auto-network plugin with vagrant plugin install vagrant-auto_network. This will help prevent collisions with other virtual networks that may exist on your computer;
  • have installed the Vagrant::Hostsupdater plugin with vagrant plugin install vagrant-hostsupdater, which will manage the host’s /etc/hosts file by adding and removing hostname entries for you;
  • familiarity with git and GitHub;
  • if using Windows, you are comfortable with troubleshooting any issues you might come across, as it’s only been tested on a Mac;
  • familiarity with Drush.

Here is how the D8config VM differs from Drupal VM:

  • the config.yml and drupal.make.yml files have been committed, unlike the normal Drupal VM repo;
  • the hostname and machine name have been changed to and d8config respectively;
  • to take advantage of the auto-network plugin, vagrant_ip is set to The d8config machine will then have an IP address from to;
  • the first synced folder is configured with a relative reference to the Vagrant file itself:
# The first synced folder will be used for the default Drupal installation, if # build_makefile: is 'true'. - local_path: ../d8config-site # Changed from ~/Sites/drupalvm destination: /var/www/d8config-site # Changed from /var/www/drupalvm type: nfs create: true

I’ll do the same with subsequent shared folders as we progress - it’s a useful way to keep the different repos together in one directory. At the end of the tutorial, you’ll have something like:

└── projects ├── another_project ├── d8config │   ├── d8config_profile │   ├── d8config-site │   └── d8config-vm ├── my_project └── top_secret_project


New nice-to-haves (thanks to recent changes in Drupal VM)

If you have used Drupal VM before but haven’t upgraded in a while, there are a load of new features. Here are just two to note:

  • Ansible roles are now installed locally (in ./provisioning/roles) during the first vagrant up;
  • PHP 7 is now an option to be installed. In fact, it’s installed by default. You can select 5.6 if you like by changing php_version in the config.yml file (see PHP 5.6 on Drupal VM).
Now do this

Create a directory where you’re going to keep all of the project assets.

$ mkdir d8config # Change to that directory in your terminal: $ cd d8config

Clone the D8config VM repo. Or, feel free to fork D8config VM and clone your version of the repo.

$ git clone # Change to the `d8config-vm` directory: $ cd d8config-vm # Checkout the `CG01` branch of the repo: $ git checkout CG01 # Bring the vagrant machine up and wait for the provisioning to complete. $ vagrant up

After successful provisioning you should be able to point your browser at and see your barebones Drupal 8 site. Username: admin; Password: admin.


If you’ve used Drupal VM before, you will want to examine the changes in the latest version. From Drupal VM tag 3.0.0 onwards, the requirements have changed:

  • Vagrant 1.8.1+
  • Ansible 2.0.1+
  • VirtualBox 5.0.20+

One sure sign that you’ll need to upgrade is if you see this message when doing a vagrant up:

ansible provisioner: * The following settings shouldn't exist: galaxy_role_file


Build your prototype

In this section of the tutorial we’re going to start building our prototype. The brief is:

The site is a portfolio site for for a large multinational corporation’s internal use. But hopefully the content architecture is simple enough to keep in your head. The following node types need to be set up: Case study, Client, Team member (the subject matter expert), and Technologies used. Set up a vocabulary called Country for countries served and a second to called Sector classify the information which will contain tags such as Government, Music industry, Manufacturing, Professional services, etc. Delete the existing default content types. You can then delete fields you know you won’t need to avoid confusion - Comments for example - which will then allow you to uninstall the comment module. And, as you might deduce by the modules I’ve selected, it’s to be a multilingual site.

Hopefully this should feel comfortable enough for you, if you are familiar with Drupal site building. There are enough specifics for clarity, yet it’s not too prescriptive that you feel someone is telling you how to do your job. Whereas in one context, you may hear a manager say “don’t bring me problems, bring me solutions”, most engineers would rather say for themselves “don’t bring me solutions, bring me problems”. I hope this brief does the latter.

Have a go at making the changes to your vanilla Drupal 8 site based on the brief.

Beyond the brief

Every ‘site building’ exercise with Drupal is a move further away from the configuration provided by the standard or minimal profiles. In our circumstance, we will enable these modules via the GUI:

  • Responsive Image
  • Syslog
  • Testing
  • BigPipe
  • Devel Generate (Devel was installed due to settings in config.yml in the d8config-vm repo)
  • Devel Kint
  • Devel Node Access
  • Web Profiler
  • Configuration Translation
  • Content Translation
  • Interface Translation
  • Language

I’ve also added a couple of contributed themes via Drush so the site will no longer look like the default site.

# While in your d8config-vm directory: $ vagrant ssh # Switch to your Drupal installation: $ cd /var/www/d8config-site/drupal # Download and install two themes: $ drush en integrity adminimal_theme -y

For more details on these themes, see the Integrity theme and the Adminimal theme. As you might expect, I set Integrity as the default theme, and Adminimal as the admin theme via the GUI.

After switching themes, two blocks appeared in the wrong regions. I went to the Block layout page and moved the Footer menu block from the main menu region to the footer first region and the Powered by Drupal block from the Main menu to the Sub footer block.

Due to the multilingual implication, I went to the Languages admin page and added French.


Replicate and automate

At this stage you’ve made quite a lot of changes to a vanilla Drupal site. There are many reasons you should consider automating the building of this site - to save time when bringing other members into the development process, for creating QA, UAT, pre-prod and production environments, etc. We will now start to examine ways of doing just this.

drush make your life easier

In this section we’re going to create a Drush makefile to get the versions of Drupal core, contrib modules and themes we need to build this site as it currently is. This file will be the first file added to the D8config profile repo. Makefiles are not a required part of a profile, and could reside in a repo of their own. However to keep administration down to a minimum, I’ve found that this is a useful way to simplify some of the asset management for site building.

Let’s first tweak the config.yml in the D8config VM repo, so that we have synced folder for the profile. To do so, either:

  1. git checkout CG02 in the d8config-vm directory (where I’ve already made the changes for you), or;
  2. Add the following to the config.yml in the vagrant_synced_folders section:
# This is so the profile repo can be manipulated on the guest or host. - local_path: ../d8config_profile destination: /build/d8config/d8config_profile type: nfs create: true

After doing either of the above, do a vagrant reload which will both create the directory on the Vagrant host, and mount it from the d8config-vm guest.

Next, let’s generate a basic makefile from the site as it now is.

# From within the d8config vm: $ cd /var/www/d8config-site/drupal $ drush generate-makefile /build/d8config/d8config_profile/d8config.make

This makefile is now available in the d8config_profile directory which is at the same level as your d8config-vm directory when viewing on your host machine.

Because we only have Drupal core, two contrib themes and the Devel module, it’s a very simple file and it doesn’t need any tweaking at this stage. I’ve committed it to the D8config profile repo and tagged it as CG01.

Raising our profile

Since we’ve established that the makefile is doing very little on this site, we need to look at completing the rest of the profile which will apply the configuration changes when building the site. The How to Write a Drupal 8 Installation Profile is quite clear and we’ll use that page to guide us.

First, our machine name has already been chosen, as I’ve called the repo d8config_profile.

Rather than writing the file from scratch, let’s duplicate from the standard profile in Drupal core, as that’s what we used to build the vanilla site to begin with. We can then modify it to reflect what we’ve done since.

# From within the /build/d8config/d8config_profile directory in the vagrant machine: $ cp /var/www/d8config-site/drupal/core/profiles/standard/ . $ mv

The first five lines of the need to look like this:

name: D8config type: profile description: 'For a Capgemini Engineering Blog tutorial.' core: 8.x dependencies:

At the end of the file it looks like this, which shows the required core modules and adding the modules and themes we’ve downloaded:

- automated_cron - responsive_image - syslog - simpletest - big_pipe - migrate - migrate_drupal - migrate_drupal_ui - devel - devel_generate - kint - devel_node_access - webprofiler - config_translation - content_translation - locale - language themes: - bartik - seven - integrity - adminimal_theme

Also, don’t forget, we uninstalled the comment module, so I’ve also removed that from the dependencies.

You still need moar!

The profile specifies the modules to be enabled, but not how they’re to be configured. Also, what about the new content types we’ve added? And the taxonomies? With previous versions, we relied on the features module, and perhaps strongarm to manage these tasks. But now, we’re finally getting to the subject of the tutorial - Drupal 8 has a configuration system out of the box.

This is available via the GUI, as well as Drush. Either method allows you to export and import the configuration settings for the whole of your site. And if you look further down the profile how-to page, you will see that we can include configuration with installation profiles.

Let’s export our configuration using Drush. This is will be far more efficient than exporting via the GUI, which downloads a *.tar.gz file, which we’d need to extract a copy or move to the config/install directory of the profile.

While logged into the vagrant machine and inside the site’s root directory:

# Create the config/install directory first: $ mkdir -p /build/d8config/d8config_profile/config/install # Export! $ drush config-export --destination="/build/d8config/d8config_profile/config/install"

When I exported my configuration, there were ~215 files created. Try ls -1 | wc -l in the config/install directory to check for yourself.


The reason we’re gathered here today (a brief intermission)…

I hope you are finding this tutorial useful - and also sensible. When I started writing this blog post, I hadn’t realised it would cover quite so much ground. The key thing I thought I would be covering was Drupal 8’s configuration management. It was something I was very excited about, and I still am. To demonstrate some of the fun I’ve had with it is still the central point of this blog. All of the previous steps to get to this point were fun too, don’t get me wrong. From my point of view, there were no surprises.

Spoiler alert

Configuration management, on the other hand - this is true drama. Taking an existing shared development site and recreating it locally using Drush make and a basic profile (without the included config/install directory) is just a trivial soap opera. If you want real fun, visit the configuration-syncing aspect, armed only with knowledge of prior versions of Drupal and don’t RTFM.


No, really. Do it.

The secret sauce in this recipe is…

After doing the export of the configuration in the previous section, I finally started running into the problems that I faced during my real world project - the project mentioned at the beginning of this post. Importing the configuration repeatedly and consistently failed with quite noisy and complex stack trace errors which were difficult to make sense of. Did I mention that perhaps I should have read the manual?

We need to do two things to make the configuration files usable in this tutorial before committing:

# Within the d8config_profile/config/install directory: $ rm core.extension.yml update.settings.yml $ find ./ -type f -exec sed -i '/^uuid: /d' {} \;

The removal of those two files was found to be required thanks to reading this and this. At this stage, I can confirm these were the only two files necessary for removal, and perhaps as Drupal 8’s configuration management becomes more sophisticated, this will not be necessary. The second command will recursively remove the lines with the uuid key/value pairs in all files.


Packaging it all up and running with it.

We’ve done all the preparation, and now need to make some small tweaks and commit them so our colleagues can start where we’ve left off. To do so we need to:

  1. add the profile to the makefile;
  2. commit our changes to the d8config_profile repo;
  3. tweak the config.yml file in the d8config-vm repo, to use our makefile and profile during provisioning.

To have the profile be installed by the makefile, add this to the bottom of d8config.make (in the D8config profile):

d8config_profile: type: profile download: type: git url: working-copy: true

I’ve committed the changes to the D8Config profile and tagged it as CG02.

Then the last change to make before testing our solution is to tweak the config.yml in the D8config VM repo. Three lines need changing:

# Change the drush_makefile_path: drush_makefile_path: "/build/d8config/d8config_profile/d8config.make" # Change the drupal_install_profile: drupal_install_profile: d8config_profile # Remove devel from the drupal_enable_modules array: drupal_enable_modules: []

As you can see, the changes to the vagrant project are all about the profile.

With both the D8Config VM and the D8Config profile in adjacent folders, and confident that this is all going to work, from the host do:

# From the d8config-vm directory $ vagrant destroy # Type 'y' when prompted. # Go! $ vagrant up

Once the provisioning is complete, you should be able to check that the site is functioning at Once there, check the presence of the custom content types, taxonomy, expected themes, placement of blocks, etc.


Summary and conclusion

The steps we’ve taken in this tutorial have given us an opportunity to look at the latest version of Drupal VM, build a quick-and-dirty prototype in Drupal 8 and make a profile which our colleagues can use to collaborate with us. I’ve pointed out some gotchas and in particular some things you will want to consider regarding exporting and importing Drupal 8 configuration settings.

There are more questions raised as well. For example, why not simply keep the d8config.make file in the d8config-vm repo? And what about the other ways people use Drupal VM in their workflow - for example here and here? Why not use the minimal profile when starting a protoype, and save the step of deleting content types?

Questions or comments? Please let me know. And next time we’ll just use Docker, shall we?

Fun with Drupal 8 configuration management was originally published by Capgemini at Capgemini Engineering on October 21, 2016.

Catégories: Elsewhere

Palantir: Migrating XML in Drupal 8

ven, 21/10/2016 - 00:14
Migrating XML in Drupal 8 brandt Thu, 10/20/2016 - 17:14 Kelsey Bentham Oct 21, 2016

Migrate in Drupal 8 is a flexible and powerful tool - you just need to know where to look. 

In this post we will cover...
  • Some findings from our first D8 projects

  • How to use the Migrate Plus XML data process plugin

  • A note on prefixed namespaces

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Drupal 8 is here which means I have had the privilege of working on my first D8 projects and the migrations that accompany them. I wanted to share some of the key findings I’ve taken away from the experience.

Migrate in Drupal 8 is awesome as long as you know what you are looking at. It is flexible, powerful and relatively easy to read. But as is the case with most things, a lot of its power is tucked away where it is hard to find if you don't know where to look. This is definitely the case with Migrate Plus XML data process plugin which is presently available only in the dev version of Migrate Plus. It is a pretty solid tool for migrating from a variety of XML based sources and today we are going to talk about how to use it.

The first thing we have to consider is where our data is coming from. Migrate plus expects to have this information fed to it in the form of a url which gives us two options:

  1. our source is from outside the website, like an rss feed; or
  2. it is stored locally.

If you have an external url, all you need to do is plug it into the url’s parameter. If your source is stored locally, you will either need to construct a url for the source or store it in the private file directory, using the private:// stream wrapper. I would go for the latter as it involves less overhead. At this point your migration source should look something like this:

   plugin: url    
   data_fetcher_plugin: http    
   data_parser_plugin: xml   
   urls: private://migration.xml

This brings us to parsing out the XML. All of the selectors we will be talking about are using xpath. The first thing you need to do is define the item selector so migrate can identify the individual items to migrate into your choose destination. For example, if we were migrating posts from a WordPress export it might look something like this:

item_selector: /rss/channel/item[wp:post_type="post"]

Next up we need to map all of our fields to nice, readable machine names that we can use in the process part of the migration. Each field will have a name that will identify it in other parts of the migration, a label for describing what sort of data we will find in that XML element, and a selector so the migration can map that data from the xml file:

    name: title
    label: Content title
    selector: title
    name: post_id
    label: Unique content ID
    selector: wp:post_id
    name: content
    label: Body of the content
    selector: content:encoded
    name: post_tag
    label: Tags assigned to the content item
    selector: 'category[@domain="post_tag"]/@nicename'

If you are using anything more complicated than the XML node names, you will need to wrap the selector as a string. The selectors are being passed to xpath in the data processor, so you can get pretty precise in selecting XML nodes.

All that is left to do is define the migration id and you have your source all ready to go:

     type: integer

Put it all together and you should have something that looks something like this:

   plugin: url    
   data_fetcher_plugin: http    
   data_parser_plugin: xml   
   urls: private://migration.xml
   item_selector: /rss/channel/item[wp:post_type="post"]
       name: title
       label: Content title
       selector: title
       name: post_id
       label: Unique content ID
       selector: wp:post_id
       name: content
       label: Body of the content
       selector: content:encoded
       name: post_tag
       label: Tags assigned to the content item
       selector: 'category[@domain="post_tag"]/@nicename'
           type: integer

A note on prefixed namespaces: you can see we mixed XML nodes that have prefixes with those that don’t. Sometimes Migrate handles this with no problem at all; sometimes it refuses to fetch data from XML nodes that don’t have prefixes. As far as I can tell, it does this when one of the nodes in the item_selector has a prefix (although it doesn’t seem to have this problem with the filters in the item_selector). If you should have a datasource with a parent prefixed node, you can still get non-prefixed children by using the following syntax:

name: description
label: Content description
selector: '*[local-name()="description"]'

It will allow you to select XML nodes with a given local name regardless of the prefix, which is very handy when you have no prefix at all.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.
Catégories: Elsewhere

Acquia Developer Center Blog: What is Information Architecture and Why it is Important to Your Website

jeu, 20/10/2016 - 22:23

Website navigation is something you probably use every day but don’t think too much about. This is how you travel from page to page within a website. It is probably the most used part of your website that you spend the least amount of time evaluating, right? I used to feel the same way. A few years ago, I inherited a site navigation that seemed to be working so my team focused on growing other areas of the site. Looking into how our menu was organized was low priority.

Tags: acquia drupal planet
Catégories: Elsewhere

Tag1 Consulting: Tag1 Quo: Versions, Versions Everywhere, Part 1

jeu, 20/10/2016 - 18:55
sam Thu, 10/20/2016 - 09:55

When Tag1 decided to build Tag1 Quo, we knew there was one question we’d have to answer over, and over, and over again: is there a security update available for this extension? Answering that question - at scale, for many websites, across many extensions, through all the possible versions they might have - is the heart of what Quo does.

Catégories: Elsewhere

Acquia Developer Center Blog: How to Make Acquia Lift for Content Syndication Work with Existing Sites

jeu, 20/10/2016 - 17:33

Acquia Lift for Content Syndication is an Acquia product that allows you to have a central repository for your content and syndicate it out to various connected sites. All the connected sites are able to send content to the repository for use on any other connected site. In an ideal world, all the connected sites would have matching content type and field machine names. However, in our reality, we had two existing sites where this was not true.

Tags: acquia drupal planet
Catégories: Elsewhere

Flocon de toile | Freelance Drupal: Improve user experience with Paragraphs on Drupal 8

jeu, 20/10/2016 - 12:00

The Paragraphs module is a very good alternative to a WYSIWYG editor for those who wants to allow Drupal users ans editors to make arrangements of complex pages, combining text, images, video, audio, quote, statement blocks, or any other advanced component.

Catégories: Elsewhere

Aurelien Navarre: We should all have a Kenny in our lives

jeu, 20/10/2016 - 10:54

Let me tell you a story. When I joined Acquia in April 2011, the Support group was a small pool of passionate and talented drupalists working day and night to service our customers. And there was Kenny, aka webkenny. The vocal, outspoken and hilarious personality that was going to accompany Tim Millwood and I every morning when we were holding down the fort during EMEA hours, as the company was scaling up.

So, yesterday evening, when we received an email informing us Kenny had passed away, this brought back all those memories, and a deep sadness, because we all fought closely together to make things right and help each other.

It is with great sadness that we learned today that Kenny Silanskas has passed away. This is a terrible loss for Kenny’s family, for us at Acquia, and for the the Drupal community.

Kenny joined Acquia in 2009 and was instrumental into building the Acquia spirit and bringing the energy needed to wake up everyday and start all over again. Not without a lot of laughter.

...and certainly not without killing it on stage.

When he decided to take on another challenge, I recommended him on Linkedin and wouldn't change a word today:

Kenny is a natural-born leader who has a passion for sharing knowledge and moving mountains. From Client Advisor to Technical Account Manager and then Support Team Manager, he has always gained respect from his peers both technically and by his positive and energetic attitude. Today I'm better at what I do thanks to the high standards of customer satisfaction Kenny taught me about.

Because, yes, Kenny was quite a character, a generous and kind-hearted man, but also an excellent troubleshooter and technical lead. Maybe you remember his epic DrupalCon London presentation with the 8-bit Dries?

Life's full of surprises. Kenny had just come back to Acquia. We were so happy. But unfortunately, at the end of September he suddenly resigned. I didn't really understand what was happening and didn't ask questions. So, when he last tweeted a few days ago, I obviously didn't imagine this would mean so much, after all.

Life is not a series of unfortunate events, but change that evolves you with each challenge. And no, that's mine. Not Confucius.

— Kenny Silanskas (@webkenny) October 17, 2016

Acquia's co-founder sums it best.

My heart goes out to the family of @webkenny. He was a force of nature on this earth, and I lament his passing. RIP Kenny. Sing with angels.

— Jay Batson (@jab) October 20, 2016

Never forget that smile. You will be sorely missed, my friend.

A GoFundMe has been set up in his memory. Please consider donating.

Catégories: Elsewhere Ionic and Android 6 Runtime Permissions

jeu, 20/10/2016 - 09:46
Ionic and Android 6 Runtime Permissions Body

Android Permission Provisioning has changed recently, If an app is using Android SDK API level 22 or below, users are asked for all the permissions in bulk at the time of installation i.e. Without granting permission user can not install the app. Now with Android 6's security patch called Run Time Permission (API level 23 and above) the app while in use can request for specific permission when the need arise ( similar to iOS ) e.g. you will be asked for the location's permission when you actually try to access the location of the device.

To work with runtime permissions on Ionic, you would need to install Cordova diagnostic plugin which gives you the function to fetch the status of the native api's exposed to the app. If a certain permission is mandatory for you app you can prompt the user to grant access to proceed. Further you have specific functions for granting permissions.

Install the plugin

cordova plugin add cordova.plugins.diagnostic

To avail the features of Run Time Permission, you have to build the app with Android platform 6.

Check you current Android platform version

ionic platform

If the version of your Android's Platform is below 5, you will need to update it to 5 or above.

Remove android platform:

ionic platform remove android

Install Android platform version 5 or above:

ionic platform add android@5

In config.xml, set the target of sdk version to 23


So far we are all set to ask user's for permission on the fly. We will have to call a functions to fetch the status of particular permission for the app. On the basis of the status we will ask the user to grant permissions or ignore it.

Add the following function in your app.js in $ionicPlatform.ready() function.

This will make $rootScope.checkPermission() global and you can call it whenever you wish to check if the user has given the permission to fetch device's location.

$rootScope.checkPermission = function() { setLocationPermission = function() { cordova.plugins.diagnostic.requestLocationAuthorization(function(status) { switch (status) { case cordova.plugins.diagnostic.permissionStatus.NOT_REQUESTED: break; case cordova.plugins.diagnostic.permissionStatus.DENIED: break; case cordova.plugins.diagnostic.permissionStatus.GRANTED: break; case cordova.plugins.diagnostic.permissionStatus.GRANTED_WHEN_IN_USE: break; } }, function(error) {}, cordova.plugins.diagnostic.locationAuthorizationMode.ALWAYS); }; cordova.plugins.diagnostic.getPermissionAuthorizationStatus(function(status) { switch (status) { case cordova.plugins.diagnostic.runtimePermissionStatus.GRANTED: break; case cordova.plugins.diagnostic.runtimePermissionStatus.NOT_REQUESTED: setLocationPermission(); break; case cordova.plugins.diagnostic.runtimePermissionStatus.DENIED: setLocationPermission(); break; case cordova.plugins.diagnostic.runtimePermissionStatus.DENIED_ALWAYS: setLocationPermission(); break; } }, function(error) {}, cordova.plugins.diagnostic.runtimePermission.ACCESS_COARSE_LOCATION); };


Here is a link of the code snippet.

Of course, you can choose to skip all this and stick to sdk target version 22, but you will miss out the new cool feature of Android 6 and amazing user experience. 

abhay.kumar Thu, 10/20/2016 - 13:16
Catégories: Elsewhere Blog: AGILEDROP: Which big names use Drupal?

jeu, 20/10/2016 - 09:10
I saw a post recently about another Drupal 8 site that got launched. It was Rainforest Alliance. Nothing special at first. But then, out of curiosity, I clicked on it and checked it. While I was admiring the impressive pictures of the forests, I suddenly remembered that over a month ago I read an article about city of Boston launching its website on Drupal. Then it hit me. Who are the »big names« that Drupal can show off to the world and say 'These are our most proud members'? As you may have heard or read or anything else, Drupal is a free and open-source content-management framework that… READ MORE
Catégories: Elsewhere Drupal 6 security update for Webform

mer, 19/10/2016 - 19:35

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Less Critical security release for the Webform module to fix an Access Bypass vulnerability.

When using forms with private file uploads, Webform wasn't explicitly denying access to files it managed which could allow access to be granted by other modules.

You can download the patch for Webform 6.x-3.x.

If you have a Drupal 6 site using the Webform, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on

Catégories: Elsewhere