Software

Last time we explored some different options that determined how the login form was displayed on your site. Today we're going to expand on that and look at different ways of wrangling or changing the actual login experience for your users. The default settings aren't exactly very refined and so it can take some configuration to get a better user experience out of the whole process.

read more

On October 1st 2014, Dries announced at DrupalCon Amsterdam that Drupal 8 had reached Beta 1, a significant milestone in the journey to Drupal 8.  

He also revealed that 2,300 individuals have contributed to the Drupal 8 project. Pretty impressive - but hard to imagine, right?   One of our Drupal developers here at CTI decided to create a visualisation to express the flurry of activity before, during and after DrupalCon, which has culminated in this significant achievement.    The video Adam created helps communicate the true scale of the project. Enjoy…  

LightSky has been using Drupal for quite some time, but because of a lot of factors haven’t contributed as much during that time as we probably should.  Mike and I implemented a philosophical change about a year ago to make a concerted effort to give back.  It has been small steps for us though, we are a small organization and in a growing phase, so our resources to give back have been limited.  Starting with attending some Drupal camps, to building modules, contributing to core, and growing from there, we have made a pretty big effort on our end to help support the Drupal community and we think you should too.

Agencies like us aren’t the only ones to give back though, companies of all different backgrounds across the globe use Drupal, and give back to the community.  Some, more directly than others, but even passively, giving back to the community is what keeps Drupal sustainable, and makes the platform so desirable.

How Can a Widget Factory Give Back to Drupal?

This is an interesting question, but it isn’t as complicated as one might think.  Look at all of our clients for example, they all give back to Drupal and many of them have no web experience, and can’t write or interpret even the most basic of code.  They give back through us.  They choose to partner with a company that gives back to the Drupal community, and that is a big deal.  There is great value in their support of the community for their company and their bottom line.  Open source projects are often some of the most cost effective choices in the software world, and Drupal is really no different. 

Experience Not Needed

Contributing doesn’t have to be through a third party though.  Content on Drupal.org can be updated by anyone with a user account.  Making documentation changes to a module that your organization is using, or building better documentation is a great way to give back, and anyone can do it.  But the way that I recommend companies give back is speaking at a Drupal camp.  Do a case study, it doesn’t have to be technical, show people how Drupal has helped your company.

Drupal allows our clients to to have an enterprise level product, that is community based, and completely flexible, and often Drupal provides them a solution that no other software could really match.  But what created this excellent product is the community, and without people giving back regularly, this product would never exist.  So if you aren’t giving back, think about how you can, and if your Drupal firm isn’t giving back, make sure that they know you think they should.

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. 

Column

Welcome back to the ANGRY THEMER!

Faithful readers of this column who have followed my outbursts over the past few years might ask, “How can I prevent myself from turning into a grumpy old themer with high blood pressure like you?”

Fortunately, the Drupal project has grown to include new tools to help battle-hardened Vikings such as I cope with Drupal’s terrible markup and keep my rage more or less under control.

And you, dear themer, no longer have to dive into code or understand the inner workings of Drupal, while also battling Responsive, Web 2.0, Internet Explorer versions 6,7, 8, 9..., Safari, Chrome, Firefox, or Opera – not to mention the gazillion tablets and smartphones. (Ah, but that’s another story, best saved for another day.)

These are my favorite weapons – uh, I mean tools, tools of the trade – that I utilize when I need to slice through the Drupal Markup sludge.

Themes

Drupal contrib has a ton of “Starter Themes”; so you don't have to trudge through all the basics every time you design a site.

Of course my favorite theme is the Mothership (Full Disclosure: written by your very own Angry Themer), which isn’t so much a theme as a complete cleanup of Drupal’s approach to markup.

Mothership – Keelhaul the DIV!

The Mothership theme is not something you use to make your site pretty; this isn’t Wordpress. It’s designed to make your source code look and act awesome by knifing through the sea of divs, classes, and about 20% of old markup fixes that come packed with Drupal, and deep-sixing it – leaving sparkling-clean HTML5 in its wake.

The Mothership theme comes equipped to clean up nearly every dusty corner and musty absess of Drupal that needs cleaning up:

• settings for removing class names
• corrects the markup to HTML5 standards
• modifies CSS & Javascript files

It also comes with commonly used basic CSS and JS libraries to help with responsive HTML5 sites, and now it even fixes the IE 9 CSS caching/respond.js issue.

As a bonus, you get to swagger and swear like a Caribbean pirate – and the ship’s captain strongly resembles Johnny Depp!

For those less-aggressive themers out there (and you know who your are), maybe Zen or Aurora – which have a more relaxed attitude towards markup – are more your speed.

Drupal 7.32, a maintenance release which contain fixes for security vulnerabilities, is now available for download. See the Drupal 7.32 release notes for further information.

Download Drupal 7.32

Upgrading your existing Drupal 7 is strongly recommended. There are no new features or non-security-related bug fixes in this release. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 and 6 include the built-in Update Status module (renamed to Update Manager in Drupal 7), which informs you about important updates to your modules and themes.

Bug reports

Both Drupal 7.x and 6.x are being maintained, so given enough bug fixes (not just bug reports) more maintenance releases will be made available, according to our monthly release cycle.

Changelog

Drupal 7.32 is a security release only. For more details, see the 7.32 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Security vulnerabilities

Drupal 7.32 was released in response to the discovery of critical security vulnerabilities. Details can be found in the official security advisory:

• SA-CORE-2014-005

To fix the security problem, please upgrade to Drupal 7.32.

Known issues

None.

Front page news: Planet DrupalDrupal version: Drupal 7.x

Episode Number: 173

In episode 173 you learn about how to make a simple countdown timer using the jQuery Countdown module. This module, which uses jQuery, allows you to specify an end date which the countdown timer will countdown to. The countdown timer is available as a block and can be placed in any region that you desire for your website. Also, at this recording their was a minor bug that didn't allow for countdown dates to extend beyond 100 days (wouldn't display the third digit).

Tags: DrupalBlocksDrupal 7Drupal PlanetJavascriptJQuery

Sometimes you could be in a fury when user picture gets deleted automatically with nothing being noticed as strange. Even this thread 935592 might not help you. Then you have come to right place. Ofcourse the culprit could be your call to user_save() somewhere. The actual issue might be, you are passing global user object instead of full account object. The first param of user_save() should be a full account object, while global user does not have all the data of account object. In this case $account->picture is an object while $user->picture is just an integer, fid (File id) of the image file. So while trying to save, your picture association with the user account gets broken. The reason can be understood by looking at the user_save() source code. The method checks for  empty($account->picture->fid) While using $user, this condition becomes false (we only have $account->picture not $account->picture->fid) and user picuter is removed. So make sure you call like this, global $user $account = account_load($user->uid); /*Some operations with $account object*/ user_save($account, $edit); /*NOT user_save($user, $edit)*/

• Read more

Search API has been my go-to module for building search pages for the last two years. Even if the client doesn't ask for anything fancy, I still download and install Search API, use Database Search for the index and Views for the page.

If you start with Search API from the beginning, then it's easier to customise later on. The core Search module, on the other hand, is easy to setup but hard to modify.

Recently, I had to create a search page that highlighted the keywords in the results. If you search using a particular keyword, then the word is highlighted.

Wow!!! As I think about the week spent in Amsterdam, I am in awe of the entire experience. This beautiful place has a very long and eventful history dating back to the 12th century, and was the perfect setting for DrupalCon Amsterdam 2014. As I think back upon the week, so many words come to mind that reflect emotions I felt while there: festivity, jubilance, liveliness, pride and treasure.   Having only been with Commerce Guys for a short 3 months, I wasn’t sure what to expect. I’ve been in the world of technology for over 13 years, and I’ve been around the block more than once with emerging technologies within the word of digital commerce. This experience for me personally will be one that I will forever treasure.     I said on many occasions that I felt like a fish out of water just trying to get some air. I consider myself fairly smart – I realized in Amsterdam with these magnificent people that any hopes of me getting an invite to be part of Mensa International most likely will never happen. Their kindness and willingness to welcome me to the world of Drupal was more than I could ever ask for.   Henry Ford once said, “Coming together is a beginning; keeping together is progress; working together is success.” The amazing group of people whom I refer to as the “Drupal People” (all 2,370 of them in attendance) embody this quote by Henry Ford. These are some of the most amazing, generous and intellectually aware people I have ever had the experience to associate with.    There was something rare and unique about this group of “Drupal People”. I believe that rareness is their desire to work together for one common goal…it’s what sets them apart from so many others. That goal is to serve the customer, and to provide the best of the best when it comes to a solution that is cost effective, manageable and scalable. From small startup business to full-blown enterprise organization, we have a solution that will work. Whether you are a current Drupal customer or are looking to make a change over to Drupal, I am here to tell you that the “Drupal People” truly are working together in a spirit of togetherness that will make Drupal the platform of the future (if they haven’t already).     I mentioned in the first paragraph some adjectives such as festivity, jubilance, liveliness, treasure and pride. There are two that stand out above all the rest: pride and treasure. I can’t be more proud of the company I have the privilege of working for and the people I have the opportunity to work with. Each and every team member of Commerce Guys brings to work a sense of pride that can’t be explained; only witnessed. Many sleepless hours are spent building the best of the best and ensuring that our customers know only one name: and that name is Drupal, a rare treasure.   I am excited about the next DrupalCons in Bogota, Los Angeles and Barcelona in 2015. As always, Commerce Guys will be there loud and proud supporting Drupal Commerce, Platform.sh, our partners, and the great people who are advocating the vision and future of Drupal.     Cheers to the beautiful city of Amsterdam, the fine people of Amsterdam, and each and every one of you who make what we do possible.   Thanks again for welcoming me to the Drupal Community in Amsterdam, I will be back!!!  

Drupal and many of the people who work with it are moving toward a configuration in code model of site development. One of the advantages of a config in code approach is that the code you add, share, and modify works for all the members of your team and across environments. Instead of everyone syncing databases (or passing around notes on how to update their environment because something changed), everything stays up-to-date with the latest code in your version control system. This essentially provides a known, common state for everyone to work against.

Configuration only gets you part of the picture, though. Modules like Features and configuration initiatives for Drupal 8 separate configuration from content. Configuration is sharable settings; content is the information that site stores/uses. This separation makes sense in organizing your code or site, but leaves a big gap in your ability to build and test a project. If I'm working on a project locally, I can't share a link to the article node I'm having trouble with because it’s a combination of configuration and content that exists only on my local machine.

You need standardized content to test against and to provide a common ground to review variations with your team. But what do you do when you're starting on a project and you don't have content from a client yet? You still need to develop code that uses content and you still need to style the site.

Luckily, we can use a common approach for bringing in content from another source, the Migrate module, to help create content we can share and test against. Additionally, the content can be updated, version controlled, and contributed back as the project rolls forward. And – this is very important for development content – when we're finished with dev content we can remove it with Migrate's rollback functionality. Content created with some modules like Devel Generate and even manually created development content aren’t easily removed when you're finished. At Aten, we commonly had many nodes with "DELETE" in the title to make it "easy" for us to find and remove it later, which is less than ideal.

How does this all work? This is our internal workflow:

• Create a resources folder in your project. Typically we now have a "root" level that has resources, a public_html folder (which has the Drupal files), and other project files.
• Inside of the resources, we create a content directory and add content files like YAML files, CSVs, etc. (more on that in a minute)
• We have started to use gulp and we have a task that will convert the YAML files to JSON.
• We create a custom module in the project for migrate and add migrate classes for each of the content files we need to import. Typically this will be something like "project_content". For dev specific content, we name the migrations with "Dev" on the end. When we have production content (which is awesome to have early in a project), we leave that suffix off the class name since that content isn't something we need to rollback later.
• We've created a script that is shared in the project that enables/disables modules, enables and reverts features, runs the migrations, updates various other things related to the project setup. If I add a new migration, I update that script's configuration to include it for others working on the project. I hope to share more about this script soon.

Creating Test Content

Now we need to create the content. Typically this requires some insight provided by our Drupal architecture document, but I have also created a couple of tools to help out with this process which help me stay in code:

• drush typeinfo
• drush taxonomyinfo

The typeinfo commands allow you to inspect content types/entities on the site. For example, if you are going to create content for an Article content type, you would run:

drush typeinfo article

That will output the content type's fields, field types, and some other information. Often this provides a good overview of what pieces you will need to create in your content file. If you have a taxonomy or entity reference field in that content type, you can also get more information about that via another typeinfo command:

drush typeinfo-field field_article_type

This will return a few specifics that may show you the taxonomy that field uses. And now we can use the taxonomyinfo command to list terms in that vocabulary:

drush taxonomyinfo-term-list article_type

We can also extend this functionality to automatically stub some of the content (à la devel-generate) by creating another drush command. This command lets us get the YAML with some data populated for us:

drush stub-content article --include-id --include-title --count=5 > resources/content/article.yaml

An example of this command is here: https://gist.github.com/robballou/a7aa247aa7bdfb3a1b2c

The stub content functionality makes some really rudimentary content and you can expand that with content from your favorite ipsum replacement or other sources.

We can migrate from a variety of sources: from CSV files, JSON files, or even other databases. CSV files are a popular choice because you can collaborate on a spreadsheet (especially via Google sheets) and export that data. JSON is another nice solution because the data can match the destination closely. In some of our projects we have even used YAML and converted that to JSON since the readability of YAML is slightly better than JSON — which means we can have people write content who don't know the ins-and-outs of JSON!

Some systems may have access to a PHP YAML library and it could be used to create a Migrate YAML source class. This would eliminate the need to convert files but may rely on that YAML library to be available on local, staging, and production servers. We've used the node.js/gulp approach because it can be shared between environments and projects that may not have this PHP support built in. Migrating and Removing Test Content

This article won't get into the details of creating your Migrate code, but the next step in the process is creating and testing the code to get this content into Drupal. When this is done, commit this to your version control system to share with others working on the project or with other systems.

As an example, we'll say we created a migration called ArticlesDev which has a handful of articles in it. The content uses a variety of the fields in the content so we can make sure all the functionality works and includes several nodes so we can test lists of various sizes. We can import the content into any system with:

drush migrate-import ArticlesDev

If the article content type changes down the line, you can update the content files and re-run the migration, updating the existing content (or adding new content):

drush migrate-import --update ArticlesDev

Development-specific content may never get imported on shared systems, but if you do want to use that content for client acceptance testing or for any other case, you can easily remove this content with:

drush migrate-rollback ArticlesDev Content in Code

If you're working in a team or if you need a client to review functionality, development content can be very handy. Building on this workflow, you can get a set of content in place early in the process, update it as things change, and get rid of it if you don't need it anymore. Your team and your clients have a common ground when discussing the project. As a bonus, your development migration code can be used as a basis for creating or importing live content as you get it from the client.

In this quick tip, we’ll be installing a local instance of Drupal 8, beta 1. By the end, you’ll have a copy of Drupal that’s not only ready to be extended with Symfony bundles and other packages, but also ready to accept content and display it to end users.

Step 1: Prepare Environment

Continue reading %Quick Tip: Up and Running with Drupal 8 in Under Five Minutes%

Here at OSTraining we've given significant coverage to Drupal Commerce. You can watch a video class with nearly 30 lessons and download a book, "Building E-commerce Sites with Drupal Commerce".

However, Drupal Commerce is an enterprise-quality solution and a good number of OSTraining members have asked for simpler solutions.

For those members, we often recommend the Payment module which makes it easy to add e-commerce fields to your content.

Payment supports about half-a-dozen gateways (PayPal, Stripe, iDEAL, Authorize.net, Ogone, Rabo OmniKassa) and we'll use PayPal in this tutorial.

This post was originally shared on the Drupal Association blog.

DrupalCon Amsterdam has wrapped up, and now that we're over the jet lag, it's time to look back on one of the most successful DrupalCons to date. DrupalCon Amsterdam was the largest European DrupalCon yet, by far. Just to knock your socks off, here are some numbers:

• More than 2,300 attendees showed up to 120 sessions and nearly 100 BoFs
• 115 attendees showed up to the community summit and the business summit
• 146 training attendees, 400 trivia night attendees, and 400 Friday sprinters made the week a success
• …and through it all, we ate 1,200 stroopwafels.

The fun extended to more than just the conference -- with 211 transit passes and 56 bike rentals, attendees from over 64 countries were able to enjoy all the city of Amsterdam had to offer. What a success!
As with any DrupalCon, DrupalCon Amsterdam wouldn't have been a success without lots and lots of help from our passionate volunteers. We'd like to take a moment to send out a big THANK YOU to all of our track chairs and summit organizers:

• Pedro Cambra - Coding and Development
• Théodore Biadala - Core Conversations
• Steve Parks - Drupal Business
• Lewis Nyman and Ruben Teijeiro - Frontend
• Michael Schmid - Site Building
• Bastian Widmer - DevOps
• Cathy Theys, Ruben Teijeiro, Gábor Hojtsy and the Core Mentors - Sprints
• Adam Hill and Ieva Uzule - Onsite Volunteer Coordinators
• Baris Wanschers - Social Media
• Emma Jane Westby - Business Summit
• Morten Birch and Addison Berry - Community Summit

We also appreciate everything our core mentors did to make DrupalCon Amsterdam a hit — and it’s thanks to lots of hard work from our passionate community members that Drupal 8 is in Beta!
We hope you had as fun and exiting a time in Amsterdam as we did. For those of us who weren’t able to make it, and even for those who were, you can relive the fun on the flickr stream, or catch any number of great sessions on the Drupal Association YouTube channel.  And remember to mark your calendar for DrupalCon Barcelona in September 2015. See you there! Below is Holly Ross' set of slides from the Amsterdam closing session.

DrupalCon Amsterdam Closing Session from DrupalAssociation
Image credit to Pedro Lozano on Flickr.

To complete my series on multilingual Drupal, here are some mini-lessons I've learnt. Some of them are are to improve the experience for administrators & translators, others cover obscure corners of code. The first few don't require any knowledge of code, but the later ones will be much more technical.

Drupalcon Amsterdam: some (user) experience

DrupalCon Europe 2014 was all about a new era that has now began on Wednesday, October 1st with the official beta 1 release - the era of Drupal 8. Compared with the DrupalCon Europe 2013, this conference was more about business and development and less about UX related matters. However, UX topics and raised questions are definitely worth mentioning.

UX and Dev: We need to have a date!

One of the most frequent UX topics of last year was better user experience crafted for the end-users of a website together with the importance of user research as a business objective. Knowledge of how and why people use a product conveys better understanding where the areas of improvements that need immediate mitigation are. 

Last week, voices were raised to provide a clear statement that the new and shiny Drupal 8 and the further development of Drupal on both core and contrib levels, needs to get UX research and design involved. Some actions were taken during the last year. However, there is definitely more potential. In her talk "Engaging UX and Design Contributors", Dani Nordin makes it clear. All people who contribute to Drupal have a common goal to create a better, highly scalable and stable version of our content management system. And to do so, UX researches, designers and developers are bound to work closely together, listen to each other and actually apply results of user research. To make this happen, we have to take action within the Drupal community. For example, UX researches and designers should be more involved in the development processes and procedures. Sometimes, designers and UX professionals are treated, as if their contribution is not important, which leads to a decrease of their motivation to spend their spare time for the community. Raising this topic lead to a lot of discussions. This resulted in the UX sprint producing a list of goals and directions that the community should go for in 2014 & 2015.

It’s about interaction.

More and more discussions within the community were devoted to interaction design. The word “design” has a rather broad definition and can be understood differently. For example, “design” for the majority of people only means visual design or visual representation of the object.  UX researches and designers differentiate the visual and interaction design. The latter is about the workflows or concrete steps that users should perform to achieve the goal. No doubt, visual design is crucial for making people want to start an interaction with an object in the first place. However, the quality of interactions is the key for the product’s success. The best way to determine a user-friendly interaction is to actually attempt to accomplish a task, find the obstacles, redefine the workflow and test again before the implementation even starts. The best way to do so is prototyping. No matter how you create your prototypes, you can use HTML, as Roy Scholten suggests in his talk “Because it's about the interactions. (Better UX through prototyping)”, or a broad palette of other tools that do not require advanced programming skills. The most crucial point is to prove that interactions really work and they do so for real users.  

Don’t prototype in Drupal!

The topic of the importance of prototyping gained further attention in the presentation of Dani Nordin. Don’t prototype in Drupal is a strong statement, and it has a point. One of the most popular prototyping tools Axure can help with the design at different levels: high and low fidelity. Creating Axure-based prototypes is faster and cheaper than spending days or weeks on Drupal site building and coding. Prototypes allow, however, to ensure the directions of a project, make it possible to talk with stakeholders about tangible and interactive product before applying the development forces and, again, it’s the way to receive the user feedback. This insighs can be applied not only to the products built in Drupal, but to Drupal itself. This will improve not only the life of content creators, but can help developing more elegant solutions using the better design features of the Drupal core together with contrib modules. 

 

For a long time I’ve harboured the belief that too few in Drupal receive the recognition they deserve. I often wonder how many bright (young) stars fall through the cracks of our vast community, fade away and perhaps leave altogether. When the Drupal project was small if you did some heavy lifting, people noticed. Now our numbers have swelled beyond 1 million it is no wonder worthy effort goes relatively unnoticed.

Few of us are seeking the limelight but being noticed, that’s another matter. It’s not just recognition either. We should be mentoring emerging talent, supporting promising businesses and championing contributions from end users. But with such a vast and growing community, as Dries so eloquently put in his keynote, the status quo is unsustainable.

“Social capital and altruism is what we already do and I don’t think it is very scalable”

DriesNote

We should remember the material for the Dries keynote was crowd sourced and as he said we should “keep an open mind, don’t draw to conclusions”. Now is the time to debate openly, engage in constructive conversation and help invigorate Drupal.

What struck me at Amsterdam was that when the audience members having contributed to Drupal Core and contrib were invited to stand, surprisingly few remained seated. In many respects talking to DrupalCon attendees was preaching to the converted. The job is for us to reach the rest.

Understanding how our ecosystem works is a very important first step

I believe the path to a healthier community hinges on how we record contributions, not how we recognise them. Currently we track what individuals contribute and there is a fixation on code based contributions. How about documentation, organising camps, mentoring, community affairs, design and so many more valuable activitites. Introducing a way to differentiate between efforts made by individuals, agencies and end users and a move towards “Track all types of contributions” for me is a giant leap forwards. It couldn't happen sooner.

How we might use this new data is less important than the ability to "track how our community really works”. Most significantly it will bring to the surface things are not working. Who is funding what? Are we depending too heavily on small groups or certain individuals? Could specific areas do with more help? Achieving the tracking Dries would like, could happen within weeks. The Rankomatic? I like to think of it as Drupal Analytics, which is open for all to query. Expose the data like data.gov.uk and the community will surely hack insightful mashups and we will have something very empowering.

Is D.O ready for a reboot?

What word is conspicuously missing from the D.O homepage? Contribute, yup, seriously. How can we expect more people to do so if we don’t clearly signpost how? When Dries talked about “Free riders” I reflected on how long (years) it took me to find a niche in Drupal. I existed on the fringes under employed. It was only when I was noticed by Isabel Schultz during DrupalCon London that things really flew for me. We need more "talent scouts". Why is Get Involved buried in the footer and not somewhere more obvious? Are many “free riders” just looking for a way to engage?

Rewarding contributions through enhanced visibility, leading by example will certainly help. Encouraging companies who don’t contribute to start doing so via subtle design changes to user and marketplace profile pages has merit. Will invigorate the contributors themselves to even greater heights? That's certainly how I roll.

What Dries suggests is sweeping change. In this respect the cynic in me worries about the glacially slow speed of change on Drupal.org (D.O). 5 months ago I created an issue proposing the community spotlight feature on the homepage of D.O. It had unanimous support but nothing ever happened. Maybe I did something wrong? Perhaps I don't understand the process?

The good news is the Drupal Association has hired staff whose role is to deliver these kinds of enhancements. It also feels like a more measured and strategic approach is being taken. I hear talk of user personas. The concept designs by During his TED Talk Harish stated companies that will thrive in the future are those who "play their role in terms of serving the communities who actually sustain them”.

Drupal is a platform having a community that sustains many thousands of businesses. Drupal has strong evidence that Harish’s hypothesis is already true. Drupal shops, even end users who contribute to the project tend to be the ones enjoying the best outcomes. The problem is we operate in a bubble, where everyone is hooked on open source. Out in the real world people’s thinking is years behind and the principles of open source sound quite peculiar even alien. Those coming to use Drupal need introducing to the benefits of taking a benevolent role.

We know who Lullabot, Palantir, Phase2, Wunderkraut are. The various Drupal shops are contributing, often in bucket loads. What we actually need is more companies like that. Indeed we need more end users contributing back too. Like how Oxfam, The Whitehouse, Sony have been instrumental in developing significant contributions to the Contrib space. Again Dries’s advertising model could help to champion these organisations, communicating why they chose this path and the benefits they have reaped over time. It’s not about penalising “free riders” it is more about persuading them to engage with Drupal, to start contributing.

“If everybody that used the commons contributed a little bit things would be perfectly fine”

Dries talked about The Tragedy of the commons - overgrazing in Drupal translates not to the software rather the "Free riders" are depending too much on people’s generosity, personal time or indeed time which they should be running their business. I’ve seen situations where people have neglected their business for the benefit of Drupal. This goes way beyond the well known plight of Alex Pott, I assure you. I'm sure the few examples I have seen are a small fraction. Here everyone loses.

Time for change

As Dries said “An imperfect solution is better than no solution”. We’ve tried for some time to encourage those who sit on the sidelines to start contributing. Now is the time for a small revolution. Recording, recognising, rewarding code and non code contributors on D.O is simply a way of scaling how it has always been. And if that sounds too radical, how about we try it out on beta.drupal.org? We need to take a leap. After all, aren’t we the round pegs in the square holes? We are the ones who think different. It’s way overdue we took some of our own medicine.

Further information: Outlandish Josh's Thoughts on the DriesNote: Towards Drupal "Contribution Credits"Watch the Dries KeynotePhoto credit - Steffen Rühlmann

At the recent DrupalCon Amsterdam sprints something amazing happened, people from all corners of the globe assembled to sprint on DrupalCI. DrupalCI is an initiative born out of the requirement for new testbot infrastructure. Our goal is to implement a brand new Continuous Integration (CI) workflow that can not only be used for Drupal but anyone wishing to run a CI infrastructure / Automated tasks. Until this point we had only corresponded via a weekly hangout and IRC.

While this was keeping us on track with building out some of the components, the conference gave us an opportunity to sit down in the same room and perform an end-to-end architectural review to ensure we didn't have any gaps. A modular design approach has been used to ensure that many of the following components could be used as a standalone entity in any infrastructure.

As part of the Google Summer of Code, I began work on getting CiviCRM and the upcoming Drupal 8 working together nicely. I made an update about midway through and it's time for another update.

I had separated the project into a number of milestones. Phases 1, 2 and 3 dealt with varying aspects of the core CiviCRM module functionality. This work has largely been completed and there are pull requests pending into CiviCRM core, though the front end user experience is still a bit rough (for example, the CiviCRM menu bar doesn’t sit well alongside the Drupal menu).

The installation process is quite different with Drupal 8: civicrm now installs as if it were any other Drupal module — simply by clicking enable. It's no longer necessary to use the CiviCRM installer before enabling the module. This handles the most common use case where CiviCRM is installed in the same database as Drupal itself. Custom options can be configured by adding configuration settings to Drupal's settings.php. For example, if Drupal is configured with a second database named 'civicrm', it will install civicrm there instead.

The next big milestone was Views integration. This went ahead quite smoothly, and I managed to reduce the code count from approximately 15,000 lines of code to under 2,000 by automating a lot of the discovery of the CiviCRM database. In general, when new fields appear in CiviCRM it should only be necessary to explicitly declare how the field is related to other data types (eg. as joins or relationships).

One quick nice-to-have was integrating Drupal's entity reference field with CiviCRM Contacts — mostly by creating a bare-bones Drupal entity. A similar technique may prove to work with Drupal's Rules module, but unfortunately time did not allow this yet.

Finally, for the first time, the module comes with a few simple integration tests (using Drupal's SimpleTest module) which will hopefully become more fully fleshed out with time. With a judicious set of tests, this should allow a more stable experience as future versions of CiviCRM are released.

Drupal 8 has finally released its first beta just over a week ago. Now that it has stabilised somewhat, we need to update the CiviCRM module to resolve breaking changes and we can then release an alpha version that the community can test, experiment with and help get into a stable state.

Drupal 8 repo: https://github.com/torrance/civicrm-drupal

• GSoC
• Drupal