Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 15 hours 41 min ago

Palantir:'s Guide to Digital Governance: URL Naming Conventions

14 November 2016 - 8:50am's Guide to Digital Governance: URL Naming Conventions's Guide to Digital Governance brandt Mon, 11/14/2016 - 10:50 Scott DiPerna Nov 14, 2016

This is the eighth 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...
  • A recommended naming convention for URL paths
  • Some tips for choosing section names
  • Questions to consider when defining rules for redirects and aliases

We want to make your project a success.

Let's Chat.

A logical progression from Website organization is defining a naming convention for URL paths. URL paths should follow a consistent naming convention throughout all of your websites. Only under exceptional circumstances should a URL path name deviate from an established naming convention for a Website.

Best practices for URL path naming conventions recommend consistency in how sections, sub-sections, pages, and sub-pages are written. For most websites, I recommend URL paths follow the general naming convention below.

This basic structure gives users an idea of where they are in the site’s hierarchy of pages. This can be especially important considering the volume of traffic that enters the site from web searches that will bypass the homepage and take visitors directly into deeper pages in the site. It’s also a good practice for improving the SEO value of your site’s pages, as it provides more specific context for the content of the page.


Under this convention, SECTION is the top-level “directory,” and generally refers to the category under which subsequent content resides. For example, in the URL path, “About” is a primary category that often appears in a main menu, and thus receives a top-level URL path.

I generally like SECTION names to be one continuous string of letters without hyphens or underscores (e.g. about, services, people, etc.) because that makes for shorter top-level URL paths, however two word hyphens may also be acceptable if they aren’t too long. Given that top-level SECTION names are usually the label-names of your main navigation, it’s additionally wise to keep them clear, simple and concise.

Acronyms and abbreviations should be avoided because they often don’t make sense to visitors unfamiliar with the abbreviations. That being said, some abbreviations, such as, may work so long as they make logical sense to most visitors.

If your Website has multiple users who are able to write URL path names, I recommended defining in the governance plan some limitation for who may write top-level directory names. These are typically the most highly sought-after URLs in a Website, and you will want to have a well-defined process for how those are distributed and assigned. A free-for-all is probably not a good process.


SUB-SECTION is the second-level directory, if one exists. Using About as an example, “Meet Our Team” is the second-level “directory” in the URL path:

since “Meet Our Team” is just one of the sub-sections under “About” in this example.

SUB-SECTION names also may be one continuous string of letters without hyphens or underscores, such as:

or a string of words separated by hyphens:

The choice between the two really depends on whether the additional words add value to the user’s understanding of location, and/or if the string of words adds SEO value because it captures important descriptive words for the content of the page.

In the example above, the words “meet our” really don’t add much information, and the shorter URL path name is simpler. Simplicity may become more important as you add pages to sub-sections and the URL path names become very long.

Some URL path names may appear to deviate from this rule if a sub-section does not actually exist, in which case the sub-section location would be occupied by the page name.


Pages on the “Meet Our Team” site would then have a URL path structure of:

where PAGE-NAME could be any number of different page names. PAGE-NAMEs should generally describe the content of the page based on the page’s title. This can be expressed either as a single word (if a single word sufficiently describes the page), such as:

where “consultants” is a page for information about consultants on the team titled “Consultants”; or by a string of hyphenated words, such as:

where “website-consultants” is a page about Website consultants on the team titled “Web Consultants.”

For the purposes of SEO, at the page level, I generally prefer to include all of the keywords in a page’s title (separated by hyphens) in the URL path, especially when it adds descriptive value.


As follows, sub-pages for any of the pages in the “Meet Our Team” site would have a URL path structure: SUB-PAGE-NAMEs

should follow the same rules as PAGE-NAMEs, however sub-page names may require longer strings of hyphenated names as pages become more detailed and specific:

Conversely, if sub-pages are breaking out content into simpler categories, they may benefit from shorter names:

rather than:

All of that being said, you should determine the system that works best for your needs and stick to it. Just keep it simple, logical, and as memorable as possible so that it is easy for all users to implement.

Multiple-Word Names

When writing URL paths with multiple-word names, I recommend using hyphens, such as:

rather than underscores:

or concatenation:

Use of underscores makes it far too easy for a user to misread an underscore as a space, especially when the URL path is hyperlinked:

Most hyperlinks are underlined to indicate to users that a section of text is a hyperlink.

Concatenation is more obviously problematic because it simply creates confusing URL paths.

Aliases & Redirects

How URL path aliases and redirected URL paths are handled will depend on the policies of your organization and the platform you use for your Website. I highly recommend you define the rules and processes surrounding URL aliases and redirects in your governance plan, and here are some questions to consider along those lines.

  • How are URL aliases and redirects managed in your Web environment?
  • Who manages URL aliases and redirects?
  • Is there a process or procedure for requesting an alias or a redirect?
  • May anyone request a URL alias or redirect?
  • Are redirects to Websites outside of your domain or server environment permitted?
  • Who determines whether a URL alias or redirected URL path is appropriate or not?
  • Are there any special rules for using top-level directories as URL path aliases or redirected URL paths?


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

Drupal Console: Drupal Console RC-9 is out

14 November 2016 - 6:34am

Latest DrupalConsole rc-9 is out including several changes and fixes.

Support for command aliases

Aliases for commands added making easy to memorize by typing less. You can find aliases definition at

Support to execute the DrupalConsole Launcher on Windows platform

This PR fixes the `\vendor\bin\drupal.php` file not found error.

Execute DrupalConsole from any directory within your Drupal site

No need to stay at site root directory. You can now switch to any directory as modules, themes, web/modules/custom or any other directory within your Drupal site. This was possible using the DrupalFinder project

NOTE: Having a configuration file containing `root: web` on the site is no longer required. You can keep the file but is required to remove that value from your `path/to/drupal8/console/config.yml`

Improvements on the `init` command 

The interactive mode for the init command now ask you and show a list of directories where to copy the configuration files.

    Update instructions:

    Categories: Drupal

    Drupal Blog: Drupal 8 will no longer include dev dependencies in release packages

    11 November 2016 - 5:19pm

    As a best practice, development tools should not be deployed on production sites. Accordingly, packaged Drupal 8 stable releases will no longer contain development PHP libraries, because development code is not guaranteed to be secure or stable for production.

    This only applies to a few optional libraries that are provided with Drupal 8 for development purposes. The many stable required libraries for Drupal 8, like Symfony and Twig, will still be included automatically in packaged releases. Drupal 7 is not affected.

    Updating your site

    To adopt this best practice for your site, do one of the following (depending on how you install Drupal):

    • If you install Drupal using the stable release packages provided by (for example, with an archive like drupal-8.2.2.tar.gz or via Drush), update to the next release (8.2.3) as soon as it is available. (Read about core release windows.) Be sure to follow the core update instructions, including removing old vendor files. Once updated, your site will no longer include development libraries and no further action will be needed.
    • If you use a development snapshot on your production site (like 8.2.x-dev), you should either update to a stable release (preferred) or manually remove the dependencies. Remember that development snapshots are not supported for production sites.
    • If you install your site via Composer, you should update your workflows to ensure you specify --no-dev for your production sites.
    Development and continuous integration workflows

    If you have a continuous integration workflow or development site that uses these development dependencies, your workflow might be impacted by this change. If you installed from a stable package and need the development dependencies, you have three options:

    1. Install Composer and run composer install --dev,
    2. Use a development snapshot (for example, 8.2.x-dev) instead of a tagged release for your development site, or
    3. Install the development dependencies you need manually into Drupal's vendor directory or elsewhere.

    However, remember that these development libraries should not be installed on production sites.

    For background on this change, see Use "composer install --no-dev" to create tagged core packages. For more information on Composer workflows for Drupal, see Using Composer to manage Drupal site dependencies.

    Categories: Drupal blog: What’s new on - October 2016

    11 November 2016 - 12:43pm

    Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

    The Drupal Association team has been getting back to work after coming back from DrupalCon Dublin in September. For the engineering team, October has been focused on some back-end services and infrastructure that support the Drupal project, while we continue to move forward on some longer term front facing initiatives. updates Promoting Drupal by Industry

    Last month we talked about the new homepage we released for, and using those editorial tools to build a membership campaign. We hinted that additional changes will be coming soon. While we're not ready to launch this new content - we can talk about it in some greater detail.

    Dries Buytaert, the project founder, has called Drupal the platform for ambitious digital experiences. That phrase expresses the incredible power and flexibility of Drupal, but also encapsulates an aspect of Drupal that can be difficult for newcomers. It can be very hard for newcomers to Drupal to understand how to take a base install of Drupal core, and extend that to achieve that ambitious vision.

    We want to help close that gap in understanding—to help evaluators see how Drupal achieves these ambitions. To do this, we'll be creating a series of landing pages that focus granularly on how Drupal creates success stories in particular industries. Look for more on this topic in coming months.

    DrupalCon Vienna Site Launched

    As is tradition, during the closing session of DrupalCon Dublin we announced that the next DrupalCon in Europe will be held in Vienna! We launched the splash page announcing the event at and we have information about sponsorship and hotel reservations already available.

    DrupalCon Vienna will happen from the 25th to 29th of September 2017, and we'll hope to see you there!

    More flexible project testing

    We've made a significant update to how tests are configured on the Automated Testing tab of any project hosted on Automated testing, using the DrupalCI infrastructure, allows developers to ensure their code will be compatible with core, and with a variety of PHP versions and database environments. In October, we updated the configuration options for module maintainers.

    Maintainers can now select a specific branch of core, a specific environment, and select whether to run the test once, daily, on commit, or for issues. Issues are limited to a single test configuration, to ensure that the code works in a single environment before being regression tested against multiple environments on on-commit or daily tests.

    Better database replication and reliability

    Behind the scenes, we've made some updates to our database cluster - part of our infrastructure standardization on Debian 8 environments managed in Puppet 4. We've made some improvements to replication and reliability - and while these changes are very much behind the scenes they should help maintain a reliable and performant

    Response to Critical Security Vulnerabilities

    When it rains, it pours—a maxim we take to heart in Portland, Oregon—and that was especially true in the realm of security in October. The most widely known vulnerability disclosed was the 'DirtyCow' vulnerability in the Linux kernel. A flaw in the copy-on-write system of the Linux kernel made it possible, in principle, for an unprivileged user to elevate their own privileges.

    Naturally, responding to this vulnerability was a high priority in October, but DirtyCow was not the only vulnerability disclosed, as security releases were also made for PHP, mariadb, tar, libxslt, and curl. We mitigated each of these vulnerabilities in short order.

    Community Initiatives

    Community initiatives are a collaboration; with dedicated community volunteers building improvements to with the architectural guidance and oversight of the Drupal Association engineering team.

    Drupal 8 User Guide

    The Drupal 8 User Guide is getting very close to being available on We are working closely with contributor jhodgdon to resolve some perplexing inconsistencies between what we're seeing in our development environment and in our initial production deployment.


    markcarver who is currently leading the charge to port Dreditor features to, has invited anyone interested in contributing to join him in #dreditor on freenode IRC or the Dreditor GitHub.

    Documentation Maintainership

    Finally, we want to continue to encourage the community to become maintainers of Drupal documentation. If you are a developer interested in contributing code to the new documentation system, please contact tvn.


    As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who made it possible for us to work on these projects.

    If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

    Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

    Categories: Drupal

    MTech, LLC: Categorizing Migrations According to Their Type

    11 November 2016 - 10:05am
    Categorizing Migrations According to Their Type

    Very often in a migration of Drupal 6/7 to Drupal 8, have a need to run and test the migration many times. This applies more to sites that are very active, where site editors are updating or adding new content.

    Keep in mind that the Migration API in Drupal 8 offers a few paths to run migrations. The first is a user interface to make migrations through the path /upgrade. Through this method, the migration process is once and you can not make any customizations.

    The other method is to use drush to upgrade. And it is done by using these steps:

    Edys Meza Fri, 11/11/2016 - 12:05
    Categories: Drupal

    NEWMEDIA: Using the Haversine Formula in Drupal 7

    11 November 2016 - 8:05am
    Using the Haversine Formula in Drupal 7 John Fiala Fri, 11/11/2016 - 16:05 The Haversine formula is one of the easiest to use pieces of complicated math I've had the pleasure to use. If you're not familiar with it, it's pretty simple in theory - it's an extension of the Pythagorean formula from a grid to the surface of a sphere, which basically means that you can use it to measure the distance between two points on a sphere (1).

    "But what," I hear you ask through the secret microphone hidden in your keyboard, "does this have to do with Drupal?"  And the answer is - search.  I've worked on a number of projects over the years where users wanted to search for things which were some distance from a central point - a zip code, a city, or the like.  This can be done with apache solr these days, but sometimes apache solr isn't what you need. Either you’re not doing a keyword search and just filtering your nodes (show me all mexican restaurants near 12th and Vine) or else you don't think you need the extra complexity of adding an Apache Solr instance to the project.  An index of restaurants isn't a bad idea for an example, so let’s build one.  In the tradition of Drupal demos, we'll say we're creating a restaurant search engine, which we will name 'Shout'.  So, we spin up a copy of Drupal 7, set up the usual database, add a 'Restaurant' node type, download Fivestar* to do ratings, set up a few quick taxonomies (cuisine, price range [low, medium, high], and maybe style [sit-down, food court, fast food]) which we add to the restaurant node type.

    Step 1

    Create a node type with location information.  To store the address there’s two good options: the Location module, which grew out of CCK, and the Address Field module, which comes from the Commerce module.

    Step 2

    Add the latitude and longitude to the nodes - if you’re using the location module you can enable storing those values in the same field, but if you’re starting with the address field you need to add a field which stores that information.  I recommend the Geofield module.

    Step 3

    Finally, you will need to set up geocoding - the process of assigning latitude and longitude based off of an address.  There’s plenty of services which will do this for you, and if you’re using the location module, then you can enable it there.  Alternately you can use the Geocoder module to store these values.


    Following along with our Shout example, let's add the addressfield, geofield, and geocoder modules, which will also in turn require the geoPHP and ctools modules.  Add the Address field and tell it to store a postal address, set up a geofield on the restaurant node as well and set the widget to 'geocode from another field', and take a look at the configuration of geocoder in admin/config/content/geocoder.  You can use the google api in batch for free, as long as you don't get too crazy with the number of requests per day.  This being an example site, I think we'll be safe, but when doing a commercial site it's always best to read the Google terms of service,sign up for an API key, and close cover before striking.



    I've named the Address field field_address, and in a fit of originality I've named the geofield field_map_location.  Once I had everything set up, I entered a few local restaurants and ran cron to make sure that I was getting data in the field_data_field_map_location table - I suggest you do the same.  (Well, to be honest, at first I wasn't getting data, but that's why we test our examples when writing blog posts.)

    Step 4

    Once you've got locations set up, the next step is your search engine.  For this task I suggest the Search API module, which allows you to define your own indexes, and to switch search engines in the future as the need arrives.  You’ll also need the Search API DB and Search API Pages modules.

    Step 5

    We'll start by setting up a service - in this case, just gave it an obvious name and select the Database engine.


      Step 6

    Then we'll create an index - although Search API creates a Default node index when it's enabled, we want one just for restaurant nodes.  So we'll click on 'Add Index', give it a name of 'Restaurant Index', select that we want to index Restaurant Nodes, and put in a quick description to remind us of what it is, and select the server we just created.


      Step 7

    After that, go into index fields for the index and select at least the title and the 'main body text' for indexing - I suggest including the address as well.  It's also important to add the Location field that you're using, and include the latitude and longitude values in the index.  When you can't find a field, expand the 'Add Related Fields' at the bottom and look for them there, and make sure you save your changes before leaving the page.



    Finally, on the filter tab I suggest excluding unpublished nodes, as well as Ignoring case and adding the HTML filter.

    With all that setup, use the search_api_pages module to set up a search page for the index you've constructed.


    With data and index set up, it's time to add the location filtering.  Let's add a quick block to filter with:

    /** * Implements hook_block_info(). */ function example_block_info() { return [ 'location' => [ 'info' => t('Search Location Filter'), 'cache' => DRUPAL_CACHE_GLOBAL, ], ]; } /** * Implements hook_block_view(). */ function example_block_view($delta) { if ($delta == 'location') { $block['subject'] = t('Filter by location:'); $block['content'] = drupal_get_form('example_location_filter_form'); } return $block; } /** * This form allows the user to restrict the search by where they are. */ function example_location_filter_form($form, &$form_state) { $form['center'] = array( '#type' => 'textfield', '#title' => t('From'), '#description' => t('Enter a zip code or city, state (ie, "Denver, CO")'), '#maxlength' => 64, '#size' => 20, '#default_value' => isset($_GET['center']) ? $_GET['center'] : '', ); $distances = [5, 10, 20, 50]; foreach ($distances as $distance) { $options[$distance] = t('Within @num miles', array('@num' => $distance)); } $form['radius'] = [ '#type' => 'radios', '#title' => t('Distance:'), '#options' => $options, '#default_value' => isset($_GET['radius']) ? $_GET['radius'] : 5, ]; $form['submit'] = [ '#type' => 'submit', '#value' => t('Filter'), ]; $parameters = drupal_get_query_parameters(NULL, ['q', 'radius', 'center']); $form['clear'] = [ '#type' => 'markup', '#markup' => l(t('Clear'), current_path(), array('query' => $parameters)), ]; return $form; } /** * Validation handler for location filter. */ function example_location_filter_form_validate(&$form, &$form_state) { if (!empty($form_state['values']['center'])) { $location = trim($form_state['values']['center']); // Is this a postal code? $point = example_location_lookup($location); if (empty($point)) { form_set_error('center', t('%location is not a valid location - please enter either a postal code or a city, state (like "Denver, CO")', ['%location' => $location])); } } } /** * Form submit handler for location filter form. */ function example_location_filter_form_submit(&$form, &$form_state) { $parameters = drupal_get_query_parameters(NULL, ['q', 'radius', 'center']); if (!empty($form_state['values']['center'])) { $parameters['radius'] = $form_state['values']['radius']; $parameters['center'] = $form_state['values']['center']; } $form_state['redirect'] = [current_path(), ['query' => $parameters]]; }

    In this case, example_location_lookup() looks for a latitude/longitude pair for a given location entered by the user, which I'm leaving as an exercise for the reader in hopes to keep this post short.  It should return an array with the keys 'lat' and 'long', at least.  For testing, you can have it return a fixed point until you've got that setup, like:

    function example_location_lookup($location) { return array('lat' => 39.7392, 'long' => -104.9903); }

    So, now we can return to the Haversine formula.  Once you've got the position entered and passed along, it's time to match it against our restaurants.  Doing complex math is hard, so after a few moments of thought, we realize that anything more than the radius miles north or south, or east and west, of the center point will be too far away to bother including in the search radius, so we'll first filter on a range of latitude and longitude around the center, and then filter by the haversine formula to knock out everything outside of the circle.  For implementing the Haversine formula in SQL, I'm indebted to Ollie Jones of Plum Island Media, who does a great job of demystifying the formula here.

    /** * Implements hook_search_api_db_query_alter(). */ function example_search_api_db_query_alter(SelectQueryInterface &$db_query, SearchApiQueryInterface $query) { $field_name = variable_get('example_location_field_name', 'field_location'); // Do we have a location? if (isset($_GET['center']) && isset($db_query->alterMetaData['search_api_db_fields'][$field_name . ':lat'])) { $location = $_GET['center']; $radius = isset($_GET['radius']) && is_numeric($_GET['radius']) ? $_GET['radius'] * 1 : 5; $point = example_location_lookup($location); if (!empty($point)) { // Basically, we make a subquery that generates the distance for each adventure, and then restrict the results from that to a bounding box. // Then, once that subquery is done, we check each item that survives the bounding box to check that the distance field is less than our radius. $latitude_field = $db_query->alterMetaData['search_api_db_fields'][$field_name . ':lat']['column']; $longitude_field = $db_query->alterMetaData['search_api_db_fields'][$field_name . ':lon']['column']; $table = $db_query->alterMetaData['search_api_db_fields'][$field_name . ':lat']['table']; $sub_query = db_select($table, 'haversine'); $sub_query->fields('haversine', ['item_id', $latitude_field, $longitude_field]); // Calculate a distance column for the query that we'll filter on later. $sub_query->addExpression("69.0 * DEGREES(ACOS(COS(RADIANS(:p_lat)) * COS(RADIANS($latitude_field)) * COS(RADIANS(:p_long - $longitude_field)) + SIN(RADIANS(:p_lat)) * SIN(RADIANS($latitude_field))))", 'distance', [':p_lat' => $point['lat'], ':p_long' => $point['long']]); // Filter out anything outside of the bounding box. $sub_query->condition($latitude_field, [$point['lat'] - ($radius / 69.0), $point['lat'] + ($radius / 69.0)], 'BETWEEN'); $sub_query->condition($longitude_field, [$point['long'] - ($radius / 69.0), $point['long'] + ($radius / (69.0 * cos(deg2rad($point['lat']))))], 'BETWEEN'); $db_query->join($sub_query, 'search_distance', 't.item_id = search_distance.item_id'); $db_query->condition('search_distance.distance', $radius, '<'); } } }

    And there you go.  In my example, I set up the page as search, and tested with the url: search/diner?radius=500&center=denver, and got back the Denver Diner, but not the New York Diner.

    * It's not certain depending on which version of fivestar you get, but you might need to download the entity api module as well. Just in case you're following along at home.

    (1) We're just going to ignore the fact that the Earth isn't a perfect sphere for the purposes of this article - there's a degree of error that may creep in, but honestly if you're trying to find locations within 300 miles of a city, there's already enough error creeping in on the 'center' of a city that the close approximation of the Haversine formula is a relief.

    Categories: Drupal

    CiviCRM Blog: The quest for performance improvements

    11 November 2016 - 7:02am

    After the socialist party upgraded civicrm to version 4.6 a month ago they are experiencing performance issues. In this blog I will round up our quest for performance improvements. But before that some facts about their installation.

    • +/- 350.000 contacts
    • +/- 300 users who can access civicrm and see members in their local chapter
    • +/- 2700 groups
    • There are several campaign websites linked to CiviCRM and one of their successfully campaigns leads to 7500 new contacts per week in the system
    • Running  on a VPS with 4 CPU cores and 8GB of RAM
    • around 40 active extensions

    Since yesterday we have added New Relic as a monitoring tool. With New Relic we can monitor and look back in the history. We can also see all the details in each request. So we can analyze the performance. 

    Above is the screenshot of the monitoring of the last 24 hours.  The red/rose squares indicates when the overall performance is poor (more than 2 seconds per request). We also see that MySQL has a big part in the  largest peaks.

    The screenshots above shows the slowest queries and the slowest mysql operations. One observation is that it looks like that the MySQL delete statements are slowing the system down.

    It is not clear what exactly those delete statements are or what is causing those to be slow. That is one of the questions to look into next.

    Another thing we want to look into is the tuning of the MySQL database configuration and we also want to get familiar with New Relic.

    Do you have any thoughts? Or did you do any performance improvements you did? We can use any help and we will keep posted about our quest for performance.


    Categories: Drupal - Thoughts: Using Paragraphs in Drupal 8

    11 November 2016 - 6:25am

    When we received the new designs for the Ixis site it was evident that they contained separate design elements which were shared across several pages, from the homepage to departmental landing pages to the “About us” page. We thought this was a perfect use case for the Paragraphs module, which allows site editors to "choose on-the-fly between predefined Paragraph Types… instead of putting all of their content in one WYSIWYG body field."

    Most content types on the new Ixis site contain a Paragraphs field. An editor can create multiple Paragraphs of any defined type and sort them to specify the elements and layout of the node's content.

    Paragraph types can be anything from a simple text block or image to a complex and configurable slideshow. Paragraph types are essentially fieldable entities and the Paragraphs module allows the creation of these types. Each defined type can have it’s own set of relevant fields, all added via the Drupal UI and exporting to config.

    So, to support the elements outlined in our page designs we added Paragraph types for:

    • Call to action - areas of bold background colour and large text;
    • Download - a downloadable asset or file;
    • Gallery - a gallery list of images;
    • Image - a single, responsive image;
    • Testimonial - a quote or testimonial;
    • Text - basic, filtered HTML edited with CKEditor;
    • Text with Callout - regular body text coupled with a styled "callout";
    • Twitter - an embedded Twitter widget;
    • Video - an embedded video from a 3rd-party site such as YouTube.

    All these Paragraph types give editors some flexibility and choice when authoring a page designed with several of these elements.


    The rendered output of Paragraphs entities can be altered using a paragraph.html.twig file in the site’s theme. For example:

    {% set classes = [ 'paragraph', 'paragraph--type--' ~ paragraph.bundle|clean_class, view_mode ? 'paragraph--view-mode--' ~ view_mode|clean_class, cta_style ? 'cta-style--' ~ cta_style|clean_class, ] %} {% block paragraph_content %} {{ content }} {% endblock paragraph_content %}

    The rendered output of each individual Paragraph type can also be affected using a suggested Twig template, for example we have paragraph--testimonial.twig.html for appropriately rendering a testimonial quote and cited author.

    In some places we’ve used a field combined with a preprocess to provide multiple variations of the same paragraph. You can see this in action above with the cta_style variable which gives us a standard or inverted dark style for Call to action paragraphs.

    Content Migration

    During the initial content migration, we migrated directly into a Text Paragraph in the new Paragraphs field for some content types such as blog posts. To do this, we needed a new process plugin:

    /** * Saves D6 Page Body field to D8 Page Paragraph (Textarea) field. * * @MigrateProcessPlugin( * id = "node_paragraph_textarea" * ) */ class NodeParagraphTextarea extends ProcessPluginBase { ... }

    We used a slightly modified version of the example plugin in this article by Amit Goyal. Then in our migration.d6.node__blog.yml we removed:

    ... body/format: plugin: migration migration: d6_filter_format source: format body/value: body body/summary: teaser ...

    and replaced with the new process plugin to instead migrate the source body into the Paragraphs field:

    ... field_paragraphs: plugin: node_paragraph_textarea source: body ...

    In summary, Paragraphs is a great alternative to a single WYSIWYG editor for site editors who want to be able to lay out complex pages combining text, images, video, audio, quotes or any other advanced component. Here's some further reading:

    Categories: Drupal

    Valuebound: How Drupal can be used to develop data driven web application

    11 November 2016 - 4:44am

    Everything about building a website or a web application is not just coding and hosting an app. It includes a thorough ecosystem research and co-designing a scalable product to cooperate and compete within the networked internet of things. Drupal is the perfect platform to build large systems like CRM system or ERP system, which is complicated as well as data oriented.

    The data acquired is first organized appropriately and then analyzed to make essential business decisions. Various underlying platforms serve critical aspects in the complete system, which work really well with applications developed with Drupal.  Management, governance and security are always on the top of the list when it comes to media and entertainment companies.

    Building a complex website with Drupal…

    Categories: Drupal

    Sooper Drupal Themes: New Logistics Design with Glazed 2.5.4 and Carbide Builder 1.0.15

    10 November 2016 - 7:49pm

    First of all, sorry for the late blog. This blog refers to the drupal themes updates on November 1st. I'm currently travelling China and while I rushed to get the release out before my departure, the blog had to wait a little longer.


    Glazed Logistics Design And Reaching Product-Market Fit

    With the release of the Logistics design we addded a unique and beautiful theme to our collection while at the same time the core products only needed minor adjustments. This is an indication that the products have achieved a state of stability and product-market fit. SooperThemes now pivots to focus more on creating new designs and features based on the current core products. Of course this doesn't mean we don't add new features at all, there will always be a need for change in a turbulent environment like Drupal frontend development. 

    Creating Great Design For The Drupal Community

    In the past year we have laid the neccessary ground work that is needed to provide the Drupal community with much desired high quality designs. The site building workflow with Glazed theme and Carbide Builder is incredibly fast, efficient and produces precisely designed responsive Drupal websites. This doesn't just improve productivity of our customers and our customers' content creators but also our own productivity. At this point we completely design our Glazed demos using just the theme and drag and drop builder, no photoshop or coding. This big gain in productivity really allows us to focus more on art direction, photography and design. For our logistics demo we created a set of unique 3D isometric line icons, and we curated a collection of beautiful stock photography to really create the right atmosphere for our niche design. We can afford to produce such detailed niche designs thanks to the productivity gains we made with Glazed theme and Carbide Builder. Our goal of closing the gap with the top tier multi-purpose WordPress themes is now appearing on the horizon.  

    Glazed Magazine Component and Drupal 8

    This stability also means we will start planning our Drupal 8 upgrade and migration paths. The next couple of months we will focus on ramping up the design release cycle and on adding a new magazine component to our Glazed CMS distribution. We want to avoid spending months on Drupal 8 migration while the Drupal 7 product offering is only at an 80% market fit. We are aiming to offer more than just great theme settings and drag and drop functionality: expect a multitude of niche designs with fully features demo content in a turn-key installation profile. We strive to become Drupal's first "Mega Theme".

    Value As A Service

    As a subscription Drupal shop, we really focus on building long-term relationships with our customers and with the Drupal community at large. We make decisions based on what we think provides the most value to the most people. An important part of making those decisions in listening to the community. If you can spare a minute, please write a comment on the blog and describe what you would value the most in a Drupal theme. One feature I'm think about adding to the distribution is ready-made translation configuration as an optional component in the Glazed CMS distribution, let me know in the comments if that is something you would value.

    Categories: Drupal

    Drupal core announcements: Drupal core security release window on Wednesday, November 16, 2016

    10 November 2016 - 2:44pm
    Start:  2016-11-15 12:00 - 2016-11-17 12:00 UTC Organizers:  cilefen xjm stefan.r catch David_Rothstein Event type:  Online meeting (eg. IRC meeting)

    The monthly security release window for Drupal 8 and 7 core will take place on Wednesday, November 16.

    This does not mean that a Drupal core security release will necessarily take place on that date for any of the Drupal 8 or 7 branches, only that you should watch for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

    There will be no bug fix or feature release on this date. The next window for a Drupal core patch (bug fix) release for all branches is Wednesday, December 07. The next scheduled minor (feature) release for Drupal 8 will be on Wednesday, April 5.

    Drupal 6 is end-of-life and will not receive further security releases.

    For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

    Categories: Drupal

    Acquia Developer Center Blog: A walk through New Orleans with Shyamala Rajaram

    10 November 2016 - 12:46pm

    A conversation with our newest community representative to the Drupal Association Board, Director at Large, Shyamala Rajaram, recorded walking to the New Orleans Convention Center during DrupalCon NOLA 2016.

    Yes, I can see I need to get a gimbal or a steady cam, but the video is still fun (for me anyway) :-)

    Our conversation

    Mentioned in the conversation
    More Shyamala on the web

    Rakesh James has trained more than 600 new Drupalists - I said 200 in the recording.


    A full transcription of the conversation will be added shortly!

    Skill Level: BeginnerIntermediateAdvanced
    Categories: Drupal

    Lullabot: WordPress vs Drupal

    10 November 2016 - 12:00pm
    Matt and Mike site down with a number of cross-functional Drupal and WordPress developers to talk about the differences and similarities between the platforms, concepts, and communities.
    Categories: Drupal

    Drupal Association News: Buy The Gift of Drupal

    10 November 2016 - 11:15am

    We’re raising funds for 2017 Drupal community programs by clearing out our Drupal merchandise. Everything must go to make room for new things to come. What better time for a big Drupal swag sale, than holiday time! Give your friend, co-worker, or favorite module maintainer a Drupal hoodie, coffee mug, t-shirt, and more.

    All merchandise is 50% off. Just use the coupon code BUYBYE. Sale ends 12/31!

    Visit the Store

    Categories: Drupal

    Leopathu: 6 Essential Drupal Interview Questions*

    10 November 2016 - 10:26am
    1. Name and describe the five conceptual layers in a Drupal system.
    Categories: Drupal

    Four Kitchens: Frontend Style Guide Miniseries: Part Two: KSS Node

    10 November 2016 - 9:32am

    Welcome to part two of our frontend miniseries on style guides! In this installment, we will cover the pros and cons of using KSS Node. […]

    Categories: Drupal

    Vardot: 4 Patches to Get Entityqueue on Drupal 8 Behave as it Should Be (as of November 10, 2016)

    10 November 2016 - 8:53am
    How to, Resources Read time: 4 minutes


    1. Add "Reverse order in admin view" option:
    2. Fix a problem that causes the queue to be always required when using "Limit to a specific entity queue":
    3. Add a tab for Entityqueue on content types:
    4. Make "Contextual links" work for views using Entityqueue:


    When using the Entityqueue module in Drupal 8 as a tool for editors and site admins to order content, you will end up working on the following use cases:

    • Use case 1: Use Entityqueue as a filter: shows only the items chosen in the queue.
    • Use case 2: Use Entityqueue as a loose sorting tool: does NOT limit the items based on queue, but prioritizes the items chosen in the queue to be displayed first, then shows the rest, perhaps in a reverse chronological order.

    These are the most common use cases we use at Vardot for our clients when we build a site.

    Use case 1 works perfectly if you use Entityqueue as is.

    However, use case 2 does not work properly. Therefore, we have contributed (or contributed to), two patches that would make life easier to build a solid experience using the Entityqueue module in Drupal 8.

    Added to that, we also patched two missing features that existed in Nodequeue, and should now exist in Entityqueue for Drupal 8.

    Note: this post was written in November 10, 2016, which until this date, these patches are not yet committed to Entityqueue. Please review the patches, we hope that they get committed and become part of the next Entityqueue release.

    1. Queue is always required when using "Limit to a specific entity queue"

    Issue link:

    Needed for use case 2, you will most likely need your view to limit results to only items in the entity queue your joining in.

      2. Get the good old "Reverse order in admin view" option

    Issue link:

    For use case 2, this option will come in handy, since you will be sorting in reverse chronological order after the items in the queue are shown first.
    Therefore, this nice workaround allows you check "Reverse order in admin view" to ensure the items in queue appear first in view when you sort.

      3. Get the good old Nodequeue tab to appear along with content tabs

    Issue link:

    If I'm an editor or a site admin, it wouldn't make sense to me to see the queues that I can add a piece of content to.

    This tab has been missed from Entityqueue, now it comes back.

    4. Get Contextual Links to send you directly to the queue edit page

    Issue link:

    Plans for this is to integrate with the new outside-in approach of Drupal 8.2 using the Settings Tray module.

    This patch provides you as an editor or site admin, to go directly to the queue from the front end using the contextual links, instead of searching for the queue by its name from the admin view.



    Let's hope these patches get committed and pushed to Entityqueue module.

    This tab has been missed from Entityqueue, now it comes back.

    Tags:  Drupal drupal 8 Drupal Planet Title:  4 Patches to Get Entityqueue on Drupal 8 Behave as it Should Be (as of November 10, 2016)
    Categories: Drupal

    Dries Buytaert: Content and Commerce: a big opportunity for Drupal

    10 November 2016 - 7:08am

    Last week Acquia announced a partnership with Magento. I wanted to use this opportunity to explain why I am excited about this. I also want to take a step back and share what I see is a big opportunity for both Drupal, Acquia and commerce platforms.

    State of the commerce market

    First, it is important to understand what is one of the most important market trends in online commerce: consumers are demanding better experiences when they shop online. In particular, commerce teams are looking to leverage vastly greater levels of content throughout the customer's shopping journey - editorials, lookbooks, tutorials, product demonstration videos, mood videos, testimonials, etc.

    At the same time, commerce platforms have not added many tools for rich content management. Instead they have been investing in capabilities needed to compete in the commerce market; order management systems (OMS), omnichannel shopping (point of sale, mobile, desktop, kiosk, etc), improved product information management (PIM) and other vital commerce capabilities. The limited investment in content management capabilities has left merchants looking for better tools to take control of the customer experience, something that Drupal addresses extremely well.

    To overcome the limitations that today's commerce platforms have with building content-rich shopping experiences, organizations want to integrate their commerce platform with a content management system (CMS). Depending on the situation, the combined solution is architected for either system to be "the glass", i.e. the driver of the shopping experience. is a nice example of a content-rich shopping experience built with Drupal and Drupal Commerce. Drupal's unique advantage for commerce

    Drupal is unique in its ability to easily integrate into ambitious commerce architectures in precisely the manner the brand prefers. We are seeing this first hand at Acquia. We have helped many customers implement a "Content for Commerce" strategy where Acquia products and Drupal were integrated with an existing commerce platform. Those integrations spanned commerce platforms including IBM WebSphere Commerce, Demandware, Oracle/ATG, SAP/hybris, Magento and even custom transaction platforms. Check out Quicken (Magento), Puma (Demandware), Motorola (Broadleaf Commerce), Tesla (custom to order a car, and Shopify to order accessories) as great examples of Drupal working with commerce platforms.

    We've seen a variety of approaches to "Content for Commerce" but one thing that is clear is that a best-of-breed approach is preferred. The more complex demands may end up with IBM WebSphere Commerce or SAP/hybris. Less demanding requirements may be solved with Commerce Tools, Elastic Path or Drupal Commerce, while Magento historically has fit in between.

    Additionally, having to rip and replace an existing commerce platform is not something most organizations aspire to do. This is true for smaller organizations who can't afford to replace their commerce platform, but also for large organizations who can't afford the business risk to forklift a complex commerce backend. Remember that commerce platforms have complex integrations with ERP systems, point-of-sales systems, CRM systems, warehousing systems, payment systems, marketplaces, product information systems, etc. It's often easier to add a content management system than to replace everything they have in place.

    This year's "State of Retailing Online" series asked retailers and brands to prioritize their initiatives for the year. Just 16% of respondents prioritized a commerce re-platform project while 41-59% prioritized investments to evolve the customer experience including content development, responsive design and personalization. In other words, organizations are 3 times more likely to invest in improving the shopping experience than in switching commerce platforms.

    The market trends, customer use cases and survey data make me believe that (1) there are hundreds of thousands of existing commerce sites that would prefer to have a better shopping experience and (2) that many of those organizations prefer to keep their commerce backend untouched while swapping out the shopping experience.

    Acquia's near-term commerce strategy

    There is a really strong case to be made for a best-of-breed approach where you choose and integrate the best software from different vendors. Countless point solutions exist that are optimized for narrow use cases (e.g. mobile commerce, marketplaces and industry specific solutions) as well as solutions optimized for different technology stacks (e.g. Reaction Commerce is JavaScript-based, Magento is PHP-based, Drupal Commerce is Drupal-based).

    A big part of Acquia's commerce strategy is to focus on integrating Drupal with multiple commerce platforms, and to offer personalization through Lift. The partnership with Magento is an important part of this strategy, and one that will drive adoption of both Drupal and Magento.

    There are over 250,000 commerce sites built with Magento and many of these organizations will want a better shopping experience. Furthermore, given the consolidation seen in the commerce platform space, there are few, proven enterprise solutions left on the market. This has increased the market opportunity for Magento and Drupal. Drupal and Magento are a natural fit; we share the same technology stack (PHP, MySQL) and we are both open source (albeit using different licenses). Last but not least, the market is pushing us to partner; we've seen strong demand for Drupal-Magento integration.

    We're keen to partner with other commerce platforms as well. In fact, Acquia has existing partnerships with SAP/hybris, Demandware, Elastic Path and Commerce Tools.


    Global brands are seeing increased opportunity to sell direct to consumers and want to build content-rich shopping journeys, and merchants are looking for better tools to take control of the customer experience.

    Most organizations prefer best of breed solutions. There are hundreds of thousands of existing commerce sites that would like to have more differentiation enabled by a stronger shopping experience, yet leave their commerce capabilities relatively untouched.

    Drupal is a great fit. It's power and flexibility allow it to be molded to virtually any systems architecture, while vastly improving the content experience of both authors and customers along the shopping journey. I believe commerce is evolving to be the next massive use case for Drupal and I'm excited to partner with different commerce platforms.

    Special thanks to Tom Erickson and Kelly O'Neill for their contributions to this blog post.

    Categories: Drupal

    OSTraining: How to Use the Drupal 8 Video Embed module

    10 November 2016 - 5:54am

    In this tutorial, I will explain how to use the Drupal 8 Video Embed module so that you can easily add YouTube videos to your Drupal 8 site.

    Categories: Drupal

    Drop Guard: Drupalers, what do you want?

    10 November 2016 - 2:50am

    It's no secret that Drupal's success depends heavily on the collaborative community culture and the continuous communication process between all members of the community. It’s not for nothing that we embrace the “come for the code, stay for the community” mantra.

    Today we're asking you - an agency, freelancer or a lone webmaster - to think with us a little bit about the quality of security protection your service provider delivers to ensure your website and online services are running smoothly.

    Security Drupal Planet Drupal Process Drupal Community
    Categories: Drupal