Nu ook in het Nederlands.

Feed aggregator

clemens-tolboom pushed to feature/triage at clemens-tolboom/dreditor

On github - Wed, 2014/05/28 - 1:07pm
May 28, 2014 clemens-tolboom pushed to feature/triage at clemens-tolboom/dreditor
  • 105e2fc Added task/target 'dev' to speed up rebuild via 'grunt watch:dev' for…
  • b026d2a Fixed patch review buttons are duplicating themselves on every invoca…
  • 143 more commits »

OhTheHugeManatee: Drupal Superheroes: ASSEMBLE!

Planet Drupal - Wed, 2014/05/28 - 12:44pm

Regular Drupalcon attendees know that the opening pre-keynote session is one of the highlights of the con. That’s the session where we welcome everyone to the con with stupid jokes, some well known Drupalists, and a lot of fun. This year is going to be especially good – and we need your help!

The evil Lord Over Engineering is threatening to delay the release of the CMS, which we need to save the world! The only way to stop him is to assemble the greatest force of Drupal superheroes ever assembled! Can the heroes save the day? Can we manage to make the final git push? You’ll have to be there to find out!

“If you only get up early once during DrupalCon, this is the morning to do it. And hey, at least you’ll get better seats for my keynote right after.” — Dries

In Prague we had the Drupal Opera, with solos sung by Gabor Hojtsy. In Portland we had the Drupal Game show, including Doug Vann’s amazing beatbox of the Tetris theme. In Munich, we taught the world to yodel and pour good German beer. Don’t miss out this year! The fun is just getting started!

If you want to participate onstage, you can go to Robert Douglass’ blog and sign up with our superhero/villain application form. But even if you just want to party from your comfy chair in the audience, costumes are encouraged! So get your best superhero costume together, and I’ll see you at the pre-keynote!


Mogdesign: 2/3 Using custom fields in the feed/csv

Planet Drupal - Wed, 2014/05/28 - 11:00am

This is part 2 of Aegir mini-series.


clemens-tolboom opened issue dreditor/dreditor#181

On github - Wed, 2014/05/28 - 10:59am
May 28, 2014 clemens-tolboom opened issue dreditor/dreditor#181 Patch name suggestion seems broken

Drupal core announcements: Rerolling patches for PSR-4

Planet Drupal - Wed, 2014/05/28 - 8:01am

All Drupal 8 core module code was recently converted to the PSR-4 standard. This issue moved hundreds of files and so many patches will need rerolls. You can update patches safely with the following workflow (provided by @donquixote):

  1. Ensure you have the latest 8.x HEAD in your Drupal 8 repository: git pull origin 8.x
  2. git checkout -b tmp 00339b3d to create a new a new (temporary) branch from the Drupal 8 commit hash before the patch for Issue #2247991 i=was committed.
  3. git apply --index the patch and commit to the new branch.
  4. git rebase 8.x -- This should actually preserve all the local changes to existing files, because git understands if a file has been moved.
  5. Run php core/scripts/ and commit the changes. This is for files that were added in the patch or local branch. Remember, this script will add and remove files without udpating the git index, so you will need to add and remove files with git add.
  6. git diff 8.x to produce a new version of the patch.
  7. Upload the new patch to the issue and set the issue "Needs review".

As always, be sure to review your updated patch carefully for any errors.


AGLOBALWAY: Drupal Social Media Login with OneAll Social Login in 3 easy steps

Planet Drupal - Tue, 2014/05/27 - 9:49pm
As social media is more and more popular, logging into your preferred CMS tool with your social media account is clearly becoming one of the most frequent requirements in most projects.    There are a bunch of modules contributed to this feature. Here we’ll go over what it takes to implement "OneAll Social Login", which is available for Drupal 7 only. For more details, please visit the module page With this module, it is super convenient to connect your Drupal site with the users' social media account.    First, you need a OneAll account and API credentials. You can register here:   For the Drupal site, download the module and enable all the components: Oneall Social Login, Oneall Social Login Core, and Oneall Social Login Widget.    Then go to the configuration -> Social Login plugin settings page to enter your API Keys, choose your settings and enable the Social Networks of your choice.   What's next? All set! The API supports more than 20 social networks including almost all the hot sites like Facebook, Twitter, Google, Linkedin, Yahoo, OpenID... It is really an all in one module make everything on the fly.  Tags: drupaldrupal planet

Robert Douglass: Attention Drupal Super Heroes! Your powers are needed!

Planet Drupal - Tue, 2014/05/27 - 8:19pm

Calling all DRUPAL SUPER HEROES: it is time to assemble! The CMS is threatened by Lord Over-Engineering, and only you can help save humanity! 

We're looking for volunteers to participate in Rob and Jam's pre-keynote opening session at DrupalCon, Austin, in 1 week. If you don't know what I'm talking about, just imagine yourself having this much fun:

Not fun enough? How about THIS MUCH FUN:

You get the picture?

Just fill out the following form to sign up for the most important Drupal adventure of your lifetime.

I hereby attest to posession of DRUPAL SUPER POWERS which I will use to serve the good of mankind and defeat LORD OVER-ENGINEERING at DrupalCon, Austin. I am fully aware that this obligates me to not only attend the showdown pre-keynote session, which takes place at the inhumanly early hour of 8am on Tuesday, June 3, but also to disquise my true identity and dress as is appropriate for a DRUPAL SUPERHERO to dress

Name E-mail Description of Super Powers I can fly Yes No Roles that I would like to play Evil minion Vigilante posse Offstage coordinator Assistant to Lord Over Engineering Innocent bystander Damsel in distress Victim of senseless annihilation By submitting this form, you accept the Mollom privacy policy.

Phase2: Combining Tasks with Grunt

Planet Drupal - Tue, 2014/05/27 - 7:37pm

I was recently asked to help out with a few build steps for a Drupal project using Grunt as its build system. The project’s Gruntfile.js has a drush:make task that utilizes the grunt-drush package to run Drush make. This task in included in a file under the tasks directory in the main repository.


module.exports = function(grunt) { /** * Define "drush" tasks. * * grunt drush:make * Builds the Drush make file to the build/html directory. */ grunt.loadNpmTasks('grunt-drush'); grunt.config('drush', { make: { args: ['make', '<%= config.srcPaths.make %>'], dest: '<%= config.buildPaths.html %>' } }); };

You can see that the task contains a few instances of variable interpolation, such as <%= config.srcPaths.make %>. By convention, the values of these variables go in a file called Gruntconfig.json and are set using the grunt.initConfigmethod. In addition, the configuration for the default task lives in a file called Gruntfile.js. I have put trimmed examples of each below.


module.exports = function(grunt) { // Initialize global configuration variables. var config = grunt.file.readJSON('Gruntconfig.json'); grunt.initConfig({ config: config }); // Load all included tasks. grunt.loadTasks(__dirname + '/tasks'); // Define the default task to fully build and configure the project. var tasksDefault = [ 'clean:default', 'mkdir:init', 'drush:make' ]; grunt.registerTask('default', tasksDefault); };


{ "srcPaths": { "make": "src/project.make" }, "buildPaths": { "build": "build", "html": "build/html" } }

As you can see, the project’s Gruntfile.js also has a clean:default task to remove the built site and a mkdir:inittask to make the build/html directory, and the three tasks are combined with grunt.registerTask to make the default task which will be run when you invoke grunt with no arguments.

A small change

In Phase2′s build setup using Phing we have a task that will run drush make when the Makefile’s modified time is newer than the built site. This allows a user to invoke the build tool and only spend the time doing a drush make if the Makefile has indeed changed.

The setup needed to do this in Phing is configured in XML: if an index.php file exists and it is newer than the Makefile, don’t run drush make. Otherwise, delete the built site and run drush make. The necessary configuration to do this in a Phing build.xml is below.


<target name="-drush-make-uptodate" depends="init" hidden="true"> <if> <available file="${html}/index.php" /> <then> <uptodate property="drush.makefile.uptodate" targetfile="${html}/index.php" srcfile="${drush.makefile}" /> </then> </if> </target> <!-- Use drush make to build (or rebuild) the docroot --> <target name="drush-make" depends="-drush-make-uptodate, init" hidden="true" unless="drush.makefile.uptodate"> <if> <available file="${html}"/> <then> <echo level="info" message="Rebuilding ${html}."/> <delete dir="${html}" failonerror="true"/> </then> </if> <exec executable="drush" checkreturn="true" passthru="true" level="info"> <arg value="make"/> <arg value="${drush.makefile}"/> <arg value="${html}"/> </exec> </target>

You’ll note that Phing also uses variable interpolation. The syntax, ${html}, is similar to regular PHP string interpolation. By convention, parameters for a Phing build live in a file.

A newer grunt

The grunt-newer plugin appears to be the proper way to handle this. It creates a new task prefixed with newer: to any other defined tasks. If your task has a src and dest parameter, it will check that src is newer than dest before running the task.

In my first quick testing, I added a spurious src parameter to the drush:make task and then invoked the newer:drush:maketask.

grunt.config('drush', { make: { args: ['make', '<%= config.srcPaths.make %>'], src: '<%= config.srcPaths.make %>', dest: '<%= config.buildPaths.html %>' } });

That modification worked properly in concert with grunt-newer (and the drush task from grunt-drush task didn’t complain about the extra src parameter,) but I still also needed to conditionally run the clean:default and mkdir:init only if the Makefile was newer than the built site.

Synchronized grunting

The answer turned out to be to create a composite task using grunt.registerTask and that combined the three tasks existing tasks and then use the grunt-newerversion of that task. The solution looked much like the following.


module.exports = function(grunt) { /** * Define "drushmake" tasks. * * grunt drushmake * Remove the existing site directory, make it again, and run Drush make. */ grunt.registerTask('drushmake', 'Erase the site and run Drush make.', function() {'clean:default', 'mkdir:init', 'drush:make'); }); grunt.config('drushmake', { default : { // Add src and dest attributes for grunt-newer. src: '<%= config.srcPaths.make %>', dest: '<%= config.buildPaths.html %>' } }); }

I could then invoke newer:drushmake:default in my Gruntfile.js and only delete and rebuild the site when there were changes to the Makefile.

Learn more about build systems in Adam Ross’s blog post “Creating Options in Automated Software Deployment.”


Blink Reaction: Why is Symfony in Drupal 8, and how Does that Change Things?

Planet Drupal - Tue, 2014/05/27 - 6:30pm

This post is the first of a series exploring the integration of Symfony2 into Drupal's next major release, Drupal 8.

Is Drupal 8 harder to learn than previous versions?

If you have been working with and developing Drupal modules for a few years, and now you are trying to learn about all of the Drupal 8 changes, your answer may be a resounding, "YES."


2bits: Using Drush for a Seven Day Daily Backup scheme for Drupal sites

Planet Drupal - Tue, 2014/05/27 - 4:50pm
Everyone needs to have a backup plan for their live site. Not only can your server's disk get corrupted, but you can also erroneously overwrite your site with bad code or bad data, or your site can get hacked. Detecting the latter situations takes some time. Hours or days. For this reason, you should have multiple backup copies at multiple time points. The most convenient scheme is to have a 7 day sliding backup: that is, you have one backup snapshot for each day of the week, with today's backup overwriting the backup from 8 days ago.

read more


Dries Buytaert: Acquia raises $50 million series F

Planet Drupal - Tue, 2014/05/27 - 3:48pm
Topic: DrupalAcquiaBusiness

We've got great news to share today; we are announcing that Acquia raised $50 million, the largest round of financing we’ve ever completed.

The round is led by New Enterprise Associates (NEA), one of the world's top investors in our space. They have made various great investments in Open Source (MongoDB, Mulesoft, etc.) as well as SaaS companies (SalesForce, Workday, Box, etc.).

With the new funding, we can continue to go after our vision to help many more organizations with their digital platform and digital business transformation. In addition, Acquia is charting new territory in the world of software with a very unique business model, one that is rooted in Open Source and that helps us build a web that supports openness, innovation and freedom.

We have such a big and exciting opportunity ahead of us. This vision will not come to life on its own and the proprietary competitors are not resting on their laurels. We'll use the funding to double down on all aspects of our company; from increasing our investment in products to deeper investments in sales and marketing.

In addition to lead investor NEA, other investors include Split Rock Partners, and existing investors North Bridge Venture Partners, Sigma Partners, Investor Growth Capital, Tenaya Capital, and Accolade Partners. The new funding will bring Acquia’s total fund-raising to $118.6 million.

Of course, none of this success would be possible without the support of our customers, the Acquia team, our partners, the Drupal community and our many friends. Thanks so much for supporting Acquia!


High Rock Media: Drupal 8 DevOps: Leveraging OpenShift Online PaaS

Planet Drupal - Tue, 2014/05/27 - 3:21pm

In my free time recently, I've been designing and developing a little Drupal 8 site that I'd like to bring online. From the start, I knew I'd need a decent web host with all the fixins' Drush, Git and most of all, PHP 5.4 as that's the minimum required for Drupal 8.

The first place I thought of was Get Pantheon but as it turns out, as of this writing, they only have PHP 5.3. I also took a look at Linode but admittedly I'm not a huge fan as it requires a fair amount of server setup and management.

Enter, OpenShift Online, Red Hat's scalable PaaS or Platform as a Service in the cloud. OpenShift is an all in one development, hosting and deployment platform which supports PHP, Java, Node.js, Python and more. The idea behind this is to let the developer / designer focus on what matters, code and apps rather than tedious server administration and management. For me, this is a huge win and best of all, Red Hat has a basic plan that gets you everything you need for free.

Apps, Gears, and Cartridges

OpenShift's terminology takes a little getting used to but I'll break it down and try to define what's what. Think of an Application as just an instance of a website. Gears are an allocated amount of server resources ranging in size from small to large for scalability. Think of a Cartridge as an a la carte style add on for your app. Need Jenkins, phpMyAdmin or cron? No problem, just browse the list of available cartridges or add one from a URL and OpenShift does all the installation work for you.

Build Your App

My workflow involves developing a website locally and then bringing it into dev / production via Git. With OpenShift, this is no different, however with a few caveats. Normally you'd use .gitignore for persistent non-tracked data files, i.e. Drupal's files directory and then these untracked items can just sit on your server happy to go about their business. However, with OpenShift, anything not in Git gets deleted on the next push regardless of .gitignore. OpenShift handles the untracked files via their data directory - ${OPENSHIFT_DATA_DIR} - and symbolic links. So while .gitignore is fine for your local, you'll need to do a little wrangling on the OpenShift end and I'll show you how.

We can automate file handling by designing a custom deploy script. This can have any command you'd normally execute directly on the server but with added logic to test for certain conditions, e.g whether a file or folder already exists. I wrote a full scale deploy script (Gist) from scratch which turned out to be extremely challenging and a lot of fun. The script executes on each git push.

Getting Started

First, create an account at OpenShift Online, login and create your first app. The best way is to simply click the "Add Application" button in your app console and then search for PHP. I added PHP 5.4 since I was going to use Drupal 8. You'll be asked to name your app and can follow the simple steps there. This creates your base app which is now up and running with the flavor of PHP you chose.

Here's the other OpenShift cartridges I use in my Drupal 8 app.

There's also an option to install PHPmyAdmin as well. Note for Drush, enter the URL in the Cartridge UI page, i.e. "Install your own cartridge" You can also use Red Hat's RHC language to setup Cartridges from your local, it does require Ruby. I'm sure I'll get in to that next, I just have not had time to work on it yet but it looks pretty cool.

Local Setup

Once you've got all your cartridges installed, you can now pull from Git and get your local dev environment setup, ready to push your code up. Here's a general outline of what I do in Terminal that woks well.

 # Within your project directory:
$ git clone [git_url] [project_site]
$ cd [project_site]
 # Remove OpenShift's default index file:
$ rm index.php
 # Now download drupal (latest 8.x Alpha)
$ drush dl drupal-8.0-alpha11
 # Rename the drupal folder to "php"
$ mv drupal-8.0-alpha11 php

With the above setup, you'll note that we rename the Drupal directory to php. That's because OpenShift best serves web files if you have a sub directory named php. They also automatically alias this for you so you don't see php in the URL. Here's how my local directory structure looks once I'm done.

| |____project_site
| | |____.git
| | |____.openshift
| | | |____action_hooks
| | | | |____build
| | | | |____deploy
| | | | |
| | |____php
| | | |____[drupal-files-here]

Push and Deploy

To get around the persistent non-tracked files / folders issue, we can implement the deploy script I mentioned above in our local OpenShift repo that runs on each git push. Essentially this creates a sites/default/files directory in your Openshift data directory or ${OPENSHIFT_DATA_DIR} and then symlinks it to your repo or ${OPENSHIFT_REPO_DIR} In addition, it copies default.settings.php as settings.php to the data directory and proceeds to symlink that as well. The deploy script should be located at:


My deploy script has conditional statements to insure that already existing files and folders in the ${OPENSHIFT_DATA_DIR} don't get overwritten. For your deploy script to be recognized, be sure to give it appropriate permissions. Once you set with all this, it's time to commit and push for the first time.

 # Commit your changes and push to OpenShift
$ git commit -a -m 'Initial commit'
$ git push

On first push, I noticed that my deploy script did not run and that was a real mystery. In the end, it turned out to be a permissions issue on the file. It was set to 644 so a chmod to 777 took care of it. Once git has been pushed and the deploy script runs, here is what my OpenShift /repo/php/sites/all/files directory looks like:

files -> /var/lib/openshift/[app_id]/app-root/data/sites/default/files
settings.php -> /var/lib/openshift/[app_id]/app-root/data/sites/default/settings.php Once you either import your database or install Drupal, you'll want to reset the permissions on settings.php in the data directory to not be writable.

A note about settings.php

I could not find much documentation with regard to Drupal's settings.php and OpenShift. Suffice it to say, I found this snippet. (See further below with regard to QuickStarts.)

if (array_key_exists('OPENSHIFT_APP_NAME', $_SERVER)) {
  $src = $_SERVER;
} else {
  $src = $_ENV;
$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => $src['OPENSHIFT_APP_NAME'],
      'username' => $src['OPENSHIFT_MYSQL_DB_USERNAME'],
      'password' => $src['OPENSHIFT_MYSQL_DB_PASSWORD'],
      'host' => $src['OPENSHIFT_MYSQL_DB_HOST'],
      'port' => $src['OPENSHIFT_MYSQL_DB_PORT'],
      'driver' => 'mysql',
      'prefix' => '',

The code above use OpenShift Environment Variables to connect to your database, this is the preferred method, especially if you build a scaleable app. If you want to print out all the variables, you can SSH in and simply do env in terminal or you can add a build file in your action_hooks directory with the line of code export. The next time you git push, you'll see all these vars print out. Pretty cool!

QuickStarts Alternative

As an alternative to the process I've outlined above and to get up and running super fast on OpenShift, you can choose from a variety of Quickstarts that are offered, these are one click app installs pre-configured with the cartridges you need. An eclectic list is offered appealing to any designer or developer including Ghost, WordPress, Ruby, JBoss and of course Drupal. In the Drupal category sits a Drupal 8 app ready to deploy.

With this method, you'll want to create symlinks from your repo to the themes and modules directory of Drupal. From what I can tell, this method is not meant for a ton of customization and is probably more akin to something like @Srdjan_Popovic blogged about this method for a Drupal 7 QuickStart and you check out his post). What he outlines could be adapted for the Drupal 8 QuickStart as well. I tested Popovic's method out and it worked well.

Is PaaS the Future?

In the end, OpenShift seems to have a lot of promise, especially with a Drupal 8 beta, RC and final release not too far around the corner. Compared to a cPanel hosting paradigm, OpenShift feels modern, fresh and the way forward. It seems like they've adapted to the needs of and the way in which developers are now working.

  • Drupal
  • PaaS
  • OpenShift
  • Drupal Planet
  • DevOps

Drupalize.Me: A Guide to Drupal 8 at DrupalCon Austin

Planet Drupal - Tue, 2014/05/27 - 3:05pm

DrupalCon Austin is rapidly approaching and the big question on my mind is: What Drupal 8 sessions do I need to put on my radar? To figure that out, I've mined the schedule for Drupal 8 related talks and events and organized them a bit to help me – and hopefully you – find the Drupal 8 sessions not to be missed.

Information Overload

The bottom line? There is a LOT of Drupal 8 content at DrupalCon Austin, as one would expect. So, what is my strategy for gleaning as much Drupal 8 information as possible for use in my work as a trainer? There are two facts that generally guide my strategy at DrupalCon:

  1. Sessions are recorded and archived on the Drupal Association's YouTube channel.
  2. BoFs are usually not recorded.

So how does this help me decide what to do with my time? I check the BoF whiteboard early and often and if there's a BoF and a session at the same time that are equally interesting to me, I chose the BoF and make a note to watch the session recording later.


ThinkShout: Chimpfestation, A Closer Look at the New MailChimp Module

Planet Drupal - Tue, 2014/05/27 - 3:00pm
Your Basic Monkey

A few weeks ago, we released the initial beta of the 3.x version of the MailChimp Module on The third major revision of the MailChimp Module for Drupal 7 is actually the fifth major revision of the module, including two versions for Drupal 6. ThinkShout Partner Lev Tsypin rolled the first release in January of 2008, and the first version of the project page included a little information about his goals for the module:

Right now, I am focusing on 3 types of integration:

  1. Using hook_user to maintain a members list in MailChimp.
  2. Having an opt in field in the user profile which uses one of the MC merge fields to allow for segmenting the members into those who want to receive communications.
  3. Having an anonymous sign up form to enroll users in a general newsletter.

The module (and the project page!) have both come a long way since then, but the functionality described in that initial post has remained the core of the module through each version: anonymous signup forms and authenticated subscription control describe the core use cases that have resulted in over 15,000 installs. Sure, there's campaign integration, activity reporting, and all sorts of bells and whistles around list and subscription management, but anonymous signup forms and user-based subscription control have always been the bread and butter.

Identity Crisis

Building on the success of the MailChimp module, ThinkShout has made the contribution of robust, useful Drupal modules a core part of our business. In building Entity Registration, RedHen, Salesforce v3, Leaflet, and a bunch of other great modules, we've often leveraged Drupal 7's Entity and Field systems to make our tools as versatile and abstract as possible, allowing for any imaginable use-case.

We had a bit of a wake-up call when one of our favorite clients, The Salmon Project, asked us to integrate their fancy new RedHen CRM directly with MailChimp. Integrating RedHen Contact Entities doesn't actually match up with either of these: anonymous signup forms and authenticated subscription control.

It was time to bring ThinkShout's signature versatility and abstraction to ThinkShout's signature module.

Monkeys Everywhere!

The first thing we did was de-couple the configuration of anonymous signup forms and authenticated subscription control. The MailChimp Lists configuration UI had grown into a bit of a monster: it included 16 separate options, not counting merge field sync settings, ranging from the submit button label (on the signup form) to the roles allowed (to access the list on user configuration pages). For version 3, rather than framing everything around each list, we broke things out by their Drupal-side functionality:

  1. The Signup Module was created for generating anonymous list signup forms.
  2. The List Module now provides a field type: "MailChimp Subscription", which, modeled on Entity Registration's successful architecture, leverages Drupal's Field API to allow any entity to become an independently-controlled MailChimp list subscriber.

What does this mean? If all you need to do is generate some anonymous subscription blocks or pages, the MailChimp Signup module has you covered. Just enable it, go to the "Signup Forms" tab in the MailChimp Admin UI, and create a signup! The UI lets you generate blocks or pages easily, include one or more lists on each form, pick which merge fields to include, and voila!

If, however, you want to subscribe some type of entity to a MailChimp List (like a user, say, or a RedHen contact), you can now do that lickity-split using Field UI:

This handy MailChimp Signup field will insist on being tied to one of your MailChimp lists. Once that's done, you can configure instances of this field like you would any other Drupal field. It will automatically pull in the available Merge Fields and let you select which properties or fields from the entity you want to push into these fields: Want to default your entity to be subscribed to the list? Use field UI's built-in configuration options. Use field display options to hide the field if you want to, or display it as a form right on the entity.

Do you want to get the old role-based subscription behavior? Easily done with a field on your user bundle and a simple rule or two! We've included the custom rules actions you need, and there's even an example rule in the README file in the MailChimp Lists submodule.

What this all boils down to is do what you want! You can MailChimp-ify any entity on your site with an email address in under 5 minutes. So go ape!

Peeling Away Campaign Complexity

ThinkShouter Dan Ruscoe brought huge improvement to the Campaign module, including the ability to send to list segments from directly within Drupal and some awesome UI improvements. We have long offered the ability to pull site content into campaigns, but you had to come up with the exact token for the content on your own: not the simplest task, especially if you have a non-developer creating your campaigns.

Now? A simple drop-down interface generates the token for you. Create a view mode for your entity types specifically for use in campaigns, or re-use an existing view mode. Just select your content type, the view mode, and search by title, and the module generates the token. Pop it into your campaign anywhere you want.

We also added a handy mergefield key selector patterned after the Token UI.

Other Evolutions

We didn't stop with fancy configuration options. Heck, we didn't start with fancy configuration options. The goofs at MailChimp HQ released the 2.0 version of their API, and we wouldn't want you using that Late Pleistocene 1.x nonsense, so we re-wrote the entire core of the MailChimp Module to leverage the new API. While we were at it, we re-wrote the asyncronous functionality to make it much simpler and less error-prone. It may not be easy enough for a chimp to understand quite yet, but it's certainly more tolerant of a little monkeying.

Climb Aboard!

You can download the MailChimp Module 7.x-3.0 beta now. We're already using it on a few sites and it's working great. So give it a try and let us know what you think!


Open Source Training: Contextual Filters and Arguments in Drupal

Planet Drupal - Tue, 2014/05/27 - 9:45am

Sometimes the name you give something is really important. 

In Drupal 6, a key feature in Views was called "arguments". This term made perfect sense to developers, but caused plenty of raised eyebrows amongst news users.

Both the name and location of this feature has changed in Drupal 7. Arguments are now called "Contextual filters".

Here's an introduction to arguments and contextual filters. We'll show you why they are so useful, whatever they may be called.


Chris Hall on Drupal 8: Developing Drupal 8 in the Codio web ide

Planet Drupal - Tue, 2014/05/27 - 9:30am

Despite all the computers, cloud servers and devices that are 'almost computers' and similar I have access to I still hadn't found a good answer to this type of problem:

I have some time spare, I want to be able develop and poke around with Drupal 8 whenever and wherever.

Of course you could substitute 'Drupal 8' with many other things in the above problem.

Perhaps I get somewhere 20mins early I can grab a coffee, whip out a Chromebook and continue where I left off, perhaps fire up a web browser on a computer somewhere I am contracting, perhaps I want to teach or show somebody something quickly without the overhead of first going through setting up a development environment.

Virtual machines, and the convenience of Vagrant solve the problem to some extent and are a great choice in many cases, but you still need to bring some fairly heavyweight resourses with you and plan ahead, some devices you may not be able to run a virtual machine on. 

Enter Codio WEB IDE provide a cloud based Web IDE, I started playing around with it a little while ago and initially expected it to simply be a place where you could work on HTML, CSS and Javascript with something special on the back-end to handle Node.js development. Surprisingly each project is backed by a Box Server which is a Ubuntu instance pre-installed with various software and a large, growing collection of other software that can be installed, check out the features video for more of an idea of what is available.

I tried installing a PHP cms called SilverStripe into a Codio project and it worked, after trying a few more things in different projects I thought I would have a go with Drupal 8, I didn't expect it to work. Drupal 8 is a large  beast and not even production ready yet, even so within a short space of time I had a working Drupal 8 project.

When you are working on your project in the web ide you can access a command line to your box where you can do most things that you would on a normal server, you also have access to a Box Url where you can view the server output of your project in another browser tab.

With full Git support and the ability to add tools like Composer and Drush the Codio project is a place where I can actually develop and experiment with Drupal 8 at the drop of a hat, from lots of different places.

You can start doing all of the above for free.


Codio is still in Beta, I use it regularly and although I rarely have problems occasionally there have been performance or technical issues, usually they are quickly resolved.

I suspect the Box server may struggle a little with a large number of modules enabled or under any other test conditions of high load, I did find problems with running tests in the UI (they ran fine through Drush though).

With a free account your projects are public, although working on public code for an opensource project that is hardly a problem. A paid account costs just $8pm though (plus local taxes), I am more than happy to pay that for the use I get out of Codio.

The web ide is very good but can't offer some of the functionality you may find in Netbeans or PHPstorm (functionality that requires analysis of the entire code-base).

An easy starting point

I have written an article about how to set up a Codio project for Drupal 8 development and also a little script on Github that will set up everything for you, please feedback if the script doesn't work for you, the aim is to allow automatic setup and install of the latest Drupal 8 code into and an empty Codio project. I try to steer away from putting anything too technical into blog posts as blog posts age naturally but techinical articles and things on Github are easier to keep updated.

Educational potential

Codio has a terrific educational potential it is easy to setup widely accessible working examples and public projects can be forked. I have just started using it to aid helping somebody learn to code, Codio provides a great bridge between quickly getting started but still keeping in touch with servers, software and command-line.


Acquia: Patching with Drush Make

Planet Drupal - Tue, 2014/05/27 - 7:46am

Patching software is a common practice in open source software that enables developers to fix bugs and implement features within their projects, independent of the upstream software’s development cycle. The offset of this approach is that it can become cumbersome to maintain and re-apply patches as the upstream software continues to fix bugs, implement features and fix security vulnerabilities.


InternetDevels: YouTube video optimization

Planet Drupal - Mon, 2014/05/26 - 11:00pm

As you have probably noticed the most of queries entered into Google web search make primarily YouTube videos appear in the top of the list. Why it is so and how to make your video to be among the first when the relevant query is entered? If you have a high-quality video and want more people to know about it, this article is what you need. Following are the main rules of YouTube video optimization.

1. Video file name

Read more

Drupal Association News: team week notes #26

Planet Drupal - Mon, 2014/05/26 - 9:55pm

Upcoming deployments: improvements to comments

You may have noticed that user profiles now let you upload your picture. These will be shown with comments. You can see a preview on the staging site, the HTTP user/password is drupal/drupal: in the issue queue (example) and forum (example). You can log in with your username and password to test more.

There are more improvements to come in the next few weeks. This is the first round of implementation for a design process led by Mark Carver and Bojhan Somers. Read more about the design changes and future work in the issue queue. improvements

One small but useful deployment of the last two weeks is path aliases for user pages. When you save your user profile, you now get an aliased path like

Long usernames display got fixed, they are no longer truncated on issue pages and elsewhere. We also implemented RSS feeds for new projects, separately for full projects and sandboxes.

Other deployments included bakery improvements for syncing user profiles across sites, bug fixes in versioncontrol* modules, project issue, BUEditor, and Views 3.8 security update. infrastructure news

The web nodes all rebuilt and load balancer rebuild started. CDN deployment for has been delayed until after DrupalCon Austin. The host name change is too big to be rushed before DrupalCon. Ongoing cleanup of dev and staging VMs and improving our use of configuration management is moving forward.

Other news Support

We have some good progress on support related metrics. Take a look at the recent detailed post about our plans to improve support for our users.

Drupal Jobs

We are getting close to the launch of Drupal Jobs, a website for posting jobs and highlighting job seekers with companies looking to hire. Job seekers will be able to search jobs by city and keyword and view special company profiles pages that highlight the benefits of working for that company.

A beta version of Drupal Jobs should be ready right around DrupalCon Austin and we hope to launch the full product this summer.

DrupaCon Austin Sprints

DrupalCon Austin starts in about a week. Our team is super excited, because we will continue good tradition of DrupalCon Prague and Drupal Developer Days Szeged, and have a big sprint. Our team members will be there both for extended sprints pre-Con on Sunday, June 1st, official sprint day - Friday, June 6 and extended sprints post-Con: Saturday, June 7, and Sunday, June 8.

We will have all kinds of tasks for interested volunteers. Code-writing and infrastructure configuration tasks, site building tasks and general issue queue clean up, front-end / theming tasks and documentation writing.

If you haven’t signed up yet, you can do so IN THIS SPREADSHEET. Scroll down till you see ‘ sprint’ on the left and add your name and available days.


When we are not sprinting, there will be a few related sessions to attend.

Tuesday, June 2nd
The future of developer tools. A session by the Developer Tools team.

People want to help. They don’t know what to do! Let's make d.o issue picking easier.

Wednesday, June 3rd Working Groups: Who we are and what we’re up to

Thursday, June 4th
Open Infrastructure team meeting

The future of Community Tools. A session by the Community Tools Team.

Come and let’s talk about!

As always, we’d like to say thanks to all volunteers who are working with us and to the Drupal Association Supporting Partners and Technology Supporters, who made it possible for us to work on these projects. The Supporting Partner Program crowd sources funds that pay for the development team’s time and hosting costs.

Cross-posting from g.d.o/drupalorg

Personal blog tags: week notes

Midwestern Mac, LLC: DrupalCon Austin 2014 - Notes on my First Timer's Guide

Planet Drupal - Mon, 2014/05/26 - 9:50pm

I wrote A First Timer's Guide to DrupalCon two years ago, and 99% of the advice in that post is still relevant. I've been preparing my presentation DevOps for Humans: Ansible for Drupal Deployment Victory! for a few months now, and since DrupalCon is less than a week away, I thought I'd take a few minutes to supplement the earlier post:



Subscribe to build2be/com/e aggregator