Software

It’s that time of year again! And boy, are we excited... BADCamp is around the corner and we’ve already got our bags packed for San Francisco. BADCamp is one of our favorite Drupal Camps out there because it’s close to home, attendance is free, and it offers a handful of great Drupal trainings for all skill levels. And, of course, there’s the Nonprofit Summit that takes place on Thursday, November 6.

We’ve been hard at work helping coordinate this summit and we’re thrilled with the day that’s come together.

We’ve lined up speakers from the Sierra Club, Kiva, and the Electronic Frontier Foundation, who will share their experience and insights into leveraging Drupal to further their mission. You’ll also be able to join a variety of discussion-style breakout sessions, led by Drupal experts and nonprofit tech leaders. Looking for a topic that’s not on the schedule? Lead a discussion of your own during the open breakout sessions!

We’ve got a jampacked schedule in addition to the Nonprofit Summit day. On Saturday and Sunday, you can find ThinkShout at booth #4 - stop by and say hi - we’d love to chat with our fellow BADCampers. Several members of our team will be speaking - check out the schedule below for a full breakdown of our presentations.

Saturday, Nov. 8

"Maps Made Easy" - Gabe Carleton-Barnes (@uncle_gcb)

Room: Rainbow Road

Time: 10:00am-11:00am

Maps are all over the web these days, and they can be extremely effective tools for finding and sharing information. Embedding a simple Google Map is easy, but what about building something that is more integrated with your content? It turns out you can build awesome integrated maps in Drupal almost entirely with point-and-click tools: all you need is the Open Source Leaflet library, Views, and a few other Contrib Modules. In this session we'll show you how by interactively building a site with a map from a bare Drupal 7 install.

Participants will choose what type of mappable content to create, and will be asked to add content using their own devices to build a rich demonstration of the map's capabilities.

As we assemble the required modules and configure our site, we will discuss the roles played by each module without a bunch of geospatial techno-babble. By the end of the session, we will have an interactive map displaying content that is easy for any site user to input using address data. If there is sufficient time, we will discuss how to customize the map's "tiles", add plugins, use proximity filtration, and other potential features for your map!

"Responding to Responsive - A Designer’s Guide to Adapting" - Josh Riggs (@joshriggs)

Room: Warp Zone

Time: 10:00am-10:30am

There’s no denying that a designer’s role is changing. Responsive Design has made the whole process much more complex. Designers are now expected to be equal parts artist and coder, and to use HTML, CSS & Javascript as their palette. I’ve met that challenge, and I‘ve spent the last few years working on several large, responsive Drupal sites. This talk will include a candid, real-world look at my personal evolving design process, as well as lessons from my own personal journey as a designer.

Topics include:

• A thorough walkthrough of responsive design deliverables: Content Strategy, HTMLWireframes, Style Tiles, & Style Mocks. Examples will be shown.

• Managing the expectations of Clients, Users and Developers

• Keeping the focus on User Experience

• Real world successes and failures

• A fight to the death between Photoshop & In-Browser design

• Creating a better iterative process

• Bridging the gap between design and front-end development

• Embracing the concept of Kaizen (continuous improvement) as a designer

"Responsive Image Loading with the Picture Module"- Cooper Stimson (@cooperstimson)

Room: Warp Zone

Time: 5:30pm-6:00pm

Responsive Web Design (RWD) is increasingly vital in the contemporary web landscape, where your content can be displayed on a phone, a laptop, an 84-inch 4k monitor, a refrigerator, or even a watch. In this session you will learn how to leverage the Picture module (and its dependency, the Breakpoints module) to achieve responsive image loading in Drupal 7.

The Picture Module

There is no RWD solution for images in Drupal 7 core. Luckily, a responsive image handling module called Picture will be included in Drupal 8 core, and has already been backported to Drupal 7. Picture uses the new HTML5 picture element.

This session will cover:

• Installation and configuration of the Picture, Media, Chaos Tools Suite, and Breakpoint modules

• Creating breakpoints and breakpoint groups

• Configuring picture mappings

• Setting up file type display settings

• Applying these options to an example content type

• Basic introduction to the picture element and media queries

Image loading is particularly important for RWD; loading an image size inappropriate to screen resolution is problematic whether you're stretching a 100x100 thumbnail over a massive screen, or sending a ten megapixel background to a QVGA phone. In the former case you're making a pixelated mess, and in the latter case you're eating up both your own bandwidth and your user's data plan on a resolution they can't use - nobody wins.

Benefits for Your Site

There are many reasons to responsively load images on your site. A few highlights are:

• Consistent user experience across platforms

• Single URL per page

  • No need to code up a separate mobile version
  • SEO optimization -- Don't split your pageview count between multiple URLs
  • Improved shareability

• Massive pageload benefits on mobile

Target Audience

This session is aimed at beginning level Drupalers who haven't used the Picture module before.

It’s completely free to register, just sign up on the BADCamp website.

See you in San Francisco!

Episode Number: 176

In this video we look at the Publication Date module. This module allows content creators to use the date in which the content on their website is published and NOT just when it is created. In other words, if you create a post a week prior to publishing it, this module will use the date in which the post goes to published. Again, this is a simple module but can be extremely helpful if you post a lot of content or have a habit of writing content days or weeks prior to publishing.

Tags: DrupalFieldsViewsDrupal 7Drupal Planet

The first time I spoke at a tech conference was about five years ago at the University of Southern California (USC), in Los Angeles. It was at an annual conference called Code Camp whose audience is mostly Microsoft developers. I didn’t know what to expect in that kind of setting. I selected a topic I was fairly comfortable with, Designing with CSS3. Not only was the topic well received but it quickly became the most popular session in the conference with over 140 attendees interested in it. Now I was really freaking out.

Drupal makes it so easy to add image fields to your content types. Fields in core for the win! With image styles in core, its as easy as ever to create multiple image sizes for display in various contexts (thumbnails, full, etc.). But what about providing hi-resolution versions of your rasterized images for retina displays? Out of the box, you don’t really have a lot of good options. You could simply upload high resolution versions and force your users, regardless of display type to download massive file versions, but that’s not exactly the best for performance. You could use some custom field theming and roll your own implementation of the <picture> element, but browser support is basically null at this point. That won’t do. You could do what Apple does and force the browser to download 1x versions of your images then use javascript to detect high resolution displays and then force the browser to download all of the high resolution versions…I think you see my point.

What if you could create hi-resolution versions of these images without a ton of added filesize overhead? What if you could do this all within Drupal? No special coding, no uploading of multiple versions, no special field templates or unnecessary javascript. Just a basic Drupal image field with a special image style defined.

Here’s how you do it:

1. Create your image field. (In most cases, you’ve probably already got this.)
2. Download and install the HiRes Images module This module allows you to create an image style at 2x the desired pixel dimensions. If your desired maximum image width is 720 css pixels, your output image would be saved at 1440px.
3. Download and install the Image Style Quality module This nifty module allows you to define specific image qualities on a per image style basis instead of using Drupal’s global image quality setting.
4. Add a new image style (or alter an existing)
5. Add your normal image style presets, like scale, crop etc. If you’re scaling, set your scale to be 2x your desired maximum output in pixels. So if you want an output of 720, set your scale to 1440px.
6. Add the “Hi-Res (x2)”" effect. This will output you’re image element at half the scale amount above. So we get a max of 720px.
7. Add the “Quality” effect and set it to something like 60%. This may take some experimenting to find a balance between image quality and file size. In my example, I went with 60% compression. This yielded an image that was still really sharp and a reasonable file size.
8. Set your display mode to use this new (or altered) image style.
9. Enjoy your beautiful, high resolution, performant image fields!

Hard to believe this works right? You’d think your retina version would look really crappy with that much compression, but it doesn’t. In fact, in some cases it will look just as sharp and be smaller than a 1x counterpart. See my screenshots below for proof:

Side-by-side comparison:

Network panel output:

So we end up with a high resolution version of our uploaded image that is actually smaller than the original version at 720px! Looks great on retina devices and doesn’t badly penalize users of standard definition displays. WIN!

For a detailed explanation of this technique in broader terms, see Retina Revolution by Daan Jobsis

I recently ran into an issue where drush vset was not setting a string variable (in this case, a time period that would be used in strtotime()) correctly:

# Didn't work:
$ drush vset custom_past_time '-1 day'
Unknown options: --0, --w, --e, --k.  See `drush help variable-set`      [error]
for available options. To suppress this error, add the option
--strict=0.

Using the --strict=0 option resulted in the variable being set to a value of "1".

After scratching my head a bit, trying different ways of escaping the string value, using single and double quotes, etc., I finally realized I could just use variable_set() with drush's php-eval command (shortcut ev):

BIP 70 describes a high-level payment system for Bitcoin. It uses Protocol Buffers and X.509 certificates for the following major improvements:

• Human-readable payment destinations instead of Bitcoin addresses
• Resistance from man-in-the-middle attacks
• Payment received messages sent back to the wallet
• Refund addresses

I compiled the BIP 70 Protocol Buffers definition file into PHP using ProtobufPHP.

I have implemented most of BIP 70 in the Coin Tools Drupal project. It contains a new Bitcoin payment entity class that contains all the specified fields in its base table. Bundles can be created to add additional fields to payments.

Payments can currently be created through an admin interface, although this would typically happen in an automated process on a real website.

When viewing an unfulfilled payment in the admin interface the QR code for the payment will be present. It decodes to a backward-compatible payment protocol URI.

Currently the module is unable to detect Bitcoin payments not sent using the payment protocol, i.e. the payment is sent to the address but the website is not notified. This will be quite easy to implement though.

For payments made using the new protocol, Coin Tools is able to complete the transaction and has been tested with both the original QT client and Andreas Schildbach's Android Wallet. Interestingly Andreas's wallet does not display the status message returned by the merchant.

The specification does not seem to have any method for the merchant to inform the app that the payment was not satisfactory, other than setting the human readable status message (the wallet would not know there was a problem), or returning an HTTP error code (resulting in unpleasant error message for customer).

Coin Tools will check the transactions provided by the wallet are sending enough bitcoins to the payment address. It then broadcasts the transactions via bitcoind. Currently Coin Tools is relying on bitcoind rejecting transactions that have not been signed correctly. This assumption needs to be verified.

When the payment protocol QR code is displayed, Coin Tools enables a small Javascript program to poll the website to determine if the payment has been made, reloading the page once this has happened. Ideally this would be implemented as a long-running AJAX request.

The X.509 certificate part of the payment protocol specification has not yet been implemented in Coin Tools. This is a critical component.

The implementation of the payment protocol in Coin Tools only permits a single Bitcoin address per payment. The specification does support having more than one and in theory this could be used to increase payment anonymity by each address only being spent into by a single output in a single transaction. In practise this is not so effective as all the transactions would be broadcast simultaneously.

Coin Tools will also store a single refund address provided by the wallet making the payment. The wallet actually provides payment scripts, but Coin Tools will determine if the script is a standard payment and extract the address. Multiple refund addresses are also supported by the standard, but Coin Tools will only store one.

According to the specification the wallet can allow the customer to provide a note to the vendor. Coin Tools will store this note, however I do not know of any wallets that support this feature.

The HTTP responses for PaymentRequest and Payment need to be implemented as Symfony response handlers. Currently they are implemented in a simplistic manner setting their own HTTP headers and and calling exit().

It is currently only possible to make payments from the admin interface. A template needs to be provided so the payments can be made from elsewhere on a website, e.g. integration with Drupal Commerce.

For a standard ecommerce website that wants to accept bitcoins it may make more sense to use a provider such as BitPay or Coinbase. Accepting payments natively on a website means that a hacker could steal funds. One solution to this problem would be to use Hierarchical Deterministic Wallets so that private keys are only stored on backend systems.

For a project that is doing something more interesting than just accepting Bitcoin as a payment method and is already running bitcoind, it may be advantageous to have a native implementation on BIP 70 on the website rather than relying on a third-party provider.

No tests have yet been written for Coin Tools. It is essential that Payment and PaymentRequest routes are fully tested including the edge cases defined in the specification.

A few limitations of Drupal 8 have been encountered during the creation of this functionality. In Drupal 8 it is now possible to have fields in entity base tables. This is really great, but unfortunately when these fields are present in a view it is not possible to use their formatters. I discussed this with Daniel Wehner at Amsterdam and he didn't seem very optimistic about this being able to be fixed so some sort of workaround will need to be found as this functionality is critical to the module.

Date field is now in D8 core, but unfortunately it stores the date as a varchar in the database. This means that it is not possible to sort or filter on date - a major limitation. If core is not changed to use database-native date storage Coin Tools will have to use another date field.

The Payment Protocol functionality needs to be backported to Drupal 7 Coin Tools and integrated with Payment / Commerce.

Selling Organic Groups with Drupal Commerce just got way more powerful. Actually it did so a while ago when Commerce License and Commerce License OG where created.

About 18 months ago I wrote about how you could sell access to Organic Groups with Drupal Commerce with a configuration of fields and Rules.

With Commerce License and Commerce License OG selling access to Organic Groups you have a setup that is as easy to setup than the 'old' field+Rules way (if not easier) and you'll have great new functionality for revoking membership access.

Step by Step instructions

You can find the step-by-step instruction on how to sell your Organic groups with Drupal Commerce based on Commerce Licenses at https://www.drupal.org/node/2366023. Just follow the 8 easy steps and you'll have it setup in no-time.

How does it work?

Basically you'll be selling licenses to your Organic Group (content). These licenses can expire, or be forever. You can configure them the way you see fit. The license determines if a user has access to the Organic Group or not.

Commerce License is a framework for selling access to local or remote resources.

Read more about Commerce Licenses at https://www.drupal.org/node/2039687 under Basic Concepts -> License.

Show me

If you follow the 8 steps in the instruction at https://www.drupal.org/node/2366023 you'll see that you can easily configure the products like this:

and users on the site will be given licenses like this

 

From Dev to Stable

commerce_license_og module is currently in dev state. It works fine for the most common usecase: users buying access to your site. However make sure it works the way you want it before you decide go 'all in' implementing this on a production site.

Currently there seems to be an issue with granting anonymous users access to Organic Groups (https://www.drupal.org/node/2366155). 

Please add your input to https://www.drupal.org/project/issues/commerce_license_og to help developing this module to a stable release.

Category: Drupal Planet Drupal Commerce Drupal Organic Groups

At the Drupal Association, we believe it’s good to pause and be grateful from time to time. So, today, we’d like to express gratitude for our unbelievably fantastic Supporting Partners.

Without contributions from partners like Exove, Duo Consulting, Chapter Three, Lullabot, Chromatic, The Cherry Hill Company, Elevated Third, and Technocrat, we wouldn’t be able to do what we love: serve the Drupal community and help make Drupal great. Our partners are helping us fund improvements to Drupal.org.

Our partners are making several key intiatives for Drupal.org possible, including:

• Better account creation and login
• Organization and user profile improvements
• Responsive redesign of Drupal.org
• Issue workflow and Git improvements
• Make Drupal.org search usable
• Improved tools to find and select projects
• Groups migration to Drupal 7

In addition to major projects, Supporting Partner contributions make the ongoing work to sustain and maintain Drupal.org happen:

• We performed user research to guide our work on new features and improvements;
• We are starting work on a comprehensive content strategy for Drupal.org;
• We’ve bought and installed new server hardware to improve performance and responsiveness;
• We are improving development environments to make development for Drupal.org faster and more efficient;
• We have faster testbot instances for Drupal 8 development and contribution sprints;
• We implemented content delivery networks (CDN) for Drupal.org and downloads;
• We are improving behavior driven development (BDD) tests to ensure Drupal.org deployments are successful and error free, and many more.

This is only a small portion of the many improvements we’ve been able to make with the help of our Supporting Partners. From helping us make Drupal.org better to making it easier than ever to give back, the Drupal Association’s many wonderful Supporting Partners are some of the heroes of the Drupal project.

Feature

One of the most anticipated features in Drupal 8 is the integration of RESTful Web Services in Drupal core. Drupal devs are looking forward to being able to do things with core which they couldn't before, such as:

• Offering their site’s data up in an API for others to use and contribute to;
• Building better user interactions by adding and updating content in place instead of a full page submission;
• Developing iPhone and Android apps that can serve and manage content hosted in a Drupal site.

But what are RESTful Web Services? In this article, I will walk you through the different conceptions of what is RESTful and explain how the new modules in Drupal core address these different concepts.

A Quick History of REST

Many developers have become aware of REST due to the rising popularity of APIs. These APIs enable developers to build on top of services such as Twitter and Netflix, and many of these APIs call themselves RESTful. Yet these APIs often work in extremely different ways. This is because there are many definitions of what it means to be RESTful, some more orthodox and others more popular.
The term REST was coined by Roy Fielding, one of the people working on one of the earliest Web standards, HTTP. He coined the term as a description of the general architecture of the Web and systems like it. Since the time he laid out the constraints of a RESTful system in his thesis, some parts have caught hold in developer communities, while others have only found small – but vocal – communities of advocates.

For a good explanation of the different levels of RESTful-ness, see Martin Fowler’s explanation of the Richardson Maturity Model.

What is RESTful?

So what are the requirements for RESTfulness?

This has been an interesting couple of weeks for Drupal, and that platform as a whole has received a lot of press.  With the release of Drupal 7.32, a major (I use this term lightly) security vulnerability was corrected.  Drupal then announced this week that, despite there being no significant evidence of a large number of sites attacked, any site that wasn't patched within a 7 hours of the patch release should consider itself compromised.  Hosts were reporting automated attacks beginning only hours after the patch announcement.  The vulnerability was unprecedented for the Drupal community, but really it shows why Drupal is great, and isn't a black mark on Drupal in our eyes.

First lets look at the announcement by the Drupal Security Team this week, where they say that sites were beginning to be attacked within hours of the patch announcement.  The biggest thing to take from this announcement is the words Drupal Security Team.  Yep, Drupal has one.  I did a search this morning using the following criteria "<popular CMS> security team", and I found the results quite interesting.  When I added Drupal as the "popular CMS" I got a page full of Drupal Security team information, policies and procedures.  For every other CMS I tried, I got nothing about a team of security people, but a lot of information stating that they are secure and if you find a problem here is how to report it.  Drupal focuses on security, and the Security Team at Drupal is a prime example of how important this really is to the Drupal community.

The second thing to take away from this is that the patch really notified the world that there was a vulnerability, and there is no way to stop this from happening.  We didn't have any mass attacks on Drupal sites prior to this release, and the damage here after the release seems to be primarily related to those who chose not to apply the updates as they were instructed to.  This really emphasizes the importance of applying available updates.  Sites where the update was applied quickly likely did not experience any negative effects of the vulnerability, and if they did it was very limited.  Updates to Drupal are certainly optional, but they are necessary to avoid headaches down the road, and this is proof of exactly why.  

So don't be discouraged by all of the bad looking press related to this.  I still stand by the idea that Drupal is the most secure platform available, but it is only as secure as you allow it to be.  If you aren't applying the updates as they are available, you are likely putting your self at risk to have your site compromised.  The big difference I see between Drupal and the other CMS options is that Drupal works diligently to fix module and core vulnerabilities as a habit.  Many others aren't as diligent.

For more tips like these, follow us on social media or subscribe for free to our RSS feed and newsletter. You can also contact us directly or request a consultation. 

In our last post we used CasperJS to rapidly test the user interface of a website. Now we will build on these skills and add a familiar element into the mix: Drupal. Like any framework, Drupal offers many predictable, standard behaviors which we can take advantage of. Using this predictability, we can easily test many behaviors including logged-in activity such as posting content.

Testing JavaScript Drupal

With the first Drupal 8 beta having been released at Drupalcon Amsterdam, we thought this would be a good time to a look at the top 100 projects on drupal.org to see just how far along the line the process of preparing for Drupal 8 is. However, given that there's a lot of progress to be made and I don't feel like manually updating a long list of modules, I decided to make a small tool to get the status of these modules and keep the data up to date.

This turned out to be a fun little project, and slightly more involved than I anticipated at first. (Isn't it always the case!) However, at its heart it's a bone-simple Drupal project - one content type for the Drupal projects (and their metadata) we're interested in, and a few views to show them as a table and calculate simple statistics. The work of updating the metadata from drupal.org is handled in 85 lines of code, using hook_cron to add each project to a Queue to be processed. The queue callback borrows code from the update module and simply gets release data, parses it, and updates the metadata on the project nodes. In the end, the most work was doing the research to determine which projects are already in core, and adding notes about where to find D8 upgrade issues and so on.

So, how did it all turn out? Using the current top 100 projects based on the usage statistics on drupal.org, our tool tells us that as of today, out of the 100 most popular projects:

Thanks for reading, and be sure to keep an eye on the status page to see how the most used contrib modules are coming along!

Tags: Drupal PlanetDrupal 8

If you weren't able to update your Drupal site within a few hours on October 15th, you may be worried about your site.

Even under normal conditions, it's almost never possible to prove that a site is 100% safe. But by checking your site, you can either give yourself some additional peace of mind or you can confirm that you were hacked.

With the Drupal Security team's release of a public service announcement, the infamous security update known as 'SA-005' is back in the news. Even though it's old news, we've been fielding a new round of questions, so we thought we'd try to clear up some of the confusion.

Published: Thu, 10/30/14Download this episodeCINC

• What is CINC?
• How is it different from Features or Configuration Management?
• Is it something you use on an ongoing basis? Or is it just for the initial site setup?
• What types of configuration can you manage with CINC?
• What if you already have a content type created, and you want to add a field to the content type?
  • How does that affect existing content, and new content.
• What about the reverse? Can you remove a field?
  • What happens to the data that is already in the database?
• Can you undo configuration that you’ve created with CINC?
• How do you prevent site admins from disabling the module and deleting their content types?
• CINC YAML
• CINC & Features
• CINC & Drupal 8 Config API
• cinc.io
• Sheet2Module
• How do you see CINC working in a headless Drupal setting?

Use Cases

• Create dozens of fields quickly.
• Add a field to a content type after an existing field.
• Update configuration only if it still matches the default settings.
• How do you use this in a dev/staging/production
• Have you noticed any improved feedback, improvements to your workflow while using CINC?
• If people want to jump in and help development or work on new features what should they do?

Episode Links: Scott on drupal.orgScott on TwitterTags: Configurationplanet-drupal

By:
Tim Erickson, stpaultim, @stpaultim from Triplo
Alina, alimac, @czaroxiejka
Cathy Theys, YesCT, @YesCT from BlackMesh

DrupalCon Amsterdam Sprints

DrupalCon is a great place to enhance your Drupal skills, learn about the latest modules, and improve your theming techniques. Sure, there are sessions, keynotes, vendor displays, and parties... like trivia night!

But.. there is also the opportunity to look behind the curtain and see how the software really gets made. And, more importantly, to lend your hand in making it. For six days, three both before and after DrupalCon, there are dedicated sprint opportunities where you can hang out with other Drupalistas testing, summarizing issues, writing documentation, working on patches, or generally contributing to the development of Drupal and the Drupal community.

We want to share some details about the DrupalCon Amsterdam Sprints (and pictures to reminisce about the good times) and mention some upcoming sprints that you can hopefully attend.

• Sponsors supporting the sprinters
• Pre-con Extended sprints on Saturday and Sunday (60 Saturday, 100 Sunday, 180 Monday)
• During the con
• Friday Sprint (450 people)
• Post-con Extended sprints on Saturday and Sunday (80 Saturday, 60 Sun)
• Feedback about the sprints
• Upcoming sprints

Sprint sponsors

• Drupal Association, @DrupalAssoc
• Acquia (Large Scale Drupal), @Acquia
• Open8, @open8roger
• Bluehost, @Bluehost
• David Hernandez, @davidnarrabilis
• Wunderkraut, @Wunderkraut

Our sponsors helped us have:

• Space:
  • Co-working space Saturday and Sunday before the con.
  • Sprint space at the venue Monday-Thursday.
  • Big sprint space Friday.
  • Co-working space Saturday and Sunday after the con.
• Food and coffee all of the days.
• Sprint supplies: task cards, stickers, markers, signs, flip charts.
• Mentor thank you dinner.

Pre-con sprints

During the weekend before DrupalCon 60 people gathered on Saturday and 100 on Sunday at The Berlage, a fantastic old castle just blocks from the central train station. On most days the Berlage serves as co-working space. For 48 hours it was home to contributors working together on Drupal core, contrib projects, distributions and Drupal.org itself. Our supportive sponsors supplied lunch and coffee on both days while contributors worked on a number of initiatives: Multilingual, Drupal 8 criticals and beta blocking issues, Headless Drupal and REST, porting contrib projects to Drupal 8, Drupal 8 Frontend United, Search, Drupal.org, Behat (Behavior Driven and javascript/frontend testing), Commerce, Panopoly, Rules, Media, Documentation, Migration, Performance, Modernizing Testbot, and more.

The outside of the Berlage co-working space (castle) with the Drupal Association banner.
(photo: @gaborhojtsy)

Sprinters sprinting inside the cool looking Berlage.
marthinal, franSeva, estoyausente, YesCT, Ryan Weal
(photo: @gaborhojtsy)

We had lots of rooms for groups to gather at the Berlage.

pwolanin, dawehner, wimleers, Hydra, swentel
(photo: @Schnitzel)

Sutharsan, yched, Berdir
(photo: @Schnitzel)

On Monday sprint attendance grew to 180 sprinters. We moved to the conference venue, Amsterdam RAI. Other pre-conference events taking place included trainings, the Community Summit, and the Business Summit. At this particular DrupalCon there was much excitement about the anticipated beta release of Drupal. Many people did a lot of testing to make sure that the beta would be ready.

Discussing a beta blocker issue they found.
lauriii, sihv, Gábor Hojtsy, lanchez
(photo: @borisbaldinger)

Lots of people sprinting and testing the beta candidate, with support from experienced core contributors walking around and helping.
tstoeckler, mauzeh
(photo: @borisbaldinger)

During the con

Sprinting continued during the conference, Tuesday through Thursday. And, to prepare for Friday's mentored sprint, the core mentoring team scheduled a series of 8 BOFs (‘Birds of a Feather’ or informal sessions). Preparations included mentor orientation, setting up local environments, and reading, updating, and tagging issues in the Drupal issue queue. Mentoring BoFs were open to all conference participants.

Mentor Training
YesCT, sqndr, -, -, lazysoundsystem, neoxavier, Mac_Weber, patrickd, roderik, jmolivas, marcvangend, -, realityloop, rteijeiro
(photo: stpaultim)

To promote contribution sprints, mentors volunteered at the mentoring booth in the exhibition hall during all three days of DrupalCon. Conference attendees who visited the booth learned about the Friday sprints. Mentors also recruited additional mentors, and encouraged everyone to get involved in contributing to Drupal.

The mentor booth with lots of signage, and welcoming people.
mradcliffe, kgoel
(photo: stpaultim )

At the booth, conference attendees were able to pick up our new contributor role task cards and stickers which outlined some of the various ways that people can contribute to Drupal and provided them with a sticker as recognition for the specific roles that they already play.

Task cards and stickers
(photo: @HornCologne)

Mentored Sprint

In Amsterdam, 450 people showed up to contribute to Drupal on Friday.

(photo: _SteffenR)

People gathered in groups to work on issues together.

-, -, -, -, -
(photo: @peterlozano)

For many people the highlight of the week is the large “mentored” sprint on Friday. 180 of the 450 participated in our First-time sprinter workshop designed to help Drupal users and developers better understand the community, the issue queues, and contribution. The workshop helped people install the tools they would use as contributors. Another 100 were ready to start work right away with our 50 mentors. Throughout the day people from the first-time sprinter workshop transitioned to contributing with other sprinters and mentors. Sprinters and mentors helped people identify issues that had tasks that aligned with their specific skills and experience.

The workshop room.
(photo: stpaultim)

Mentors (in orange shirts): rachel_norfolk, roderik
(photo: stpaultim)

Hand written signs were everywhere!
(photo: stpaultim)

A group picture of some of the mentors.
mradcliffe, Aimee Degnan, alimac, kgoel, rteijero, Deciphered, emma.maria, mon_franco, patrickd, 8thom, -, lauriii, marcvangend, ceng, Ryan Weal, YesCT, realityloop, -, lazysoundsystem, roderik, Xano, David Hernández, -, -, -, -
(photo: @Crell)

Near the end of the day, over 100 sprinters (both beginners and veterans) gathered to watch the work of first time contributors get committed (added) to Drupal core. Angie Byron (webchick) walked the audience through the process of evaluating, testing, and then committing a patch to Drupal core.

Live commit by webchick
webchick, -, -, marcvangend
(photo: Pedro Lozano)

Extended sprints on Saturday and Sunday

On Saturday after DrupalCon 80 dedicated contributors moved back to the Berlage to continue the work on Drupal core. 60 people came to contribute on Sunday. During these final days of extended sprints, Drupal beginners and newcomers had the chance to exercise their newly acquired skills while working together with some of the smartest and most experienced Drupal contributors in the world. The value of the skills exchanges and personal relationships that come from working in this kind of environment is cannot be underestimated. While there is an abundance of activity during Friday’s DrupalCon contribution sprints, the atmosphere during extended sprints is a bit more relaxed. Attending the pre and post-con sprints gives sprinters time to dive deep into issues and tie up loose ends. After a number of hallway and after-session conversations, contributors working on specific Drupal 8 initiatives meet to sketch out ideas, use whiteboards or any means of note-taking to make plans for the future.

LoMo, Outi, pfrenssen, lauriii, mortendk, emma.maria, lewisnyman
(photo: stpaultim)

Aimee Degnan, Schnitzel, dixon, -, Xano, alimac, boris, Gábor Hojtsy, realityloop, YesCT, justafish, eatings, fgm, penyaskito, pcambra, -
(photo: stpaultim)

-, jthorson, opdavies, drumm, RuthieF, -, -, killes, dasrecht
(photo: stpaultim)

Feedback about the sprints

• Sprinting for the First Time - Blog post by AdamEvertsson
• From Rookie to Drupal Core Contributor in One Day - Blog post by @dmsmidt
• DrupalCon Amsterdam, 2014 - Blog post by @valvalg
• “Mentoring at #DrupalCon sprints is the most rewarding and enjoyable part of the week :) <3 @drupalmentoring #DrupalSprint - Original Tweet from @emma_maria88
• “One hour at the #DrupalCon code sprint and I've already submitted my first patch. It is going to be a good week.” - Original Tweet from @skwashd
• Hi, I'm George! I'm your mentor! - Blog post by Thamas (@eccegostudio)

Please contact me to get your DrupalCon Amsterdam sprint related blog added to the list here.

Upcoming sprints

• BADCamp (sprint details November 5 - 10 2014)
• Global Sprint Weekend January 17, 18 2015
• DrupalCon Latin America in Bogota (sprint details Feb 8 - 13 2015)
• lots of camps, check druplical.com (The drupal event location visualization tool.)
• Drupal Dev Days April 2015
• DrupalCon North America in Los Angeles (sprint May 9 - 17 2015)
• DrupalCon Europe in Barcelona (sprint Sept 19 - 27 2015)

Plan your travel for the next event so you can sprint with us too!

Corrections

If there are corrections, for example of names of people in the pictures, please let me know. -Cathy, @YesCT, or Drupal.org contact form.

DrupalSprintsDrupalConDrupal Planet

As extremely pedantic developers we take documenting our APIs very seriously. It's not rare to see a good patch rejected in code review just because the PHPdocs weren't clear enough, or a @param wasn't declared properly.

In fact, I often explain to junior devs that the most important part of a function is its signature, and the PHPdocs. The body of the function is just "implementation details". How it communicates its meaning to the person reading it is the vital part.

But where does this whole pedantic mindset got when we open up our web-services?
I would argue that at least 95% of the developers who expose their web-service simply enable RESTws without any modifications. And here's what a developer implementing your web-service will see when visiting /node.json:

Continue reading…

They say that hindsight is 20/20. With the many advances that have happened in the Drupal community recently, we asked our team "What is the one thing you wish you knew about Drupal two years ago?" 

"I wish I knew about the Headless Drupal initiative so I that I could be ahead of the curve as far as the Javascript technologies that it will require." - Chris Doherty

Much like an evolutionary tree our goal in technology adoption is too continue to move forward and evolve, rather than getting caught in a dead end.  In the natural world, becoming bigger can be good but can lead to extinction events should the environment or food source change.  Right now we are in a technology Jurassic...

• Read more

If you have been around CodeKarate.com for awhile you have noticed that our branding has been, we