Agrégateur de flux

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

Planet Drupal - 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?

Planet 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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

Planet Drupal - 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?

Planet 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

Planet Drupal - 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

BlackMesh: Don’t Set Fire to your Laptop: Managing Multiple Projects without Losing it! (PART I)

Planet Drupal - mer, 19/10/2016 - 18:30

Thanks to everyone who participated in this year’s New England Drupal Camp – otherwise known as “NEDCamp.” A special thanks to those of you that attended my session and to the organizers for putting together an excellent conference!

Upon posting my presentation slides online (you can find them here:, I realized they’re not going to be terribly helpful since I am rarely inclined to condense all of my talking points into a slideshow. Therefore, I decided to write a two-part blog that will elaborate on crucial points I made during the presentation; this first post will focus on task prioritization and keeping all your projects and clients straight.

Throughout my presentation, we discussed different things to consider when trying to prioritize multiple projects. Three categories come into play for me when determining overall priority: 1) Client; 2) Tasks, and; 3) Other factors.

In this corner of our industry, we work with individual clients of varying sizes. It‘s therefore essential for us to understand each client’s priority.

There are six factors I take into account when prioritizing my client accounts:

  1. Budget. This is generally the only factor people use in prioritization.
  2. Client Deadlines. In my kick-off meetings, I always talk about deadlines with my clients. Questions such as, “Do you have any contracts ending we need to know about?” “How about internal blackout dates?” “Any launches coming up?” Asking these questions can give us a lot of insight to the client expectations as well as what is important to them. This is also a great start for a candid conversation around those dates and expectations.
  3. Growth potential. If your current project with the client is a proof of concept or one of a series of projects, prioritize it as though you have those additional projects or the proof of concept was successful.
  4. Internal or external. Internal customers are often a bit more flexible with their deadlines and priorities with respect to external customers. Learn where that priority lies, and, if the project is critical to the organization, you need to know that when prioritizing as well.
  5. Partnership potential. This is something that can often be overlooked. If a client has potential for partnership (e.g., sending you more business, being vocal on social media, participating in a case study) take that into consideration when prioritizing.
  6. Relationship. If the relationship with the client is in a bad space, I want to make sure I take that into consideration and use the project as an opportunity to turn things around.

There are four factors for determining overall priority based on tasks:

  1. Importance. We’ll talk a lot more about importance vs. urgency in the next post, but, in short, a task is important if it moves you towards the goal of your project.
  2. Urgency. A lot of people equate urgency with importance, but these are distinct things. Urgency is deadline based and is not related to the project goals.
  3. Value. When picking what task to prioritize, higher value tasks will go to the top.
  4. Effort. If a task is low effort, but still important, those will often get prioritized just to get them complete and out of the way.

Other factors I take into account when looking at my priorities are:

  • Political ramifications
  • Overall impact
  • Overall risk to the project, client, and relationship.

When taking these factors into account, I consider the whole picture when determining my priorities. Going off just one or two of these can lead to dangerous blind spots for your projects.

Another challenge to managing multiple projects is to keep everything straight when it comes to client teams, deadlines, schedules, and resources. For all aspects of your projects, nothing is going to replace hard work. Take the time to learn your projects, teams, deadlines, schedules, and resources. Putting time into this will save time in the long run as well as potential embarrassment in front of your clients.

Be specific in your notes and don’t assume you’ll know what you mean later. It’s easy to fall into the trap of “I’ll remember what I meant,” but don’t take it for granted. If you’ve switched topics and projects three times since your notes, you probably won’t remember. Aim to write your notes as if another team member will be reading them.

For your clients, don’t underestimate the power of face time and building relationships. This not only helps you keep things straight, but also essential to a successful project. While we don’t always have the luxury of traveling to client site, there are things like conferences, hangouts, and Skype to help grow these relationships.

The first thing I do when assigned a project is read the statement of work (SOW) or contract. Knowing the documented details helps me keep things straight and facilitates conversations about changes and expectations.

Schedules, deadlines, and resources often require similar different tactics. For all three of these, I recommend you keep a master calendar. Know who is working on what and when. This will avoid overscheduling as well as insight into your team members’ priorities.

There is a good chance your resources are working on more than just your projects. Get to know your team members’ priorities. Your number one project may be number three for them. Knowing these priorities can help you schedule accordingly.

In the upcoming second half of this series, we’ll discuss common pitfalls to managing multiple projects and how to best utilize your quieter times to make your busy times more manageable.


Like this story? Follow us on Facebook and share your thoughts!

DrupalProject Manager
Catégories: Elsewhere

Dries Buytaert: Nasdaq using Drupal 8 for new Investor Relations websites

Planet Drupal - mer, 19/10/2016 - 16:59

I wanted to share the exciting news that Nasdaq Corporate Solutions has selected Acquia and 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, 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 Facebook, are now eligible to start using Drupal 8 for some of their most critical websites. If you want to learn more, consider attending Acquia Engage in a few weeks, as Nasdaq's CIO, Brad Peterson, will be presenting.

Catégories: Elsewhere

Third & Grove: Third & Grove releases a Hybris Drupal integration module

Planet Drupal - mer, 19/10/2016 - 16:58
Third & Grove releases a Hybris Drupal integration module mike Wed, 10/19/2016 - 10:58
Catégories: Elsewhere


Subscribe to jfhovinne agrégateur