Kristof De Jaeger: Configuration split: deploy subsets of configuration in Drupal 8

Planet Drupal - Mon, 28/11/2016 - 11:01
Written on November 28, 2016 - 11:01

From the Configuration split project page: "The Drupal 8 configuration management works best when importing and exporting the whole set of the sites configuration. However, sometimes developers like to opt out of the robustness of CMI and have a super-set of configuration active on their development machine and deploy only a subset. The canonical example for this is to have the devel module installed or having a few block placements or views in the development environment and then not export them into the set of configuration to be deployed, yet still being able to share the development configuration with colleagues."

This small utility module for Drupal 8 allows you to exactly achieve this use case (and many others). I will cover two common scenarios, explaining how to configure your site and which commands you need to run:

  1. Have (development/ui) modules installed on your dev environment, uninstalled on production
  2. Have modules installed on your production environment, but not on development

I've also recorded a screencast in which I configure and run all the commands explained underneath. The best way in the end is to play around with the module itself of course.

Configuration split 101

Configuration split exposes a configuration entity which controls what you want to split off. Currently you can

  • blacklist modules: any configuration that this module owns will automatically be blacklisted too.
  • blacklist configuration: settings or configuration entities. These will be removed from the active sync directory.
  • graylist configuration: settings or configuration entities. These will not be removed if they are in the active sync directory, but also not exported if they are not there yet. I won't cover this functionality in this article post, that will be for another time.

After you configured one or more configurations split entities, you can use the drush commands to export and import configuration, based on one or more of those config entities. When it comes to exporting configuration, you can not use the existing drush core command (config-export / cex). Using drush config-import (cim) or the UI to import may still be used, but this depends on your setup. Drupal Console commands are under revision.

Each config split entity defines the directory in which the splitted configuration will live in case there are some. Not all modules define configuration, so there's a possibility that this directory is empty after you do an export.

An important technical aspect is that the module does not interfere with the active configuration but instead filters on the import/export pipeline. What simple happens is this: just before the actual writing, it will check the configuration and remove any entries that you don't want to be there. Then your active configuration is written away. Config that doesn't belong into the active configuration will be moved to separate directory. On import, the opposite happens: it will merge settings back in and set modules to the installed state just before core configuration then starts importing.

Last, but not least: you can swap the config.storage.sync service so that the synchronize screen will use the config split config entities for importing. More information is in the README file and in the video.

Scenario 1: modules installed on dev, not on production

Step 1

After you installed the module, go to 'admin/config/development/configuration/config-split' and click on 'Add configuration split'. Naming is important, so we'll enter 'Dev split' as the name for this configuration. We'll also create a directory called 'sync-dev-split'. Now toggle the modules that you don't want to have installed on production. In this case, we're going to blacklist Devel, Devel Kint, Field UI, Views UI and database logging. Additionally, also toggle system.menu.devel. This configuration is owned by the system module, so there's no dependency on the devel module. There's no problem having this config on your production site though, so it's not required to blacklist it.

Optionally, you can also blacklist the configuration split module because it doesn't necessarily have to be installed on production. We're not doing that here, because in the second scenario, we're building further on this one and we want to have it installed on the production environment as well.

Step 2

Go to your command line interface and run following command:

swentel@dev:/home/drupal/drupal-core$ drush csex --split=dev_split

The split option is not required, but when starting to work with the module, it helps you to know which config split will be used for this command. It's possible to override the status of any config split config entity so that eventually, you can omit the split option. Sadly enough, you don't get any feedback (yet), but after the command has run you should see various files in your sync-dev-split directory:

swentel@dev:/home/drupal/drupal-core$ ls sync-dev-split/
dblog.settings.yml  devel.settings.yml  field_ui.settings.yml  system.menu.devel.yml

Step 3

You can now commit your active sync and go to production. You don't necessarily have to put the sync-dev-live directory in your version control because production doesn't need to know about these files at all. Once you have pulled on production, go to the synchronize screen to verify what is staged. You will see that the setting files will be removed and core.extension will be changed uninstalling the development modules and installing configuration split. Since we only have one config split configuration, you can hit 'Import all' here or run drush config-import, (which is the drush core command). Note that if you don't use the UI, you can blacklist the configuration manager module as well.

You might wonder why we don't use the 'config-split-import' command from the module itself: this would import the active sync directory and also include the modules and settings again that we have blacklisted. And that's not what we want. This seems confusing at first, but ultimately, if this is your setup, you just keep on using the core / drush commands to import your staged configuration on production.

# This command can be used now, but not anymore further on when we will add scenario 2.
swentel@live:/home/drupal/drupal-core$ drush cim Scenario 2: modules installed on production, not on dev

Step 1

This scenario builds further on the first one. Config split is now installed on our live website. Create a new config split configuration called 'Live split'. You will need a new directory for this second config split, so make sure it's there. On production we still want to log events and for that we're going to use the syslog module. Install the module, so that we can now blacklist it for the live split configuration.

Step 2

Go to your command line interface and run following commands:

swentel@live:/home/drupal/drupal-core$ drush csex --split=live_split

Again, no feedback here, but after the command has run you should see the syslog settings file in your sync-live-split directory:

swentel@live:/home/drupal/drupal-core$ ls sync-live-split/
syslog.settings.yml Doing exports and imports on dev or live

From now on, if you want to import new settings whether it's on your dev or live environment, you can not use the drush core commands anymore. Use following commands:

# to export on your dev environment
swentel@dev:/home/drupal/drupal-core$ drush csex --split=dev_split
# to import on your dev environment
swentel@dev:/home/drupal/drupal-core$ drush csim --split=dev_split
# to export on your live environment
swentel@live:/home/drupal/drupal-core$ drush csex --split=live_split
# to import on your live environment
swentel@live:/home/drupal/drupal-core$ drush csim --split=live_split The future

Please join us in the issue queue because there's still some work:

  • Optimize the user interface and allow wildcards
  • Add confirmation and feedback in the drush commands

Ultimately, this functionality should live in core. A core issue to discuss this is at https://www.drupal.org/node/2830300.

Categories: Elsewhere

ADCI Solutions: Drush

Planet Drupal - Mon, 28/11/2016 - 08:44


Drush is a command line utility for Drupal that allows to avoid or at least to speed up many kinds of routine tasks. Usually a developer deals with these Drush parts: Drush make, adding the extra Drush commands and tuning Drush and Drupal via configuration files. In this article we listed the main Drush commands, thoroughly described the Drupal website configuration process with the help of Drush, told about shell and Drupal site aliases and learned how working with Drush has changed in Drupal 8. We supplemented each description of working with a particular Drush part with code samples: please feel free to use these examples in your development workflow.


Drush (The Drupal Shell) is a command line utility for Drupal, which provides many commands to interact with Drupal, its modules, themes, etc. Drush is a great developer’s helper and it allows to avoid or at least to speed up many kinds of routine tasks.

There are many articles telling about different Drush commands and how they helpful are, so I'd like to focus on Drush configuration possibilities and do a quick overview on Drush commands and Drush make. When you use Drush all the interactions with a Drupal site happen by executing commands, but there are some other Drush parts you may deal with:

  • Drush make which is combination of a special definition stored in the (make) file and a few specific commands to build a Drupal site codebase;
  • possibilities to add your own Drush commands by writing code in the files called in a special way and placed properly;
  • tuning Drush and Drupal via configuration files and more.

Drush processes described below are not necessarily should be implemented together. Since it’s not an algorithm of working with Drush, but a descriptive compilation, you may refer to the any article’s part when needed.

Drush commands

As you already know,  an interaction with a Drupal site happens via Drush commands. The Drush core provides many commands for many different purposes, but I believe the most used Drush commands are:

  • drush pm-download (dl) - download one or several projects (the Drupal core, module, theme, distribution), so you don't have to visit drupal.org to download and then unpack projects one by one;

  • drush pm-enable (en) - enable (install, if wasn't enabled before) one or several modules or themes;
  • drush cache-clear (cc) - clear cache (routing, theme, all, Drush, etc. cache).

With Drush you also can:

  • make a full site backup;
  • update the Drupal core, contrib modules and themes;
  • run cron jobs;
  • execute SQL query;
  • block user account(s);
  • change Drupal settings;

and other.

Drush make

Drush make allows to create a ready-to-use Drupal site codebase including the Drupal core, modules, themes, etc., (but without installation) from a definition stored in the just one file. Drush make does the work for you:

  • downloads the Drupal core, modules, themes;
  • fetches code from Git, SVN repositories;
  • downloads and applies patches;
  • downloads .tar.gz and .zip archives in general;
  • downloads libraries in particular.

The Drush make file can be written in 2 formats: YAML and the older Drupal .info INI format similar to modules' .info. YAML is recommended though, since Drupal is switched to YAML for configurations (since Drupal 8).

There are 2 main commands to work with Drush make:

  • drush make example.make.yml docroot - make a Drupal codebase using the definition stored in the example.make.yml file;
  • drush make-generate example.make.yml - generate the make file from a current Drupal site.

In case you develop Drupal distributions with following publishing at drupal.org, you have to deal with Drush make anyway.

Drush make file example (in YAML):

core: 7.x api: 2 projects: drupal: type: core admin_menu: subdir: contrib ctools: version: "1.7" tao: type: theme download: url: "git://github.com/developmentseed/tao.git"Extending the list of Drush commands

New commands can be easily added to Drush, and many contrib modules provide their own Drush commands: there is the modulename.drush.inc file in the module containing Drush integration code in this case. For example:

  • drush fn-hook (Devel module) - shows a list of implementations for the particular hook;
  • drush generate-content (Devel module) - generates dummy content;
  • drush features-revert-all (Features module) - reverts all the configurations exported into modules via the Features module to the code state;
  • drush views-list (Views module) - lists all the views on the site.

It's also possible to add Drush commands outside of modules, for example, to perform some specific actions for deployment, so you don't have to create and install a module on the site just to be able to invoke these Drush commands.

Drush configuration

Drush as well as a Drupal site can be configured in the context of running Drush commands. Needed configurations are defined in the drushrc.php file (DrushRC = Drush Runtime Config). For example, it's possible to force some global options for the Drush commands like always answering "yes" to all the confirmation prompts, force some of the command-specific options, change some of the Drupal settings (like an emails handler class and so on).

Drush looks for the drushrc.php file in the following directories, one by one as listed below. The order is basically the same when Drush looks for the files containing additional Drush commands (if the commands aren't related to the particular module):

  • sites/{default|example.com}/drushrc.php - a site specific directory;
  • Drupal /drush and sites/all/drush directories;
  • /drush directory 1 level above the Drupal root;
  • as specified by --config (-c) option when running a Drush command;
  • User's .drush folder (~/.drush/drushrc.php);
  • /etc/drush/drushrc.php;
  • the Drush installation folder.

Let's see some examples (see the code comments for more info on what each setting means):

/** * Drush commands configuration. */ // Force verbose mode for all commands. $options['v'] = 1; // Answer "yes" to all confirmation prompts. $options['y'] = 1; // Force --notes option for pm-update command. $command_specific['pm-update'] = ['notes' => TRUE]; // Use admin/admin as superuser credentials when installing Drupal site. $command_specific['site-install'] = [ 'account-name' => 'admin', 'account-pass' => 'admin', ]; /** * Site configuration. */ // Change site name. $options['variables']['site_name'] = 'My Drupal site'; // Use different theme. $options['variables']['theme_default'] = 'minnelli'; // Disable clean URLs. $options['variables']['clean_url'] = 0; // Use different directory for temporary. $options['variables']['file_temporary_path'] = '/home/vagrant/tmp'; /** * SQL dump and structure tables. */ // List of tables to export structure only without data on dump. $options['structure-tables']['common'] = [ 'cache', 'cache_*', 'history', 'search_*', 'sessions', ]; // Force "common" structure tables list by default on sql-dump command. $command_specific['sql-dump'] = [ 'structure-tables-key' => 'common', ]; Shell aliases

Drush also allows to define short aliases for a command or a number of commands, potentially used with a number of set options, via drushrc.php file, and this is not limited by Drush commands only.

// drush wipe $options['shell-aliases']['wipe'] = 'cache-clear all'; // drush pulldb $options['shell-aliases']['pulldb'] = '!git pull && drush updatedb'; // drush offline $options['shell-aliases']['offline'] = 'variable-set -y --exact maintenance_mode 1'; // drush online $options['shell-aliases']['online'] = 'variable-delete -y --exact maintenance_mode'; // drush unsuck $options['shell-aliases']['unsuck'] = 'pm-disable -y overlay, dashboard'; The lines starting with ! are not Drush commands, the lines without ! - are supposed to be Drush commands and the leading drush word is not needed in this case.

As it was shown, Drush allows to shorten the entered commands (executed at the command line) via different configurations, and to properly configure a Drupal site when you interact with it via Drush. All of these decrease an amount of routine actions and speed up the process of dealing with Drupal as a result.

Drush site aliases

Let’s expand on an interaction with Drupal via Drush. Usually, the interaction and an execution of some commands require that you have to navigate to the Drupal root directory first. If it’s a Drupal multi-site you need to navigate deeper to the site directory (sites/site-name), or explicitly set --uri (a site address when the site is opened in a browser) and --root (a path to the Drupal root directory) options when executing a Drush command. With the help of Drush site aliases all of these can be shortened to drush @example.com status with no difference from where the command is executed.

Drush site aliases can be defined in the file similar to drushrc.php, and Drush looks for this file in the same places it looks for drushrc.php. To define the site alias you just need to set uri and root properties.

// drush @example status $aliases['example'] = [ 'root' => '/var/www/example.dev/docroot', 'uri' => 'http://dev.example.com', ];

There are 3 ways to name the file where the site aliases are defined:

  • ALIASNAME.alias.drushrc.php - commands are executed like drush @ALIASNAME status;
  • aliases.drushrc.php - commands are executed like drush @ALIASNAME status;
  • GROUPNAME.aliases.drushrc.php - commands are executed like drush @GROUPNAME.ALIASNAME status.

The 3rd way is convenient for defining several instances / environments of the same site:

/** * @file * example.aliases.drushrc.php */ // drush @example.dev status $aliases['dev'] = [ 'root' => '/var/www/example.dev/docroot', 'uri' => 'http://dev.example.com', ]; // drush @example.stage status $aliases['stage'] = [ 'root' => '/var/www/example.stage/docroot', 'uri' => 'http://stage.example.com', ];

It's also possible to execute a command for all sites in a group simultaneously:

drush @example status

Actually, Drush allows to interact via the site aliases not with local sites only, but also with remote sites. In this case, you need to set a few more properties, at least remote-host and remote-user (but there are more options available).

$aliases['example.stage'] = [ 'remote-host' => 'server.example.com', 'remote-user' => 'www-admin', 'root' => '/var/www/example.stage/docroot', 'uri' => 'http://stage.example.com', ];

When you deal with the remote sites, you definitely want to avoid any mistakes: this can be done by adding a validation via Drush command hooks:

/** * @file * policy.drush.inc */ /** * Implements drush_hook_COMMAND_validate(). */ function drush_policy_sql_sync_validate($source = NULL, $destination = NULL) { // Deny sync to prod/production. if (preg_match("/^@.*prod/i", $destination)) { return drush_set_error('POLICY_DENY', dt('Nope.')); } }

Basically this is the same way how new Drush commands are added, so file naming is the same. In this particular case there is a convention to call this "Policy".

Drush contains a number of special commands for usage with the remote sites and the sites aliases.

drush core-rsync @site.remote:db.sql @site.local:backup/ drush core-rsync @site.remote:%files/ @site.local:%files/

- to rsync the Drupal tree to/from another server using ssh. %files is a special token pointing to a public file uploads directory, but there are more tokens available and custom ones may be defined via path-aliases site alias property.

drush sql-sync @site.remote @site.local

- to copy the database content from a source site to a target site, a database dump is transferred via rsync.

To connect to the Drupal site's server via SSH for an interactive session:

drush @site.remote site-ssh

or to run a shell command:

drush @site.remote site-ssh ls -la drush @site.remote core-execute ls -la drush @site.local core-execute ls -la Drush and Drupal 8

There are many changes in Drupal 8 in comparison with the previous version. When it comes to Drush, there are no big difference in dealing with a Drupal site. Probably the most noticeable change is that there is no more drush cache-clear all to flush all the caches. There is drush cache-rebuild instead. The another kinds of caches can still be cleared via drush cache-clear. An interaction with Drupal 8 via Drush requires Drush 8 version and newer.

Also there is few new Drush commands to interact with things specific to Drupal 8:

config-edit (cedit) config-export (cex) config-get (cget) ...

- to deal with configurations;

state-get (sget) state-set (sset) ...

- to deal with states.


Drush is a great tool which can help you with a Drupal site building, development and maintenance, and it noticeably speeds up these processes. The main part of  Drush is its commands, of course, but you can also tune Drush and Drupal (in context of interaction via Drush) for your own needs via configuration files, you can add custom commands like contrib modules often do, build a Drupal site codebase from a single file, deal with remote Drupal sites via Drush site aliases and more. Drush exists for a long time, but it's still a must-have: a very stable, well maintained and always evolving tool for Drupal. Stable and actively maintained Drush version for that moment is 8.x (you need this version or newer to deal with Drupal 8), Drush 9.x is in alpha and is being actively developed.

The observed Drush parts and processes are definitely going to cross your development and site-building path, so make sure to save and share this article with fellow Drupal developers. Good luck!


Categories: Elsewhere

PreviousNext: Presentation: At 16 years of age - does Drupal have an identity problem?

Planet Drupal - Mon, 28/11/2016 - 01:44

At Drupal South 2016, I attempted to summarize some of my pain points with Drupal core.

The session 'At 16 years of age, does Drupal have an identity problem' is the result of this.

You can watch the recording, or download the slides below.

Categories: Elsewhere

DataSmith: Inconsistent nofollow handling in Drupal input formats

Planet Drupal - Sun, 27/11/2016 - 20:18
Inconsistent nofollow handling in Drupal input formats The Problem

Working on setting up commenting, which is highly suggested for sites who's content appears on Drupal Planet, I came across a bit of a confusing situation in regard to URLs in content. When using the "Limit allowed HTML tags and correct faulty HTML" filter, one of the option is to add rel="nofollow" attributes to anchor tags. However, in the default Plain Text format, the "Convert URLs into links" filter does not provide that option. So if a user types in an HTML anchor, nofollow gets added. But if they type in a plain URl, it gets converted to an HTML anchor without the nofollow.

To illustrate, if I allow anchor links to be entered as html and set the option to add rel=nofollow and I also enable the filter to convert URLs to links, if a user enters:

www.nytimes.com Another NY Times link

The output HTML in the comment is:

Another NY Times link

For commenting, I really want to tighten permissions down as far as I can to avoid potential security risks, so the Plain Text format with the "Display any HTML as plain text" filter is the best choice1. However, for usability I do want URLs converted to links. But I also want those links set to nofollow for link fraud prevention2.

By playing with format filter configurations and ordering I was able to make a solution that works (albeit a little janky-ly), but it sure feels like this is an area where a core patch could improve the situation. If I have time one day maybe I'll work on that3.


The solution I came up with is to set the following filters on the input format (the order is significant):

  1. Display any HTML as plain text
  2. Convert URLs into links
  3. Convert line breaks into HTML (i.e.


  4. Limit allowed HTML tags and correct faulty HTML

Then for the allowed HTML tags, I allowed <a href hreflang> <p> <br> and checked the `Add rel="nofollow" to all links` option.

The result is that user entered HTML is rendered as plain text, then URLs and line brakes get converted to HTML, and finally the Limit allowed HTML filter double checks the markup and adds `rel="nofollow"` to anchor tags.  So given a user input comment like in the screen shot below, the resulting HTML is:

<h2>This should not be displayed as an h2 element.</h2>
<a href="If" rel="nofollow">www.example.com">If this is a link to example.com and not www.nytimes.com, you've failed.</a>
Comment preview showing the user entered comment, the resulting comment, and the help text.

Now, this solution is not perfect. Mostly, it's hinky to set up and I hate that I have to allow any HTML, even if user input is first stripped to plain text. Secondly though, it's also a user experience problem. As you can see in the picture above, the help text says that no html is allowed and that the anchor, break, and paragraph tags are allowed.


1. using the core commenting facility at least. Add on tools like Disqus obviate the issue but I don't want to go that route. I also don't want to require (or even allow) users to register before commenting. And yes, I do require approval of comments before they are visible, but I don't want to have to remember to add rel=nofollow in links.

2. Yes. I want to eat my cake and have it too.

3. I was put on this earth to achieve certain things. At this point I'm so far behind I'll never die.

Barrett Sun, 11/27/2016 - 13:18 Tags Add new comment
Categories: Elsewhere

Drupal Modules: The One Percent: Drupal Modules: The One Percent — Sticky Navigation (video tutorial)

Planet Drupal - Sun, 27/11/2016 - 18:39
Drupal Modules: The One Percent — Sticky Navigation (video tutorial) NonProfit Sun, 11/27/2016 - 11:39 6

Here is where we look at Drupal modules running on less than 1% of reporting sites. Today we'll consider Sticky Navigation, a module which allows you to easily ensure your navigation remains within the viewport.

Categories: Elsewhere

Justin Winter: shasum Checksum function

Planet Drupal - Sat, 26/11/2016 - 01:00
##New PHPStorm Version released today.##
Categories: Elsewhere

Drupal Modules: The One Percent: Drupal Modules: The One Percent — Field Display Label (video tutorial)

Planet Drupal - Fri, 25/11/2016 - 19:00
Drupal Modules: The One Percent — Field Display Label (video tutorial) admin_gg Fri, 11/25/2016 - 12:00 5

Here is where we look at Drupal modules running on less than 1% of reporting sites. Today we'll consider Field Display Label, a module which allows you to set different field labels for your creation and display pages.

Categories: Elsewhere

TimOnWeb.com: JQuery.cookie in Drupal 7

Planet Drupal - Fri, 25/11/2016 - 17:06

A quick tip for all Drupalistas outhere: if you want to use jQuery.cookie in your project, you actually don't have to download and install the library. jQuery.cookie is a part of Drupal 7 and can be included as easy as typing: 

  1. drupal_add_library('system', 'jquery.cookie');

Wondering to ...

Read now

Categories: Elsewhere

Ixis.co.uk - Thoughts: Social Media Cards: Metatag and semantic data

Planet Drupal - Fri, 25/11/2016 - 14:41

One requirement for our new Drupal 8 site was to implement the necessary markup to provide enough semantic data for services like Twitter, LinkedIn and Facebook to grab the appropriate node data (title, body and image) when sharing posts.

The Twitter developers documentation states that "with Twitter Cards, you can attach rich photos, videos and media experience to Tweets that drive traffic to your website. Simply add a few lines of HTML to your webpage, and users who Tweet links to your content will have a "Card" added to the Tweet that's visible to all of their followers." Facebook have a similar feature and corresponding documentation, as do LinkedIn.

Fortunately with the Metatag module enabling this functionality in Drupal 8 was a relatively painless task! All that was required was to install and enable the Metatag and Metatag: Twitter Cards modules (we're using 1.0-beta10 at the time of writing) and configure some basic, content-global settings.

Essentially, we ensure the card type is set to "Summary card" and that the description uses the [node:summary] token. We also want to provide an image for the summary card. We could provide the "Image URL" in the Twitter card setup which defines the twitter:image meta tag, however Facebook and LinkedIn use Open Graph for cards and we’d also have to provide the og:image metatag too.

This would cause two meta tags to be present in the header containing the same image URL, wasting bandwidth. Luckily, Twitter will fall back to the Open Graph tag if the twitter:image tag is not present so we only have to configure og:image tag.

We also configured several other Open Graph meta tags to support Facebook and LinkedIn.

We have only configured a subset of the tags available, but this gave us the basic card functionality we were after.

There are tools available to aid in development - allowing you to validate the meta tags and how they will render on social networks.. Your site has to be publicly accessible for these to work.

There are plenty of other guides available if you want more details about what you can do with the Metatag module, try these links:

Categories: Elsewhere

Cheeky Monkey Media: The Secret to Branding DrupalCon: A Stunning Example of a Brand and Web Style Guide

Planet Drupal - Thu, 24/11/2016 - 23:33
The Secret to Branding DrupalCon: A Stunning Example of a Brand and Web Style Guide chris Thu, 11/24/2016 - 22:33

Cheeky Monkey Media has been involved in the design and creation of the Drupal Association's North American DrupalCons since 2015.

  • DrupalCon Los Angeles in 2015 was inspired the work of Shepard Fairey and his propaganda/street art stylings.
  • DrupalCon New Orleans in 2016 was inspired by the rich French history and wrought iron that is so prevalent in New Orleans.
  • The upcoming DrupalCon in Baltimore in 2017 draws on the work of Edgar Allan Poe, and has a mysterious, almost moody edge to it.

Events of this scale take months of planning and preparation. The process and relationships between planning groups are key. The trick, however, is keeping all the moving pieces and deliverables (from the pins that get handed out to the signage guides the attendees to the website that handles all the registrations) consistent and on brand. That’s where our secret resource, the brand and web style guide, comes in.

Categories: Elsewhere

Lullabot: Past, Present, and Future of Drupal with Dries Buytaert and Matthew Tift

Planet Drupal - Thu, 24/11/2016 - 22:00
Matt and Mike talk with Drupal project lead Dries Buytaert and senior developer Matthew Tift to talk about the history of Drupal, what's currently going on, and what the future holds.
Categories: Elsewhere

qed42.com: Implementing #autocomplete in Drupal 8 with Custom Callbacks

Planet Drupal - Thu, 24/11/2016 - 17:29
Implementing #autocomplete in Drupal 8 with Custom Callbacks Body

Autocomplete on textfields like tags / user & node reference helps improve the UX and interactivity for your site visitors, In this blog post I'd like to cover how to implement autocomplete functionality in Drupal 8, including implementing a custom callback

Step 1: Assign autocomplete properties to textfield

As per Drupal Change records, #autocomplete_path has been replaced by #autocomplete_route_name and #autocomplete_parameters for autocomplete fields ( More details -- https://www.drupal.org/node/2070985).

The very first step is to assign appropriate properties to the textfield:

  1. '#autocomplete_route_name':
    for passing route name of callback URL to be used by autocomplete Javascript Library.
  2. '#autocomplete_route_parameters':
    for passing array of arguments to be passed to autocomplete handler.
$form['name'] = array( '#type' => 'textfield', '#autocomplete_route_name' => 'my_module.autocomplete', '#autocomplete_route_parameters' => array('field_name' => 'name', 'count' => 10), );

Thats all! for adding an #autocomplete callback to a textfield. 

However, there might be cases where the routes provided by core might not suffice as we might different response in JSON or additional data. Lets take a look at how to write a autocomplete callback, we will be using using my_module.autocomplete route and will pass arguments: 'name' as field_name and 10 as count.

Step 2: Define autocomplete route

Now, add the 'my_module.autocomplete' route in my_module.routing.yml file as:

my_module.autocomplete: path: '/my-module-autocomplete/{field_name}/{count}' defaults: _controller: '\Drupal\my_module\Controller\AutocompleteController::handleAutocomplete' _format: json requirements: _access: 'TRUE'

While Passing parameters to controller, use the same names in curly braces, which were used while defining the autocomplete_route_parameters. Defining _format as json is a good practise.

Step 3: Add Controller and return JSON response

Finally, we need to generate the JSON response for our field element. So, proceeding further we would be creating AutoCompleteController class file at my_module > src > Controller > AutocompleteController.php.

<?php namespace Drupal\my_module\Controller; use Drupal\Core\Controller\ControllerBase; use Symfony\Component\HttpFoundation\JsonResponse; use Symfony\Component\HttpFoundation\Request; use Drupal\Component\Utility\Tags; use Drupal\Component\Utility\Unicode; /** * Defines a route controller for entity autocomplete form elements. */ class AutocompleteController extends ControllerBase { /** * Handler for autocomplete request. */ public function handleAutocomplete(Request $request, $field_name, $count) { $results = []; // Get the typed string from the URL, if it exists. if ($input = $request->query->get('q')) { $typed_string = Tags::explode($input); $typed_string = Unicode::strtolower(array_pop($typed_string)); // @todo: Apply logic for generating results based on typed_string and other // arguments passed. for ($i = 0; $i < $count; $i++) { $results[] = [ 'value' => $field_name . '_' . $i . '(' . $i . ')', 'label' => $field_name . ' ' . $i, ]; } } return new JsonResponse($results); } }

We would be extending ControllerBase class and would then define our handler method, which will return results. Parameters for the handler would be Request object and arguments (field_name and count) passed in routing.yml file. From the Request object, we would be getting the typed string from the URL. Besides, we do have other route parameters (field_name and Count) on the basis of which we can generate the results array. 

An important point to be noticed here is, we need the results array to have data in 'value' and 'label' key-value pair as we have done above. Then finally we would be generating JsonResponse by creating new JsonResponse object and passing $results.

That's all we need to make autocomplete field working. Rebuild the cache and load the form page to see results.

PURUSHOTAM RAI Thu, 11/24/2016 - 21:59
Categories: Elsewhere

Palantir: Palantir.net's Guide to Digital Governance: Personal Websites

Planet Drupal - Wed, 23/11/2016 - 21:38
Palantir.net's Guide to Digital Governance: Personal Websites Palantir.net's Guide to Digital Governance brandt Wed, 11/23/2016 - 14:38 Scott DiPerna Nov 28, 2016

This is the tenth installment of Palantir.net’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...
  • The context you should consider based on what type of institution you are
  • Questions you should think about regarding affiliated websites run by individuals at your organization

We want to make your project a success.

Let's Chat.

Depending on the type of organization for which you are writing a governance plan, you may need to address the issue of personal websites within the context of your institution’s web properties and server environment. For colleges and universities, the questions you need to answer will likely be in relation to faculty, students, and alumni. For businesses, the questions will relate to employees. For non-profits, it may be employees, trustees, and/or volunteers.

Regardless of who the people are, or what function they serve in the organization, if they have a website affiliated with your organization that they control, you probably want to have some guidance for how those properties relate to your organization. Here are some questions to consider for all types of institutions.

  • Are there services available for individuals in your organization to have a personal or independent web property (i.e. website, blog, social networking account, etc.)?
  • Who provides the service(s)?
  • How does an individual acquire the web property?
  • Who owns and maintains the web property?
  • Where is the web property hosted (i.e. whose servers)?
  • Who provides technical support for the web property?
  • What levels of support are provided (hosting, domain, programming, training, etc.)?
  • Who designs and produces the property?
  • Are there guidelines related to visual appearance?
  • What happens to the web property if the owner leaves the organization?
  • Are there subject matter limitations or guidelines for personal sites?
  • Is there any form of review process for content on personal websites?
  • What happens if a personal website owner violates subject matter guidelines?
  • Who is responsible for costs related to personal web properties?
  • Are outside or 3rd-party vendors permitted to work on personal web properties?
  • How do 3rd-party vendors access the site and deliver changes?

This list is not an exhaustive checklist for personal website governance planning, but it is a good start that should unearth further questions and circumstances to consider for your plan.


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. URL Naming Conventions – 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.
Categories: Elsewhere

Acquia Developer Center Blog: Learn Drupal 8 for Free: Building a Basic Site Using Drupal 8

Planet Drupal - Wed, 23/11/2016 - 18:21

When we last checked in with Rod Martin, in a previous post, he was touring the Drupal 8 interface. In this course, Building a Basic Site Using Drupal 8, he shifts into tutorial mode, deliberately moving step by step through the creation of a fictional Drupal 8 site, Drupalville, which he describes as a site about “all things Drupal.”

Tags: acquia drupal planet
Categories: Elsewhere

Lullabot: Rebuilding POP in D8: Configuration Management

Planet Drupal - Wed, 23/11/2016 - 18:00

In my last article, I talked about new options for setting up a development environment in Drupal 8. Having done that, I need to setup a workflow for development as well as a process for deploying changes. Additionally, for this project, I have a partner that I need to share changes with before they go live. It would be really nice for her to be able to preview these changes and push them live after review.

As mentioned in my last article, I have a pretty basic setup for this project. I am doing work on my local laptop, and I have a private repository on Github for my code, and two virtual hosts on my hosting provider. One is a preview site that is password-protected so that we can review changes as they go live, and one is the production website.


There is no custom code at all in the Pinball Outreach Project website outside the theme (and precious little there), but there is a lot of custom configuration that needs to be pushed around. Additionally, some of that configuration is tough to test outside of a site that is publicly accessible. Thankfully, Drupal 8 brings the gift of CMI.

The simplest workflow

I realize I may be biased, given my role as the former CMI initiative lead, but I have to say, the D8 configuration management system is an absolute joy. It allows a variety of workflows and performs precisely as advertised. I created a pretty simple workflow for this project, but one of the beauties of the system is that you can create a workflow as simple or complex as needed.

Using the built-in Configuration Synchronization tool that ships with Drupal 8 provides the simplest possible workflow. Go to:


...and download your site's entire configuration as a tarball. You can then go to:


...on the destination site and upload that tarball into the new system. Once you have uploaded your configuration, you are presented with a list of the items that have changed and have the opportunity to review each one.

undefined undefined

In this example, I have changed the view called 'Press' to sort descending instead of ascending. If you are happy with these changes, then you can click Import All to integrate them into your site.

While this doesn't give you all the functionality a more technical user might require, it works and would be sufficient for a simpler site.

My workflow

I wanted to have a little more control over my configuration and maintain the ability to experiment and roll those changes back if I decided I didn't like them. My process, which is still basic as deployment workflows go, works like this:

  • I make some changes through the admin UI on my local development environment.
  • I open up a terminal to this environment and run drush config-export -y from the project's root directory. This exports all configuration to your config export directory (see the last article in this series for details about how that is set up.)
  • Again, in terminal, I run the git status command to check that my configuration changes are what I expect them to be. If all has gone well, I should see that some configuration files have been modified in my config export directory, and this configuration should only be related to the changes I just made.
  • I add the changes to git (git add), commit (git commit -m) and push them (git push).
  • Next, I SSH to the destination environment and pull the changes down (git pull).
  • Finally, I run drush config-import -y from the project's root on the remote server. This command imports the configuration changes I pulled down from git.

While this might seem like a pretty simple workflow, it is incredibly powerful, especially if you are used to the Features workflows prevalent in Drupal 7. First off, it allows you to be as granular as you want with your commits. I can commit a change as simple as adjusting a View's sort order or as large as an entire collection of new content types. With my changes in version control, I can roll them back as easily as I can import them (mostly, some content type/field changes cannot be rolled back.) Keeping changes as simple as possible can also help minimize merge conflicts in projects with multiple developers.


This process will work between any source environment and any destination environment, assuming the two environments are instances of the same site. Clearly, it is both ideal and easy to make changes locally and push them live, but that is not always the best option. For instance, while setting up Metatag module, I realized it would be much easier to test from a publicly accessible environment. So I went to the live site and tweaked my settings to where I wanted them, then exported and committed these changes and brought the changes back down to my local. In another case, I was on the phone with my partner who was viewing some changes on the preview site. As she was making comments and asking for changes, I made them until we were both happy with them. Then, I could merge those changes down to my local before pushing them live.

In many cases, this setup will not be workable. As the sole dev and site admin, it works for me because I know exactly what is going on all the time and I can make sure that the changes I'm making won't overwrite someone else's work. Nevertheless, there's no reason this model couldn't be expanded to work with multiple developers. For instance, you could lock down the live site so that its admin is read only (simple with a module like Config Read Only) and then come up with an automated or user-instantiated process to make those changes live. This could also pretty easily be expanded to a multi-developer environment.

More advanced options

Here at Lullabot we have already started talking through some different options for our more advanced projects. In one case, we ended up going back to Features. The client already had a Features-based workflow for their D7 site and was reluctant to change to a totally new system. Additionally, they maintained a network of sites based on a common core repository or “distribution.” We needed to get off the ground quickly with something we already understood rather than figuring out a config workflow that would work. Features offered us that.

Alex Pott has proposed another workflow that involves shipping your config with an install profile. In this scenario, your configuration lives in your install profile, and you essentially rebuild your entire site from scratch when you push changes. This works especially well with advanced composer-based workflows in which your assets are scattered and imported as part of your build process. Additionally, this setup can get around some technical problems involving the way Drupal 8 assigns UUIDs to configuration. For more information on this, see the presentation he did with fellow Lullabot Matthew Tift at DrupalCon New Orleans.

As we get farther and farther into the Drupal 8 cycle, we will see a ton more workflows and processes around configuration management and deployment. Some will be use-case specific, some will end up becoming best practices, and some will probably just be weird. I wouldn't have it any other way because it means the configuration management system works for site owners and not the other way around.

Next in the series, I will talk about some interesting things D8 has enabled around theming and templating.

Header photo by Karl Lind Films

Categories: Elsewhere

FFW Agency: Announcing Docksal, a Docker-Based Development Environment

Planet Drupal - Wed, 23/11/2016 - 17:48
Announcing Docksal, a Docker-Based Development Environment leigh.anderson Wed, 11/23/2016 - 16:48

At FFW, 90% of our staff spends all day, every day, working with code. We’re site builders and developers, and we’ve created a number of tools to help make our jobs easier. Today, we’re excited to share our Docksal development environment with you in the hopes that it will make your team’s life easier, too.

Docksal is an open-source tool created by FFW for defining and managing development environments. It brings together common development tools, minimizes time spent on configuration, and ensures the consistency of local development environments throughout a team’s continuous integration workflow.

Docksal automatically configures each project's environment to ensure team members are using the same tools, and versions, regardless of the individual requirements of each project. Most importantly, it makes the entire process easy. Docksal offers fully containerized environments with Docker, provides cross-platform support (MacOS, Windows, and Linux,) and has built-in tools that include:

  • drush
  • Drupal Console
  • composer
  • PHP Code Sniffer
  • Apache Solr
  • Varnish
  • Memcache
  • Built-in testing support with Behat and Selenium.

Docksal will even automatically configure virtual hosts for you, so no more editing host files and server configurations.

How can Docksal help your organization?

Docksal has a threefold value proposition. It improves time-to-market and quality on development projects through:

  1. Bringing together common development tools on a unified platform
  2. Minimizing time spent configuring development environments
  3. Assuring quality by ensuring that local environments are consistent across a team’s continuous integration and development workflow.

Docksal makes it easy to bring new team members onto projects in no time flat: the software allows them to get set up and running easily and quickly. We built Docksal to streamline the process of adding team members to our projects: previously, they’d have to go find the code for the project, get it set up on their laptop, get it to work with everything on their laptop, perform a database dump, get the site running. We wanted to simplify this process.

Docksal reduces the work of several hours to several minutes. Our developers don’t have to waste time figuring out why the code isn’t working with the configurations they have on their computers, and our teammates who aren’t code-oriented don’t spend frustrating hours trying to simply access the project. With Docksal, anyone can get a specific Drupal environment set up and running on their machine in two minutes -- and everyone is running the same environment, which acts as an important check on quality and consistency.

Our suite of development tools

Docksal’s features may sound familiar to those of you who previously used our Drude tool. That’s because Docksal is Drude renamed and expanded. Docksal doesn’t just work with Drupal: it works with WordPress, stand-alone HTML files, or any other PHP project— because even though we all love Drupal, sometimes we have to work with other technologies, too.

In addition to Docksal, we’ve also created another development tool called CIBox. CIBox (Continuous Integration toolbox) is a development workflow tool that simplifies the process of checking changes to each project’s codebase. CIBox uses continuous integration -- the process of immediately testing new code when it’s contributed to a project -- to support a truly Agile development process.

CIBox allows developers to have an unlimited number of testing environments, deployment plans, and additional automations. It supports a continuous integration server dedicated to running site builds and tests, as well as a toolbox of scripts for Code Driven Development with Drupal, Wordpress, Symfony, Sylex support. It offers deployment plans and skeletons, and an improved QA workflow from most CI tools. Stay tuned for an upcoming blogpost that speaks to CI Box in more detail.

Try the software for yourself

Docksal and CIBox are both great tools for building projects and managing development environments. Both have saved us a lot of time and ensured that we have streamlined, quality-focused processes.. To get Docksal for yourself, visit docksal.io for downloads and more information, or to try CIBox, check here.  We hope that you give them a try — we think they’ll make your life better, too.

Categories: Elsewhere

Unimity Solutions Drupal Blog: Drupal + Alfresco - A Next Gen Content Strategy

Planet Drupal - Wed, 23/11/2016 - 13:22

Organizations are using Enterprise Content Management (ECM) to manage their digital content. ECM is used to manage traditional documents like: word, excel, ppt and pdfs that are created with complex workflows. ECM is popular in the Financial Services, Medical Services, Manufacturing, Government and Publishing. ECM brings with it storage, versioning, workflows and highly customizable metadata models.

Categories: Elsewhere

Drupalize.Me: Free Exercise Series for Building Drupal Sites

Planet Drupal - Wed, 23/11/2016 - 10:00

We're happy to announce a new kind of series on Drupalize.Me which provides a project for you to practice the skills you've learned in Drupal site building, theming, and module development. Our free Hands-On Exercises: Movie Project provides you with wireframes and customer requirements for a movie review site. Each exercise in the series has you progressively build the site according to the specifications. To help you along the way, each lesson also lists some tutorials and learning resources that will show you what kind of knowledge you need to have to accomplish the given tasks.

Categories: Elsewhere

Agiledrop.com Blog: AGILEDROP: Drupal Camps in Europe

Planet Drupal - Wed, 23/11/2016 - 07:10
Our world tour is far from over. This time it continues with Drupal Camps in Europe. After already exploring Drupal Camps that take place in Africa, Asia and North America, it's time for the continent from which our company comes from. We concluded that Drupal Camps are the most frequent in North America, followed by Asia and Africa, which currently takes the last place. What about Europe? Which spot is reserved for it? Since Drupal was founded in Europe by Dries Buytaert – you can read about that too in our blog post –, we expected that Drupal activities and camps will be as frequent as in… READ MORE
Categories: Elsewhere

Drupal Modules: The One Percent: Drupal Modules: The One Percent — Office Hours (video tutorial)

Planet Drupal - Wed, 23/11/2016 - 04:17
Drupal Modules: The One Percent — Office Hours (video tutorial) NonProfit Tue, 11/22/2016 - 21:17 4

Here is where we look at Drupal modules running on less than 1% of reporting sites. Office Hours allows you to easily display repeating weekly time schedules.

Categories: Elsewhere


Subscribe to jfhovinne aggregator - Elsewhere