Feed aggregator

Chromatic: How To Write A Great Commit Message

Planet Drupal -

So annoying. Fixed a bug! Hope I never see this again.

These are not great commit messages; in fact, they are nearly worthless. A great commit message should tell the reader all they need to know about the what of the commit. They should only have to look at the actual diff of the commit to see how it was accomplished.

Anatomy of a Great Commit Message

Think of a commit message like an email:

  • It contains your contact information. You don't even have to do anything; you get this for free!
  • It should have a subject: the shorter, one-line summary.
  • A body: the detailed description.

All commit messages should abide by the following criteria:

  • Begin with a one line summary. It should be capitalized and succinct (50 chars or less).
  • This should be followed by a longer description, if necessary.
  • The first two items should be separated by an empty line.
  • All lines should be wrapped at approximately 72 characters.
  • Reference an issue in your commits whenever possible. If using Github issues, you can reference them by using 'gh-80' for issue '#80'. If your commit completes the issue, you can use a number of terms to close the issue, such as: .Closes gh-80'.
  • If you forget to reference the issue in your commit, and the commit has already been pushed, reference the commit's hash in a comment on the ticket.

Here is a model Git commit message:

Capitalized, short (50 chars or less) summary. More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. * Bullet points are okay, too. * Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here. * Use a hanging indent. Closes gh-80.

The majority of your commit messages may be much simpler than the example above, but pick and choose the appropriate elements. Here is an example more common to the real world:

Fix for editor dashboard showing incorrect date. * Fixed date calculation logic. * Added function docblock to comply with coding standards. * Refactored foreach loop, improving clarity. Closes gh-80.

With just a few small improvements to your commit messages, your fellow developers, and your future self will surely thank you!

Drupal.org Featured Case Studies: AL DÍA News

Planet Drupal -

Completed Drupal site or project URL: http://aldianews.com

ALDÍANews.com is a national news outlet offering fully bilingual content, equally accessible in both English and Spanish at the click of a toggle. The new site - which publishes news related to politics, business, culture, opinion, media, and technology - allows readers to quickly and easily choose the language in which they want to view a comprehensive array of content and features optimized for various devices through responsive design.

After evaluating AL DÍA’s content and traffic, we uncovered the untapped potential for a larger audience and advertising stream by repositioning this local news site as a national news platform. The new site implements a number of innovative elements that benefit viewers and advertisers alike, including lightning-fast browsing using AngularJS, a fully bilingual interface, and advertising that can be served to specific sections, topics, or geographies.

Key modules/theme/distribution used: ServicesSimpleAdsTaxonomy menuViewsRadioactivityOrganizations involved: Eastern Standard

Imagine Creativity: What is Drupal & Intro to Drupal workshops - Global Training Day

Planet Drupal -

11822447_10153102896299716_3404987443558823562_n.png18 Aug 2015

We are happy to announce that we are running Drupal training sessions this month as part of the Global Training Days. The initiative is run by the Drupal Association to introduce new and beginner users to Drupal.

Come and join us on Friday 21st August to learn about what Drupal does and how it can help you. We will discuss the software and show you examples of it in action.

What is a Drupal Global Training Day?

Drupal Global Training Days is a worldwide initiative to increase the adoption of Drupal. All across the world, people are teaching and learning Drupal, and sharing that open source love.

During the last session run on May, 25 training companies from 15 countries participated in hosting Introduction to Drupal sessions. We are happy to be a part of this for the first time.

The two types of sessions are :-

  • What is Drupal - is a half-day workshop to address the basics of Drupal. It is designed for those interested in evaluating or implementing it.
  • Intro to Drupal - is a full day introductory training workshop. Attendees will leave having successfully built a Drupal site. It is designed for those interested in Drupal as a career path.
Who should attend
  • Web developers/designers willing to get started with Drupal.
  • Project managers managing or considering Drupal projects.
  • Decision makers evaluating Drupal. 
What is Drupal - Course outline
  1. Introduction to CMS
  2. Why Drupal; Comparative analysis of Drupal with other CMS.
  3. Case studies / Sites using Drupal
  4. When to and not to use Drupal?
  5. Where to find Drupal and Drupal installation
  6. Inside of DrupalGetting a functional site set up in 30-45 mins. Using contrib modules/themes/distributions, and getting community-based support
    1. Overview of each item of admin menu (e.g. Content, Appearance)
    2. Create and edit content
    3. Work with menus from admin
    4. Content type and its usage
    5. Block and where to find them
    6. Working with roles and users
  7. Getting a functional site set up in 30-45 mins.
  8. Using contrib modules/themes/distributions, and getting community-based support
  9. Support Drupal.org and Drupal Association
We are holding this event in partnership with CVS Brent, who will be hosting us. They work with many charity & voluntary sector organisations to better deliver their services.

Tags: DrupalTrainingDrupal Planet

Zivtech: Permissions and roles for happier users and admins

Planet Drupal -

When you first install Drupal, you are given a lot of power. With all of the contributed modules available, you can do pretty much anything. You can also horribly mangle your site security, make your users hate having to use your site, and end up having to redo work from inexperienced users trying to (ahem) "help." So let's talk about users, permissions, and roles, and how you can use them to keep your Drupal installation merrily un-borked. If you've already been through adding roles and permissions once or twice, you should feel free to skip over the how-to's, and focus on the best practice sections.


One special user: the superadministrator who bypasses normal permissions checks

There is one extra-special user that everyone who has installed Drupal is familiar with: The Superadministrator. Drupal comes with exactly one superadministrator out of the box with a user id of 1. This user is usually named something like admin or root, and bypasses normal permissions checks. When you install Drupal, you are automatically logged in as the superadministrator.

Best practice

You should not be using this user for your day-to-day site maintenance unless you can guarantee that you will never make a mistake (in other words, you really shouldn’t be using this account for day-to-day tasks). Instead, make yourself another login that you use for mundane tasks like creating content, and then use the admin account for the rarer tasks, such as changing the site name. However, you SHOULD be using this user to start administrating roles and permissions as no other role will have that ability until the superuser grants it. 

Best practice

If you work in a team, don't use your personal email for the superadministrator. Use an email that all developers have access to, such as sysadmin@example.com or dev@example.com.


The principle of least privilege

For everyone else, we will rely on the User->Role->Permissions model. The principle of least privilege states that you want your users to be able to do their jobs on the site, but not anything more (definitely check out that page if you are unfamiliar with the finer points of this idea). First off, this prevents anyone who steals an account from being able to do too much damage ("Muhuwahaha, I will now commence commenting - UNMODERATED!"). Secondly, your site is guaranteed to have at least a few careless or inexperienced users, and minimizing access can prevent accidental data loss too (“oops! I thought it was ok to delete that /node view!”). You can easily use Drupal's roles and permissions system to implement this concept. 

Think of the relationships between users, roles, and permissions as the relationship between people, jobs, and tools. The user/people analogy should be pretty obvious and trivial, but I should mention that each person should have their own account and login or the model will begin to break down as you figure out how your users specialize. A role/job is a title given to a user/person that allows them to perform certain tasks. And a permission/tool is granted to a role/job so that a user/person can complete those tasks.

Best practice

Each user should have their own account, so that you can add permissions to each user individually instead of granting privileges to a single account that may not always apply to everyone who has access to it.

Best practice

Map out the people, jobs, and tasks that need to be done before applying any roles or permissions. Once you become familiar with the process, you will be capable of doing this quickly in your head, but in the meantime, map it out on paper. Add it to your site documentation too so that everyone on your team knows what each role is about, such as the following:

  • Commenter: A trusted user who is allowed to post comments without moderation.
  • Blogger: A user who can create blog posts.
  • Content manager: An editor who can create basic pages around the site, edit other people’s blog posts, and moderate comments.
  • Site builder: A user who can perform light site maintenance such as adding items to the menu, editing views, and administering blocks.



Permissions are the tools that your users will use on a day-to-day basis. Generally, most permissions are positive: they grant users the ability to do a task but rarely take away the ability to do anything (we'll ignore those rare cases for the purposes of this blog post). Some common permissions: 

  • Administer blocks
  • Administer comments and comment settings
  • Post comments
  • Use the filtered text format
  • Use the full HTML text format
  • Administer menus and menu items
  • View published content
  • Article: Create new content
  • Article: Edit any content
  • Create and edit URL aliases
  • Administer modules
  • Use the site in maintenance mode

You can edit permissions for your site at example.com/admin/people/permissions. Notice that you only have two roles when you first create your installation: authenticated users and anonymous users. We'll get into adding roles shortly, but until then, think of these roles as two different types of users: authenticated users are people who are logged into your site, while anonymous users are not. Let's say you want both roles to be able to view comments, but only authenticated users will be able to post comments (which is a reasonable industry standard). You would edit the permissions to look like this (note that two different roles can share the same permission): 

When an authenticated user visits your site, they will see the form to add a comment, but the anonymous user will not. Both users will be able to see all comments.

You can go through the rest of the options in the permissions list on your own, but soon you will need some permissions that only apply to SOME of your logged-in users. 



To give certain logged-in users different permissions, you will need to create some new roles. Going back to the people, jobs, and tools analogy, you will be creating new jobs and then assigning different tools to each one.

For example, imagine that you want bloggers to be able to create blog posts, edit their own blog posts, and delete their own blog posts. You would create a new role at example.com/admin/people/permissions/roles and then edit the permission for that role. You don't want every blogger to be able to edit other people's blog posts, create views, or change the site name, so if I want to give those permissions to a user, I will need to grant them the appropriate role (moderater, site builder, administrator). The number of roles any site can use is unlimited, but here are some typical roles:

Any user can have more than one role. There's no reason that a user who is a site moderator should not also be able to comment, so it's perfectly normal to give a user two roles: moderator and commenter. 

With all this freedom, you may be wondering whether to create a role or add permissions to an existing role. Use the following guidelines to figure it out: 

Create a new role Add the permission to an existing role
  • This is a new permission for a new role ("we've hired a blogger!")
  • This is a new permission that will be shared among many different roles ("we've created a blog and all sales reps and developers can post to it!")
  • This is a new permission that will apply to only some members of a role ("we want some bloggers to be able to post without going through moderation!")
  • This is a new permission that expands one specific role ("we want all of our content moderators to be able to edit all these new blog posts!")
  • This is a new permission that applies to either anonymous or authenticated users ("we want everyone to be able to see our blog!")
Best practice

Unless you won't be available to do so in the near future, only grant users a role that they need right now. If a user thinks that MAYBE they would like to become a blogger SOMEDAY, then you can grant that role at a more appropriate time according to the principle of least privilege.

Best practice

To go back to the above analogy, you don't want to be giving all your chefs access to a dog-leash. Nothing good could come from that; save the leashes for the dog-walkers, and if a chef has also been trained as a dog walker, you can hire that person for two jobs instead of giving a leash to every chef. Similarly, make sure that your roles only have permission for the tasks they need to do. Instead of granting all bloggers moderation privileges, give the blogger than needs them the moderator role.


Adding roles to users

Now that the roles and permissions are set up, it's time to grant roles to users. If you only have a few users on your site, you can do this on a case-by-case basis by going to their user page and hitting the edit button.

If you have many users you want to grant roles to at the same time, you can use the people tab at example.com/admin/people. Select the users to grant the roles to, select "Change user roles" from the operations drop-down, and then click "Execute."

Revoking rules is the same process; unchecking a role from a user's edit page with withdraw those permissions from their account, or you can bulk remove roles in the same manner as above.

Depending on your version of Drupal (and how up-to-date it is), you may have to log a user out and then back in again to see role and permission changes. If you're on Drupal 7 (and if you're just starting a site today, you really should be), then you're good to go.


Testing permissions

This is the step that always gets me. I "know" how permissions work, I "know" that I set them up properly, and yet... I forgot to tick off a box somewhere and now someone can't do something that they need to do. So to finalize this walk through of best practices, the big one is to test all your hard (ok, pretty easy) work. Create a dummy user with the role you're testing (and ONLY the role you're testing), and then log in and try to do what you need to do. I like to use an incognito window so I don't have to log out of my administrator window to test.

If you can do the functions of the role that you have set up, then YOU ARE DONE. You now have a reasonably secure site, although there are always ways to get more secure. Happy Drupalin'!


Red Crackle: Object Oriented PHP

Planet Drupal -

I am sure that by now you must have heard that Drupal 8 is using Symfony components and is based on object-oriented programming in PHP. If you are a Drupal 7 developer, then you may not know what is object-oriented programming or fail to understand the benefits it offers. In this series of posts, you will learn the basics of object-oriented PHP programming so that you can start developing for Drupal 8.

DrupalCon News: Training Spotlight: Frontend Performance Training

Planet Drupal -

Mobile device usage is surging as people use them to read content, shop online, and find information on the go. Users are proven to be happier and more willing to spend time and money on your site when it loads fast and responds quickly to their actions. Adding performance to the ever-growing list of project responsibilities can seem daunting, but it doesn't have to be.

In this full-day training, we will address every step in the process of improving frontend performance: auditing a site for problems, creating an effective solution, testing sites to ensure that the work was successful, and implementing automation tools that prevent regressions from creeping back into the codebase. Additionally, we will offer tools and suggestions to help your organization adopt a culture of performance, boosting its visibility in discussions and allowing your team to expose performance problems earlier in the development cycle, long before launch.

Drupal Watchdog: Wait, $langcode? What the Heck?

Planet Drupal -


Wait, $langcode? What the Heck?

If that was the most polite thought that crossed your mind when dealing with the Drupal 7 Field API, please read on.

No matter whether you build complex multilingual sites, or whether just hearing the words “Drupal” and “language” in the same sentence makes you want to hide in the darkest corner of your office, there are a few language-related notions that you really need to know to write Drupal 8 code that works properly. After all, language is an intrinsic property of textual content, and since Drupal is supposed to manage content, having to deal with language does not seem such a peregrine idea, does it?

Speaking of Content

Historically, content in Drupal is a user-friendly way to refer to nodes. However, in Drupal 8, content has a broader meaning: it refers to any entity type which stores information usually meant to be experienced in some form by a certain set of site users.

Content entities, such as nodes, comments, terms, custom blocks, custom menu links, and users, are all examples of this kind of entity type. The other main category is Configuration entities: node types, views, fields, menus, and roles, are meant to store information mainly related to determining the site behavior. Note that this distinction may not always be so clear-cut, as in some cases the choice of picking one category or the other may be determined mainly by implementation details, as in the case of module-provided menu links.

To sum up, when in Drupal 8 we speak of content, most of the time we are referring to content entity types.

Multilingual Content: A Bit of History

In Drupal 7, a new way of translating content was introduced by adding native multilingual support to the Field API. That allowed the ability to store multilingual values for any field attached to any entity type. But code that implements business logic needs to explicitly deal with field language, which implies a very poor developer experience (DX); i.e., this infamous field data structure:

Gathering places for Drupal Developers

Twin Cities Drupal Group -

Is there any places that people meet on a weekly schedule to study Drupal? I'd like to get a real quick overview of Drupal and dive right in. I'm still new to Drupal. I know there's the monthg meetup but that is still a little by away. If there's such a place where Drupal learners gather then I would love to know.


Red Crackle: Configure PHPStorm to debug Drupal 8

Planet Drupal -

Devel module provides dsm() and dpm() functions to output variables on the page for debugging Drupal. But if the problem is more complicated, then that's not sufficient. You can simplify debugging tremendously if you stop code execution using breakpoints and then execute the application one step at a time. All IDEs that support PHP debugging, such as Eclipse, Netbeans, PHPStorm, etc., provide the functionality to put breakpoints in the code. But it requires quite a bit of configuration to make it work. In this post, you will learn how to configure PHPStorm 9 to debug Drupal 8. By the end of this article, you will be able to stop code execution in PHPStorm by putting a breakpoint.

Ensuring the web is for everyone

Cloudflare Blog -

This is the text of an internal email I sent at CloudFlare that we thought worth sharing more widely. I annotated it a bit with links that weren't in the original.

"Tim Berners-Lee- Mosaic by Sue Edkins at Sheen Lane Centre" by Robert Smith - Own work. Licensed under CC BY-SA 4.0 via Commons

Subject: Days of future past


One of the exciting things about working at CloudFlare is our continual push to stay on top of what's new for our customers. We've pushed things like IPv6 and SPDY in the past; and we'll soon be giving the world DNSSEC and HTTP/2. In the world of SSL we've stayed on top of changes in recommended cipher suites and offer the latest signature algorithms SHA-2 to our customers.

But as we do this we must not forget the old protocols. Because we serve a truly global audience we serve everyone on the planet. It's easy inside a Silicon Valley bubble to think that everyone is on 1Gbps Internet connection with the latest version of Chrome on a new Mac, but the worldwide reality is far different.

We see every type of machine and browser out there. And by machine I mean computers old and new, smartphones, dumb phones, command-line clients, every type of proxy server. And we see them on satellite connections from ships at sea, 3G connections in developing countries, fiber connections to the home and more.

As we keep pushing for the future we also have to look to the past and make sure we support everyone. Supporting everyone means that all CloudFlare sites are accessible to everyone who uses the web and when someone asks "Can you handle X?" we can simply answer "Yes" without any caveats. And X can be something created 15 years ago or 15 months ago.

So, when making technical decisions we need to ask ourselves "Who are we excluding if we do this?" and really push ourselves to come up with a solution if we are excluding some portion of the Internet's users and create solutions that don't compromise speed and security.

At the 2012 Olympics in London the creator of the web, Tim Berners-Lee, appeared in the opening ceremony and tweeted "This is for everyone". Let's make sure we keep the web available, secure and fast for everyone.


SitePoint PHP Drupal: From Request to Response: A Journey into Drupal 8 Internals

Planet Drupal -

In the first article on Drupal 8 module development we looked a bit at the routing aspect of this process. We’ve seen that creating pages with paths is now a matter of declaring routes that match up with controllers. The latter, as we’ve seen, can return a render array that gets interpreted into markup and displayed in the main content area of that page. However, did you know that under the hood, Drupal actually transforms that array into a Response object according to the dictates of Symfony’s HTTPKernelInterface?

In this article, I would like us to go deeper into the internals of Drupal 8 (and Symfony2) and look at what actually happens (and can happen) from the moment a request is made by a user to the one in which they see something returned in response. The example I mentioned above is just one direction this process can go in, and today we are also going to see other possibilities. The goal is to understand the flexibility of the system which in turn can help us build awesome applications.

Before going into it, I strongly recommend you check out this diagram which does an amazing job at synthesizing what is often referred to as the render pipeline. Though in my opinion it represents more than the name implies because the render system is only part of what’s depicted, albeit a big one.

Continue reading %From Request to Response: A Journey into Drupal 8 Internals%

Annertech: 6 Reasons Why We Suggest Drupal to Our Clients

Planet Drupal -

6 Reasons Why We Suggest Drupal to Our Clients

We recommend using Drupal as a content management system platform for our client projects for many reasons, not least of which is that it is a widely adopted, free, open source solution. Here are some of the strengths that we see our clients benefiting from when they use the Drupal content management system.

Jim Birch: Using Fences and Page Manager to optimize HTML markup in Drupal 7

Planet Drupal -

I have been searching for a way to make Drupal output cleaner, lighter, more semantic HTML since I started theming.  We all know Drupal core, and it's many contrib modules have a tendency to inject a couple-two-tree divs in 'dere.  I have tried many different ways, much to the chagrin of the developers I have worked with, most of them probably not worth the effort I put in.  That is until now!

The goal of my approach here is to minimize the markup that Drupal puts out, and gain complete control over the what and the where of the markup.  I can gain control of the fields using the Fences module; control over the templates in my theme; and gain even more control over the placement and what gets loaded using ctools Page Manager and Panels.  I will step through each of this in detail below.

Read more

Imagine Creativity: Drupalaton 2015 : our perspective

Planet Drupal -

17 Aug 2015

Last week we attended Drupalaton for the second year in a row. It was so valuable to us last year we couldn’t resist returning, especially after attending the great events Drupalaton & Drupal Dev Days Szeged last year. See our blog post from last year Drupalaton 2014.

What is Drupalaton?

It is a 4 day Drupal Camp which takes place on the edge of Lake Balaton, the largest lake in Central Europe. It started off as a group of 50 Hungarian Drupalers that knew each other quite well, as a Drupal Camp in the city of Pécs. After it grew the local community decided to move it to Balaton and change the name. After 1 year they decided to open it up to a much wider community, so in 2013 lots of attendees came from neighbouring countries.

Last year in 2014 there were 79 attendees from 13 countries including Belgium, France, Finland, Germany, Netherlands, Spain, Sweden, Switzerland, the UK. This year it was great to see us reach 115 attendees from a more diverse group of countries, many of which re-attending for years (including Pieter Frenssen).

What makes Drupalaton unique to other DrupalCamps?
  • Sessions - Longer, friendlier & more interactive.
  • Weather - At 35C during the trip it was great to make sure relaxation was had. Having the lake a few steps outside the hotel was very much welcomed.
  • Social activities - Morning jogs, group meals, evening drinks, boat party, grill party, swimming together on the lake, Go Karting.
  • People - The great weather and opportunities for socialising make it an amazing environment to make new and strengthen existing friendships. Some attendees brought their children who also made new friends!
The amazing organisers

We can’t say how much we appreciated all of the organisation effort that went into the event. The team was led by Tamás ‘York’ Pintér, with support from Zsófi Major, Gábor Reisinger, István Csáki. They are the real heroes of the event, and in addition to the months of organisation, they put in lots of additional time from early in the morning until the late night socials. They deserve a huge round of applause.

Extended sessions/talks

These were longer than usual 1 hour given at other Drupal Camps & Drupal Cons, but also in a workshop format. These were upto 3 hours in length, people had their laptops out on tables and were encouraged to ask the speakers questions as they went.

Boat party

This was a lot of fun and also a very good opportunity for attendees to exchange experiences and knowledge with eachother. There was tasty food, beer thanks to the fantastic sponsors. The boat journey was perfectly timed to give a view of an amazing sunset.

Grill party & the Drupalaton song

More tasty food followed, truly a feast which was much appreciated. Here some played poker with Druid's scrum cards and others played with the children, all before we were treated to a perfomance of the Drupalaton song. There were guitars and singing provided by Ruben Teijeiro, Gergely Csonka, Ernő Zsemlye & Tamás Hajas who gave us 'Drupal Get Commit' and the catchy chorus "We’re up all night to get a commit". YouTube video.

Fun games

5Net from Hungary gave puzzle pieces in everyone’s goodie bags which were used to create a giant jigsaw puzzle with the Drupalaton logo. REEA from Romania brought a unique game Crokinole, in which you slide pieces into circles and knock your opponents’ ones out, during which I won a t-shirt & mug after beating my opponent.

Family friendly

Lake Balaton is a popular holiday destination for the whole family which is one of the reasons many Drupal attendees brought their partners and children. It is very pleasing to see how happy everyone is and how much they interacted with the rest of us during the social time. It is good fun for the whole family and encourages them to all become friends with each other too. Perhaps in future events we could even have sessions for children, what do you think?

Drupal in Hungary

With famous Hungarian Drupalers including Gábor Hojtsy & chx , it was a different environment than you would normally see them in. I was very pleased to find out about how the Drupal community started to grow adoption in the country, especially in the early days.

Drupal in Central & Eastern Europe

Drupal companies in the area are keen to get away from the outside world seeing them as a cheap place to outsource to. They prefer to work on a partnership basis where you gain a relationship with team members, instead of ‘resources’. It is interesting to see that they are increasingly working on local client projects too. I was glad to see many friends again from the nearby countries of Serbia, Romania, Slovakia again from last year as well as other camps. For some local attendees Drupalaton has become an affordable alternative to DrupalCons as wages are generally a lot lower than in Western Europe. It will be exciting to see what happens with Drupal Iron Camp next year in Budapest, an event that aims to showcase the talent of the area and provide accessible Drupal training with low cost tickets.


Tamás ‘TeeCee’ Szügyi has perfected his art of photographing Drupal events with precision and was everywhere capturing it all. He has added photos to this Flickr group. If you have any photos please share them there too.

Next year

For 2016’s event the dates have been announced for 11-14th August. Hope to see you all at Drupalaton again next year!

Image - Top: Tags: DrupalDrupal CampDrupal Planet

Chen Hui Jing: Drupal 101: Theming Drupal 7 with gulp

Planet Drupal -

I still remember the first Drupal 7 theme I built. It was for the Singapore Gastric Cancer Consortium website, and at the time I barely knew my way around HTML and CSS. I used the Zen theme as my starter theme, and unknowingly wrote my CSS in .scss files without realising the distinction. I was a little bit confused to why I needed to install a software called Codekit to make everything work but was too busy trying to get the theme up and running to worry about it at the time.

Let’s talk about that thing called Sass

After I finished up with that project, I took the time to understand exactly what was going on....

Steve Purkiss: Drupalaton Day Zero: Drupal 8 shipped - you didn’t miss the boat already?

Planet Drupal -

Saturday, 15th August 2015Drupalaton Day Zero: Drupal 8 shipped - you didn’t miss the boat already? Shit.

“Shit, shit, shit!” exclaimed the guy sitting next to me, bashing his fingers away on his laptop in the reception area of Hotel Helikon, an ageing family summer fun destination perched on the southern shores of lovely lukewarm shallow Lake Balaton in Hungary where I had arrived a day early for the yearly Drupal event Drupalaton

You wouldn’t have noticed the extra sweat on my forehead in the sweltering 36 degrees heat, but these words made me nervous, for these weren't the words I was expecting to hear come from Daniel Wehner, the person who has the most commit mentions in Drupal 8. Had Drupal 8 broken horribly? Had some big problem just been found? No - well, not exactly. It was to do with supporting a beta-to-beta update path - more on that in a moment, for the moment let’s bring everyone up to speed.

Patch me in!

“But Steve, wait a code-damn minute there - what’s a ‘Commit mention in Drupal 8’ when it’s at home?" I hear some of you say! It means you were involved in some way in something that ended up being part of the core package of the next version of Drupal, version 8. What is Drupal? It’s a piece of software which currently powers over a million websites around the world. Everyone from those who accidentally became a Drupal developer whilst looking for a solution to help their tennis club to those in charge of running the United States use Drupal to communicate with their community via the web - see more examples over at this showcase of Drupal sites.

Drupal is a Free Software project (you may have heard it incorrectly referred to as 'Open Source'). This means anyone in the world is free to participate in the project - you can use it, study how it works, make changes, and share those changes if you want. A commit mention means you might have fixed a bug, reviewed some code, or been involved in some way with helping an issue move along the process until it has been deemed reviewed and tested by the community (“R.T.B.C.”) and thus ready to be committed to the codebase of the Drupal project. OK, now let’s get back to Hotel Helikon!

Getting on the Island

Later that evening after I’d unpacked and had a little wander around, I chatted with Daniel out on the island which, by daylight every inch of the hotel's small private enclave surrounded by the lukewarm shallow water of the lake is covered with holidaying families. Once a year, by night, the island becomes a hotbed of Drupal chat, especially this time as we are so tantilisingly close to release which has been worked on for four years now since the release of Drupal 7 in 2011.

“BDFL!” Daniel suddenly exclaimed. I thought for a moment - I didn’t recognise the acronym at first, thinking it may have been some internal subsystem only a few people knew as seemed the way with previous versions of Drupal to 8 which is now far more easier to approach using standard industry practices. This BDFL meant “Benevolent Dictator For Life”. It’s how the Drupal works currently, with that BDFL being founder of the project Dries Buytaert, whose own company Acquia recently announced that even though 8 wasn’t released and would be “ready when it’s ready”, they were ready to support customers who wanted to use Drupal 8. I guess this means they would value some kind of beta-to-beta upgrade path.

Grow the island communities

From the perspective of being one of the people who supports that upgrade path whilst also being asked every five milliseconds “When is Drupal 8 going to be ready?” I can imagine it’s probably quite stressful. Acquia aren’t the only ones of course, from a value perspective it means more adoption, certainly an easier life for me as I now partake in Brighton’s Homebrew Website Club to help keep the ball rolling on my migration of my own purkiss.com site to Drupal 8, although now I’ve thought of a few more pet projects I’d like to get up and running now I can actually base my efforts on the solid, well-thought-out foundation Drupal 8 provides me with.

Whatever the case, I leave my peers up to discuss and my readers to join in appropriately if they want. All I know is these decisions could be influenced by me if I wanted as it’s a Free Software project and if I cared enough about a certain topic I could get involved however I fit best and change it, not enough people understand or make use of those freedoms. Whilst Drupal is the largest community of contributors and over 3,000 people have commit mentions in Drupal 8, that’s a tiny proportion of those who use it, many whom make and create a lot of value and some of whom make a shed-ton of money out of it. Of course many more than just commit mentions make the community what it is, however the adoption rate at which Drupal has been taking that percentage is getting smaller every day.

An enormous amount of money comes back into the community in one way or another, but we are quite a way away from being able to simply visualise a piece of software in our minds and it suddenly spring up into existence in front of us without any human expense of effort. We may be able to one day do that - especially if we continue to freely innovate - but for the moment we have what we have, and every little piece takes human resources; at least until we replace them with running code.

As the Drupal project and community grows we need more people to be involved in building and supporting the very foundations which support us as a whole, and if that means rambling on in a lengthy, potentially edgy blog post in order to perhaps gain just one more person as a contributor then, until I am able to express myself in a better way, I’ll be doing that. I gained Daniel’s permission to blog about our discussions, I think it’s important to open up our processes deeply so people can see where they can potentially help out and become part of the thing we commonly refer to as Drupal.

As for the BDFL topic, I think it has obviously shown to work out well so far for Drupal, as for whether it’s a long-term solution well that’s also obvious to humans ;) Seriously though, I have no issues with the current situation until something proves me otherwise, I still believe we have a way to go before we are able to dissolve the fine leadership Dries provides to the community he has successfully fostered for the last fifteen-or-so years now.

Dries always seems open to discussion and is the most patient person I’ve ever met, certainly holds a role I would stress out in five minutes doing. I don’t see it working any differently for the moment at least - perhaps it would take a fork to even prove something like that. Forks are a Good Thing as they show in the long run what works and what doesn’t, providing the ultimate freedom of expression in an interdependent community such as Drupal.

Community ahoy!

As Daniel and I furthered discussion, he said something which resonated so much with me my virtual self almost shocked itself to spring into eternal existence. Sadly it didn’t, but it now has this quote emblazoned in its tiny, tiny virtual mind: “We should sell the community not the CMS.”

As an independent consultant who sometimes still writes code for certain things (only 8 commits in Drupal 8 so far though!) but works with people far better than himself in the community to deliver world-class software it’s something I’ve been doing but had not heard it in this simple, switch around way before. I invest in visiting the community and see what wonderful things they are building and his words to me, meant when you sell the CMS, you sell a product. There’s expectations put on that product often now knowing how those expectations will pan out. When you sell a community, you focus on promoting the people in that community, and as a Free Software community, provided you join in in some way, you too can benefit from the output.

Selling Freedom

Let’s just get the issues with the notion of selling Free Software - and people - out of the way. I’m not saying ‘Selling out’, just ‘selling’. Making a sale is an exchange of value between two or more parties, for example “you’ve sold it to me, I’ll use Drupal for my voluntary community project web enabled systems, thank you kindly!”.

It’s been working for me ever since I made the decision last year to not work through agencies after having to deal with yet another bad implementation of a CMS. Drupal is far greater than this, and so is my life. Since then I’ve had nothing but win/win/win results and although my cashflow has taken a dive as longer projects take time to bear fruit, it’s temporary one I'm almost out of and I’m kinda enjoying hacking on some bad code to pay the rent but even there I believe I’ve managed to turn the situation around and have an interesting offline mobile project in the pipeline. Along with the great work we’re doing with CRM (topic for another post!), it’s all about working together and supporting each other, and you don’t get that from talking about Drupal as a CMS.

As Simon Sinek says, start with the “Why?”.

As for did you miss the boat with Drupal 8? Not if you start now. Don’t wait for Drupal 8, in fact don’t use Drupal. Be part of it. Trust the community of peers and do what you can to help the project move along, and if you don’t know what that is then that is most likely a good place to start looking.

Is it that time already?

I didn’t imagine for a minute it would take this long to just describe day zero but I believe it’s of value, please do leave your thoughts in the comments below. In the next part I will move onto the workshops of the week, i.e. the ones I went to ;) This will cover why Drupal 8 Rules Configuration Management and Data Storage, manages client expectations with Behat, and why sometimes hospitals may seem a good prospect, but only if there’s air conditioning!

Oh, and a boat party and an outside grill with live music. It's not all serious talk on the shores of Lake Balaton you know ;)

tags: DrupalatonDrupal 8Planet DrupalDrupal Planet


Subscribe to Cruiskeen Consulting LLC aggregator