Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 2 hours 44 min ago

Code Enigma: Track all the things with Google Analytics

15 March 2016 - 4:15am
Track all the things with Google Analytics Language English Track all the things with Google Analytics

Custom dimensions and metrics allow to track almost anything you could need.

Tue, 2016-03-15 11:15By salva

Certainly, there's no need to introduce Google Analytics as an analytics tool for websites. However, not all of its features are equally known to site administrators, and it's very easy for organisations to get tempted to spend part of their budget into a custom tracking system that covers very specific aspects of their site.

The reality is, though, that Google Analytics can cover much more ground than it seems to, yet some of its features are sometimes overlooked and not really used. We've talked about custom event tracking in the past, and in this post I'd like to introduce another feature introduced not so long ago: custom dimensions and metrics.

Custom dimensions and metrics

At its core, Google Analytics (GA) tracks plenty of details about the visitors of a website. However, the information it tracks can't go beyond the details that can be extracted from the HTTP request or from the user's browser (user location, user browser, language of the user, etc). Anything that falls beyond this type of information belongs to the business domain, and as such, Google Analytics can't really track it without further details

For example, a site owner might want to know how many users like different types of food (vegetables, fish, meat, etc). That's simple enough to track on any site. But now imagine the owner wants to know how well a section of the site is doing with a particular audience (e.g: how popular the "Vegetables" section is among the users that like meat), in order to change their marketing approach, ads displayed on that section, etc, as they want to attract more people from a specific audience. The problem starts to unfold and become more complex now, because in order to surface that information, the site would need to track each visit to a page, but also store information about the specific details of the user that visited that page.

This kind of data belongs to the business domain, and it's exactly what custom dimensions and metrics allow site owners to track. In short, they make it possible to track user information alongside the standard details that Google stores for any page view. So, continuing with the example above, using this feature from GA we can easily track user-specific details, or other details about the contents, (e.g: the food shop that sponsors a specific page). With these details stored, GA allows to surface them when creating custom reports, in the same way we can use the default dimensions and metrics (like language, number of page views, number of sessions, etc).

The bare minimum thing to understand about this feature, is that using a custom metric, we can only track numeric values, whereas using a custom dimension, you can track any type of value (e.g: shop names). This is a basic description of custom dimensions and metrics, but you can find the complete documentation (with guidelines and examples of use case scenarios) in the help section of GA. Now, let's look at how easy it is to set this up in GA and integrate it in Drupal.

Setting up Custom Dimensions and Metrics in Analytics

This step couldn't be much simpler. All you have to do is going to the Administration tab of your GA account, choose the web property for which you want to track some custom data, and expand the Custom definitions section. From there, you can click to add either a custom dimension or a custom metric. For both of them, there are a few additional details to specify. Most of the time the default values will be good to go. For more complex data tracking, refer to the full documentation. The screenshot below shows how to access these pages from the Administration tab. Some more details can be found here.

Setting up Drupal

Once the GA part is sorted out, it's the time to start sending custom information from Drupal. Fortunately, the Google Analytics module already has support for this feature. From the settings page, located at admin/config/system/googleanalytics, you can access two separate fieldsets from which to specify the site or user data to send to Analytics, alongside the page view information. The great thing here, is that it leverages the use of tokens, so every available token in the system can be used here. What if you want to send some custom information that is not provided by an existing token? In such case, Token API comes to the rescue!

The picture below shows the configuration page for the Google Analytics module, with some custom dimensions added as tokens:

 

Note that I've stayed away of showing any code snippets. If you're not using the Google Analytics module, you can still send custom information to Google very easily, by manually adding the analytics.js file to your site, and with just a few lines of code. Since that's out of the scope of this article, I'll just link to this help page, which shows some examples of code snippets for different scenarios.

Show me the reports

So, we've configured our Analytics account, and configured Drupal to start sending those valuable bits of data that will allow us to engage with our audience in the most efficient way. Now we want to surface this data in some way (tables, anyone?). For that, we just need to go to the Customisation tab (back in the GA interface), and click on create custom report. You'll see there's a section for dimensions, and another one for metrics. Choose the ones to show in the table from your custom ones (or from the standard ones), and save:

 

After some time (give it at least one day!) the statistics should start to come through, and you'll be able to export, filter, reorder or perform any of the standard operations available in Google Analytics. The screenshot below shows some custom details captured from one of our sites and surfaced through the Analytics UI:

 

This article is a brief introduction to GA Custom Dimensions and Metrics, and to show how easy is to harness the power of this feature to create complex reports without having to go through a lot of development in your site. While GA is not limitless, it certainly allows for much more than what it's commonly known. Make sure you check it out before discarding it for a custom reports solution.

 

BlogGoogle Analytics Custom Events BlogBetter UX in your forms, the easy way BlogWYSIWYG flexibility with the Shortcode module PageWe build sites in Drupal
Categories: Drupal

ActiveLAMP: Sandcamp 2016 Recap

14 March 2016 - 7:00pm

The San Diego Drupal Camp was great! You can’t beat the weather in San Diego, and as usual, these regional events are great for catching up with old friends that are still plugging away with the Drupal content management system. Checkout our highlight video: This year I had the pleasure of giving 3 sessions at the camp, and as promised, I want to share the slides and code for everything that I presented. Each deck is iframed in on this article, feel free to checkout my github page</a< if you want the speaker notes too.

Read more...
Categories: Drupal

Drupal core announcements: Update: PHP dependencies removed from git (8.1.x and 8.2.x branches)

14 March 2016 - 5:17pm

The Composer-managed vendor directory has been removed from the Drupal core git repository for the 8.1.x and 8.2.x branches. (This change was previously committed, but rolled back due to rate limits on Github affecting composer installation. Those limits have since been lifted, so we have recommitted the change.)

There will not be any changes for people downloading Drupal 8 from Drupal.org. The Drupal.org packager will add dependencies to zip and tar packages.

If you're not using zip / tar files, e.g. when using a git clone, run composer install to get dependencies. See https://www.drupal.org/documentation/install/download#git for instructions.

For background information, see the change record for this change and the related Drupal 8 core issue.

Categories: Drupal

Jeff Geerling's Blog: Happy #PiDay 2016 - Celebrating with the Raspberry Pi

14 March 2016 - 2:53pm

I think today was my most Pi-full π day, ever! Let's see:

Early in the morning, I finished upgrading all the Ansible playbooks used by the Raspberry Pi Dramble so my cluster of five Raspberry Pis would run faster and better on the latest version of official Raspberry Pi OS, Raspbian Jessie.

Later, opensource.com published an article I wrote about using Raspberry Pis placed throughout my house to help my kids sleep better:

Raspberry Pi project to regulate room temperature and sleep better https://t.co/ikwRbS5wns by @geerlingguy pic.twitter.com/rXA1eWodIm

— Open Source Way (@opensourceway) March 14, 2016

Categories: Drupal

FFW Agency: Managing CSS and JavaScript files in Drupal 8 with Libraries

14 March 2016 - 12:05pm
Managing CSS and JavaScript files in Drupal 8 with Libraries David Hernandez Mon, 03/14/2016 - 19:05

Drupal 8 revolutionizes the theming experience with many significant improvements to make theming easier, and give themers the flexibility and control they've never had before. One of those major improvements is to the library management system, which controls the attaching of CSS and JavaScript files.

In this post we will cover how to create and control libraries from a theme. This will include SMACSS categorization for CSS files, dependencies, how to conditionally attach libraries, manipulating libraries that come from anywhere in a site (core, modules, or base themes,) and targeting individual files for removal or replacement. All this without needing a single line of PHP.

Creating Libraries

The scripts and stylesheets properties used in previous versions of Drupal no longer exist. In Drupal 8 we manage all of these files using libraries defined in a .libraries.yml file, added to your theme.

Each library defined in this file includes a unique name, any number of CS or JS files, dependencies, and other information needed to define the properties of the library or assets.

Here is an example of a library file:

# In mythemename.libraries.yml

# Give your library a name.
my-library-name:
  version: "1.0.x"
  css:
    # The SMACSS category.
    base:
      # The path to the css file.
      assets/css/base.css: {}
    theme:
      assets/css/print.css: { media: print }
  js:
    assets/js/myglobal.js {}
  dependencies:
    - core/jquery

# In the following example, we add a Google font (Lato).
lato:
  css:
    base: '//fonts.googleapis.com/css?family=Lato': { external: true }

The file is in YAML format, which Drupal 8 uses for all configuration files. It should be named using the name of your theme, just like your .info.yml file. Let’s take a look at each line to get a better understanding of all the properties.

Naming

# Give your library a name.
my-library-name:

Each library is given a custom name. This name can be anything, but must be unique to the module or theme that supplies it. This should be easy to keep track of since the libraries that belong to the same module or theme are defined in the same file. The name does not have to be unique to the entire website, because libraries are referenced using both the library name and source. For example, mythemename/my-library-name, but we’ll get to that later when we start attaching and manipulating libraries.

Version

version: "1.0.x"

The version is completely optional. It is only used for identification purposes, along with other properties like license, remote, and a few others that we won’t go into. You may want to add a version for a library you use with multiple projects to keep track of which version is used at any given time. It is also helpful when creating a library that uses CSS or JS from an external source. For example, if you copy code for a slideshow, you may want to add the source version here to keep track of it.

CSS

css:
  # The SMACSS category.
  base:
    # The path to the css file.
    assets/css/base.css: {}
  theme:
    assets/css/print.css: { media: print }

All CSS files are included below the css: line. In this case there are two CSS files, base.css and print.css. Each is listed below a category, base and theme, respectively. These are SMACSS categories, which Drupal 8 uses for all CSS file. See the documentation page on CSS file organizaton.

SMACSS

SMACSS is a method for organizing files and CSS rules. You don’t have to follow it in your theming, but you do need to understand how it works and what categories exist, because it used everywhere in Drupal 8 that you encounter CSS files. If you’ve never used SMACSS before, just know that there are five categories; base, layout, component, state, and theme.

When libraries are processed and stylesheets added to a page, they are added in the order of these categories. So a file in the base category will always come before a file in the theme category. The one caveat to this is all module libraries are grouped together and then all theme libraries, so regardless of category, a theme’s stylesheets will always come after the ones supplied by modules.

Back to our example...

Additional Properties

theme:
  assets/css/print.css: { media: print }

The line below the SMACSS category is where we add the CSS file. The path, relative to the root of the theme, is used to identify the file. Following the file are a pair of curly braces where additional properties can be set. In this case, the media property is set to print. The available values for media are screen, print, or all. If no value is set, all is used.

JavaScript

js:
  assets/js/myglobal.js {}

Like CSS, we add JavaScript files below the js: line, with each file on a separate line. Unlike CSS, there is no SMACSS category to worry about. But, just like CSS, you can set additional properties inside the curly braces following the file name. For example, adding minified: true will tell Drupal this file has already been minified, so don’t try to minify it again when aggregating the files.

One thing to note is Drupal 8 adds all JavaScript files to the footer of a page. If you need to have your JavaScript loaded in the header, add header: true to the library.

my-library-name:
  header: true
  ...
  js:
    assets/js/myglobal.js {}
  ...

If the header property is set to true, any dependencies defined in the library will also get loaded in the header.

Dependencies

dependencies:
  - core/jquery

The dependencies: line is where you add any libraries your library requires. This must be other libraries already defined by your theme, some module, or Drupal core. Notice that the library is referenced using its name, and where it came from. In this case, core. (core refers to a literal core.libraries.yml file. Libraries defined by core modules will use their names; block, node, field, views, system, etc.) This is how we avoid name conflicts.

External Files

lato:
  css:
    base:
      '//fonts.googleapis.com/css?family=Lato': { external: true }

In the second example, we see how to link to external stylesheets. Simply supply the external URL for retrieving the file, and set the external property to true.

Attaching Libraries

There are three basic ways for a theme to attach libraries; in the .info.yml file, directly in a template file, and in a preprocess function. Let's go over each of those methods.

Global

To attach assets globally so they are added to every page of the website, add them in your theme’s .info.yml file.

libraries:
  - core/normalize
  - mythemename/my-library-name

Twig

A great way to attach a library conditionally is to do so directly in a template file. Drupal 8 has a special function called attach_library() just for this purpose.

{# In a Twig template file. #}

{{ attach_library('mythemename/my-library-name') }}

The advantage here is in matching the same conditions of the template file. For example, if you use this method in your node.html.twig, the CSS and JS files will only get added when a node is rendered. If you do it in your node--content-type.html.twig the files will only get added when a node of that particular content type is rendered. You can imagine the flexibility when doing this in specific field or views templates.

PHP

Lastly, libraries can be attached in preprocess.

<?php
function mythemename_preprocess_page(&$variables) {
  $variables['#attached']['library'][] = 'mythemename/my-library-name';
}
?>

Here you can add whatever logic needed to match the conditions you want before adding the library to the 'library' array.

Manipulating Libraries

Since all CSS and JS files in Drupal 8 are now in libraries, themes have complete control over those files, regardless of whether they are part of the theme or not. The two main ways to manipulate libraries are with libraries-extend and libraries-override.

Libraries-extend

Libraries-extend is a property used in your theme’s info file. It attaches your library to any existing library. The real power here is that the inclusion of your library will now match the library that was extended. If there is any special logic behind when and how that library is attached, your library goes along for the ride without you having to do anything to recreate that logic yourself.

# In mythemename.info.yml

libraries-extend:
  # Classy's forums library is only included when the forums.html.twig
  # template is used. This will add my theme's 'forums' library at the same
  # time.
  classy/forums:
    - mythemename/forums

In the above example, a forums library is created as part of our example theme, and attached to Classy’s forums library. Any time Classy’s library gets attached, which is only when a forum is rendered, the example theme’s library also gets attached.

Libraries-override

Libraries-override is an even more powerful property that can be used in your theme’s info file. It gives you complete control over any library, to manipulate in anyway you see fit.

Let’s take a look at some examples.

Remove a File

# In mythemename.info.yml

libraries-override:
  # The library name.
  core/jquery.ui:
    # CSS files are always labeled as such. This format is required.
    css:
      # The SMACSS category is required.
      theme:
        # The path to the file. It is not a path relative to your theme.
        assets/vendor/jquery.ui/themes/base/theme.css: false

You’ll notice the structure is exactly the same as when you define a library in your .libraries.yml file. You specify the library name, SMACSS category, and original path to the CSS file. The only difference being the library name must also include the source. In this case, core is prepended to the library name, because the jquery.ui library is defined by Drupal core.

On the line with the path to the CSS file, note that this path is the same as defined by the library. It is not a path relative to your theme, or the website root. It is exactly the same as defined by the jquery.ui library. The path is used as a key to identify the CSS file, so it has to match. If you don’t know what the path is, just find the .libraries.yml that defined the library, and copy it.

Lastly, in this example we’ve added false after the file. This tells Drupal to remove that CSS file any time the library is used. When we say, “no more PHP”, this is it. Gone are the days of preprocessing or alters, doing string searches, and unsetting array elements.

Replace a File

# In mythemename.info.yml

libraries-override:
  system/maintenance:
    css:
      theme:
        # Replace the System module's maintenance CSS file with a custom one.
        css/system.maintenance.css: css/maintenance.css

Here we have targeted one particular CSS file added by the System module, in a library called maintenance. Following the system.maintenance.css we supply the path to our own CSS file. This path is relative to the theme’s directory. And since we are supplying a file to an already existing library, this file does not have to be part of any other library defined by the theme.

When doing this yourself you’ll also notice that the new file gets placed in the exact same place the original file was linked in the head of a page. Whether the original file was first or seventh, the new file will be the same. This ensures the cascade of rules in all the stylesheets is not disturbed.

Replace and Remove Whole Libraries

# In mythemename.info.yml

libraries-override:
  # Replace Classy's messages library with a custom one.
  classy/messages:
    mythemename/messages

  # Remove Classy's search results library completely.
  classy/search-results: false

In this example, we are doing two things. First, replace Classy’s  messages library with one from the example theme. This will prevent any of the files used in the Classy library from getting used, and replace them with the files in the example theme’s library. Note that your theme’s library does not have to match the original library. You can have more, or fewer, files, and call them whatever you want. This just substitutes your library for the original one.

Second, the false placed after Classy’s search-results library removes it completely. This is similar to how we removed an individual CSS file in the previous example, but in this case we remove the entire library.

Voila!

As you can see, given the all-in approach Drupal 8 has taken with libraries, and the power of libraries-extend and libraries-override, themers now have total control!

Tagged with Comments
Categories: Drupal

Jeff Geerling's Blog: Developing with VirtualBox and Vagrant on Windows

14 March 2016 - 12:02pm

I've been supporting Drupal VM (a local Drupal CMS development environment) for Windows, Mac, and Linux for the past couple years, and have been using Vagrant and virtual machines for almost all my development (mostly PHP, but also some Python and Node.js at the moment) for the past four years. One theme that comes up quite frequently when dealing with VMs, open source software stacks (especially Drupal/LAMP), and development, is how much extra effort there is to make things work well on Windows.

Problem: tool-builders use Linux or Mac OS X

The big problem, I see, is that almost all the tool-builders for OSS web software run either Mac OS X or a flavor of Linux, and many don't even have access to a Windows PC (outside of maybe an odd VM for testing sites in Internet Explorer or Edge, if they're a designer/front-end developer). My evidence is anecdotal, but go to any OSS conference/meetup and you'll likely see the same.

Categories: Drupal

Acquia Developer Center Blog: Drupal How-To: Get Inline Images on Your Drupal Site.

14 March 2016 - 11:35am

In this 3-part Drupal How-To series, I'm going to show you various options for configuring images on your site.

In Part 1, we looked at how to tweak the default image options. Here, in Part 2, we'll see ways to allow inline images. In Part 3, we'll see the latest options for responsive images.

Tags: acquia drupal planet
Categories: Drupal

Evolving Web: Drupal 8 Theming Foundations: Using Stable vs. Classy as a Base Theme

14 March 2016 - 10:09am
Drupal 8 Theming Foundations: Using Stable vs. Classy as a Base Theme Suzanne Kenned… Mon, 03/14/2016 - 13:09
Categories: Drupal

Evolving Web: Drupal 8 Theming Foundations: Using Stable vs. Classy as a Base Theme

14 March 2016 - 10:09am

For themers, there are lots of exciting new features in Drupal 8: the Twig tempting system, libraries for loading assets, and the replacement of theme functions with templates. There are also a new set of core themes that come with Drupal 8.

read more
Categories: Drupal

Acquia Developer Center Blog: Migrating the Acquia Library from D6 to D8: Learning by Building

14 March 2016 - 7:49am

This post may be of interest to project managers and sitebuilders looking to migrate from Drupal 6 to Drupal 8 during the early months after the launch of GA D8.

On the Acquia Support Team we often find ourselves using Acquia’s public-facing documentation and article library as an effective tool for explaining product-related tasks, technical how-tos, and a variety of other topics. These resources are useful when communicating via our Support Help Center. Unfortunately, the underlying infrastructure for this site was Drupal 6.37.

Tags: acquia drupal planet
Categories: Drupal

J-P Stacey: Drupal 8 embraces composer's bleeding edge

14 March 2016 - 4:54am

I've long held that I'm happy to treat Drush Make and the rest as transition technologies until Drupal moves fully to Composer. If that day isn't strictly here yet, then it's awfully close.

Read more of "Drupal 8 embraces composer's bleeding edge"

Categories: Drupal

Valuebound: Managing user roles & permission in Drupal 8

14 March 2016 - 2:58am

One of the reason why Drupal is hugely popular for content management application development, because of customizable content authoring workflow. We can simulate good old editorial experience where authors create the article, sub-editor review it and finally editors will confirm & publish if all organization lead criteria are met. In Drupal we create this permission system by creating roles.

Instead of assigning specific permissions to each user, permissions are assigned to roles. And then specific users are assigned role(s) e.g. author, reviewer, editor.

In this post we will explore how to create roles, specify permission for the role and assign specific role to user.

Step 1: First step is to go to Manage >> People >>…

Categories: Drupal

Drop Guard: Drop Guard response about insecure update process

14 March 2016 - 1:30am
Drop Guard response about insecure update process Igor Kandyba Mon, 14.03.2016 - 09:30

6 January 2016 was a memorable day for the Drupal community. Probably for the first time since the Drupalgeddon a vulnerability with potential to affect millions of websites was discovered. The report on the insecure Drupal update process, published by IOActive, got immediate traction and responses from Acquia, Drupal Security Team and major players in the community.

The analysis of the risks, however, showed the impact is not significant enough and as a result, the patches to fix the issues listed in the report are still "work in progress" (first and second).

As the updates automation and security is the Drop Guard's only focus and business model, we feel responsible for providing our answer to each of the issues. 

Issue #1 (part 1): Incorrect update statuses Whenever the Drupal update process fails, Drupal states that everything is up to date instead of giving a warning.

This issue affects the display of the core or contrib update status on the "Available updates" screen, in case the update information is not properly fetched from Drupal.org.

First, Drop Guard users don't need to have the Update module enabled at all (one less module enabled, huh!), as they delegate the heavy lifting updates detection work entirely to Drop Guard. 

Second, under the hood Drop Guard uses a combination of the Update Manager code, rewritten to mitigate most common update process issues, our custom update detection logic and manual checks of the modules in question. It happens quite often, when, for example, the security advisory for a module can not be parsed automatically - in this case, our team investigates the issue and adjusts the update status. 

Lastly, long before the report from IOActive was published, Drop Guard was smart enough to stop the updates detection process if the update information couldn't be fetched. In the unlikely case of Drupal.org infrastructure issues or general network problems the worst thing which could happen - the update won't be available to a user unless its status will be properly fetched and confirmed.

Issue #1 (part 2): CSRF vulnerability The "Check Manually" link can be used to perform a cross-site request forgery (CSRF).

Drop Guard server doesn't use the Update module UI, and don't need it enabled, so there is no risk someone could ever click on the "Check Manually" link at all. We always recommend disabling the Update module on the production sites protected by Drop Guard.

Issue #2: Spying on the network traffic An attacker may point a website owner to a backdoored version of Drupal by eavesdropping on the unencrypted network traffic between a website and updates.drupal.org domain.

Drop Guard users never visit the "Available Updates" page on their websites, which mitigates this vulnerability. Besides, all the networking with updates.drupal.org services is performed over the encrypted connection on our side.

And luckily, Drop Guard users never download updates via the Update's module interface. We highly recommend not to use this functionality for any Drupal maintainer and use the proper updates and deployment workflows instead.

Issue #3: Unencrypted updates transfer Drupal security updates are transferred unencrypted without checking the authenticity, which could lead to code execution and database access.

As mentioned in the section above, Drop Guard always uses the encrypted connection when fetching updates information from Drupal.org.

The actual update archives from Drupal.org are fetched to our servers via the encrypted connection as well. It's also worth saying that Drupal.org team is working tirelessly to switch infrastructure and update processes to use secure channels, so when trying to access the http://updates.drupal.org/release-history/drupal/7.x for example, you will be redirected to the encrypted version automatically.

So as we can see, the easiest way to ensure that you're not in the risk group (apart from using Drop Guard obviously), is to check if the Update Manager is enabled and if it's used to fetch actual updates to your server.

The latter practice can not be recommended for any beginner or advanced user. You should be using proper development workflows and practices instead.

Do you still use the Update Manager module to update your Drupal installation? Do you think it's a good practice? What's your experience overall? Please do share your thoughts in comments!

Security infrastructure Drupal Planet Drop Guard

View the discussion thread.

Categories: Drupal

DataSmith: Git Bisect: The go-to tool for answering the "when did this stop working" question

13 March 2016 - 6:24pm
Git Bisect: The go-to tool for answering the "when did this stop working" question

Continuous integration and automated testing can significantly reduce the odds of regressions, but eventually, every project will fnd themselves facing a feature that used to work and no longer does.  When that time comes for you, I recommend git bisect.

Barrett Sun, 03/13/2016 - 21:24
Categories: Drupal

Promet Source: Think Fast! Playing Drupal Trivia at MidCamp

13 March 2016 - 3:08pm
Time to break out your best Drupal knowledge, Chicago! Demonstrate your Drupal genius at #MidCamp this year.

 

Do you have what it takes to be quizmaster at Promet Source's booth during MidCamp? Promet is inviting the community to participate in a friendly round of Drupal trivia during MidCamp activities Friday, March 18 and Saturday, March 19, 2016.

Categories: Drupal

Drupal core announcements: Drupal core security release window beginning Wednesday, March 16, 2016

13 March 2016 - 11:02am
Start:  2016-03-16 00:00 - 23:30 UTC Organizers:  xjm 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, March 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, April 06. The next scheduled minor (feature) release for Drupal 8 will be on Wednesday, April 20.

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

Drupal Association News: Measuring Drupal's health

11 March 2016 - 1:45pm

The Drupal community is diverse. We're from different places. We speak different languages, code in different languages, and use Drupal in different ways. But the one thing we all have in common is that we care about the fate of Drupal. We invest our time, intellect, and emotions into this project. And we want that investment to make the project successful.

We have a lot to be proud of. In the last few years, Drupal use and community contribution has grown tremendously. Some metrics—like comments and commits created each month—are available at drupal.org/metrics. We share project usage and track BuiltWith statistics. We've also started reflecting company contributions in the marketplace and on organizations list.

The Association's mission is to unite a global open source community to build and promote Drupal. One of its 3-to-5 year goals is to ensure the sustainability of our project and community. To meet that goal, we need to get much better as a community at answering the question: Is Drupal healthy? But that's not an easy question to answer.

In the last board meeting, board members and staff talked about what kinds of metrics show health. In this post, I share some of that thinking, and ask for your ideas. But before we get into recommendations, let’s start at the beginning.

What's project health?

Association staff and board members use “project health” as shorthand for project success. "Health" is robust. Think about your own health. You might think first about physical aspects (Do I have a fever?). But you also might think about emotional aspects, like depression or stress. You may even think about social aspects (Do I have the right people around me to support me and keep me focused on the right habits?). Health isn't binary. Health is multi-dimensional.

So, too, is the health of an open source project. It's easy to take the temperature of a project with metrics like usage or number of committers. But to understand the complexity of our project's health, we need broader measurements. In our work on staff, we've defined four dimensions of product health1 we think we need to explore:

  • Product: whether the business of the Drupal product (the software) is sound. Examples of areas to explore: marketshare; Drupal businesses' revenue.
  • People: whether we have the right kinds of people contributing the right kinds of things. Examples of areas to explore: number of contributors; kinds of contributions; contributors' skills.
  • Process: how the way we do things contributes to the project. Examples of areas to explore: ability to meet published release dates; succession planning.
  • Systems: whether we use the right tools. Examples of areas to explore: testing times for DrupalCI; amount of documentation edits; responses to posts in forums; issue resolutions; commits and integrated repositories.
Acknowledging our limitations

There's the ideal, and then there's reality. We know we won't be able to track everything we want to. So, we'll have to make choices. We'll have to choose metrics that give us directional, even if not precise, accuracy. So, what are some of our limitations?

The future of the project

Knowing what categories of metrics we need to track is necessary, but not enough. Setting metrics also requires knowing where we want the project to go. Taking your temperature is only helpful if you know what you want it to be (and what it means if it's not).

This is a challenge Association staff discussed with the board. The Association doesn't set the software's future. It does, though, need to know where the project is going. To support the project's journey, it needs to know its direction. For example, maybe headless Drupal is the future. If so, we might measure “People” success by how many JavaScript developers contribute. But it’s not 100% clear what the future holds for Drupal. We have work to do before we can identify the best metrics.

Resources

Tracking project health is an Association priority, but it’s not its only mandate. It has to consider the time and expense invested in DrupalCons and Drupal.org too, for example. Unfortunately, budget limitations mean not hiring analysts or consultants to help. For the most part, they mean working with the (wonderful) people already on staff.

So, for example, measuring contribution only by code or comment attribution isn't enough. People contribute in so many ways. (There's even an issue open on this topic already.) Will measuring contribution expand to include other things? Yes. But will it also likely still not give some contributions the attention they deserve? Unfortunately, yes. Hard choices will mean we'll all have to accept some less than ideal outcomes.

Balancing competing frames and other fun factors

Once we know what outcome we want and have found things we can actually measure, we'll still need to do more. Any metric we choose has to also align with the project's mission and our community’s values. We also can't be too dependent on internal metrics. We'll have to measure our success with external indicators too. (See? There's a lot to think about here!)

Examples, please

There’s good news and bad news here. The good news is that we are definitely not alone. Many software projects—including open source projects—have worked on these same issues. There are resources all around us. We've created lists of some of them already.

Bitergia dashboards Open source projects on GitHub Project-run dashboards So what should we track?

There's a lot to consider when we think about the health of the Drupal project. We've just begun this conversation and want to make sure you're part of it from the beginning. So, now we turn things over to you.

Which metrics are indicative of Drupal project health? Share your ideas in the comments section. We'll include your feedback in a document we'll share with you.

1 We borrowed these concepts from Product Lifecycle Management.

Flickr photo: Thomas Haynie

Categories: Drupal

ImageX Media: QA: What Does It Mean to ImageX and Our Clients?

11 March 2016 - 11:53am

Quality Assurance (QA) bridges technology and user experience design, giving a big picture and wind angle understanding of systems and projects. It adds value to the development process, not just by ensuring that every project meets our standards of excellence, but also by defining and maintaining the focus of the team through the entire lifecycle.

Categories: Drupal

Dries Buytaert: White House deepens its commitment to Open Source

11 March 2016 - 10:09am

Yesterday, the White House announced a plan to deepen its commitment to open source. Under this plan, new, custom-developed government software must be made available for use across other federal agencies, and a portion of all projects must be made open source and shared with the public. This plan will make it much easier to share best practices, collaborate, and save money across different government departments.

However, there are still some questions to address. In good open source style, the White House is inviting developers to comment on this policy. As the Drupal community we should take advantage and comment on GitHub within the 30-day feedback window.

The White House has a long open source history with Drupal. In October 2009, WhiteHouse.gov relaunched on Drupal and shortly thereafter started to actively contribute back to Drupal -- both were a first in the history of the White House. White House's contributions to Drupal include the "We the People" petitions platform, which was adopted by other governments and organizations around the world.

This week's policy is big news because it will push open source deeper into the roots of the U.S. government, requiring more government agencies to become active open source contributors. We'll be able to solve problems faster and, together, build better software for citizens across the U.S.

I'm excited to see how this plays out in the coming months!

Categories: Drupal

Pages