Planet Drupal

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

CiviCRM Blog: Easier creation of email newsletters - Content Tokens!

mar, 25/11/2014 - 01:15

When preparing an email newsletter, one part of it that is time consuming is gathering together all the content that is needed. In my experience, virtually all the content already exists elsewhere, such as in the local CMS, in CiviCRM, or on a blog, or some other online source.    So I was thinking how can I make this process easier.  What I did: I created mail merge tokens for CiviCRM that autofill a list of recent blog posts, stories, or any other type of CMS content.  So the end-user sees a list of tokens, one for each content type and for each date range. Such as "Content of type 'blog' changed in the last 7 days" .  What is particulary powerful about this approach, is that if you are also using a CMS aggregator (such as the aggregator module in Drupal core) then virually any external RSS feed is turned into CMS content, which is now available as a CiviCRM token. 

Some examples of how this new extension may help your organization:

   - Your staff posts new content of type "story" each week.Your monthly newsletter editor can use the new token for "Content of type 'story' changed in the last 1 month" to save time preparing the newsletter.

  - A national organization you are affiliated with has a number of blogs that they host. Your local organization would like to include recent blog posts from the national organization in the local member newsletter.  Your local webmaster previously configured the aggregator module to pull in those external blogs into your CMS. Your monthly newsletter editor can use the new token for "Content of type 'feed item' changed in the last 1 month" to save time preparing the newsletter.

- Any other situation where there is existing content that you want to include in your email or PDF.

This new extension "Content Tokens" is published in the CiviCRM extensions area 

This new extension is designed in the same style as the "Fancy Token" extension that provides tokens for upcoming events, contribution pages, profiles, and WebForms. 




Catégories: Elsewhere

Shomeya: Failure to Launch: The Myth of the Missing Map

mar, 25/11/2014 - 01:00

It's all about perspective when it comes to launching. We always think we need something more, that missing set of instructions or special ingredient that will propel us to finish. That special person, few moments of sanity, or foolproof plan.

But at the end of the day, while those things may encourage us to make the choice to take action or bring balance and clarity, they never change the fact that we won't make it anywhere until we start the journey. We could be waiting at the bus stop thinking it's the only way we'll get there, when the whole time we could have been on the train.

Read more
Catégories: Elsewhere

Visitors Voice: Turn the negative trend regarding site search

lun, 24/11/2014 - 22:10
Almost every second user (45%) are dissatisfied or very dissatisfied, having a hard time finding information they are looking for according to a survey (2014). The survey also shows that it is getting worse due to rapid information growth and users’ tendency to increase expectations. The better web search engines like Google gets, the higher […]
Catégories: Elsewhere

Wizzlern: Drupal 8 Configuration Management with Drush

lun, 24/11/2014 - 20:45

Today I got my feed wet with Drupal 8 Configuration Management. For those who are new to this excellent feature in Drupal 8, you should read the documentation at (Managing configuration in Drupal 8) or watch this DrupalCon Amsterdam video. This article assumes you are familiar with Drush and Drush aliases.

I worked with a very basic workflow using a development site and an acceptance site. Both sites are under revision control, where the complete webroot (core + modules, but not settings.php) is placed in git. For gitignore I used a copy of the example.gitignore which you'll find in Drupal's root directory.

I used Drush 7 to import and export the configuration. 'Export' is to transfer a site's configuration from Drupal to file and 'Import' is to transfer in reversed direction. Using drush @dev config-export you export the configuration from the development site to the sites/default/config_*/staging directory. The staging directory now holds many *.yml files that each contain the configuration of an individual section. I've chosen to use git to transfer these files to the acceptance site. At the acceptance site drush @acc config-import is used to transfer the configuration from the file system to the acceptance site.

Make sure that the acceptance site is a copy of the development site. For example using drush @dev archive-dump you can make a copy of both the files and database. With this you can create a copy of the site using drush archive-restore.

I made these changes to the .gitignore file to allow the staging directory to be added to git:

Tags: drupal 8drushdeploymentconfiguration management
Catégories: Elsewhere

Drupal Association News: Forum One to work on Content Strategy for

lun, 24/11/2014 - 19:38

Several weeks ago, we issued an RFP for Content Strategy project. We got a number of great submissions, and the next couple of weeks the Drupal Association staff and the Content Working Group members spent reviewing proposals and interviewing potential vendors.

Today we are happy to announce that we’ve selected a vendor for the content strategy project: Forum One, an open-source digital agency.

Their proposal met all our project requirements and outlined a solid plan for how we can make this project happen. During the interviews Forum One impressed us with their professionalism, passion for content strategy, their extensive experience working on large content strategy projects, and their deep knowledge of the Drupal community and, the website.

We believe that together our staff and Forum One team will make this project a success. Can’t wait to start working and improve content for all our varied audiences.

Catégories: Elsewhere

Phase2: Drushful Thinking

lun, 24/11/2014 - 19:00
What is Drush?

If you’re asking that question right now then congratulations! You are one of the lucky people who will have your life changed today! Cancel everything and read up on Drush, the command line bridge to Drupal.

Everybody knows about Drush, ya Dingus!

That’s more like it. Who doesn’t love Drush, right? Right!

But more and more, I find myself seeing people reinventing things that Drush already handles because they just don’t know all that Drush can do. It’s getting frustrating, and I want to fix that.

First, The Basics Stuff everybody knows

Here are a few Drush commands that most people know and love, just to get them out of the way:

  • drush updb: run pending database updates
  • drush cc all: clear all caches
  • drush dl <something>: download the <something> module
  • drush en <something>: enable the <something> module
Stuff everybody knows (Features Edition)

And if you’re using Features, you’re probably familiar with:

  • drush fra: revert all Features
  • drush fe: export a new or updated Feature with a new component
  • drush fu <featurename>: update the <featurename> Feature with updated site config
  • drush fr <featurename>: revert the site’s config to the current state of the <featurename> Feature

For a lot of the fun stuff, you’ll have to understand Drush aliases. If you don’t, here’s the gist: Drush aliases give you an easy way to run Drush commands on remote Drupal sites, as opposed to only being able to use it on your local sites. If you’re constantly SSH’ing into different environments just to run a couple quick commands, you need to stop doing that.

There’s lots of documentation about Drush aliases and how to create your own, but most of the docs lack notes on some of the lesser known awesome things you can do with aliases. Keep reading, sailor.

Well, one more thing. This is probably a good time to mention a couple quick commands.

Firstly, let’s run an arbitrary shell command on our dev environment.

drush @foo-dev exec echo $SOMETHING

Or maybe we should just go ahead and SSH in to do something a little more complex.

drush @foo-dev ssh

Or maybe we need to do a bunch of aliased commands, but we want to do it without SSH’ing in (because the commands require local files or something). We can make a Drush alias persist until we tell it to stop using:

drush site-set @foo-dev

And then when we’re done doing what we do, we can just run it again without the “@foo-dev” argument to unset it.

Now, keep reading, sailor.

Syncing Ship

(Warning: these headlines are going to get worse and worse)

One of the most common things to do with Drush aliases is to sync stuff from one alias to another.

For example, want to sync the dev site database down into your local?

drush sql-sync @foo-dev @foo-local

How about files? Sync ‘em!

drush rsync @nexderm-dev:%files @nexderm:%files

Or maybe some unwashed sent you a DB dump and you have to import it the old fashioned way?

cat ~/path/to/file.sql | drush sql-cli

Sometimes you want to drop your entire database before importing, to make sure you don’t get any tables left behind from your old install that aren’t supposed to be there. That’s as easy as:

drush sql-drop

Sometimes, it’s useful to be able to automate running arbitrary SQL commands on multiple environments, and that’s pretty easy too. Say for example that you quickly want to get the username for uid 1 on the prod environment (the “drush user-information” command would be much better for this, but shut up).

drush @foo-prod sqlq 'select name from users where uid = 1'

That one is also good for automation, like if you want to write a quick script that changes the username for uid 1 on all environments.

Drupal Without Drupal

It’s often useful to run one-off arbitrary code within the context of Drupal, without having to actually put it in the codebase somewhere. This is typically done one of two ways:

If it’s just a short one-liner, then there’s the ever-useful “php-eval” (aka “ev”) command. For example, let’s inspect a node object.

drush @foo-dev php-eval 'print_r(node_load(123));'

Or if it’s a longer one, then we can just throw our code into a PHP file, and run it using:

drush php-script filename.php

Reports Cohorts

Drush is really good at getting us information from Drupal without waiting for a full page load.

How many times have you navigated to the Watchdog page and sat through page load after page load while you went through the pagination and added filtering and blah blah blah to find an error message? Stop doing that! Do this instead:

drush watchdog-show

There are a lot of useful options for watchdog-show, such as:

  • –tail (continuously show new messages)
  • –full (show the full output, with all of the fields, instead of the summarized version)
  • –severity (such as “–severity=error”)
  • –count (show more than the default 10, such as “–count=100″)

And I’d bet you’re familiar with “drush vget” to get variables, but did you know you can pass “–format=whatever” to get the results formatted as JSON or CSV or YAML or a bunch of other things, for easy scripting?

Another one of my favorites is this charm, which basically prints out the stuff you see on the Status Report page in Drupal. It’s nice for sanity checking before pushing releases live.

drush status-report

And then there’s this guy, which prints out a bunch of useful info about the current installation, such as DB info, path to PHP executable and .ini file, Drupal version, Drupal root, etc. It’s a nice first step when debugging a broken install.

drush status

And for those times when you need to edit a config file (php.ini, or settings.php, or an alias file, or .htaccess, etc.), you can run this to let you choose which of those files to edit and it’ll open it up in an editor for you:

drush config

Using Users

Drush is nothing short of a miracle when it comes to user management.

First of all, there’s the ever-annoying task of logging in as this user or that user. You usually don’t know the password, or maybe you’re just too lazy to type it. Run this to open up your browser with a one-time login link so you can skip all of that malarky:

drush user-login name-or-uid

Or, if you’re slightly less lazy, and just want to change the password to something so that you can log in the old fashioned way:

drush user-password name-or-uid --password=test1234

Then there’s the “fun” process of adding a user and filling out the form. Skip that:

drush user-create person123 --mail="" --password="letmein"

Once that’s done, you probably want to give that new user some roles. For role stuff, you have this:

drush user-add-role "user editor" person123 drush user-remove-role "user editor" person123

But watch out! The role you need to add doesn’t exist yet! Let’s add it, and give it some permissions.

drush role-create 'user editor' drush role-add-perm 'user editor' 'administer users'

If you just need to show information about a user, such as email address, roles, UID, etc., try this. I’m embarrassed to say that I’ve been using raw SQL for this for years.

drush user-information name-or-uid

Fields of Dreams

One of the most under-used things that Drush gives you is field management tools. I’m going to be lame here and just copy and paste the docs, since they’re pretty self explanatory.

Field commands: (field) field-clone Clone a field and all its instances. field-create Create fields and instances. Returns urls for field editing. field-delete Delete a field and its instances. field-info View information about fields, field_types, and widgets. field-update Return URL for field editing web page.

Other Schtuff

Here are some great commands that don’t really fit into any clear-cut categories.

It has some neat archiving tools:

drush archive-dump #backup code, files, an DB to a single package drush archive-restore #expand one of those archives into a full Drupal site

Somewhat similar to those is this one, which will download and install Drupal, serve it using a little built-in server, and log you in, all in one command. Note that this one includes about a bazillion options and is super duper powerful.

drush core-quick-drupal

Drush also lets you play with the cache, which can save a lot of time when debugging a caching issue:

drush cache-get your-cid your-bin drush cache-set your-cid your-data your-bin your-expire

There are a couple unknown commands for working with contrib:

drush pm-info modulename #display included files, permissions, configure link, version, dependencies, etc. drush pm-releasenotes modulename #show the release notes for the version of module that you're using

Run cron! Not exciting, but super useful.

drush cron

Have you ever been in the middle of debugging and you know that something is happening in a form_alter (or some other hook) but you’re not sure in which module? Try this command, which will tell you all of the implementations of a given hook, and let you choose one to view the source code of it.

drush fn-hook form_alter

And finally, this bad boy is basically “Drush docs in a box” and has a TON of useful info. Seriously, try it now.

drush topic

Drushful Thinking

There’s a giant heap of useful Drush commands, some of which you hopefully hadn’t seen before. So what, right?

The “so what” is that it’s useful to start thinking in terms of “how can Drush do this for me?” and you’ll often find that the answer is “pretty easily.”

Play a game with yourself. Next time you’re working on site building or anything that involves a lot of clicky clicky in the Drupal UI, give yourself a jellybean or a chip or something every time you do something in Drush instead of in the UI.

But why? Well for one, before you know it, you’ll be spending  much less time waiting on page loads. But secondly, Drush lends itself to automation, and thinking in terms of Drush naturally leads you to think in terms of automating and scripting things, which is a great place to be.

Practice some Drushful Thinking! And let me know any of your favorite Drush tips and tricks in the comments. Check out for some more inspiration.

Catégories: Elsewhere

Appnovation Technologies: Easing Time Inc.'s Transition to Drupal

lun, 24/11/2014 - 16:25


var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Catégories: Elsewhere

3C Web Services: Essential Drupal 7 Modules

lun, 24/11/2014 - 16:01


Drupal is a great CMS but really isn't very powerful out of the box. To harness its power you'll need to use contrib (contributed) modules. Contributed modules are created by the community and are not part of the core Drupal download. But they can be downloaded and installed from the website.

Catégories: Elsewhere

Midwestern Mac, LLC: NFS, rsync, and shared folder performance in Vagrant VMs

lun, 24/11/2014 - 15:28

It's been a well-known fact that using native VirtualBox or VMWare shared folders is a terrible idea if you're developing a Drupal site (or some other site that uses thousands of files in hundreds of folders). The most common recommendation is to switch to NFS for shared folders.

NFS shared folders are a decent solution, and using NFS does indeed speed up performance quite a bit (usually on the order of 20-50x for a file-heavy framework like Drupal!). However, it has it's downsides: it requires extra effort to get running on Windows, requires NFS support inside the VM (not all Vagrant base boxes provide support by default), and is not actually all that fast—in comparison to native filesystem performance.

Catégories: Elsewhere

Open Source Training: A Beginners Guide to the Drupal Services Module

lun, 24/11/2014 - 15:21

The Services module allows to provide web services from your Drupal site.

Services is really popular and works with formats such as REST, XMLRPC, JSON and SOAP.

However, when asked about Services during a training in class last week, I was realized that the students were asking me because there was little-to-no clear documentation available.

So, I sat down with and decided to write a Beginners guide to the Services module.

Here's a 5-step guide to using Services creating a REST API for your Drupal site.

Catégories: Elsewhere

Web Omelette: Drupal update hooks with multiple passes

lun, 24/11/2014 - 14:05

If you do a lot of Drupal development and need to deploy configuration I am sure that you are using update hooks to some extent at least. If you don't use Features and want to create a taxonomy vocabulary or something in code, the hook_update_N() hook is the way to go.

But have you ever needed to perform an update the size of which would exceed PHP's maximum execution time? If you need to create 1000 entities (let's just say as an example), it's not a good idea to trust that the production server will not max out and leave you hanging in the middle of a deploy. So what's the solution?

You can use the batch capability of the update hook. If you were wondering what the &$sandbox argument is for, it's just for that. You use it for two things mainly:

  • store data required for your operations across multiple passes (since it is passed by reference the values remain)
  • tell Drupal when it should stop the process by setting the $sandbox['#finished'] value to 1.

Let me show you how this works. Let's say we want to create a vocabulary and a bunch of taxonomy terms with names from a big array. We want to break this array into chunks and create the terms one chunk at the time so as to avoid the load on the server.

So here is how you do it:

/** * Create all the terms */ function my_module_update_7001(&$sandbox) { $names = array( 'Fiona', 'Jesse', 'Michael', ... 'Sam', 'Nate', ); if (!isset($sandbox['progress'])) { $sandbox['progress'] = 0; $sandbox['limit'] = 5; $sandbox['max'] = count($names); // Create the vocabulary $vocab = (object) array( 'name' => 'Names', 'description' => 'My name vocabulary.', 'machine_name' => 'names_vocabulary', ); taxonomy_vocabulary_save($vocab); $sandbox['vocab'] = taxonomy_vocabulary_machine_name_load('names_vocabulary'); } // Create the terms $chunk = array_slice($names, $sandbox['progress'], $sandbox['limit']); if (!empty($chunk)) { foreach ($chunk as $key => $name) { $term = (object) array( 'name' => $name, 'description' => 'The name is: ' . $name, 'vid' => $sandbox['vocab']->vid, ); taxonomy_term_save($term); $sandbox['progress']++; } } $sandbox['#finished'] = ($sandbox['progress'] / $sandbox['max']); }

So what happens here? First, we are dealing with an array of names (can anybody recognise them by the way?) Then we basically see if we are at the first pass by checking if we had set already the progress key in $sandbox. If we are at the first pass, we set some defaults: a limit of 5 terms per pass out of a total of count($names). Additionally, we create the vocabulary and store it as a loaded object in the sandbox as well (because we need its id for creating the terms).

Then, regardless of the pass we are on, we take a chunk out of the names always offset by the progress of the operation. And with each term created, we increment this progress by one (so with each chunk, the progress increases by 5) and of course create the terms. At the very end, we keep setting the value of $sandbox['#finished'] to the ratio of progress per total. Meaning that with each pass, this value increases from an original of 0 to a maximum of 1 (at which point Drupal knows it needs to stop calling the hook).

And like this, we save a bunch of terms without worrying that PHP will time out or the server will be overloaded. Drupal will keep calling the hook as many times as needed. And depending on the operation, you can set your own sensible chunk sizes.

Hope this helps.

var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Catégories: Elsewhere

Another Drop in the Drupal Sea: R.O.O.S.T.S. && Women in Tech

lun, 24/11/2014 - 12:57

There was a session at BADCamp this year asking how Men can be better allies for Women in tech. The panelists had experiences with males that ranged from helpful, to innocently bungled, to outright demeaning. There was a small amount of suggestions about what men can do to be better allies.

read more

Catégories: Elsewhere

BlackMesh: Strategies for businesses investing (in Drupal 8) through giving their employees Drupal contribution time

lun, 24/11/2014 - 06:00

By Cathy Theys, with help from xjm, Michael Schmid, and Donna Benjamin.


The target audience of this post is decision makers in businesses that are deciding if and how their employees might work on Drupal 8 in a way that helps Drupal 8 be released faster. There are benefits to the individuals and the company from every kind of contribution, even if it does not match the recommendations in this post.

Do not let anything hold you back. Just doing it is better than not doing it at all. Contribution does not have to be perfect. Drupal is great at helping people get involved at whatever level they want to be involved.

See these great resources to help you get started:

People will be helpful and supportive.


There are lots of ways that businesses invest in Drupal. Some sponsor events like Drupal camps or DrupalCons. Some help fund travel for key contributors to attend sprints (hearing about the need via word of mouth or an employee who knows of someone in need and brings it to their employer's attention). Some host sprints in their offices. Some have Drupal Association memberships, are Drupal Association Supporting Partners, or join contribution alliances like Large Scale Drupal. Some produce training or documentation. Some contribute funding directly to community members working on a specific project. Some give money to teams or individuals via Drupal Gratipay.

Companies paying their employees to contribute

Some businesses are giving their employees contribution time or are hiring people specifically to contribute.

This post covers some ideas to make employee paid contribution time an even more effective investment, especially when companies want to help with getting Drupal 8 released.

Types of Contribution

Strategies in this post can apply in general to contributing:

  • to any open source project,
  • to a Drupal project, module, theme, distribution,
  • to Drupal core,
  • to infrastructure or testbot (Continuous Integration aka CI 2.0),
  • on the security team
  • by planning an event like DrupalCon, a Drupal camp, or a sprint,
  • by preparing talks or trainings for Drupal events,
  • at a meta level by working in a governance group like the DA board or a Drupal Working Group,
  • to improvements like issue queue workflow, profiles, landing page content, or
  • by building, maintaining, or sponsoring outside tools (like or Drupical).

Drupal is constantly improving its recognition and definition of contribution to include: organizing, communicating, fundraising, testing, documenting, mentoring, designing, architecting, reviewing, and coding.

A particular interest to me is contributing to Drupal 8 and helping it get released sooner. (It is of interest to some businesses too :) which is what inspired this post.)

Contributing to Drupal 8 release

The Drupal 8 branch of the codebase was opened for development in early 2011. The first Drupal 8 beta was released October 1 2014. There are 125 Drupal 8 critical issues (some complex, some straightforward). A Drupal 8 release candidate will be tagged when there are zero critical issues, and once subsequent critical issues are resolved, one such release candidate will become the 8.0.0 release. There will be much rejoicing. (Check the Release cycle page on for up-to-date release cycle information.)

What is really needed to help Drupal 8 get released?

  • Reviewing
    Lack of quality reviews is the biggest problem we have. People get good at giving quality reviews first by just reviewing. Their review skills will get better over time.
  • Keeping critical issue summaries clear and up-to-date
    This is not easy busy work; this is much appreciated and important. Some issues will not be committed without an accurate summary. Summaries help people get involved with, stay involved in, and review issues.
  • Adopting issues
    An issue can have a working patch, but that is not sufficient to get it committed. Sometimes an issue needs someone to adopt it and not give up until it is marked fixed and committed. This person becomes familiar with the issue, and checks in on it to see what it needs: maybe a re-roll, maybe an issue summary update, maybe track down a particular person whose feedback is needed, … they pay attention to the issue and help it get whatever it needs so that issue gets committed.
  • Focusing on development milestones and release blockers
    Unblocking the beta-to-beta upgrade path will enable more early adopters to begin investing resources in Drupal 8. Work on upgrade path issues, other critical Drupal 8 issues which block release, and release-blocking changes to is the most direct way to accelerate the release itself.
  • Paying attention to Drupal 8 news and priorities
    Reading Drupal 8 updates is a good way to stay up-to-date.
Benefits of Contribution

What benefits would a company be looking for?

  • A quicker release of Drupal 8 means your organization can use all of Drupal 8's improvements for real projects, as well as drive growth in Drupal-related businesses (like Drupal hosting and training).
  • Employees with expertise in Drupal 8.
  • Employees with better skills. (Employees will interact with a huge community of experts, and learn from them.)
  • Employees with more skills. All Drupal 8 issues have to pass core gates in: documentation, accessibility, usability, performance, and testing. People who work on core issues learn about those areas.
  • Employees with even more skills. Working with the community builds other valuable skills, that are not strictly about technology, applicable to internal processes as well as to client work.
  • Saving money on training. Businesses just have to pay for one side of the "training", for their employee time. They do not have to pay for the trainer time like they would for on-site training, or pay for training classes for their employees to attend.
  • Making connections with possible future additional employees.
  • Raising the company's profile, brand recognition, and appeal. (See Dries's DrupalCon Amsterdam Keynote on contribution recognition.)
  • Steering the future of Drupal in ways that align with the company and the community.
Strategies for businesses investing in getting Drupal 8 released sooner through giving their employees Drupal contribution time Reduce ramp-up time.

Sometimes people who are experts at their job, in a certain area, can feel ineffective or inefficient while contributing. Before telling everyone "Go contribute", businesses can:

  • consult with an experienced contributor or mentor for advice on structuring your contribution policies or program ,
  • share resources with employees about how to contribute,
  • get employees tools that might help for contributing (they maybe not the same tools necessary for their job), and/or
  • have employees attend a sprint that has mentoring for new contributors, or work with experienced contributors and mentors online in #drupal-contribute in IRC, in #drupal during core mentoring hours, or arrange for an experienced contributor or mentor to hold an event onsite (or virtually) for employees.
Reduce pressure to work on client or internal deadlines.

Not every employee will be interested in spending work time on contribution. Instructing all employees to contribute may not have the best results.

For example, if a company schedules certain time for contribution, say the last Friday of the month, for all employees to optionally spend the day contributing, some people will want to spend that time on client work, or internal projects, maybe because of a deadline, or maybe just because they do not want to contribute that day. People who want to contribute during the scheduled time will see their co-workers working on work projects and feel pressure to also not contribute.

Something that can overcome this, is letting people who want to contribute, contribute during off time, so they are still working while the rest of their team is. They can keep track of their contribution time, and later exchange it for scheduled vacation or professional develop time going to conferences or training.

Consolidate time.

The following strategies center around an idea: Concentrate your resources.

Let's take an example: a business who has 10 employees that is thinking about giving each person 4 hours of contribution time every week (10% time), or having one day a month where everyone contributes (5% time).

4 hours a week, or one day a month is not enough to work on a complicated issue. The time would start with reading any new comments on an issue, maybe changing local environment (requirements are different for Drupal 8 compared to Drupal 7), seeing if any changes in the code base effect the issue, maybe verifying the problem still exists, … thinking, trying ideas, maybe there would be enough time to implement them, and post back to the issue, update the issue summary as needed and explain what was changed and why in a comment, but more likely, there would not be enough time. It depends on the complexity of the problem.

There are things that a person can do with 4 hours a week that are helpful contributions. There are even things on issues blocking Drupal 8 release that people could do… but there are things where after 4 hours, a person is just understanding enough to get started ... and then they are out of time, and have to wait till next week. Where they might need to spend the 4 hours getting back up to speed again.

Consolidate by saving up contribution time.

If employees have 4 hours a week contribution time, let them save it up for a couple months, and then use it in a chunk. For example, if someone does not contribute for 2 months, they could then have 36 hours of contribution time they could save up and take a (almost) full week to tackle a complicated problem, or tackle a bunch of not quite so complicated issues, without having the overhead of ramping up and context switching.

Consolidate by giving fewer people more contribution time.

Instead of 10 people contributing 4 hours a week, pick 2 people from those that that want to contribute, give them each 20 hours a week.

With 20 hours a week, there is time to work on a complex problem, and also respond to feedback quickly. This reduces the overhead of needing to come back up to speed, context switching, or rebasing on a code base that has changed a lot.

With more consecutive time, people can concentrate on more complex problems, and stay up to date better, with less overhead. We can take that even further...

Focus long-term.

If instead of 10 people contributing 4 hours a week, you have 2 people contributing 20 hours a week, let them plan to do that for a few months.

Some issues need someone to look after them, week after week, to see the issue through to completion.

When someone shows they can make a reliable and ongoing contribution to the project, other experienced contributors, or project leaders will invest more into bringing that person up to speed and helping them get things done.

Give people 3-4 months where they can plan on contributing.


After a few months, bring an employee back to full time client billable hours. And give another employee a turn to concentrate on contributing for 3-4 months.

Employees learn so much while contributing. Returning to focus on client projects or in-house work with their team is an opportunity to share that learning with everyone in the company. The company benefits from the improved skills and new community connections that employee gained while contributing directly to the project.

This can also help to protect people from burning out on contributing.


Here are some examples of businesses having their employees contribute. Some are recent, some have been doing this for years. [These are examples of direct Drupal core contribution by employers. There are many ways to contribute to Drupal, and many businesses contribute in different, valuable ways.]

  • Blink Reaction had a sprint for their employees and brought in local experienced contributors and mentors to help their employee contribution time be effective, and get help targeting issues that are currently relevant. Blink Reaction had their event on non-working hours, a Saturday, so people did not have to stop working during regular hours when they feel like they should be working on projects with deadlines. People who work a full day at the contribution event on Saturday, get a compensation day they can schedule to take later.
  • Pantheon is hiring a contributor, and going to bring in an experienced contributor to mentor that person for a week or two.
  • Acquia has multiple full-time employees working on Drupal 8 issues.
  • Chapter Three employs one of Drupal 8's four branch maintainers to work on Drupal 8.
  • NodeOne (now part of Wunderkraut)), Zivtech, erdfisch, comm-press, Cheppers, Breakthrough Technologies, and New Digital Partnership (among others) dedicated 25-50% of one employee's time for several months to a particular Drupal core initiative.
  • Freelancers and independents like Jennifer Hodgdon (and many others) incorporate contribution work with their billable time.
  • PreviousNext hired Donna (kattekrab) Benjamin to help focus the company's community engagement activities. She spends half her time on client work to ensure her role is sustainable, and half her time on community activity, such as the community working group, Drupal Association board and organising events. She also works with the PreviousNext team to help them find their own niche for making a useful contribution. Lee (larowlan) Rowlands and John Albin also spend some of their paid time mentoring other PreviousNext staff to contribute, who all have 20% time to work on the Drupal project code or community.
  • Amazee Labs built their own company website on Drupal 8 Alpha and continues to implement customer websites on Drupal 8. Employees are paid to: find issues in Drupal 8, open issues in the issue queues, fix them, post the fixes on the issues, and further work on the issues.
  • BlackMesh hired me. :) To work on Drupal 8 issues and to help others contribute to Drupal.
Help for businesses

Sometimes it helps to have someone you can just talk to. You can talk to me. Reach out and ask any questions you have. I can answer them, or connect you with people who can.


Contribute. Doing it in any way is better than doing it perfectly. These are some strategies for paying employees to contribute that will help Drupal 8 release sooner. Concentrate your resources. Talk to others about what works at their companies. Get help from experienced contributors and mentors.


If there are corrections or missing examples, please let me know.

@YesCT or contact form

ps. How to find and contact mentors and experienced contributors

See the list of core mentoring leads in MAINTAINERS.txt, and contact them in #drupal-contribute in IRC or via their contact pages. There are also more mentors beyond the mentoring maintainers, and there is not exactly a list of experienced contributors. So, please feel free to just contact me and I can put you into contact with others.

DrupalContributorSprintsDrupal 8
Catégories: Elsewhere

orkjerns blogg: Headless Drupal with head fallback

dim, 23/11/2014 - 22:22
Headless Drupal with head fallback admin Sun, 11/23/2014 - 21:22

I just wanted to take a moment to talk about how I approached the hot word "headless Drupal" on my blog. It uses some sort of "headless" communication with the Drupal site, but it also leverages Drupal in a standard way. For different reasons. (by the way, if you are interested in "headless Drupal", there is a page about the subject.)

First of all, let's examine in what way this simple blog is headless. It is not headless in the way that it offers all the functionality of Drupal without using Drupals front-end. For example, these words I am typing is not typed into a decoupled web-app or command-line tool. Its only headless feature is that it loads content pages with ajax through Drupal 8's new REST module. Let's look at a typical set-up for this, and how I approached it differently.

A typical setup

A common way to build a front-end JavaScript application leveraging a REST API, is using a framework of your choice (backbone / angular / or something else *.js) and build a single-page application (or SPA for short). Basically this could mean that you have an index.html file with some JavaScript and stylesheets, and all content is loaded with AJAX. This also means that if you request the site without JavaScript enabled, then you would just see an empty page (except of course if you have some way of scraping the dynamic content and outputting plain HTML as fallback).

Head fallback

I guess the "headless" metaphor sounds strange when I change it around to talk about "head fallback". But what I mean with this is that I want a user to be able to read all pages with no JavaScript enabled, and I want Drupal (the head) to handle this. All URLs should also contain (more or less) the same content if you are browsing with JavaScript or without it. Luckily, making HTML is something Drupal always has done, so let's start there.

Now, this first part should be obvious. If a user comes to the site, we show only the output of each URL as intended with the activated theme. This is a out-of-the box feature with Drupal (and any other CMS). OK, so the fallback is covered. The next step is to leverage the REST module, and load content async with AJAX.

Head first, headless later

A typical scenario would be that for the front page I would want to request the "/node" resource with the header "Accept:application/hal+json" to get a list of nodes. Then I would want to display these in the same way the theme displays it statically on a page load. The usual way of doing this is that when the document is ready, we request the resource and build and render the page, client side. This is impractical in one way: You are waiting to load the entire document to actually render anything at all. Or maybe even worse: You could be waiting for the entire /node list to load, only to destroy the DOM elements with the newly fetched and rendered JSON. This is bad for several reasons, but one concrete example is a smart phone on a slow network. This client could start rendering your page on the first chunk of html transferred, and that would maybe be enough to show what is called the "above the fold content". This is also something that is a criteria in the often used Google PageSpeed. Meaning in theory that our page would get slower (on first page load) by building a SPA on top of the fallback head.

It is very hip with some "headless Drupal" goodness, but not at the cost of performance and speed. So what I do for the first page load, is trust Drupal to do the rendering, and then initializing the JavaScript framework (Mithril.js in my case) when I need it. Let's take for example you, dear visitor, reading this right now. You probably came to this site via a direct link. Now, why would I need to set up all client side routes and re-render this node when all you probably wanted to do, was to read this article?

Results and side-effects

OK, so now I have a fallback for JavaScript that gives me this result (first picture is without JavaScript, second is with JavaScript):

As you can see, the only difference is that the disqus comment count can not be shown on the non-js version. So the result is that I have a consistent style for both js and non-js visitors, and I only initialize the headless part of the site when it is needed.

A fun (and useful) side-effect is the page speed. Measured in Google PageSpeed this now gives me a score of 99 (with the only suggestion to increase the cache lifetime of the google analytics js)

Is it really headless, then?

Yes and no. Given that you request my site with JavaScript enabled, the first page request is a regular Drupal page render. But after that, if you choose to go to the front page or any other articles, all content is fetched with AJAX and rendered client side.

Takeaways and lessons learned

I guess some of these are more obvious than others.

  • Do not punish your visitor for having JavaScript disabled. Make all pages available for all users. Mobile first is one thing, but you could also consider no-js first. Or both?
  • Do not punish your visitor for having JavaScript enabled. If you render the page based on a AJAX request, the time between initial page load and actual render time will be longer, and this is especially bad for mobile.
  • Subsequent pages are way faster to load with AJAX, both for mobile and desktop. You really don't need to download more than the content (that is, the text) of the page you are requesting, when the client already have the assets and wrapper content loaded in the browser.

First: these techniques might not always be appropriate for everyone. You should obviously consider the use case before using a similar approach

If you, after reading this article, find yourself turning off JavaScript to see what the page looks like, then you might notice that there are no stylesheets any more. Let me just point out that this would not be the case if your _first_ page request were without JavaScript. By requesting and rendering the first page with JavaScript, your subsequent requests will say to my server that you have JavaScript enabled, and thus I also assume you have stored the css in localStorage (as the js does). Please see this article for more information

Let's just sum this up with this bad taste gif in the category "speed":

Catégories: Elsewhere Todo app with RESTful backend

sam, 22/11/2014 - 23:00

The Drupal community can now proudly claim its own implementation of a Todo app with a RESTful backend!

TodoMVC is a site that helps you select the right JS MVC library. But more then that, it allows you to learn by comparing those libraries, as they all implement the same thing - a simple Todo app.

I've decided to fork the Angular example, and build it on top of RESTful. Looking at the Angular code, I was pleasantly surprised.

Continue reading…

Catégories: Elsewhere

Paul Booker: How to determine the A and MX records for a given Domain for a given DNS server

sam, 22/11/2014 - 11:36
$ dig A @ ; <<>> DiG 9.8.3-P1 <<>> A @ ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55528 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: 10800 IN A ;; Query time: 131 msec ;; SERVER: ;; WHEN: Fri May 31 17:44:54 2013 ;; MSG SIZE rcvd: 50 $ dig MX @ ; <<>> DiG 9.8.3-P1 <<>> MX @ ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42037 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ; IN MX ;; ANSWER SECTION: 10800 IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. 10800 IN MX 1 ASPMX.L.GOOGLE.COM. 10800 IN MX 10 ASPMX2.GOOGLEMAIL.COM. 10800 IN MX 10 ASPMX3.GOOGLEMAIL.COM. 10800 IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. ;; Query time: 122 msec ;; SERVER: ;; WHEN: Fri May 31 17:46:13 2013 ;; MSG SIZE rcvd: 167

If no DNS server argument is provided, dig consults /etc/resolv.conf and queries the name servers listed there.

$ cat /etc/resolv.conf # # Mac OS X Notice # # This file is not used by the host name and address resolution # or the DNS query routing mechanisms used by most processes on # this Mac OS X system. # # This file is automatically generated. # nameserver nameserver

These nameservers are provided by my broadband provider ..

$ dig -x ; <<>> DiG 9.8.3-P1 <<>> -x ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48388 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ; IN PTR ;; ANSWER SECTION: 22026 IN PTR ;; Query time: 12 msec ;; SERVER: ;; WHEN: Fri May 31 17:50:01 2013 ;; MSG SIZE rcvd: 88

.. virgin media via DHCP.

If you want to find out more about dig then you need to "man dig" not sure what man is, then you need to "man man". Dig? :D

Catégories: Elsewhere

Paul Booker: Allowing a user to login only if they have an active infusionsoft CRM contact.

sam, 22/11/2014 - 11:17
/** * Implements hook_user_login(). */ function mymodule_infusionsoft_user_login(&$edit, $account) { global $tag; if (user_access('administer site configuration')) { return TRUE; } $contact_active = _mymodule_infusionsoft_contact_active($account->mail); if ($contact_active == FALSE) { session_destroy(); session_start(); // Load the anonymous user $user = drupal_anonymous_user(); drupal_set_message(variable_get('mymodule_infusionsoft_message', 'Infusionsoft account not created or has expired.'), 'warning'); if (empty($tag)) drupal_goto('user/register'); if ($tag == "expired") drupal_goto('account-expired'); if ($tag == "blocked") drupal_goto('account-blocked'); } else { // Update membership roles to match CRM groups/tags _mymodule_infusionsoft_update_membership_roles($account); } } function _mymodule_infusionsoft_contact_active($mail) { global $tag; $contact_active = FALSE; $contact_id = infusionsoft_contact_load_by_email($mail); if (!empty($contact_id) && is_numeric($contact_id)) { $groups = infusionsoft_group_contact_options($contact_id); $num_groups = count($groups); if ($num_groups == 0) return FALSE; if (in_array(STATUS__EXPIRED, $groups)) { $tag = "expired"; return FALSE; } if (in_array(STATUS__LIVE, $groups)) { $tag = "active"; return TRUE; } } Tags:
Catégories: Elsewhere

3C Web Services: How to redirect all traffic to HTTPS on your Drupal site

sam, 22/11/2014 - 00:57

Since Google announced that it gives an additional SEO boost for sites that are fully encrypted with HTTPS it is now advisable to encrypt your entire site and not just pages with sensitive information such as user login and checkout pages.

There are multiple method to achieve this. We like using the below modification to .HTACCESS file. Simply add this code to the .HTACCESS file that is located in the Drupal root directory after the the line "" and all traffic to your site will now automatically be redirected from HTTP to HTTPS.

Catégories: Elsewhere

ImageX Media: Delivery Documentation

ven, 21/11/2014 - 22:11
When buying a car, there’s a reason you are given such a comprehensive user's manual to cover everything that the salesperson or technician was unable to show you how to do in the first demonstration. Things like what to do when the "Check Engine" light comes on, or which grade of oil to use when it comes time for an oil change. Although you may not reference it often, when needed the supporting user manual is worth its weight in gold.
Catégories: Elsewhere

Blink Reaction: Matt Korostoff Talks REST and SOAP

ven, 21/11/2014 - 21:53

This talk was given at Drupal Camp Baltimore 2014. In it, I discuss REST and (briefly) SOAP APIs built with Drupal. I give a number of hands on examples using Views Datasource, RESTful Web Services (restws), and the Services module.

Catégories: Elsewhere