Drupal

Kia ora DrupalSouth - stories, insights, Drupal

Drupal Main Content - 13 December 2017 - 12:37pm

This month’s Drupal Spotlight is a Q&A snapshot from some amazing speakers and organisers behind the recent DrupalSouth in Auckland, New Zealand. We look in and beyond the code at the voices and perspectives of people  building in Drupal and influencing our community, including how they got into technology, and vision for the future.

Please note: videos of the DrupalSouth presentations will be up in the New Year - we will let you know when they are up so you can come back and watch!

Katie Graham

Code | Lego | cats (or for a second opinion) Interested | introverted | innovator

How did you get your start in technology?

As a kid I was always interested in finding out how things worked so I was obsessed with computers from when I first encountered one when I was four or five. We got dial up internet when I was about 14 and I soon figured out how to create websites, later learning PHP and MySQL. I never wanted to get paid for developing websites as I thought it might make it less fun, but a few years later I ended up doing a design degree and it was there that everything came together and I realised that development is what I should be doing. I started using Drupal in the final year of my degree and haven’t looked back!

As one of the organisers of this years DrupalSouth what is the number one tip you could give to people running Drupal events?

There were certain areas that were a lot more work than I anticipated, for example, we received so many more session submissions than we were expecting, so it was quite overwhelming.

I think it’s really important to have a solid core team organising the conference and a lot of helpers for things that need to be done closer to and during the conference. Shout out to the other organisers and everyone who helped us! I’d also say try to relax and enjoy the event itself if you can...

You are the technical director for a New Zealand web company, looking forward how do you expect to see the skill set of the people you need to hire changing over the next five years?

That’s a tricky one as it depends on the direction that technology heads in, as well as what our clients are after. These days we’re hiring people with much different skill sets than we were five years ago as we’ve moved from primarily creating websites to creating apps and business systems too, plus we’re using front end frameworks like Vue.js which didn’t exist five years ago. I think what will stay consistent is that I’ll be looking for people who want to continue learning and are happy to try new things.


DrupalSouth organising team (and @Schnitzel!) Nicole Kirsch | Dave Sparks |  Michael Schmid | Pam Clifford  | Katie Graham | Morten Kjelstrup
Rebecca Rodgers

Passionate | honest | energetic 

How did you get your start in technology?

I kind of fell into it as a HR professional, I was the only one in my team that could translate what the users needed to the tech guys so they could understand it.  That led to a post-grad in online education before moving on to designing great employee experiences.

You specialise in intranets, on day one of looking at an intranet build, what’s the most important advice you give to organisations and their staff when preparing for the journey?

Don't try to tackle too much.  Take a user centred design approach by understanding your employee needs, create a strategy that takes those needs and the needs of the organisation into account and go from there.  Let the needs and strategy drive the project rather than the technology. 

What’s a trend in intranets and adoption of digital transformation that Drupal builders should keep in mind when planning for the future platform needs?

Employees are facing more challenges than ever with the introduction of many information systems in the employee landscape which is making it harder for them to find the information they need.  It is essential to consider the whole Digital Workplace and the Digital Employee Experience which considers how employees work in the digital world rather than just looking at the intranet.

Rebecca's DrupalSouth talk was: Put the employee experience at the heart of the digital workplace

Laura Munro

Nerdy | organised | creative 

How did you get your start in technology?

I got my start in technology through a social enterprise called DesignGel. When I graduated design school in 2013 my friend Denny Ford & I took over as company directors, and along with traditional design work, I would build Wordpress sites for small businesses, teaching myself along the way. Then about 3 years later I got pinched to work at Xequals after talking at a CSS Meetup. 

At DrupalSouth you shared the site https://policy.nz. How important is it for developers to stretch their skills by taking on passion projects from time to time?

I think developers are given a bit of a hard time on this point, because we're continuously learning on the job as it is. Doing passion projects from time to time is fantastic to keep inspiring you to try new things, especially if you're getting bogged down by more boring-ish projects at work.

But I don't think developers should be expected to be coding every waking hour of their day, it makes us less productive and leads to burn out very quickly. I only work a 30 hour week at most, and it's great for productivity and my general well-being.

You are all about the front end. What is your advice on the emerging techniques or frameworks to master for the future of Drupal front end?

Get involved in the community! Drupal and front-end has a great community, in Wellington anyway. Go check out your local tech Meetups and find out what other people are getting excited about, or what their pain points are. My session at DrupalSouth featured the new CSS display properties flexbox and CSS grids, two new features in front-end that I'm really excited about.

Laura's DrupalSouth talk was: Theming Drupal in 2017: A New Hope

Kristy Devries

Sassy | passionate | conscientious 

How did you get your start in technology?
 
My whole life I have always wanted to do everything, especially when it came to creative industries. When I was young, I did not have motivation to keep pursuing hobbies, apart from playing rollercoaster tycoon (which has resulted in me now being a bit cautious around theme parks). I was around fourteen years old when I randomly decided that I wanted to learn how to make websites. So I bought two books, one on HTML and the other on PHP and spent hours everyday after school learning. I initially used my HTML and CSS knowledge to spruce up my MySpace profile page and then I bought a domain name and installed the very first version of WordPress, I did not know about Drupal back then (so sorry), and started a blog. I don’t remember what I wrote about but I remember I had random internet blogger friends, I would list their website on my site and vice versa. Those were the days. 
 
After high school, I did a year of an interdisciplinary creative industries bachelor, before deferring and spending the next few years working in hospitality and traveling around the world.  One morning, while working in a coffee shop in Europe, I decided that I wanted to pursue a career in technology. I came back to Brisbane with a plan to study and concentrate on my career. After dedicating many nights on an application, making a website resume and sending it off, revamping my website resume, sending that off again and numerous calls later, I landed a job as a junior web developer at a local agency in Brisbane - my first job in this tech industry. 

Support can be one of the toughest and sometimes even least rewarding gigs in tech, you seem to really enjoy it… why?
 
While it can certainly be tough sometimes, the people I work with are a big part of why I enjoy it. There’s a real sense of comradery, especially within Acquia Support. If you’re stuck on a puzzling problem, there’s a global group of amazing people ready to jump in to help you. And provide banter of course. 
 
I also get a chance to work on projects, for example presenting at Drupal South, as part of my role within Support. These projects can involve front end web development, user experience, design, strategy, event planning, which gives me a chance to dabble in a few areas of interest. While we do have an office in Brisbane, we have the flexibility work from home, or work remotely from another country (I spent 2 months in USA this year) so I get to travel as well as develop my career, which one of the reasons I wanted to work in the tech industry. 

All in all, I feel like working in Support is a mixture of feverishly putting out fires and being on a treasure hunt. There is definitely always something to learn, and sometimes I feel like after two years in support, I don’t know anything. However, this blend of problems means there’s never really a dull moment! 

You have leadership aspirations, what makes a good leader in the technology industry?
 
A good leader has your back. A good leader gives you challenges and enables you to grow your career. A good leader is transparent and humble. A good leader leverages the frustrations of the team and customers and finds ways to turn that into solutions. A good leader hires the right people because he/she knows that having good coworkers is important for creating a fun and supportive culture. 
 

Kristy's DrupalSouth talk was: How to be a self rescuing Princess

Laura Bell

Security | cat | herder

How did you get your start in technology?

At age 16 I found myself homeless and needing a job. My home town doesn't have many options so I applied to a junior/apprentice software role doing COBOL development. I didn't know much about computers and I'd never coded before but I needed a job and this looked like it had a future (hehe irony). I then went on to study AI and work a range of software and operations jobs before ending up in Security.

You attended DrupalGov in Washington DC this year, what was your main takeaway?

That the challenges we all face require a community to solve them. No single vendor or product can keep us safe or solve our needs so we need to start working together with authenticity and openness.

Looking forward, what’s a piece of security advice or insight Drupal developers and site builders should be thinking about?

80% of our problems can be solved by fixing 20% of our vulnerabilities in security. Pick simple behaviours and changes and try and change them one after another.... it soon adds up. 

Laura's DrupalSouth talk was: Fear itself

Hannah Del Porto

Disciplined | organized | a little bit silly

How did you get your start in technology?

It was an accident. I needed a job in college and ended up doing front-end development to pay the rent. I actually meant to be a lawyer!

At DrupalSouth you talked about the difficulty in making changes to technology once a build is underway, considering the flexibility of Drupal what are some strategies for locking down scope?

Putting scope in writing is extremely important to make sure both sides are on the same page and have a reference for what was agreed on. In my experience there are a lot of situations where you can't lock down scope before you've started work. That's where sprints are helpful so you can review and make adjustments as early as possible.

It's also important to be as up-front as possible. If scope is not settled, be specific about what is undefined and how that may affect timeline and budget. Even for projects with a formal scope, building in a 10% budget and timeline reserve can make changes less painful for everyone.

As a Chief Operating Officer where do you think future trends will evolve over the next couple of years? And how does this shape your forward planning?

10 years ago I took an online Anatomy class which involved having a dead rat sent to my house then uploading photos of its dissected body to our class website. Every day there are new ways to have online experiences that used to require physical presence. At Brick Factory we focus on non-profits, so the future is about looking at how stakeholders interact with organizations and bringing those experiences online in ways that were previously reserved for "real life".

Hannah's DrupalSouth talk was: How to Win Friends and Influence People (on the Programming Team)

Aimee Whitcroft

Open | inquisitive | incorrigible

How did you get your start in data?

I wandered into the open data / open government space over a period of years, starting during my work with the National Institute of Water and Atmospheric Research (NIWA) and continuing through my work with GovHack NZ and various government departments and civil initiatives.

In your talk you have a slide combining open data, open gov and open source equalling civic technology. Why is civic technology important for society?

Civic technology is about "using technology to help empower the public in its dealings with government(s), though better information-generating/sharing, decision-making and accountability."  It's more than just "hacking for social good - it’s about hacking civic issues, and finding ways to directly help people."

Medium post: Why we keep going on about CivicTechTowards a more open NZ (DrupalSouth Speech notes)

If you could control the trends and data was open by default, would sort of web projects would we be building in the future?

Gosh - that's an impossible question to answer! It would totally depend on the individual communities' needs. I think a great place to look for ideas is at previous GovHack projects (govhack.org.nz and govhack.org). My request would be that technologists (and I don't just mean developers!) find ways to reach out, respectfully and responsibly, into communities - especially our most vulnerable - to ask what they need and want, and then work with them to create those products and services.

Aimee's DrupalSouth talk was: How can open source contribute to a stronger, kinder, more resilient NZ?

Heike Theis

Strangely | optimistic | human

How did you get your start in technology?

When I was about 4 years old, I took a pair of scissors and cut through the cable of my radio to see what electricity looks like. The cable was plugged in, the radio was on, and the scissors had metal handles ... it was an interesting experience. But the incident did not take away an overwhelming desire to understand how things work and to find out if you can make them better. 

During your DrupalSouth talk you shared examples of how you get customers to take control of their content. How important is it to build sites for publishers and digital marketers?

Content is language and language is communication. A site that does not allow 'communicators' to take control of the dialogue (or monologue) with their customers is not a website at all. 

You have been involved in an internal transformation and as a result your team has built a distribution, how does this approach help future proof your company's development needs?

Streamlining and consolidating coding and configuration allows every member of our teams - thinkers, planners, designers, writers, and coders - to concentrate on the ... let's call them 'special' ... features. The things that are not already part of the Distro. The boring bits vanish. E.g. how many times do you want to decide (or discuss) which buttons to show in a minimal WYSIWYG editor profile? The Distro makes this decision for you: it presents you with 11 buttons we decided we want in 'general'. 10 buttons will be right for your specific site, and you might want to remove one and add two others. Still, that leaves you with 9 buttons you don't have to think about every single time. Does that make people happy ... maybe not. But having to add 11 buttons every single time makes most people unhappy. Making people less unhappy in this industry is a big win in my book, and yes I think that helps to 'future proof our team's needs'. 

Mind, working with Distros will not work for every company, every team, or every team member. If you want to re-invent the wheel every time or only do things 'your way', this is not going to work for you. 

Heike's DrupalSouth talk was: From Content Strategy to Modular Design: Kick starting your Drupal Projects

Ruth McDavitt

He tangata | he tangata | he tangata  translation/context (or less poetic English words) Connect | inspire | facilitate

How did you get your start in technology/connecting people into technology?

I've always been a connector, but was working on the business side, helping tech companies connect with customers and global markets. 

Connecting people to technology careers evolved from that, my growing realisation that there's a huge disconnect between what people are learning & exposed to through mainstream education, and the growing need for more relevant & diverse skills to support the development of technology & enterprise & people.

In your DrupalSouth talk you were firm in the need to create opportunities for people to gain experience in technology. Why is this important?

We used to go to school to learn how to do things. with the current pace of technological change, we now have to DO things to learn about them. 

It's always been difficult to get experience without a job, and a job without experience, but the rapid change in tools, processes and technologies means that it's harder than ever for teachers to keep up. 

People (of all ages, backgrounds and experience) are creating, adapting, rejecting and inventing technology, and exposing them to the possibilities & tools is the best way I know to support them to create the future. 

What’s a future trend or opportunity that you think the Drupal community could miss out on if we don’t increase diversity and make space for new people?

Sustaining the Drupal community will only be possible through welcoming newcomers, and supporting their growth and needs. DrupalSouth was my first experience with your community and it felt very healthy! 

For the aspiring tech people I work with though, I don't know what to tell them. Are there good pathways in, for people from all walks of life? Once you're a newbie, is there support & oopportunity to grow? Do you retain diverse senior & experienced people or are they moving on? Do all people feel valued, supported & celebrated? 

I don't know the answers, but DrupalSouth felt open, welcoming, and I had great conversations with a diverse range of people. If you're thinking about these things then I reckon you're on the right track. The value of communities is the people in them, their passion and commitment for doing, sharing and making more awesomeness possible.

Ruth's DrupalSouth talk was: Developing Developers: finding & growing new tech talent

Fonda Le

Passionate | goofy | hyperempathetic 

How did you get your start in technology?

At the last minute, I changed my degree from Design to Media. After uni, I happened to fall into a web production role and (despite still having great interest in the design industry) I haven't looked back since - working in IT/Digital has offered me a variety of opportunities which I'm grateful for.

Why did you choose to talk about the benefits of being an introvert scrum master at DrupalSouth? What do you want people to realise/understand? 

To be honest, I wanted to submit something left of field so I was very surprised to find out my talk was accepted! After working for a bank where mainly extroverts were appreciated and/or promoted and after leading teams with so many introverts, I thought it'd be worth my while to look into generalisations around introversion and there's a bunch of material around on it these days. I feel like the (competent) introvert scrum master works really hard in the background and never asks for anything in return from the team or anyone really so I was keen for people to recognise this. I also wanted to highlight just how interesting the servant leader role is and how much of an influence the role has on a team.

Project management approaches change over time. Is agile here to stay or can you foresee a shift that will be needed for projects of the future as organisational capacity changes?

While agile feels like it's trendy at the minute, I don't think it's going anywhere as there are different 'flavours' that will suit different teams, projects and organisations ie. Scrum shouldn't necessarily be the go-to method for every company.

Having a range of project management methodologies allows us all to be pragmatic - we should be using an approach that makes the most sense for what we're working on (considering what sort of experience or buy-in we have from the team members, company execs, etc) and anything within that approach which doesn't have value can be discarded.

Fonda's DrupalSouth talk was: Benefits of an introvert Scrum Master

Donna Benjamin

Curious | connected | caffeinated

How did you get your start in technology?

We had an apple IIe when I was a kid, I wanted to be a hacker after seeing War Games, I was a Sysop on a couple of telnet BBSes, and I made my first webpage in 1995, I ran my own business for 20 years.  I think I was always a nerd, who loved the shiny glint of technology, so I feel blessed I managed to make it my job! I believe tech helps us change things, make them better. I know it can also be used for less wonderful stuff.  It's on all of us to harness technology's power for good.

‘Being human’ is a stream that is often popular at Drupal conferences, why is it important to focus on the human side of code and tech?

So important. So, so sooo important! Oh goodness me. Why? We make stuff for humans, we are humans. When we forget this, bad things happen.

We must always bring our humanity to the table whenever we make things, and we must acknowledge our collective fragility when we work together. Tech can be high stakes and stressful, and that sometimes brings out the worst in people, but the flipside of this is we can always practice being better humans. And we should. And we should share tips and tricks on how to do so!

You’ve been around Drupal for a while and seen some changes, if you could control the future where will Drupal be in five years’ time? How will it be being used?

Drupal has consistently led the way when it comes to democratising technology that was only available to megacorps.  I hope it continues to do that.  In 5 years time? I reckon Drupal will still be used in ways it's being used right now, just as we see sites created in 2012 still working pretty much the way they did then. But we'll also continue to innovate. Omnichannel digital experiences, extending the web beyond the browser into conversational, kinaesthetic, tactile and mindpowered UIs will stretch us all. Re-imagining content itself, and addressing the challenge of personalisation without facilitating mass surveillance will really test our mettle. The march forward for Drupal is about embracing change, empowering the community, and maintaining our careful balance of commerce and community - it's one of the things I've always thought is special about the DrupalVerse.

Donna's DrupalSouth talk was: Communication skills for everyone

Rikki Bochow

Happy | quiet | focused 

How did you get your start in technology?

I studied graphic design at uni, and always enjoyed the web class (table based html and flash) that was included. I'd applied for a range of design positions afterwards but was particularly keen on web design, so was more than happy when a small web agency called me in for an interview. Unfortunately, I didn't get the job as I didn't have the technical abilities they were after.

I went home and did some online tutorials around the kind of tech they were using, built a one page html/css (with divs!) thank you letter and sent it through, asking, if they had any work experience positions to please let me know! A couple of weeks later they called me in for work experience, which shortly turned into a full time position.

I learnt more and more development languages and started enjoying coding way more than designing.

What’s your favourite thing about the front end changes in Drupal 8 compared to 7?

Twig is probably the one that stands out the most. The fact that there is less Drupalism in the theme layer, so we could hire front end developers who didn't necessarily have Drupal experience was a huge win. I also really like the improvements made to the Asset Library system (surprise!), making adding, overriding and extending core/module and base theme css/js so easy, it's really great.

What advice do you have for a graphic designer wanting to make the leap into Drupal front end development?

Don't let anyone, ever, tell you you can't or shouldn't bother (I was often told that UX would be better for me than development and I'm glad I ignored them)! Coding is the ultimate design tool and I think that's a nice way to think about it - it's not so scary, it's just a new tool. Designing in the browser is heaps of fun, as are animations and transitions (interaction design). You'll always be a designer, you don't have to stop. The two disciplines fit so well together you'll be so much better at both for having knowledge of the other.

Rikki's DrupalSouth talk was: Front-end performance improvements with Drupal 8 Asset Libraries

Next month the Community Spotlight will pay tribute to the life an impact of valued community member J-P Stacey whom recently passed away. We invite you to use this form to share thoughts and memories of J-P for us to share.

Thanks to Dreamcoat Photography for the DrupalSouth images, visit the DrupalSouth Flickr page for more

Some scheduling conflicts mean we will be bringing you the Spotlight article for Fatima Sarah Khalid @sugaroverflow very early in the new year.

Drupal version: Drupal 8.x
Categories: Drupal

Accelerate Drupal 8 by funding a Core Committer

Drupal Main Content - 13 December 2017 - 12:44am

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

We have ambitious goals for Drupal 8, including new core features such as Workspaces (content staging) and Layout Builder (drag-and-drop blocks), completing efforts such as the Migration path and Media in core, automated upgrades, and adoption of a JavaScript framework.

I met with several of the coordinators behind these initiatives. Across the board, they identified the need for faster feedback from Core Committers, citing that a lack of Committer time was often a barrier to the initiative's progress.

We have worked hard to scale the Core Committer Team. When Drupal 8 began, it was just catch and myself. Over time, we added additional Core Committers, and the team is now up to 13 members. We also added the concept of Maintainer roles to create more specialization and focus, which has increased our velocity as well.

I recently challenged the Core Committer Team and asked them what it would take to double their efficiency (and improve the velocity of all other core contributors and core initiatives). The answer was often straightforward; more time in the day to focus on reviewing and committing patches.

Most don't have funding for their work as Core Committers. It's something they take on part-time or as volunteers, and it often involves having to make trade-offs regarding paying work or family.

Of the 13 members of the Core Committer Team, three people noted that funding could make a big difference in their ability to contribute to Drupal 8, and could therefore help them empower others:

  • Lauri 'lauriii' Eskola, Front-end Framework Manager — Lauri is deeply involved with both the Out-of-the-Box Experience and the JavaScript Framework initiatives. In his role as front-end framework manager, he also reviews and unblocks patches that touch CSS/JS/HTML, which is key to many of the user-facing features in Drupal 8.5's roadmap.
  • Francesco 'plach' Placella, Framework Manager — Francesco has extensive experience in the Entity API and multilingual initiatives, making him an ideal reviewer for initiatives that touch lots of moving parts such as API-First and Workflow. Francesco was also a regular go-to for the Drupal 8 Accelerate program due to his ability to dig in on almost any problem.
  • Roy 'yoroy' Scholten, Product Manager — Roy has been involved in UX and Design for Drupal since the Drupal 5 days. Roy's insights into usability best practices and support and mentoring for developers is invaluable on the core team. He would love to spend more time doing those things, ideally supported by a multitude of companies each contributing a little, rather than just one.

Funding a Core Committer is one of the most high-impact ways you can contribute to Drupal. If you're interested in funding one or more of these amazing contributors, please contact me and I'll get you in touch with them.

Note that there is also ongoing discussion in Drupal.org's issue queue about how to expose funding opportunities for all contributors on Drupal.org.

Categories: Drupal

Massachusetts launches Mass.gov on Drupal 8

Drupal Main Content - 6 December 2017 - 12:04am

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Earlier this year, the Commonwealth of Massachusetts launched Mass.gov on Drupal 8. Holly St. Clair, the Chief Digital Officer of the Commonwealth of Massachusetts, joined me during my Acquia Engage keynote to share how Mass.gov is making constituents' interactions with the state fast, easy, meaningful, and "wicked awesome".

Constituents at the center

Today, 76% of constituents prefer to interact with their government online. Before Mass.gov switched to Drupal it struggled to provide a constituent-centric experience. For example, a student looking for information on tuition assistance on Mass.gov would have to sort through 7 different government websites before finding relevant information.

To better serve residents, businesses and visitors, the Mass.gov team took a data-driven approach. After analyzing site data, they discovered that 10% of the content serviced 89% of site traffic. This means that up to 90% of the content on Mass.gov was either redundant, out-of-date or distracting. The digital services team used this insight to develop a site architecture and content strategy that prioritized the needs and interests of citizens. In one year, the team at Mass.gov moved a 15-year-old site from a legacy CMS to Drupal.

The team at Mass.gov also incorporated user testing into every step of the redesign process, including usability, information architecture and accessibility. In addition to inviting over 330,000 users to provide feedback on the pilot site, the Mass.gov team partnered with the Perkins School for the Blind to deliver meaningful accessibility that surpasses compliance requirements. This approach has earned Mass.gov a score of 80.7 on the System Usability Scale; 12 percent higher than the reported average.

Open from the start

As an early adopter of Drupal 8, the Commonwealth of Massachusetts decided to open source the code that powers Mass.gov. Everyone can see the code that make Mass.gov work, point out problems, suggest improvements, or use the code for their own state. It's inspiring to see the Commonwealth of Massachusetts fully embrace the unique innovation and collaboration model inherent to open source. I wish more governments would do the same!

Congratulations Mass.gov

The new Mass.gov is engaging, intuitive and above all else, wicked awesome. Congratulations Mass.gov!

Categories: Drupal

We have 10 days to save net neutrality

Drupal Main Content - 6 December 2017 - 12:01am

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Last month, the Chairman of the Federal Communications Commission, Ajit Pai, released a draft order that would soften net neutrality regulations. He wants to overturn the restrictions that make paid prioritization, blocking or throttling of traffic unlawful. If approved, this order could drastically alter the way that people experience and access the web. Without net neutrality, Internet Service Providers could determine what sites you can or cannot see.

The proposed draft order is disheartening. Millions of Americans are trying to save net neutrality; the FCC has received over 5 million emails, 750,000 phone calls, and 2 million comments. Unfortunately this public outpouring has not altered the FCC's commitment to dismantling net neutrality.

The commission will vote on the order on December 14th. We have 10 days to save net neutrality.

Although I have written about net neutrality before, I want to explain the consequences and urgency of the FCC's upcoming vote.

What does Pai's draft order say?

Chairman Pai has long been an advocate for "light touch" net neutrality regulations, and claims that repealing net neutrality will allow "the federal government to stop micromanaging the Internet".

Specifically, Pai aims to scrap the protection that classifies ISPs as common carriers under Title II of the Communications Act of 1934. Radio and phone services are also protected under Title II, which prevents companies from charging unreasonable rates or restricting access to services that are critical to society. Pai wants to treat the internet differently, and proposes that the FCC should simply require ISPs "to be transparent about their practices". The responsibility of policing ISPs would also be transferred to the Federal Trade Commission. Instead of maintaining the FCC's clear-cut and rule-based approach, the FTC would practice case-by-case regulation. This shift could be problematic as a case-by-case approach could make the FTC a weak consumer watchdog.

The consequences of softening net neutrality regulations

At the end of the day, frail net neutrality regulations mean that ISPs are free to determine how users access websites, applications and other digital content.

It is clear that depending on ISPs to be "transparent" will not protect against implementing fast and slow lanes. Rolling back net neutrality regulations means that ISPs could charge website owners to make their website faster than others. This threatens the very idea of the open web, which guarantees an unfettered and decentralized platform to share and access information. Gravitating away from the open web could create inequity in how communities share and express ideas online, which would ultimately intensify the digital divide. This could also hurt startups as they now have to raise money to pay for ISP fees or fear being relegated to the "slow lane".

The way I see it, implementing "fast lanes" could alter the technological, economic and societal impact of the internet we know today. Unfortunately it seems that the chairman is prioritizing the interests of ISPs over the needs of consumers.

What can you can do today

Chairman Pai's draft order could dictate the future of the internet for years to come. In the end, net neutrality affects how people, including you and me, experience the web. I've dedicated both my spare time and my professional career to the open web because I believe the web has the power to change lives, educate people, create new economies, disrupt business models and make the world smaller in the best of ways. Keeping the web open means that these opportunities can be available to everyone.

If you're concerned about the future of net neutrality, please take action. Share your comments with the U.S. Congress and contact your representatives. Speak up about your concerns with your friends and colleagues. Organizations like The Battle for the Net help you contact your representatives — it only takes a minute!

Now is the time to stand up for net neutrality: we have 10 days and need everyone's help.

Categories: Drupal

Holistic Collaboration

Drupal Main Content - 2 December 2017 - 4:44am

The following blog was written by Drupal Association Premium Supporting Partner, Wunder Group.

For the past couple of years I have been talking about the holistic development and operations environments at different camps. As this year’s highlight,  I gave  a session in DrupalCon Vienna around that same topic. The main focus of my talk has been on the improvement opportunities offered by a holistic approach, but there is another important aspect I’d like to introduce: The collaboration model.

Every organization has various experts for different subject matters. Together these experts can create great things. As the saying goes “the whole is more than the sum of its parts”, which means there is more value generated when those experts work together, than from what they would individually produce. This however, is easier said than done. 

These experts have usually worked within their own specific domains and for others their work might seem obscure. It’s easy to perceive them as “they’re doing some weird voodoo” while not realizing that others might see your work in your own domain the same way. Even worse, we raise our craft above all others and we look down at those who do not excel in our domain.

How IT people see each other:

But each competence is equally important. You can’t ignore one part and focus on the other. The whole might be greater than the sum of its parts, but the averages do factor in. Let's take for example a fictional project. Sales people do great job getting the project in, upselling a great design. The design team delivers and it gets even somehow implemented, but nobody remembered to consult the sysops. Imagine apple.com, the pinnacle of web design, but launched on this:
 


(Sorry for the potato quality).
 

Everything needs to be in balance. The real value added is not in the work everybody does individually, but in what falls in between. We need to fill those caps with cooperation to get the best value out of the work. 

So how do you find the balance?

The key to find balance and to get the most out of the group of experts is communication and collaboration. There needs to be active involvement from every part of the organization right from the start to make sure nothing is left unconsidered. The communication needs to stay active throughout the whole project. It is important to speak the same language. I know it’s easy to start talking in domain jargon. And every single discipline has their own. The terms might be clear to you, but remember that the other party might not have ever heard of it. So pay attention to the terms you use. 

“Let's set the beresp ttl down to 60s when the request header has the cache-tag set for all the bereq uris matching /api/ endpoint before passing it to FastCGI” - Space Talk

Instead of looking down to each other we should see others like they see themselves. Respect both their knowledge and the importance of their domain.

How IT people should see each other: 
(Sysadmins: not because we like to flip at everybody, but because Linus, the guy who can literally change the source code of the real world Matrix, the Web.)
 

Everybody needs to acknowledge the goal and work towards it together. Not just focus on their own area but also make sure their work is compatible with that of others. There needs to be a shared communications channel where everyone can reach each other. It should also be possible to communicate directly to those people who know best without having any hierarchy to go through. The flat organization structure doesn’t only mean you can contact higher ups directly, but also that you can contact any individual from different area of expertise directly.

By collaboration you can also eliminate redundancies. It can be so that there are different units doing overlapping work, both with their own ways. Or there could be a team that is doing the work falling in between two other teams. A good example of this is the devops team. Only in a very large organization there is probably enough work to actually have a dedicated team taking care of that work. As devops need to know something about both the development and the operations side they need to be experts on multiple areas. Still there are project specific stuff they need to adjust. This means communication between the development and devops team. Likewise this same information needs to be passed to sysops team. The chain could be even longer, but it’s already easy to play a chinese whispers, or telephone, over such a short distance. And there is probably nothing devs and ops couldn’t do together when communicating directly and working together to fill those gaps. 

Working together, not only to get things done, but also to understand each other gives a lot of benefits with a small work. Building silos and only doing improvement inside them will only widen the cap and all the benefits gained from such improvements will disappear when you need to start filling the gaps between them. Now, go and find a way to do something better together!

Written by Janne Koponen.

Categories: Drupal

An update on the Workflow Initiative for Drupal 8.4/8.5

Drupal Main Content - 23 November 2017 - 1:57am

This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Over the past weeks I have shared an update on the Media Initiative and an update on the Layout Initiative. Today I wanted to give an update on the Workflow Initiative.

Creating great software doesn't happen overnight; it requires a desire for excellence and a disciplined approach. Like the Media and Layout Initiatives, the Workflow Initiative has taken such an approach. The disciplined and steady progress these initiative are making is something to be excited about.

8.4: The march towards stability

As you might recall from my last Workflow Initiative update, we added the Content Moderation module to Drupal 8.2 as an experimental module, and we added the Workflows module in Drupal 8.3 as well. The Workflows module allows for the creation of different publishing workflows with various states (e.g. draft, needs legal review, needs copy-editing, etc) and the Content Moderation module exposes these workflows to content authors.

As of Drupal 8.4, the Workflows module has been marked stable. Additionally, the Content Moderation module is marked beta in Drupal 8.4, and is down to two final blockers before marking stable. If you want to help with that, check out the Content Moderation module roadmap.

8.4: Making more entity types revisionable

To advance Drupal's workflow capabilities, more of Drupal's entity types needed to be made "revisionable". When content is revisionable, it becomes easier to move it through different workflow states or to stage content. Making more entity types revisionable is a necessary foundation for better content moderation, workflow and staging capabilities. But it was also hard work and took various people over a year of iterations — we worked on this throughout the Drupal 8.3 and Drupal 8.4 development cycle.

When working through this, we discovered various adjacent bugs (e.g. bugs related to content revisions and translations) that had to be worked through as well. As a plus, this has led to a more stable and reliable Drupal, even for those who don't use any of the workflow modules. This is a testament to our desire for excellence and disciplined approach.

8.5+: Looking forward to workspaces

While these foundational improvements in Drupal 8.3 and Drupal 8.4 are absolutely necessary to enable better content moderation and content staging functionality, they don't have much to show for in terms of user experience changes. Now a lot of this work is behind us, the Workflow Initiative changed its focus to stabilizing the Content Moderation module, but is also aiming to bring the Workspace module into Drupal core as an experimental module.

The Workspace module allows the creation of multiple environments, such as "Staging" or "Production", and allows moving collections of content between them. For example, the "Production" workspace is what visitors see when they visit your site. Then you might have a protected "Staging" workspace where content editors prepare new content before it's pushed to the Production workspace.

While workflows for individual content items are powerful, many sites want to publish multiple content items at once as a group. This includes new pages, updated pages, but also changes to blocks and menu items — hence our focus on making things like block content and menu items revisionable. 'Workspaces' group all these individual elements (pages, blocks and menus) into a logical package, so they can be prepared, previewed and published as a group. This is one of the most requested features and will be a valuable differentiator for Drupal. It looks pretty slick too:

An outside-in design that shows how content creators could work in different workspaces. When you're building out a new section on your site, you want to preview your entire site, and publish all the changes at once. Designed by Jozef Toth at Pfizer.

I'm impressed with the work the Workflow team has accomplished during the Drupal 8.4 cycle: the Workflow module became stable, the Content Moderation module improved by leaps and bounds, and the under-the-hood work has prepared us for content staging via Workspaces. In the process, we've also fixed some long-standing technical debt in the revisions and translations systems, laying the foundation for future improvements.

Special thanks to Angie Byron for contributions to this blog post and to Dick Olsson, Tim Millwood and Jozef Toth for their feedback during the writing process.

Categories: Drupal

An update on the Layout Initiative for Drupal 8.4/8.5

Drupal Main Content - 16 November 2017 - 12:39am

This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Now Drupal 8.4 is released, and Drupal 8.5 development is underway, it is a good time to give an update on what is happening with Drupal's Layout Initiative.

8.4: Stable versions of layout functionality

Traditionally, site builders have used one of two layout solutions in Drupal: Panelizer and Panels. Both are contributed modules outside of Drupal core, and both achieved stable releases in the middle of 2017. Given the popularity of these modules, having stable releases closed a major functionality gap that prevented people from building sites with Drupal 8.

8.4: A Layout API in core

The Layout Discovery module added in Drupal 8.3 core has now been marked stable. This module adds a Layout API to core. Both the aforementioned Panelizer and Panels modules have already adopted the new Layout API with their 8.4 release. A unified Layout API in core eliminates fragmentation and encourages collaboration.

8.5+: A Layout Builder in core

Today, Drupal's layout management solutions exist as contributed modules. Because creating and building layouts is expected to be out-of-the-box functionality, we're working towards adding layout building capabilities to Drupal core.

Using the Layout Builder, you start by selecting predefined layouts for different sections of the page, and then populate those layouts with one or more blocks. I showed the Layout Builder in my DrupalCon Vienna keynote and it was really well received:

8.5+: Use the new Layout Builder UI for the Field Layout module

One of the nice improvements that went in Drupal 8.3 was the Field Layout module, which provides the ability to apply pre-defined layouts to what we call "entity displays". Instead of applying layouts to individual pages, you can apply layouts to types of content regardless of what page they are displayed on. For example, you can create a content type 'Recipe' and visually lay out the different fields that make up a recipe. Because the layout is associated with the recipe rather than with a specific page, recipes will be laid out consistently across your website regardless of what page they are shown on.

The basic functionality is already included in Drupal core as part of the experimental Fields Layout module. The goal for Drupal 8.5 is to stabilize the Fields Layout module, and to improve its user experience by using the new Layout Builder. Eventually, designing the layout for a recipe could look like this:

Layouts remains a strategic priority for Drupal 8 as it was the second most important site builder priority identified in my 2016 State of Drupal survey, right behind Migrations. I'm excited to see the work already accomplished by the Layout team, and look forward to seeing their progress in Drupal 8.5! If you want to help, check out the Layout Initiative roadmap.

Special thanks to Angie Byron for contributions to this blog post, to Tim Plunkett and Kris Vanderwater for their feedback during the writing process, and to Emilie Nouveau for the screenshot and video contributions.

Categories: Drupal

An update on the Media Initiative for Drupal 8.4/8.5

Drupal Main Content - 10 November 2017 - 11:49pm

This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

In my blog post, "A plan for media management in Drupal 8", I talked about some of the challenges with media in Drupal, the hopes of end users of Drupal, and the plan that the team working on the Media Initiative was targeting for future versions of Drupal 8. That blog post is one year old today. Since that time we released both Drupal 8.3 and Drupal 8.4, and Drupal 8.5 development is in full swing. In other words, it's time for an update on this initiative's progress and next steps.

8.4: a Media API in core

Drupal 8.4 introduced a new Media API to core. For site builders, this means that Drupal 8.4 ships with the new Media module (albeit still hidden from the UI, pending necessary user experience improvements), which is an adaptation of the contributed Media Entity module. The new Media module provides a "base media entity". Having a "base media entity" means that all media assets — local images, PDF documents, YouTube videos, tweets, and so on — are revisable, extendable (fieldable), translatable and much more. It allows all media to be treated in a common way, regardless of where the media resource itself is stored. For end users, this translates into a more cohesive content authoring experience; you can use consistent tools for managing images, videos, and other media rather than different interfaces for each media type.

8.4+: porting contributed modules to the new Media API

The contributed Media Entity module was a "foundational module" used by a large number of other contributed modules. It enables Drupal to integrate with Pinterest, Vimeo, Instagram, Twitter and much more. The next step is for all of these modules to adopt the new Media module in core. The required changes are laid out in the API change record, and typically only require a couple of hours to complete. The sooner these modules are updated, the sooner Drupal's rich media ecosystem can start benefitting from the new API in Drupal core. This is a great opportunity for intermediate contributors to pitch in.

8.5+: add support for remote video in core

As proof of the power of the new Media API, the team is hoping to bring in support for remote video using the oEmbed format. This allows content authors to easily add e.g. YouTube videos to their posts. This has been a long-standing gap in Drupal's out-of-the-box media and asset handling, and would be a nice win.

8.6+: a Media Library in core

The top two requested features for the content creator persona are richer image and media integration and digital asset management.

The results of the State of Drupal 2016 survey show the importance of the Media Initiative for content authors.

With a Media Library content authors can select pre-existing media from a library and easily embed it in their posts. Having a Media Library in core would be very impactful for content authors as it helps with both these feature requests.

During the 8.4 development cycle, a lot of great work was done to prototype the Media Library discussed in my previous Media Initiative blog post. I was able to show that progress in my DrupalCon Vienna keynote:

The Media Library work uses the new Media API in core. Now that the new Media API landed in Drupal 8.4 we can start focusing more on the Media Library. Due to bandwidth constraints, we don't think the Media Library will be ready in time for the Drupal 8.5 release. If you want to help contribute time or funding to the development of the Media Library, have a look at the roadmap of the Media Initiative or let me know and I'll get you in touch with the team behind the Media Initiative.

Special thanks to Angie Byron for contributions to this blog post and to Janez Urevc, Sean Blommaert, Marcos Cano Miranda, Adam G-H and Gábor Hojtsy for their feedback during the writing process.

Categories: Drupal

5 Steps to Get Your Drupal Site Multilingual Ready

Drupal Main Content - 2 November 2017 - 4:43am

The following blog was written by Drupal Association Premium Technology Partner, Lingotek.

Everyone is jumping on the localization bandwagon because it’s dawning on enterprises everywhere that creating site content in a customer’s language is one way to personalize their experience and improve engagement. That means more organizations are going to prioritize making their Drupal websites multilingual, so we’ve created a handy checklist to help you get ready.

From Module Mayhem to Built-in Language Support

Drupal 7 is a very stable and well-used content management platform and it supports a vast array of modules, but it wasn’t built with multilingual in mind. Making a Drupal 7 site multilingual can be a time-intensive process for developers. To address this issue, the Drupal community went to work to rebuild language support. Drupal 8 was created to understand language from the beginning. Custom or contributed modules or themes don’t have to understand language support--it’s already built in.

Drupal 8 is a great platform to work with, not only because it is so multilingual capable out-of-the-box, but also because you can easily expand while maintaining the translatability of your data. The Drupal 8 multilingual core paves the way for more automation, more seamless workflows, and better publication management.

Whether you use Drupal 7 or Drupal 8, every Drupal developer who works with contributed or custom modules designed for multilingual or non-English sites needs to know how to build the best integration possible.

To make your path to global engagement and localization easier, we’ve created a checklist for getting your Drupal site multilingual ready in five steps.

Step 1: Understand Your Site

First step in your multilingual prep is to understand your site! Take a look at your customizations, nodes, fields, and modules so you have an idea of the size and scope of your multilingual prep. Let’s be honest though, most of us will never really know our sites completely. But that doesn’t mean you shouldn’t try. Start your multilingual readiness by taking a look at your theme, content, and modules.

Step 2: Examine Your Theme

Next step, review any customizations you have. Make sure all strings are wrapped in a t() function. You need to ensure both your base and sub-themes are multilingual ready. It helps if you use a well-established, multilingual-ready base theme like Zen, BootStrap3, etc.

Step 3: Think About Your Content

Figure out how many nodes are on your site and familiarize yourself with how and where they are used. Find out how many different content types you have and make note of diverse custom fields. The more types of content, the more complex your site translation will be. It’s also important to know how many languages are currently on the site, so check your node language settings. If they aren’t set up correctly, it can lead to translation barriers down the road.

Step 4: Rein In Your Modules

Find out how many modules are installed on your site. For multilingual, the fewer modules installed, the better! When it comes to contributed modules, you’ve got to rein them in. Too many modules can compromise functionality and interfere with site translation. Limit your modules to those that you really need and use. It’s best to have as few as you can (under 200). Be sure to code review your custom modules to ensure all strings are properly wrapped in t() functions.

Step 5: Examine Potential Trouble Spots

There are some additional areas that have the potential to become trouble spots. They may not affect large portions of your site, but it’s good to know where you might run into issues. Take a moment to inspect the following areas to ensure your Drupal site’s multilingual readiness:

  • URL Aliases
  • Taxonomy Terms
  • Blocks
  • Fieldable Panels Panes
  • Mini-panels
  • Groups
  • Views

Every Drupal developer who works with contributed or custom modules designed for multilingual or non-English sites needs to know how to build the best integration possible. It’s also good for Drupal themers who want to make their theme templates translation-ready and for those who want to know how to build Drupal multilingual support for modules, themes, and distributions. By doing a little upfront prep, and following this short 5-step checklist, you will be ready to join the legions who are making the switch to multilingual.

Learn more about integrating translation in your site, check out the Lingotek - Inside Drupal Module.

Written by Calvin Scharffs

Categories: Drupal

Community Spotlight: Rwandan enthusiasm for Drupal causes big challenge

Drupal Main Content - 19 October 2017 - 3:00am

For Ildephonse Bikino (bikilde) of Rwanda, it was supposed to be an uneventful Drupal Global Training Day call-out; he expected 50 people but he got 388!

Bikino began working to get local interest in Drupal, sharing information by creating a simple website and posting information about the trainings on groups.drupal.org and sharing it locally.

Hoping to reach the room capacity of 50 people, the registrations came flowing in.

“The venue, which is kLab, where I was expecting to run my first training, they only accommodate 50 people. And the channel I used to announce the training, I was not expecting too many people attending, but people ...shared my communication to different channels and in so many different ways. I was surprised to get more than 388 applications.”

How do you deal with the logistics of training 388 people? That’s hard! Bikino was committed to the challenge. One session became eight over a number of weekends. Bikino made sure everyone got the opportunity to attend!

Discovering Drupal

Bikino's start with Drupal began commonly enough; through his job. Like many small teams, staff get mixed roles and he inherited the website role. His experience grew from there. In 2016 he had the opportunity to attend DrupalCon New Orleans via scholarship through the Drupal Association. This let him discover the global opportunities and connections that open source software and the Drupal community can provide.

“My interest [in going to DrupalCon New Orleans] was to learn how thousands of people can just work together to deliver one single platform, how it works, and how people can really do it as volunteering work and through contributions. [The experience left me feeling that] I could really share that culture and community with young Rwandan people… and how they can love what they are doing this much. That’s where my inspiration came from.”

Bikino says technology offers more than just jobs, it provides local activities, ways to collaborate, and a chance to build knowledge. He plans to create a platform for the Rwanda Drupal community to share skills, projects, opportunities and experience.

Moving Forward

The local support for the Drupal Global Training Day is a sign of changing times in Rwanda. Those attending the training are educated, but there can be a lack of connection between what they are learning in school and the outside market. Bikino wants to connect those gaps by creating opportunities to learn, build, and develop. Like many countries across the globe, the Rwandan government sees technology as a way to build economic diversity, nurture jobs, and transform the country.

Local Projects

The Rwanda Information and Communication Association (RICTA) and partners launched The 1K Websites project, to promote Local Content Hosting. For now most of the websites made are Government, but they are expanding the project. With good internet infrastructure already in place, this is the start of local content creation and websites for business and community..

Diversity in the community is going to be a challenge, but Bikino realises it’s an important one. The Sustainable Development Goals 5 is “achieve gender equality and empower women and girls”, and access to technology in developing countries such as Rwanda is important for sustainability. Bikino is actively working with kLab management to find funds to develop opportunities for women in technology.

The Future

The last group of the 388 people have just gone through their training. The aim now is to develop local freelancers, do projects within the community, and find mentors to share tips, guidance and best practices. The group would even like to contribute to translating Drupal into the local language (Kinyarwanda). And of course one day, host an African DrupalCon.

Peel away the layers of an impressive attendance to a Drupal Global Training Day event, and you have a story about the potential for technology and Drupal to transform people, communities and industry.

You can follow and connect with Bikino via Twitter or say hi to him in the Drupal Slack. Bikino is the Deputy Director for ICT in Education Projects with FHI 360.

Next Spotlight?

Our next spotlight will be Fatima Sarah Khalid who you may recognise as @sugaroverflow. To those watching DrupalConEur from twitter it looked like no one had more fun than her! Fatima is going to be interviewed by Nikki Stevens who you may recognise as @drnikki. We think it’s going to be very cool.

We are also going to have our new Drupal Spotlight site up very soon. We have big ideas!

Categories: Drupal

Drupal looking to adopt React

Drupal Main Content - 12 October 2017 - 1:05am

This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Last week at DrupalCon Vienna, I proposed adding a modern JavaScript framework to Drupal core. After the keynote, I met with core committers, framework managers, JavaScript subsystem maintainers, and JavaScript experts in the Drupal community to discuss next steps. In this blog post, I look back on how things have evolved, since the last time we explored adding a new JavaScript framework to Drupal core two years ago, and what we believe are the next steps after DrupalCon Vienna.

As a group, we agreed that we had learned a lot from watching the JavaScript community grow and change since our initial exploration. We agreed that today, React would be the most promising option given its expansive adoption by developers, its unopinionated and component-based nature, and its well-suitedness to building new Drupal interfaces in an incremental way. Today, I'm formally proposing that the Drupal community adopt React, after discussion and experimentation has taken place.

Two years ago, it was premature to pick a JavaScript framework

Three years ago, I developed several convictions related to "headless Drupal" or "decoupled Drupal". I believed that:

  1. More and more organizations wanted a headless Drupal so they can use a modern JavaScript framework to build application-like experiences.
  2. Drupal's authoring and site building experience could be improved by using a more modern JavaScript framework.
  3. JavaScript and Node.js were going to take the world by storm and that we would be smart to increase the amount of JavaScript expertise in our community.

(For the purposes of this blog post, I use the term "framework" to include both full MV* frameworks such as Angular, and also view-only libraries such as React combined piecemeal with additional libraries for managing routing, states, etc.)

By September 2015, I had built up enough conviction to write several long blog posts about these views (post 1, post 2, post 3). I felt we could accomplish all three things by adding a JavaScript framework to Drupal core. After careful analysis, I recommended that we consider React, Ember and Angular. My first choice was Ember, because I had concerns about a patent clause in Facebook's open-source license (since removed) and because Angular 2 was not yet in a stable release.

At the time, the Drupal community didn't like the idea of picking a JavaScript framework. The overwhelming reactions were these: it's too early to tell which JavaScript framework is going to win, the risk of picking the wrong JavaScript framework is too big, picking a single framework would cause us to lose users that favor other frameworks, etc. In addition, there were a lot of different preferences for a wide variety of JavaScript frameworks. While I'd have preferred to make a bold move, the community's concerns were valid.

Focusing on Drupal's web services instead

By May of 2016, after listening to the community, I changed my approach; instead of adding a specific JavaScript framework to Drupal, I decided we should double down on improving Drupal's web service APIs. Instead of being opinionated about what JavaScript framework to use, we would allow people to use their JavaScript framework of choice.

I did a deep dive on the state of Drupal's web services in early 2016 and helped define various next steps (post 1, post 2, post 3). I asked a few of the OCTO team members to focus on improving Drupal 8's web services APIs; funded improvements to Drupal core's REST API, as well as JSON API, GraphQL and OpenAPI; supported the creation of Waterwheel projects to help bootstrap an ecosystem of JavaScript front-end integrations; and most recently supported the development of Reservoir, a Drupal distribution for headless Drupal. There is also a lot of innovation coming from the community with lots of work on the Contenta distribution, JSON API, GraphQL, and more.

The end result? Drupal's web service APIs have progressed significantly the past year. Ed Faulkner of Ember told us: "I'm impressed by how fast Drupal made lots of progress with its REST API and the JSON API contrib module!". It's a good sign when a core maintainer of one of the leading JavaScript frameworks acknowledges Drupal's progress.

The current state of JavaScript in Drupal

Looking back, I'm glad we decided to focus first on improving Drupal's web services APIs; we discovered that there was a lot of work left to stabilize them. Cleanly integrating a JavaScript framework with Drupal would have been challenging 18 months ago. While there is still more work to be done, Drupal 8's available web service APIs have matured significantly.

Furthermore, by not committing to a specific framework, we are seeing Drupal developers explore a range of JavaScript frameworks and members of multiple JavaScript framework communities consuming Drupal's web services. I've seen Drupal 8 used as a content repository behind Angular, Ember, React, Vue, and other JavaScript frameworks. Very cool!

There is a lot to like about how Drupal's web service APIs matured and how we've seen Drupal integrated with a variety of different frameworks. But there is also no denying that not having a JavaScript framework in core came with certain tradeoffs:

  1. It created a barrier for significantly leveling up the Drupal community's JavaScript skills. In my opinion, we still lack sufficient JavaScript expertise among Drupal core contributors. While we do have JavaScript experts working hard to maintain and improve our existing JavaScript code, I would love to see more experts join that team.
  2. It made it harder to accelerate certain improvements to Drupal's authoring and site building experience.
  3. It made it harder to demonstrate how new best practices and certain JavaScript approaches could be leveraged and extended by core and contributed modules to create new Drupal features.

One trend we are now seeing is that traditional MV* frameworks are giving way to component libraries; most people seem to want a way to compose interfaces and interactions with reusable components (e.g. libraries like React, Vue, Polymer, and Glimmer) rather than use a framework with a heavy focus on MV* workflows (e.g. frameworks like Angular and Ember). This means that my original recommendation of Ember needs to be revisited.

Several years later, we still don't know what JavaScript framework will win, if any, and I'm willing to bet that waiting two more years won't give us any more clarity. JavaScript frameworks will continue to evolve and take new shapes. Picking a single one will always be difficult and to some degree "premature". That said, I see React having the most momentum today.

My recommendations at DrupalCon Vienna

Given that it's been almost two years since I last suggested adding a JavaScript framework to core, I decided to talk bring the topic back in my DrupalCon Vienna keynote presentation. Prior to my keynote, there had been some renewed excitement and momentum behind the idea. Two years later, here is what I recommended we should do next:

  • Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.
  • Embrace all JavaScript frameworks for building Drupal-powered applications. We should give developers the flexibility to use their JavaScript framework of choice when building front-end applications on top of Drupal — so they can use the right tool for the job. The fact that you can front Drupal with Ember, Angular, Vue, React, and others is a great feature. We should also invest in expanding the Waterwheel ecosystem so we have SDKs and references for all these frameworks.
  • Pick a framework for Drupal's own administrative user interfaces. Drupal should pick a JavaScript framework for its own administrative interface. I'm not suggesting we abandon our stable base of PHP code; I'm just suggesting that we leverage JavaScript for the things that JavaScript is great at by moving relevant parts of our code from PHP to JavaScript. Specifically, Drupal's authoring and site building experience could benefit from user experience improvements. A JavaScript framework could make our content modeling, content listing, and configuration tools faster and more application-like by using instantaneous feedback rather than submitting form after form. Furthermore, using a decoupled administrative interface would allow us to dogfood our own web service APIs.
  • Let's start small by redesigning and rebuilding one or two features. Instead of rewriting the entirety of Drupal's administrative user interfaces, let's pick one or two features, and rewrite their UIs using a preselected JavaScript framework. This allows us to learn more about the pros and cons, allows us to dogfood some of our own APIs, and if we ultimately need to switch to another JavaScript framework or approach, it won't be very painful to rewrite or roll the changes back.
Selecting a JavaScript framework for Drupal's administrative UIs

In my keynote, I proposed a new strategic initiative to test and research how Drupal's administrative UX could be improved by using a JavaScript framework. The feedback was very positive.

As a first step, we have to choose which JavaScript framework will be used as part of the research. Following the keynote, we had several meetings at DrupalCon Vienna to discuss the proposed initiative with core committers, all of the JavaScript subsystem maintainers, as well as developers with real-world experience building decoupled applications using Drupal's APIs.

There was unanimous agreement that:

  1. Adding a JavaScript framework to Drupal core is a good idea.
  2. We want to have sufficient real-use experience to make a final decision prior to 8.6.0's development period (Q1 2018). To start, the Watchdog page would be the least intrusive interface to rebuild and would give us important insights before kicking off work on more complex interfaces.
  3. While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.
  4. This adoption should be carried out in a limited and incremental way so that the decision is easily reversible if better approaches come later on.

We created an issue on the Drupal core queue to discuss this more.

Conclusion

Drupal should support a variety of JavaScript libraries on the user-facing front end while relying on a single shared framework as a standard across Drupal administrative interfaces.

In short, I continue to believe that adopting more JavaScript is important for the future of Drupal. My original recommendation to include a modern JavaScript framework (or JavaScript libraries) for Drupal's administrative user interfaces still stands. I believe we should allow developers to use their JavaScript framework of choice to build front-end applications on top of Drupal and that we can start small with one or two administrative user interfaces.

After meeting with core maintainers, JavaScript subsystem maintainers, and framework managers at DrupalCon Vienna, I believe that React is the right direction to move for Drupal's administrative interfaces, but we encourage everyone in the community to discuss our recommendation. Doing so would allow us to make Drupal easier to use for site builders and content creators in an incremental and reversible way, keep Drupal developers' skills relevant in an increasingly JavaScript-driven world, move us ahead with modern tools for building user interfaces.

Special thanks to Preston So for contributions to this blog post and to Matt Grill, Wim Leers, Jason Enter, Gábor Hojtsy, and Alex Bronstein for their feedback during the writing process.

Categories: Drupal

Progress on the Salesforce Suite for D8 and a Call for Participation

Drupal Main Content - 10 October 2017 - 3:21am

The following blog was written by Drupal Association Premium Supporting Partner, Message Agency.

After months of work, hundreds of commits, and lots of new thinking, the Salesforce Suite for Drupal 8 is reaching maturity.  There is tremendous interest in these modules, and many enterprises are waiting for this milestone to integrate D8 sites with Salesforce. In an effort to accelerate refinement and adoption of this important contribution, the module’s developers are raising awareness about the release and asking the community to start downloading and contributing.

A few months ago at Drupalcon Baltimore, Message Agency announced a release candidate (8.x-3.0-rc1) for the Salesforce Suite in Drupal 8.  This collection of modules supports integration with Salesforce by mapping Drupal entities with standard or custom Salesforce objects and pushing Drupal data to Salesforce as well as pulling Salesforce data into Drupal.

Since then, we've continued to expand the Suite and build out critical features. We've also continued to groom the 8.x roadmap, solicit community participation through webinars, and build awareness about how to use the modules. With a solid foundation and full functionality, the Suite is beginning to gain traction and see increasing adoption as projects switch to Drupal 8.

What’s new in the Suite?

The modules are a complete rewrite of the Suite for Drupal 8, and they fully leverage Drupal core’s object-oriented code patterns.  Message Agency’s senior software engineer, Aaron Bauman, was the original architect of the Suite for 6.x in 2009 and has continued to support this important tool ever since. He took the lead in porting the modules for Drupal 8, based on feedback from the community, clients, and nearly a decade of experience integrating these two powerful platforms.

There is much to be excited about in this new version. There have been a number of updates from Drupal 7.x:

  • Queue on failure. There is now an attempt to push synchronization immediately on entity save and enqueue for asynchronous push only on failure. This feature idea is a great compromise between the previous binary sync/async decision point.
  • Test coverage.  Testing 3rd-party web services can be tricky, and requires careful planning and mocking. This Salesforce 8.x release includes test coverage for push and pull operations using mock REST features, allowing for proper regression testing and test-driven development.
  • Push queue overhaul, and cron-based push.  Drupal 7's asynchronous push left a lot to be desired. Lack of error handling made debugging and troubleshooting difficult to impossible. Lack of optimizations burned unnecessary API calls. Both of these limitations were imposed by Drupal Queue API's fundamental nature. In Drupal 7, our options for extending the Queue system were limited. In Drupal 8, we've implemented a Salesforce Push Queue service, building on Drupal core's overhauled Queue API. We've taken the opportunity to normalize queue items, optimize queue operations, and implement error handling and recovery.
  • Objectification of Salesforce resources. Moving in the direction of a proper REST PHP SDK, we now have proper classes for Query Result, SObject, Salesforce ID, various REST Responses, and others. This not only allows for simple type-hinting across other classes, but also gives developers consistent and reliable interfaces, and paves the way for even greater extensibility in the future.
  • Queue settings per mapping. The Suite now allows administrators to assign sync intervals per-mapping, instead of running all sync operations on every cron run. This feature idea will allow administrators to tweak their synchronizations according to business needs, without the need to implement extensive hook-based logic.

Several new features for Drupal 8 also have been developed:

  • Goodbye hooks, hello events.  Leveraging Salesforce.api.php, we mapped old hooks onto new events—a key advantage for folks already familiar with the 7.x version.
  • A new plugin system for mapping fields.  There has been a mapping UI overhaul.  Salesforce Mapping Fields now enjoy their own plugin system, allowing for maximum extensibility. For example, "Record Type" is now its own mapping field plugin type, rather than receiving special treatment in the push and pull systems.
  • Pluggable everything. including the REST Client itself, thanks to Drupal services and Dependency Injection.  
  • Examples module.  There is now a working examples module with an event subscriber, exported mapping config, and demonstration of using the  REST client to connect to an Apex endpoint.

The new version also builds in some important re-includes from 7.x - 2.x branch.

  • Mapped Objects are tied to Mappings
  • Custom push queue
  • Re-attempt on failure
  • Encryption support
What is the current status? And how can you help?

The Suite has advanced to 8.x-3.0-rc6 and is nearing a stable release.  It’s time to start downloading and using the modules to help us identify and smooth out the rough spots.

For a quick start overview, watch this Acquia webinar, delivered by Aaron Bauman on how to install and configure the Suite.

https://youtu.be/9tKrpxW1sMk https://www.acquia.com/resources/webinars/how-use-salesforce-suite-drupal-8-quick-start-guide?r=735547932

Keep those issues coming in the queue!

The Heavy Lifting

This amount of work is never done alone.  By the numbers, so far:

  • 5 contributors including 2 Message Agency staff.  (Shout out to evanjenkins, bezhermoso, and gcb for their contributions.)
  • Merged 7 major branches.
  • More than 200 commits.
  • Nearly 400 hours logged across 5 Message Agency dev and PM staff, and 3 drupal.org users

Also, major thanks to Acquia's Drupal 8 Module Acceleration Program for connecting us with clients to fund and advance module development.

Categories: Drupal

An update on projects created for Drupal

Drupal Main Content - 7 October 2017 - 3:00pm

About six months ago we made a significant change to the way that modules, themes, and distributions are created on Drupal.org.

In the past, contributors had to first create a sandbox project, and then request manual review of their project in the Project Applications issue queue. The benefit of this community-driven moderation process was that modules were vetted for code quality and security issues by a group of volunteers. Project maintainers who completed this process also received the benefit of security advisory coverage from the Security Team for stable releases of their projects.

Unfortunately, the rate of project applications outpaced what volunteers could keep up with, and many worthy projects were never promoted to full project status, or moved off of Drupal.org to be hosted elsewhere.

To ameliorate this issue, we changed the process so that any confirmed user on Drupal.org may now make full projects.

To mitigate the risks of low code quality or security vulnerabilities we added new signals to project pages: including highlighting which release is recommended by the maintainer, displaying recent test results, and indicating whether the project receives security coverage both on the project page and in the composer 'extra' attribute. We're continuing to work on identifying additional signals of project quality that we can include, as well as surfacing some of this information in Drupal core. We also converted the project applications issue queue into a 'request security advisory coverage' issue queue.

What we hoped to see

We knew this would be a significant change for the project and the community. While many community members were excited to see the gates to contribution opened, others were concerned about security issues and Drupal's reputation for code quality.

Our prediction was that the lower barrier to contribution would result in an increase in full projects created on Drupal.org. This would indicate that new contributors or third party technology providers were finding it easier to integrate with Drupal and contribute those integrations back for use by others.

At the same time, we also expected to see an increase in the number of full projects that do not receive coverage from the security team. The question was whether this increase would be within an acceptable range, or represent a flood of low quality or insecure modules.

The results

The table below provides statistics about the full projects created on Drupal.org in the 5 months before March 17th, 2017 - when we opened the creation of full projects to all confirmed users.

Full projects created from 2016-10-16 to 2017-03-17…

#

% of projects created in this period

… without stable release

431

55.76%

… with stable releases

342

44.24%

… with usage >= 50 sites

237

30.66%

… with usage >= 50 sites and without stable release

68

8.80%

… with usage >= 50 sites and with stable release

169

21.86%

… with an open security coverage application*

18

2.33%

Sub-total with security coverage

342

44.24%

Sub-total without security coverage

431

55.76%

Sub-total with security coverage and >=50 usage

169

21.86%

Sub-total without security coverage and >= 50 usage

68

8.80%

Total

773

* note: full projects that did not have stable releases were not automatically opted in to security coverage when we opened the full project creation gates.

… and this table provides statistics about the projects created in the 5 months after we opened the creation of full projects to all confirmed users:

Full projects created from 2017-03-17 to 2017-08-16…

#

Diff

% of projects created

Diff %

… without stable release

851

+420

69.53%

+97%

… with stable releases

373

+31

30.47%

+9%

… with usage >= 50 sites

156

-81

12.75%

-34%

… with usage >= 50 sites and without stable release

64

-4

5.23%

-6%

… with usage >= 50 sites and with stable release

92

-77

7.52%

+46%

… with an open security coverage application

62

+44

5.07%

+344%

Sub-total with security coverage

182

-160

14.87%

-53%

Sub-total without security coverage

1,042

+611

85.13%

+242%

Sub-total with security coverage and >=50 usage

54

-115

4.41%

-32%

Sub-total without security coverage and >= 50 usage

102

+34

8.33%

+150%

Total

1,224

+451

+58%

As you can see, we have an almost 58% increase in the rate of full projects created on Drupal.org. We can also see a significant proportional increase in two key areas: projects with greater than 50 site usage and no security coverage(up 150% compared to the previous period), and projects that have applied for security coverage(up 344% compared to the previous period). Note: this increase in applications is for projects *created in these date ranges* not necessarily applications created overall.

This tells us that reducing friction in applying for security coverage, and encouraging project maintainers to do so should be a top priority.

Finally, this last table gives statistics about all of the projects currently on Drupal.org, regardless of creation date:

Full projects (7.x and 8.x)

#

% of Total

Rate of change after 2017-03-17

… with the ability to opt into security coverage

8,718

36.15%

-1.33%

… with security coverage and stable releases

8,377

34.74%

-1.49%

… without security coverage

15,396

63.85%

+1.33%

… without security coverage and with stable releases

464

1.92%

+1.04%

… with security coverage and >=50 usage
 

6,475

66.91 / 26.85%

-0.54%

… with security coverage and stable releases and >=50 usage

6,308

65.19 /26.16%

-0.65%

… without security coverage and >=50 usage

3,202

33.09 /13.28%

+0.54%

… without security coverage and with stable releases and >=50 usage

130

1.34 /0.54%

+0.51%

Sub-total with >=50 usage

9,677

40.13%

-1.72%

Total

24,114

From the overall data we see approximately what we might expect. The increase in growth of full projects on Drupal.org has lead to a modest increase in projects without security coverage.

Before the project application change, all full projects with stable releases received security advisory coverage. After this change, only those projects that apply for the ability to opt in(and then do so) receive coverage.

What has this meant for security coverage of projects hosted on Drupal.org?

1.92% of all full 7.x and 8.x projects have stable releases, but do not receive security advisory coverage. It is likely no accident that this translates into 464 projects, which is nearly equivalent to the number of projects additional projects added compared to our old growth rate.

Of those only 130 of those projects report more than 50 sites usage(or .54% of all 7.x and 8x full projects).

Next steps

From this analysis we can conclude the following:

  1. The opening of the project application gates has dramatically increased the number of projects contributed to Drupal.org.

  2. It has also increased the number of projects without security coverage, and the number of applications for the ability to opt in to coverage among new projects.

In consultation with the Security Working Group, we recommend the following:

  • For now, leave the project creation projects as it stands today - open to contribution from any confirmed user on Drupal.org.

    • Less than 2% of all Drupal projects with stable releases currently lack security coverage. The rate at which this is increasing is significant (and in the wrong direction) but not rapid enough to merit changing the project application policy immediately.

  • Solve the problem of too many security advisory coverage applications. The security advisory application queue has the same problem that the old project applications queue had - not enough volunteers to manually vet all of the applications - and therefore a significant backlog of project maintainers waiting on the ability to opt into coverage.

    • Recommendation: Implement an automated best practices quiz that maintainers can take in order to be granted the ability to opt into security advisory coverage. If this process is as successful as we hope, we may want to consider making this a gate on stable releases for full projects as well.

We look forward to working with the Security Working Group to implement this recommendation and continue to improve the contribution experience on Drupal.org, while preserving code quality and security.

Categories: Drupal

Drupal 8.4.0 is now available

Drupal Main Content - 5 October 2017 - 4:20am
What's new in Drupal 8.4.0?

This new version is an important milestone of stability for Drupal 8. It adds under-the-hood improvements to enable stable releases of key contributed modules for layouts, media, and calendaring. Many other core experimental modules have also become stable in this release, including modules for displaying form errors inline and managing workflows.

The release includes several very important fixes for content revision data integrity as well as an update to stop the deletion of orphaned files that was causing data loss for many sites, alongside numerous improvements for site builders and content authors.

Download Drupal 8.4.0

Important: If you use Drush to manage Drupal, be sure to update to Drush 8.1.12 or higher before updating Drupal. Updating to Drupal 8.4.0 using Drush 8.1.11 or earlier will fail. (Always test minor version updates carefully before making them live.)

Inline Form Errors

The Inline Form Errors module provides a summary of any validation errors at the top of a form and places the individual error messages next to the form elements themselves. This helps users understand which entries need to be fixed, and how. Inline Form Errors was provided as an experimental module from Drupal 8.0.0 on, but it is now stable and polished enough for production use.

Datetime Range

The Datetime Range module provides a field type that allows end dates to support contributed modules like Calendar. This stable release is backwards-compatible with the Drupal 8.3.x experimental version and shares a consistent API with other Datetime fields. Future releases may improve Views support, usability, Datetime Range field validation, and REST support.

Layout Discovery API

The Layout Discovery module provides an API for modules or themes to register layouts as well as five common layouts. Providing this API in core enables core and contributed layout solutions like Panels and Display Suite to be compatible with each other. This stable release is backwards-compatible with the 8.3.x experimental version and introduces support for per-region attributes.

Media API

The new core Media module provides an API for reusable media entities and references. It is based on the contributed Media Entity module.

Since there is a rich ecosystem of Drupal contributed modules built on Media Entity, the top priority for this release is to provide a stable core API and data model for a smoother transition for these modules. Developers and expert site builders can now add Media as a dependency. Work is underway to provide an update path for existing sites' Media Entity data and to port existing contributed modules to the refined core API.

Note that the core Media module is currently marked hidden and will not appear on the 'Extend' (module administration) page. (Enabling a contributed module that depends on the core Media module will also enable Media automatically.) The module will be displayed to site builders normally once once related user experience issues are resolved in a future release.

Similarly, the REST API and normalizations for Media are not final and support for decoupled applications will be improved in a future release.

Content authoring and site administration experience improvements

The "Save and keep (un)published" dropbutton has been replaced with a "Published" checkbox and single "Save" button. The "Save and..." dropbutton was a new design in Drupal 8, but users found it confusing, so we have restored a design that is more similar to the user interface for Drupal 7 and earlier.

Both the "Comments" administration page at `/admin/content/comment` and the "Recent log messages" report provided by dblog are now configurable views. This allows site builders to easily customize, replace or clone these screens.

Updated migrations

This release adds date and node reference support for Drupal 6 to Drupal 8 migrations. Core provides migrations for most Drupal 6 data and can be used for migrating Drupal 6 sites to Drupal 8, and the Drupal 6 to 8 migration path is nearing beta stability. Some gaps remain, such as for some internationalization data. The Drupal 7 to Drupal 8 migration is incomplete but is suitable for developers who would like to help improve the migration and can be used to test upgrades especially for simple Drupal 7 sites. Most high-priority migrations are available.

Moderation and workflows

The Workflows module is now also stable, however it only provides a framework for managing workflows and is not directly useful in itself. The experimental Content Moderation module allows workflows to be applied to content and is now at beta stability. Content moderation workflows can now apply to any entity types that support revisions, and numerous usability issues and critical bugs are resolved in this release.

Platform features for web services

Drupal 8.4 continues to expand Drupal's support for web services that benefit decoupled sites and applications, including a 15% performance improvement for authenticated REST requests, expanded REST functionality, and developer-facing improvements.

Further details are available about each area in the 8.4.0 release notes.

What does this mean for me? Drupal 8 site owners

Update to 8.4.0 to continue receiving bug and security fixes. The next bugfix release (8.4.1) is scheduled for November 1, 2017.

Updating your site from 8.3.7 to 8.4.0 with update.php is exactly the same as updating from 8.3.6 to 8.3.7. If you use Drush, be sure to update to Drush 8.1.12 or higher before using it to update Drupal 8.3.7 to 8.4.0. Drupal 8.4.0 also has major updates to several dependencies, including Symfony, jQuery, and jQuery UI. Modules, themes, and translations may need updates for these and other changes in this minor release, so test the update carefully before updating your production site.

Drupal 7 site owners

Drupal 7 is still fully supported and will continue to receive bug and security fixes throughout all minor releases of Drupal 8.

Most high-priority migrations from Drupal 7 to 8 are now available, but the migration path is still not complete, especially for multilingual sites, so you may encounter errors or missing migrations when you try to migrate. That said, since your Drupal 7 site can remain up and running while you test migrating into a new Drupal 8 site, you can help us stabilize the Drupal 7 to Drupal 8 migration path! Testing and bug reports from your real-world Drupal 7 sites will help us stabilize this functionality sooner for everyone. (Search the known issues.)

Drupal 6 site owners

Drupal 6 is not supported anymore. Create a Drupal 8 site and try migrating your data into it as soon as possible. Your Drupal 6 site can still remain up and running while you test migrating your Drupal 6 data into your new Drupal 8 site. Core now provides migrations for most Drupal 6 data, but the migrations of multilingual functionality in particular are not complete. If you find a new bug not covered by the known issues with the experimental Migrate module suite, your detailed bug report with steps to reproduce is a big help!

Translation, module, and theme contributors

Minor releases like Drupal 8.4.0 include backwards-compatible API additions for developers as well as new features. Read the 8.4.0 release notes for more details on the improvements for developers in this release.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.3.x and earlier will be compatible with 8.4.x as well. However, the new version does include some changes to strings, user interfaces, and internal APIs (as well as more significant changes to experimental modules). This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.4.0 release candidate for more background information.

Categories: Drupal

State of Drupal presentation (September 2017)

Drupal Main Content - 27 September 2017 - 10:33pm

This blog has been re-posted with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Yesterday, I shared my State of Drupal presentation at DrupalCon Vienna. In addition to sharing my slides, I wanted to provide some more detail on how Drupal is evolving, who Drupal is for, and what I believe we should focus on.

Drupal is growing and changing

I started my keynote by explaining that Drupal is growing. Over the past year, we've witnessed a rise in community engagement, which has strengthened Drupal 8 adoption.

This is supported by the 2017 Drupal Business Survey; after surveying 239 executives from Drupal agencies, we can see that Drupal 8 has become the defacto release for them and that most of the Drupal businesses report to be growing.

While the transition from Drupal 7 to Drupal 8 is not complete, Drupal 8's innovation continues to accelerate. We've seen the contributed modules ecosystem mature; in the past year, the number of stable modules has more than doubled. Additionally, there are over 4,000 modules in development.

In addition to growth, both the vendor and technology landscapes around Drupal are changing. In my keynote, I noted three primary shifts in the vendor landscape. Single blogs, portfolio sites and brochure sites, which represent the low end of the market, are best served by SaaS tools. On the other side of the spectrum, a majority of enterprise vendors are moving beyond content management into larger marketing suites. Finally, the headless CMS market segment is growing rapidly, with some vendors growing at a rate of 500% year over year.

There are also significant changes in the technology landscape surrounding Drupal, as a rising number of Drupal agencies have also started using modern JavaScript technologies. For example, more than 50% of Drupal agencies are also using Node.js to support the needs of their customers.

While evolving vendor and technology landscapes present many opportunities for Drupal, it can also introduce uncertainty. After listening to many people in the Drupal community, it's clear that all these market and technology trends, combined with the long development and adoption cycle of Drupal 8, has left some wondering what this all means for Drupal, and by extension also for them.

Drupal is no longer for simple sites

Over the past year, I've explained why I believe Drupal is for ambitious digital experiences, in both my DrupalCon Baltimore keynote and on my blog. However, I think it would be valuable to provide more detail on what I mean by "ambitious digital experiences". It's important that we all understand who Drupal is for, because it drives our strategy, which in turn allows us to focus our efforts.

Today, I believe that Drupal is no longer for simple sites. Instead, Drupal's sweetspot is sites or digital experiences that require a certain level of customization or flexibility — something I refer to as "richness".

Ambitious is much more than just enterprise

This distinction is important because I often find that the term "ambitious" becomes conflated with "enterprise". While I agree that Drupal is a great fit for the enterprise, I personally never loved that categorization. It's not just large organizations that use Drupal. Individuals, small startups, universities, museums and nonprofits can be equally ambitious in what they'd like to accomplish and Drupal can be an incredible solution for them.

An example of this could be a small business that manages 50 rental properties. While they don't have a lot of traffic (reach), they require integrations with an e-commerce system, a booking system, and a customer support tool to support their business. Their allotted budget is $50,000 or less. This company would not be considered an enterprise business; however, Drupal would be a great fit for this use case. In many ways, the "non-enterprise ambitious digital experiences" represent the majority of the Drupal ecosystem. As I made clear in my presentation, we don't want to leave those behind.

Addressing the needs of smaller organizations

The Drupal ecosystem majority are organizations with sites that require medium-to-high richness, which SaaS builders cannot support. However, they also don't need to scale at the level of enterprise companies. As the Drupal community continues to consider how we can best support this majority, a lot of smaller Drupal agencies and end-users have pointed out that they would benefit from the following two things:

  1. Powerful site building tools. They want easy-to-use site building tools that are simple to learn, and don't require dozens of contributed modules to be installed and configured. They would also prefer to avoid writing a lot of custom code because their clients have smaller budgets. Great examples of tools that would improve site building are Drupal's upcoming layout builder, workspaces and media library. To make some of Drupal's own administrative UIs more powerful and easier to use, I proposed that we add a modern JavaScript to core.
  2. Easier updates and maintenance. While each Drupal 8 site benefits from continuous innovation, it also needs to be updated more often. The new Drupal 8 release cycle has monthly patch releases and 6-month minor releases. In addition, organizations have to juggle ad-hoc updates from contributed modules. In addition, site updates has often become more complex because our dependency on third-party libraries and because not everyone can use Composer. Many smaller users and agencies would benefit tremendously from auto-updates because maintaining and updating their Drupal 8 sites can be too manual, too complex and too expensive.

The good news is that we have made progress in both improving site builder tools and simplifying updates and maintenance. Keep an eye on future blog posts about these topics. In the meantime, you can watch a recording of my keynote (starting at 22:10), or you can download a copy of my slides (56 MB).

State of Drupal keynote, DrupalCon Vienna from Dries Buytaert State of Drupal keynote, DrupalCon Vienna from Dries Buytaert
Categories: Drupal

Drupal Business Survey 2017

Drupal Main Content - 25 September 2017 - 6:02pm

The Drupal Business Survey 2017 shows that Drupal has a steady position in the market, and Drupal 8 has secured its role as the most popular version for new Drupal projects. Further, Drupal is often becoming part of a larger set of solutions.

The Drupal Business Survey is an annual survey that aims to give insights into the key issues that Drupal agency owners and company leaders worldwide face. The survey is an initiative of Exove, One Shoe and the Drupal Association and has been carried out this year for the second time. It covers topics about Drupal business in general, Drupal projects and talent needs. This article summarizes the most important findings along with commentary and insights from a total of 239 respondents.

Drupal is growing steadily

The Drupal Business Survey gleaned its data for 2017 from 239 respondents in CEO/COO/CTO/founder role (87%), director role (4.6%) or management role (4.6%), working at Drupal companies with a total of 300 offices spread around the globe. The most popular office location (30.1%) was USA. The second most popular with 12.1% was UK, and after that Germany, Netherlands, India, Canada and France. There were respondents from Africa, Asia, Europe, North America, South America and Oceania.

Analysis of the data made immediately clear that Drupal is a healthy business:

Drupal project pipeline grows

For almost half of the respondents (48.5%) the Drupal project pipeline grew within the last year. For 28.9% it stayed roughly the same, and for 22.6% the pipeline shrank.

Size of Drupal projects grows

For a majority (52.3%) of the respondents the average size of Drupal project deals grew. For about one third (31.4%) the Drupal deal size stayed roughly the same, and for only 16.3% the size of deals shrank.

Drupal’s project win rate stays roughly the same

Despite the increasing competition in the CMS market, for many (46.4%) of the companies their Drupal project win rate has stayed on the same level over the last year, and about a third (34.7%) have managed to grow their win rate. For less than a fifth of the companies (18.8%) the win rate had decreased.

Drupal’s position as a high-demand service platform is steady, especially for projects in the Charities and Non-Profit sector, which is catered to by two thirds (64.9%) of the respondents. Other popular industries that use Drupal are Government & Public Administration (56.1%) and Healthcare & Medicine (49.4%). There are no major differences in industries served by Drupal companies compared to the 2016 survey results.  

Choosing Drupal

When choosing the right platform, Drupal clients trust the technical provider’s expertise: Drupal is often chosen by the clients as a result of the provider’s recommendation. In some cases the client’s previous experience or familiarity with Drupal is the definitive factor.

Besides Drupal being open-source and free of licensing fees, the definitive reasons for choosing Drupal are that Drupal is a reliable and flexible CMS choice with a strong reputation:

Without -most often than not- being able to precisely explain the reasons for which they prefer Drupal, those who do, sense that it is a better solution for their business; we shall imagine that this is due to the image of the CMS, which evokes a more robust, and serious CMS than the others.

Can do anything. Secure.

Choosing the company

When Drupal itself is less the dominating factor for the client, other unique aspects are often key factor for clients choosing a supplier, agency, or partner. The respondents mentioned that trust, commitment, quality, level of service, full service proposition, technical expertise, good reputation, and references were important factors for client decision making.

Drupal 8 has a strong place in the market

Drupal 8, the newest version of the CMS, seems to have taken a strong place in the market. The respondents’ new Drupal projects were most commonly (38.1%) built on Drupal 8. One fourth of the respondents stated that they build mostly with both Drupal 8 and some with Drupal 7. For 18% of the respondents most new project were built with Drupal 7 and some with Drupal 8. A few (6.7%) of the respondents said their new projects are equally often built with Drupal 7 and Drupal 8. 12.1% still built all of their new projects with Drupal 7.

Drupal companies broaden their services, skill-sets, techniques and expertise

Remarkably, despite the popularity of Drupal, the survey shows that a lot of Drupal companies have changed their business model over the last year to widen their services and respond to the demand.  

The most common way of changing the business model was by expanding services beyond building Drupal websites (35,1%). The data shows that companies start to offer more services, expand their technology stack and work with multiple CMS platforms.

The main reasons behind the changes were changing market conditions (40,0%) or to willingness to grow the pipeline better or faster (49,4%). A respondent explains: “Drupal is too restricted to cover all the market's needs; furthermore, adding other services allows us to expand our clientele and thus revenues.”

More services

In addition to pure web development – coding the sites – most of the companies provide services such as support, system integration, user experience design, visual design, hosting, and mobile development.

Changing the technology stack

The companies also found adding other technologies as a useful way of expanding the technology stack.

More than half of the respondents’ companies used also Node.js, while Angular (43.5%), Symfony (42.3%) and React.js (33.9%) were also commonly used technologies within the respondents. Some used also Laravel (17.2%), Vue.js (9.6%) and Django (5.9%).

Expanding their services by adding other services and CMS platforms to their toolkit

Almost half of the companies (45.2%) have added other CMS platforms to expand their services and getting variety to projects. WordPress is the most usual (54.67%) addition to the toolkit, serving particularly smaller projects, with Magento eCommerce platform and Grav CMS following. For most respondents (69.6%), the reason for using more than one CMS tool is being able to use the tool best suited for the project. For almost the half (40.2%) the reason arose from the client's’ wishes on the tool.

“WordPress is more popular, and customers want it because of the user experience.”

“There's still a battle out there between Drupal and WordPress. Clients are not enough informed about the differences, so their opinion is often based on information and visions by previous suppliers”

“We’re adding Adobe and wordpress. Looking into JS frameworks.”  

Drupal in a landscape of solutions

Drupal is widely considered as one of the most popular options in the CMS landscape. However, while digital solutions have become more complex, Drupal increasingly often serves as a part of a larger set of solutions. The survey data shows that Drupal companies do this in the belief that the company sells solutions rather than technology.  

There’s a broad range of options available for companies to build platforms. Every Drupal organization seeks different combinations of software products and programming languages that they seem most important for their projects. There are endless options that excel in their own right.

Our clients rarely come asking for Drupal (10% of the time ). But our technical prowess is a big part of their choice. That skill just happens to be in Drupal due to our own choice of platforms.

[Our Drupal expertise is the most definitive factor] when clients approach us for Drupal projects, if Drupal is not the main reason to approach us (the most common case) then Drupal expertise is irrelevant.

When it is a Drupal project the expertise is important but we no longer sell Drupal as a major part of projects. We just use it. We now sell the solution.

I sell solutions to digital problems, not solutions to Drupal problems.

The study made it clear that there are often other definitive factors than Drupal expertise affecting the client’s decision of choosing agencies. The clients reportedly value vendor’s portfolio and references of previous projects, reputation, communication, and services that differentiate the agency from its peers.

The Drupal talent factor

According to the survey, Drupal talent is hard to find and takes a lot of work. Only fraction (10.9%) of the companies say that they find Drupal talent easily. Compared to last year, the demand for Drupal talent at responding companies seems to be split between decreasing (23.4%) and increasing (25.5%) demand, with demand staying about the same at 36.8%.

With Drupal 8 gaining more and more popularity, most respondents say that Drupal 8 skills are somewhat in demand (38.1%) or high demand (33.5%). 15.9% say that Drupal 8 skills are not in demand.

Most respondents ranked the number of skilled Drupal 8 developers as average (40.2%). The responses indicate that more Drupal talent is needed, especially skilled Drupal 8 developers, due to the fact that Drupal 8 is more complex than its predecessors:

2016/17 and D8 has been a big shakeout for talent in Drupal. A lot of people who could operate in commercial Drupal delivery in 2012-2015 (with demand outstripping supply markedly) simply will not be viable candidates for Drupal work in 2018. There is no 'easy" work left and many people who came in during the good times will not be able to sustain careers in the new world.

The evolution of the CMS marketplace to favor more comprehensive and thus also more complex solutions is favoring bigger companies with stronger competences through number of experts in specific fields. This can be a struggle for small vendors, as mastering clients’ needs requires more expertise than is available on their staff:

Demand, as a whole, for Drupal seems to be significantly dropping as the increased complexity of each major release of Drupal cuts off greater and greater numbers of the ‘do-it-themselves’ business owning client/builder types. These types are prime candidates for initially using Drupal and then later turning their Drupal site over to a professional company.

Conclusion

Based on the study results, it is safe to say that Drupal has a steady position in the market, and Drupal 8 has secured its role as the most popular version for new Drupal projects.

The content management market is shifting towards more comprehensive and also complex solutions. Drupal agencies are well positioned to respond to this trend due to modern Drupal 8 architecture and also by combining Drupal into larger solutions. This drives Drupal business into larger deals and allows more long-term partnerships with the clients, thus giving financial stability to the companies and also to the community.

On the other end of the market, Drupal also faces competition from low-end solutions such as Wordpress. Some of the agencies now offering other content management solutions, Wordpress included.

The market might be challenging for smaller companies with only one CMS in their toolkit. Companies that can react to changing market conditions and provide a variety of solutions are going to succeed. Additiionally, companies that are able to distinguish themselves from other vendors through a good set of services, specialisation, or excellent customer service will flourish. This is all part of a natural evolution of any digital platform marketplace and it should be seen as a good juncture to raise the Drupal agencies to the next level.

Talent finding challenges indicate that there will be a need for multi-skilled developers with very good technical expertise.

Want to go in-depth?

More detailed results of the survey will be published at the DrupalCon Vienna CEO Dinner on Wednesday, September 27th. The presentation will become available for download afterwards.

-----

For more information, please contact Janne Kalliola (janne@exove.fi) or Michel van Velde (michel.vanvelde@oneshoe.com)

About Exove

Exove delivers digital growth. We help our clients to grow their digital business by designing and building solutions with agile manner, service design methodologies, and open technologies. Our clients include Sanoma, Fiskars, Neste, Informa, Trimble, and Finnlines. We serve also start-up companies, unions and public sector. Exove has offices in Helsinki, Oulu and Tampere, Finland; Tallinn, Estonia; and London, United Kingdom. For more information, please visit www.exove.com.

About One Shoe

One Shoe is an integrated advertising and digital agency with more than 10 years experience in Drupal. With more than 40 specialists, One Shoe combines strategy, UX, design, advertising, web and mobile development to deliver unique results for international clients like DHL, Shell, Sanofi, LeasePlan, MedaPharma and many more. For more information, please visit www.oneshoe.com.

About the Drupal Association

The Drupal Association is a non-profit organization headquartered in Portland, OR, USA. It helps the Drupal project and community thrive with funding, infrastructure, and events. Its vision is to help create spaces where anyone, anywhere, can use Drupal to build ambitious digital experiences. For more information, please visit drupal.org/association.

Categories: Drupal

What’s new on Drupal.org? - August 2017

Drupal Main Content - 20 September 2017 - 12:38am

Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

Announcement TLS 1.0 and 1.1 deprecated

Drupal.org uses the Fastly CDN service for content delivery, and Fastly has depreciated support for TLS 1.1, 1.0, and 3DES on the cert we use for Drupal.org, per the mandate by the PCI Security Standards Council. This change took place on 9 Aug 2017. This means that browsers and API clients using the older TLS 1.1 or 1.0 protocols will no longer be supported. Older versions of curl or wget may be affected as well.

Almost time for DrupalCon Vienna

DrupalCon Vienna is almost here! From September 26-29 you can join us for keynotes, sessions, and sprinting. Most of the Drupal Association engineering team will be on site, and we'll be hosting a panel discussion about recent updates to Drupal.org, and our plans for the future.

We hope to see you there!

Drupal.org updates 8.4.0 Alpha/Beta/Release Candidate 1

On August 3rd, Drupal 8.4.0 received its alpha release, followed on the 17th by a beta release, and on September 6th by the first release candidate. Several new stable API modules are now included in core for everything from workflow management to media management. Core maintainers hope to reach a stable release of Drupal 8.4 soon.

Improvements to Project Pages

We made a number of improvements to project pages in August, one of which was to clean up the 'Project information' section and add new iconography to make signals about project quality more clear to site builders.

In the same vein, we've also improved the download table for contrib projects, by making it more clear which releases are recommended by the maintainer, providing pre-release information for minor versions, and displaying recent test results.

Metadata about security coverage available to Composer

Developers who build Drupal sites using Composer may miss some of the project quality indicators from project pages on Drupal.org. Because of this, we now include information about whether a project receives security advisory coverage in the Composer 'extra' attribute. By including this information in the composer json for each project, we hope to make it easier for developers using Composer to ensure they are only using modules with security advisory coverage. This information is also accessible for developers who may want to make additional tools for managing composer packages.

Automatic issue credit for committers

Just about the last step in resolving any code-related issue is for a project maintainer to commit the changes. To make sure these maintainers are credited for the work they do to review these code changes, we now automatically add issue credit for committers.

Performance Improvements for Events.Drupal.org

With DrupalCon coming up in September we spent a little bit of time tuning the performance of Events.Drupal.org. We managed to resolve a session management bug that was the root cause of a significant slow down, so now the site is performing much better.

Syncing your DrupalCon schedule to your calendar

A long requested feature for our DrupalCon websites has been the ability to sync a user's personal schedule to a calendar service. In August we released an initial implementation of this feature, and we're working on updating it in September to support ongoing syncing - stay tuned!

Membership CTA on Download and Extend

We've added a call to action for new members on the Drupal.org Download and Extend page, which highlights some great words and faces from the community. Membership contributions are a crucial part of funding Drupal.org and DrupalCon, but much the majority of traffic we receive on Drupal.org is anonymous, and may not reach the areas of the site where we've promoted membership in the past. We're hoping this campaign will help us reach a wider audience.

DrupalCI sponsorship

DrupalCI is one of the most critical services the Drupal Association provides to the project, and also one of the more expensive. We've recently added a very small section to highlight how membership contributions help provide testing for the project - and in the future we hope to highlight sponsors who will step up specifically to subsidize testing for the Drupal project.

Infrastructure More semantic labels for testing

In August we added more semantic labels for DrupalCI test configuration. This means that project maintainers no longer have to update their testing targets with each new release of Drupal, they can instead test against the 'pre-release' or 'supported' version, etc. More information can be found in the DrupalCI documentation.

Started PCI audit

In August we also began a PCI audit, and developed a plan of action to reduce the Drupal Association's PCI scope. Protecting our community's personal and financial information is critically important, and with a small engineering team, the more we can offload PCI responsibility onto our payment vendors the better. We'll be continuing to work on these changes into the new year.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who made it possible for us to work on these projects. In particular we want to thank:

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Categories: Drupal

Drupal Association Board Meeting Announcement

Drupal Main Content - 12 September 2017 - 4:39am

The Drupal Association Board of Directors will meet twice during DrupalCon Vienna. They have a board retreat the weekend before the conference and there is  an open board meeting during DrupalCon for the community to attend. Below are details about each meeting.

Board Retreat

During a retreat, the board and the Executive Director meet in an extended executive session to plan and discuss the strategy for the Drupal Association. Normally, the retreat lasts two days and non-board members including staff are invited to participate in presentations and discussions on specific topics.

However for the upcoming retreat in Vienna, we will be exploring a holistic view of the strategy for Drupal and are structuring the retreat differently to accommodate this expanded conversation.

Open Board Meeting

The board will meet again during DrupalCon Vienna on Wednesday, 27 September  from 11:45 - 13:00 in the convention center Business Suite 3-4. This is open to the community and lunch will be served to all who attend. You can also attend remotely via Zoom. See the dial in information below.

The agenda for this meeting includes:

  • Vote to approve last board meeting minutes

  • Executive Update

  • Drupal.org Update

  • DrupalCon Europe Update

  • Community Governance update from the CWG

  • Community Q&A

  • Celebrate departing board members

Those dialing into the meeting can join zoom by registering here: https://zoom.us/webinar/register/1b63252cf48650c9d746f627e8486654

Or join by phone (see link for # by country):

https://zoom.us/zoomconference?m=ZTp9iSy-nW5sqyKJKRfhbTbxDueqU9W   

Webinar ID: 460 900 173

Categories: Drupal

Drupal 8.4.0-rc1 is available for testing

Drupal Main Content - 7 September 2017 - 8:47pm

The first release candidate for the upcoming Drupal 8.4.0 release is now available for testing. Drupal 8.4.0 is expected to be released October 4.

Download Drupal-8.4.0-rc1

8.4.x includes new stable modules for storing date and time ranges, display form errors inline and manage workflows. New stable API modules for discovering layout definitions and media management are also included. The media API module is new in core, all other new stable modules were formerly experimental. The release also includes several important fixes for content revision data integrity, orphan file management and configuration data ordering among other things. You can read a detailed list of improvements in the announcements of alpha1 and beta1.

What does this mean to me? For Drupal 8 site owners

The final bugfix release of 8.3.x has been released. A final security release window for 8.3.x is scheduled for September 20, but 8.3.x will receive no further releases following 8.4.0, and sites should prepare to update from 8.3.x to 8.4.x in order to continue getting bug and security fixes. Use update.php to update your 8.3.x sites to the 8.4.x series, just as you would to update from (e.g.) 8.3.4 to 8.3.5. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

For module and theme authors

Drupal 8.4.x is backwards-compatible with 8.3.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.4.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.3.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.3.x were automatically migrated to 8.4.x. Future bug reports should be targeted against the 8.4.x branch. 8.5.x will remain open for new development during the 8.4.x release candidate phase. For more information, see the release candidate phase announcement.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Categories: Drupal

DrupalCon Europe: Solving for “how to provide unique value”

Drupal Main Content - 7 September 2017 - 3:56am

DrupalCon Europe plays an important role in moving Drupal forward. However, with waning attendance and increasing financial losses, it’s time to find a new path forward so it is sustainable and continues to provide unique value. This blog covers the problem of relevance. In other words: how can DrupalCon Europe provide unique value, meeting the needs and wants for the European community. This blog is part of a series that includes:  

  1. The problem we need to solve for financial sustainability

  2. The problem we need to solve to create unique value

  3. Results from a proposal based on community input

  4. A new path forward for DrupalCon Europe.

As mentioned in our last post, DrupalCon is a human experience. It’s truly about bringing people together to strengthen bonds so they can do something amazing together with Drupal. As seen in the DrupalCon Dublin Wrap and DrupalCon Barcelona Wrap presentations, the event mostly attracts builders from digital agencies (developers, project managers, designers, UX) and digital agency owners. However, our community consists of so many more personas including technical decision makers, end-user business decision makers, as well as content strategists and content editors and other marketing related personas. DrupalCon’s current attendees, and those who don’t attend, have unique needs that they want DrupalCon to address. The question we ask is “How can DrupalCon serve this spectrum of needs while also being a sustainable event?” We start by looking at our current attendee base.

In the last post, we showed how attendance is waning at about 14% per year on average. Sponsor support dropped 17% this year. It’s apparent that DrupalCon Europe is not currently providing value that attendees and sponsors are willing to pay for. We understand that the cost to attend is not just buying the ticket, airfare, and lodging. There is also the opportunity cost of missing billable hours with clients and important time with family. To thrive as an event, DrupalCon Europe’s value needs to outweigh all of these costs.

Why is DrupalCon attracting fewer attendees? To find out, we spent a lot of time this year interviewing Drupal event organizers, core developers, sprint mentors, business owners, sponsors, and other engaged community members. We also conducted a survey that 350+ people participated in. This research started in December 2016 and continued through the year. We found that there are several reasons why fewer people attend DrupalCon ranging from lower-cost camps that provide similar content, to gaps in DrupalCon programming, and high attendance costs.

Event Competition

To understand how DrupalCon Europe can provide unique value through programming, we evaluated the competitive landscape for events. We looked at Drupal events (ex: Camps) and other technology events that attract Drupal developers, especially those working on headless solutions and e-commerce.

You can find the competitive analysis here. The TL;DR is that every Drupal event has some, if not a lot, of the same programming as DrupalCon Europe. The other thing that stands out is that DrupalCon Europe's programming does not cater to business decision makers who want to evaluate Drupal for their organization. However, local communities have started this work with the Splash Awards and similarly coordinated activities.

Doing this competitive analysis helped us see where DrupalCon provides unique value, which is listed in the Strengths portion of the SWOT down below. Still, we need to understand what the region needs to move Drupal and the community forward and what potential attendees want and need out of DrupalCon. So we conducted round table interviews of over 40 European community leaders and organizers and conducted a community survey. Thanks to everyone for participating in these conversations. You can find the survey findings here (spoiler: there is a lot of information in there. It is summarized in the sections below)

Findings from Interviews and Survey

Based on everyone’s input, we created a needs assessment and we also created a DrupalCon Europe SWOT analysis. Below are summaries of key questions asked.

Needs Assessment What Does Drupal Success Look like In Europe in the next 3 to 5 years

The roundtable and survey participants we talked to describe a future where in 3 to 5 years, Drupal 8 will have lower barriers to adoption (modules, usability, UX) and it will grow in market-share, especially in government and enterprise. There was also a shared vision amongst some that Drupal serves the small and mid-sized business market. It will be seen as a leader in each country over competitors like WP and Typo3. There will be enough developers for hire to support that growth. In terms of community, there will be more contributing members, especially from end users, and there will be more people volunteering time to contribute code and run events. The community will be vibrant, healthy, and engaged.

What Europeans want and need for Drupal to thrive

We asked participants what areas need focus to help Drupal achieve their vision of success. Here is a summary of what we learned:

  • Grow talent pool

    • Developers (PHP, Symfony, Javascript) need to get involved to: 1) be hired 2) contribute either by code or time to organize events - basically, the longtime contributors needs backup.
    • Education for developers to learn Drupal and deepen their skill
  • Grow adoption rate

    • not measured by just numbers - because there is no value in going after Squarespace deals. More marketing of Drupal’s power showing big, local case studies.
    • Get Drupal off the island - merge with other tech communities (PHP, JS) to talk about Drupal, organize co-located events, and recruit talent
  • A healthy community (depth of volunteer bench and mental health)

    • Camp support - turnkey websites, templated checklist, and sponsor support.
    • Promote / list country Associations, user groups on D.O
DrupalCon Europe and meeting the needs

Based on this input, it appears that the European community has a good vision for Drupal’s success and what they need to achieve it. We are pleased that DrupalCon Europe already addresses several needs such as:

  • Attracting new developers
  • Teaching developers about Drupal’s contribution culture
  • Getting people off the Drupal island with the PHP and Horizons track, which focuses on other projects and technologies.

We can adjust some programming to address currently unmet needs. For example, there is a need to deepen our community volunteer bench. Perhaps we can use Community Summits to provide mentorship.

However, there are some things DrupalCon Europe may not be able to achieve. For example, there is little support to make DrupalCon a developer event and a business / marketing event. In talking with other OSS projects, we learned that this is common in Europe. The suggestion is to decouple the two needs.

While DrupalCon can be redesigned to better meet needs, it is unclear which stakeholder to prioritize: the Drupal shops / digital agencies who want a marketing event, or the developer community who needs more people to help them build with Drupal and move the project forward. It is also unclear if camps and other Drupal events are better positioned to meet the developer community’s needs better than DrupalCon.

DrupalCon Europe SWOT Analysis

Our survey and roundtable asked other questions like what is special about DrupalCon, where does it not meet your needs, etc. We used that kind of input to create a SWOT analysis for DrupalCon Europe.

SWOT stands for Strengths, Weaknesses, Opportunities and Threats. It helps you organize input so you can consider the best strategy for your business - or in this case, your event.

Here is the DrupalCon Europe SWOT:

  • Strengths:

    • DrupalCon Europe demonstrates the power of Drupal because it is the largest Drupal event. It creates a “Disneyland feeling” that re-energizes excitement for Drupal.
    • It breaks down barriers and fosters greater knowledge sharing across international borders.
    • Because it attracts people from different countries and is the largest Drupal event, it provides the best opportunity to expand your network and learn new thinking.
    • DrupalCon is professionally produced, which improves how Drupal is perceived
    • Dries and other well-known Drupal members are there
    • Offers diverse content (it’s for project managers as well as developers)
    • DevOps and hosting sponsors (e.g. Fastly) feel they connect with the right audience
  • Weakness:

    • Cost is too high (strong agreement on this)
    • Content is not advanced enough. We want to hear about other languages (PHP, Symfony, JS)
    • “I can hear the same speakers at camps, which are cheaper and closer to home”
    • Digital shops who sponsor say there is no ROI. They can’t give more in terms of sponsorship because they put their money into sending staff, which has a hard cost and opportunity cost
  • Opportunity: [note: this section reflects contrasting community opinions]

    • Re-imagine the event to focus on a new audience

      • Attract new developers. Don’t serve the existing advanced developers because they can go to DevDays.
      • Attract and move developers from newcomer to beginner to intermediate only
      • Attract [prospective] end users and then attract Drupal agency sponsors again.
      • Create vertical-specific programming with emphasis on public sector to attract [prospective] end users
      • Don’t focus on business. Just make it even better, bigger for the community
      • Make the event bigger than Drupal. Co-locate with or include more content about PHP, Symfony, Javascript,
    • Make the main goal to attract new developers (including PHP, JS) by only going to three locations: UK, Benelux, Germany
    • Expand programming to talk more about things bigger than Drupal like JavaScript, PHP
    • Bring back the old community feel. Go back to the old days when it was more intimate and run by the community.
    • Shift resources by not doing a DrupalCon and support the camps. [But watch out for community burnout and help when camps get more attendees.]
    • Find a sustainable model for supporting European camps that can also support other regions like Asia Pacific and Latin America.
  • Threats

    • Camps, DevDays compete with DrupalCon head on with same speakers and sprints, yet provide an intimate, localized experience. Sponsorships are more affordable and sponsors can possibly get business at a camp where they can’t at DrupalCon Europe.
    • DrupalCamp London provides a regional event since it attracts attendees from all over [Western] Europe.
    • Other Technology events. Advanced developers want to go to a PHP, JavaScript conference
    • Drupal 8 is not growing and the D7 SMB market is moving to WIX and not D8, especially in certain countries.
    • Some can’t attend because of family commitments
    • Event timing conflicts with when I need to focus on business. Just returning from long summer break and it’s the end of Q3.

Looking at the SWOT, it is good to see consensus about DrupalCon’s strengths and weaknesses. That helps us know what to lean into and what to avoid as we look for solutions. What is concerning is “where do we take DrupalCon?” when looking at the opportunities. The community feedback reflects a wide spectrum of needs that DrupalCon could serve, yet it is quite unclear which ones to prioritize. Also, there was strong consensus that we lower ticket prices. Unfortunately, to lower ticket prices we need to hone our focus, rather than expand it to meet all of the expressed needs.

Summary

Overall, findings showed that there are many needs and opportunities for DrupalCon Europe to tackle. We cannot do all of them and it’s unclear which one is the top priority for the region.

Europe is many countries with many cultures. And Drupal is very flexible both in terms of how you use it technically, and also what personal or professional dream you want to pursue with it. It’s only natural that our research findings showed that the European region has multiple and differing visions for DrupalCon.

In the end, the question remains: where do we focus DrupalCon’s programming to strike at the highest priority needs of the European community and how do we do that in a sustainable way? The next blog in this series shows how we tried to answer it with community members.

Categories: Drupal