Come for the software, stay for the community
Drupal is an open source content management platform powering millions of websites and applications. It’s built, used, and supported by an active and diverse community of people around the world.
This release introduces powerful features that will help us all take Drupal to a whole new level. The new stable JSON:API core module as well as the intuitive and accessible stable Layout Builder are game-changing.
The Layout Builder module was originally introduced as an experimental module in Drupal 8.5.0. As of Drupal 8.7.0, Layout Builder is now stable and ready for production use! It provides a powerful, accessible, mobile-friendly page building tool that is fully compatible with revisions, workflows, and in-context previews.
The Layout Builder enables site builders to rapidly create layout templates for content that speed up the development process. It also permits content authors to easily customize individual pages with unique layouts.
The interface allows drag-and-drop management of your content blocks. It additionally supports keyboard controls and toggling the content preview on and off to give the content editor complete control of their experience while building their layouts.
The result of all these features is a state-of-the art content management solution that streamlines mass-production while also supporting unique creation. 123 individuals and 68 organizations contributed to this feature. More than 40 of the individual contributors volunteered some or all of their time.
Check out this demonstration based on the core Umami demo:
The team is working on implementing translation support for layouts in a future release.
New stable JSON:API support
JSON:API support is now included as a stable core feature. The JSON:API specification is an easy and fast way to build decoupled applications. Drupal core's JSON:API module is feature-complete and easy to use with robust out-of-the-box support and simple setup. JSON:API makes it simpler than ever to build ambitious projects. 147 contributors and 76 organizations contributed to this new feature. Among the individual contributors, more than 50 volunteered some or all of their time.
For example, by simply navigating to a URL like https://example.com/jsonapi/node/article, you can get a list of available articles on your site, and filter further from there, to display your Drupal content in decoupled websites, mobile applications, and so on.
Improvements in experimental Media Library
The experimental Media Library has numerous significant improvements in this release. The Media Library is built on top of the stable Media module, which allows reuse of images, documents, and even embedded remote media like YouTube videos. Items in the Media Library can be managed with drag-and-drop. This release improves the design and accessibility of the user interface, allows inline media creation in the library, and provides more flexible grid and table views. 310 contributors and 122 organizations contributed to this new feature. More than 100 individuals volunteered some or all of their time!
Check out this demonstration based the core Umami demo with Media Library enabled:
There are various tasks left to make Media Library stable in a future release, including WYSIWYG integration.
Revisionable menus and taxonomy terms
Custom menu links and taxonomy terms are now revisionable, which allows them to be used in editorial workflows (similarly to nodes, media, and custom blocks). The Entity system now also provides a new Update API to support conversion of further entity types. It supports converting the schema of any content entity type between non-revisionable or non-translatable and revisionable or translatable, which also works when there is pre-existing data for the entity type whose schema is being changed. All these changes improve core support for the Workspaces module.
New features in the Umami demo profile
The Umami food magazine demo is now more accessible and demonstrates more features out of the box, including a new welcome tour, Layout Builder integration for recipes, and multilingual features. The profile now includes a curated set of Spanish translations, and more languages are in the works. 187 contributors and 84 organizations have contributed to Umami, with more than 60 individuals volunteering some or all of their time.
Umami empowers first-time users to spin up a Drupal project in no time so that they can use to evaluate Drupal and learn about its major components.
On the way to Drupal 9
Drupal 8.7.0 includes optional support for Twig 2 (for sites that can patch their Composer configuration). Optional support for Symfony 4 also received a lot of contributions and should be complete in 8.8. This is important work, because Drupal 9 is planned for June 3, 2020 and will update various dependencies, primarily Symfony. Testing Drupal with updated third-party dependencies will help us get better feedback on our compatibility with these dependencies and any difficulties sites encounter when upgrading.
What does this mean for me?
Drupal 8 site owners
Update to 8.7.0 to continue receiving bug fixes. The next bugfix release (8.7.1) is scheduled for June 5, 2019. (See the release schedule overview for more information.) As of this release, sites on Drupal 8.5 will no longer receive security coverage. (Drupal 8.6 will continue receiving security fixes until December 4, 2019.)
Updating your site from 8.6.15 to 8.7.0 with update.php is exactly the same as updating from 8.6.14 to 8.6.15. Drupal 8.7.0 also has updates to several dependencies. 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. Read the 8.7.0 release notes for a full list of changes that may affect your site.
You can now use the stable migration path for monolingual Drupal 6 and 7 sites with the built-in upgrade user interface. For multilingual sites, there is experimental support; please keep testing and reporting any issues you may find.
Translation, module, and theme contributors
Minor releases like Drupal 8.7.0 include backwards-compatible API additions for developers as well as new features.
Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.6.x and earlier will be compatible with 8.7.x as well. However, the new version does include some changes to strings, user interfaces, internal APIs and API deprecations. This means that some small updates may be required for your translations, modules, and themes. Read the 8.7.0 release notes for a full list of changes that may affect your modules and themes.
This release has advanced the Drupal project significantly and represents the efforts of hundreds of volunteers and contributors from various organizations, as well as testers from the Minor release beta testing program. Thank you to everyone who contributed to Drupal 8.7!
Earlier this month we saw the passing of Rachel Olivero. Rachel touched a lot of people in both the Drupal and accessibility communities. She worked at the National Federation of the Blind, as the Director of Organizational Technology. I am not sure that this is where she was first exposed to Drupal, but she became involved in the community after attending DrupalCon in her hometown of Baltimore in 2017. It was there where she participated in her first code sprint and contributed her first bug report.
After attending the first-ever Nonprofit Summit at DrupalCon Baltimore, Rachel stepped up to lead an accessibility breakout at DrupalCon Nashville. She was always willing to share her knowledge and never got annoyed no matter how many times she was asked her whether the <aside> element was ever useful to a screen reader. Fortunately, about 20 minutes of the accessibility roundtable was recorded. She engaged with a few folks throughout the week, many remember her from Drupal Trivia Night.
As a technical user who was blind, her opinion was sought often in the Slack Channel. She also engaged with the Drupal Diversity and Inclusion team. Rachel was active in Twitter and other social media platforms too, where she engaged with other members of the Drupal community. As a person who was blind, transgender, and a lesbian, Rachel understood a lot about the importance of diversity.
Rachel became involved in the NTENDrupal Community of Practice calls a few years ago, when she came on a monthly call to share some accessibility knowledge. Subsequently, she became a more regular attendee of these calls. Johanna Bates and Rachel were slated to co-present a session on accessible content entry for content editors at the upcoming NTEN 19NTC in Portland. This would have been her first ever NTEN NTC.
Rachel also served on the NTEN NTC’s first-ever accessibility committee, contributing her knowledge to making conferences more accessible. This is a perfect example of how willing Rachel was to share her expertise and experience with others. She was generous with her knowledge, kind, collaborative, and extremely funny. The loss of her warmth, humor, and brilliance in the Drupal community, the nonprofit tech community, and in the a11y community is a massive and sad loss.
This fall Rachel contributed an article to the latest 24 accessibility series, Not Your Father’s Navigation Strategy: There’s More Than Just the TAB Key. She argued for developers to invest in proper semantic markup so that screen reader users can make full use of their assistive technology. This annual series of articles really draws on a Who's Who of accessibility.
Rachel was also the president of the NFB’s Amateur Radio Division. As a modern HAM enthusiast, she was active on GitHub working to create a Software-defined radio (SDR) scanner that could continuously record a set of frequencies for on-demand playback. She was interested in public safety.
Rachel had been working on NFB.org’s new Drupal 8 site for a long time. She was so excited to see it launch at the end of January. Rachel had recently been promoted at the NFB to Director of Technology. This launch was a huge piece of her work, and the site looks amazing. It is terrific to see how she was able to modernize the NFB’s website and leverage Drupal to help her create a modern responsive website.
“I’m lucky, and thankful, that blindness hasn’t caused a lot of resistance in my life. From the support of family during my early years to the encouragement of friends, to the emergency management director who I never saw blink an eye when I said, “I want to take the CERT class. You can teach me to get people out from under a collapsed wall too, right?” to all those who supported my gender transition. I’ve generally never felt that I couldn’t do something as a blind person. However, it’s the love, hope, and determination of my family in the National Federation of the Blind, that has given me the extra strength and answered the, ‘but how do I…” And that is #WhyImAFederationist”
A few community members shared memories of Rachel:
What I admired most about Rachel was her willingness to help at any level necessary and the kindness with which she acted. She was enthusiastic about building community and eager to contribute. She regularly gave time, experience, resources (like her server space, and other infrastructure) and energy to connecting people and working for a future in which technology would be accessible to all. Her unique perspective brought insight, empathy and patience to her work, and I’m sad that the world has lost such a passionate champion for inclusion.
- Nikki Stevens (drnikki)
Rachel was the kind of person who immediately made you feel at ease when you were spending time with her, even if you had just met. She was great about making sure that nobody got left out, and was quick to invite new or shy people at events who might have eaten alone to come sit with her and her friends instead.
She was generous with her time whenever I asked to bounce an idea off of her to see if what I was considering suggesting would actually be helpful for the blind community or not, and she never made me feel like a bother when I asked for her thoughts. To the contrary, she always seemed happy to help. She was encouraging when I was right, and gracious when I was wrong; she never made me feel stupid about an idea if I was off-base, and instead provided valuable insight that I apply to my work to this day.
Rachel was an awesome woman, and I wish that we had gotten to spend more time together. The Drupal community (and the world at large) will definitely be feeling her loss. I hope that we can all put what she has given to each of us to good use to carry forward what was always her mission - to make the world better for people.
- Helena McCabe (helenasue)
Rachel Olivero was really an adventurous spirit. I remember a NFB conference several years ago when Rachel mused "I've always wanted to ride a mechanical bull - y'know do as Texans do in Texas". After fighting the management of the establishment, who were not inclined to let her ride, she got to ride - for a full 30 seconds:-). Everyone at Deque will miss her. Rachel is an inspiration to all those who strive to be true to themselves and the cause of digital equality.
- Preety Kumar
In 2007, Rachel was one of the first accessibility experts I worked with after I joined Deque and I was always impressed with her technical strength and her ability to keep people at the center of any discussion. I remember the demonstration she made to Wal-Mart’s checkout team, that the shopping cart was inaccessible. Their response was getting off-track into technical mumbo-jumbo when Rachel loudly interrupted, “excuse me...excuse me. The point is that I want to put money in your pocket but since the shopping cart won’t work for me, I can’t do that. Do you want me to put my money in Target’s pocket instead?!?!” I always enjoyed working with her on any project and will miss her.
- Wes Dillon
Rachel Olivero will always be an an accessibility super hero to me. From the moment I met her, I knew she was wicked smart and a powerful force for good. She moved a11y forward through her technical work and leadership at NFB and Humana.
Our friendship grew each time we were together...from AHG to NFB to CSUN, to Penn State Web Conf and more. I think some of my favorite memories are from the “accessibility slumber party” at the Margarita Inn with Rachel, Elle, Sharron and others. Elle had brought together a team of a11y experts to solve big problems...we worked night and day...because we care so deeply about equal access for all.
A world without Rachel seems impossible to me. And then I remember how with Rachel, nothing seemed impossible. So I guess we all have to find our way to keep Rachel’s positive energy moving forward. Now It is up to each of us to make Rachel’s a11y dreams become a reality.
So with that, I raise a glass of cherry coke (one of her favs) and toast “To Rachel! To A11Y & Beyond!”
- Glenda Sims
I enjoyed talking with Rachel at both of her DrupalCons. We mostly talked shop. I was very impressed with her knowledge and patience dealing with people interested in learning. I remember talking about getting organizations like the NFB to approach technology more as makers than consumers. We also talked about challenges with procurement and the work that she was doing to revise how technology was purchased. She seemed hopeful and focused. She was clearly a big thinker.
By being involved in the Drupal community, Rachel reminded a lot of us of the importance of building our tools to work for everyone.
We were all looking forward to working with her more. She will be missed.
In lieu of flowers, the family requests that memorial donations be made to the National Federation of the Blind to support projects in which Rachel personally invested her time, treasure, and talent.
Contributions can be mailed to National Federation of the Blind, 200 East Wells Street, Baltimore, Maryland, 21230, or given online at https://nfb.org/donate.
Ginesys, led by Ginni Systems Ltd. India, is one of the leading POS companies, covering the entire retail value chain from manufacturing to distribution and retail in the country.
Specbee was entrusted with the task of architecting their website, intended to showcase their products and solutions and introduce the company to a large audience. Their previous website was difficult to handle, costly, and challenging for staff to use (who uploaded content on a regular basis) with its complexity and inflexibility. The remodeled website on Drupal 8 offered an efficient content management process and improved performance.
Update: Since the publication of this blog Drupal 9 is closer than ever. To learn what you need to do to be ready for the upcoming release, please consult our pages on Preparing for Drupal 9.
This blog has been re-posted and edited with permission from Dries Buytaert's blog. Unfortunately Dries' blog does not allow for comments at the moment, feel free to post them here.
At Drupal Europe, I announced that Drupal 9 will be released in 2020. Although I explained why we plan to release in 2020, I wasn't very specific about when we plan to release Drupal 9 in 2020. Given that 2020 is less than thirteen months away (gasp!), it's time to be more specific.
Shifting Drupal's six month release cycle
We shifted Drupal 8's minor release windows so we can adopt Symfony's releases faster.
Before I talk about the Drupal 9 release date, I want to explain another change we made, which has a minor impact on the Drupal 9 release date.
As announced over two years ago, Drupal 8 adopted a 6-month release cycle (two releases a year). Symfony, a PHP framework which Drupal depends on, uses a similar release schedule. Unfortunately the timing of Drupal's releases has historically occurred 1-2 months before Symfony's releases, which forces us to wait six months to adopt the latest Symfony release. To be able to adopt the latest Symfony releases faster, we are moving Drupal's minor releases to June and December. This will allow us to adopt the latest Symfony releases within one month. For example, Drupal 8.8.0 is now scheduled for December 2019.
We hope to release Drupal 9 on June 3, 2020
Drupal 8's biggest dependency is Symfony 3, which has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. Therefore, we have to end-of-life Drupal 8 no later than November 2021. Or put differently, by November 2021, everyone should be on Drupal 9.
Working backwards from November 2021, we'd like to give site owners at least one year to upgrade from Drupal 8 to Drupal 9. While we could release Drupal 9 in December 2020, we decided it was better to try to release Drupal 9 on June 3, 2020. This gives site owners 18 months to upgrade. Plus, it also gives the Drupal core contributors an extra buffer in case we can't finish Drupal 9 in time for a summer release.
Planned Drupal 8 and 9 minor release dates.
We are building Drupal 9 in Drupal 8
Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backwards-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality.
Let's look at an example. As mentioned, Drupal 8 currently depends on Symfony 3. Our plan is to release Drupal 9 with Symfony 4 or 5. Symfony 5's release is less than one year away, while Symfony 4 was released a year ago. Ideally Drupal 9 would ship with Symfony 5, both for the latest Symfony improvements and for longer support. However, Symfony 5 hasn't been released yet, so we don't know the scope of its changes, and we will have limited time to try to adopt it before Symfony 3's end-of-life.
We are currently working on making it possible to run Drupal 8 with Symfony 4 (without requiring it). Supporting Symfony 4 is a valuable stepping stone to Symfony 5 as it brings new capabilities for sites that choose to use it, and it eases the amount of Symfony 5 upgrade work to do for Drupal core developers. In the end, our goal is for Drupal 8 to work with Symfony 3, 4 or 5 so we can identify and fix any issues before we start requiring Symfony 4 or 5 in Drupal 9.
Another example is our support for reusable media. Drupal 8.0.0 launched without a media library. We are currently working on adding a media library to Drupal 8 so content authors can select pre-existing media from a library and easily embed them in their posts. Once the media library becomes stable, we can deprecate the use of the old file upload functionality and make the new media library the default experience.
The upgrade to Drupal 9 will be easy
Because we are building Drupal 9 in Drupal 8, the technology in Drupal 9 will have been battle-tested in Drupal 8.
For Drupal core contributors, this means that we have a limited set of tasks to do in Drupal 9 itself before we can release it. Releasing Drupal 9 will only depend on removing deprecated functionality and upgrading Drupal's dependencies, such as Symfony. This will make the release timing more predictable and the release quality more robust.
For contributed module authors, it means they already have the new technology at their service, so they can work on Drupal 9 compatibility earlier (e.g. they can start updating their media modules to use the new media library before Drupal 9 is released). Finally, their Drupal 8 know-how will remain highly relevant in Drupal 9, as there will not be a dramatic change in how Drupal is built.
But most importantly, for Drupal site owners, this means that it should be much easier to upgrade to Drupal 9 than it was to upgrade to Drupal 8. Drupal 9 will simply be the last version of Drupal 8, with its deprecations removed. This means we will not introduce new, backwards-compatibility breaking APIs or features in Drupal 9 except for our dependency updates. As long as modules and themes stay up-to-date with the latest Drupal 8 APIs, the upgrade to Drupal 9 should be easy. Therefore, we believe that a 12- to 18-month upgrade period should suffice.
So what is the big deal about Drupal 9, then?
The big deal about Drupal 9 is … that it should not be a big deal. The best way to be ready for Drupal 9 is to keep up with Drupal 8 updates. Make sure you are not using deprecated modules and APIs, and where possible, use the latest versions of dependencies. If you do that, your upgrade experience will be smooth, and that is a big deal for us.
I understand why organizations might be tempted to de-prioritize accessibility. Making a complex web application accessible can be a lot of work, and the pressure to ship early can be high.
In the past, I've been tempted to skip accessibility features myself. I believed that because accessibility features benefited a small group of people only, they could come in a follow-up release.
Today, I've come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.
As you can see in Drupal's Values and Principles, we are committed to building software that everyone can use. Accessibility should always be a priority. Making capabilities like the Layout Builder accessible is core to Drupal's DNA.
Drupal's Values and Principles translate into our development process, as what we call an accessibility gate, where we set a clearly defined "must-have bar." Prioritizing accessibility also means that we commit to trying to iteratively improve accessibility beyond that minimum over time.
Together with the accessibility maintainers, we jointly agreed that:
Our first priority is WCAG 2.0 AA conformance. This means that in order to be released as a stable system, the Layout Builder must reach Level AA conformance with WCAG. Without WCAG 2.0 AA conformance, we won't release a stable version of Layout Builder.
Our next priority is WCAG 2.1 AA conformance. We're thrilled at the greater inclusion provided by these new guidelines, and will strive to achieve as much of it as we can before release. Because these guidelines are still new (formally approved in June 2018), we won't hold up releasing the stable version of Layout Builder on them, but are committed to implementing them as quickly as we're able to, even if some of the items are after initial release.
While WCAG AAA conformance is not something currently being pursued, there are aspects of AAA that we are discussing adopting in the future. For example, the new 2.1 AAA "Animations from Interactions", which can be framed as an achievable design constraint: anywhere an animation is used, we must ensure designs are understandable/operable for those who cannot or choose not to use animations.
Drupal's commitment to accessibility is one of the things that makes Drupal's upcoming Layout Builder special: it will not only bring tremendous and new capabilities to Drupal, it will also do so without excluding a large portion of current and potential users. We all benefit from that!
Last week, I shared my State of Drupal presentation at Drupalcon Nashville. In addition to sharing my slides, I wanted to provide more information on how you can participate in the various initiatives presented in my keynote, such as growing Drupal adoption or evolving our community values and principles.
Drupal 8 update
During the first portion of my presentation, I provided an overview of Drupal 8 updates. Last month, the Drupal community celebrated an important milestone with the successful release of Drupal 8.5, which ships with improved features for content creators, site builders, and developers.
Drupal 8 continues to gain momentum, as the number of Drupal 8 sites has grown 51 percent year-over-year:
This graph depicts the number of Drupal 8 sites built since April 2015. Last year there were 159,000 sites and this year there are 241,000 sites, representing a 51% increase year-over-year.
Drupal 8's module ecosystem is also maturing quickly, as 81 percent more Drupal 8 modules have become stable in the past year:
This graph depicts the number of modules now stable since January 2016. This time last year there were 1,028 stable projects and this year there are 1,860 stable projects, representing an 81% increase year-over-year.
As you can see from the Drupal 8 roadmap, improving the ease of use for content creators remains our top priority:
This roadmap depicts Drupal 8.5, 8.6, and 8.7+, along with a column for "wishlist" items that are not yet formally slotted. The contents of this roadmap can be found at https://www.drupal.org/core/roadmap.
Four ways to grow Drupal adoption
Drupal 8 was released at the end of 2015, which means our community has had over two years of real-world experience with Drupal 8. It was time to take a step back and assess additional growth initiatives based on what we have learned so far.
In an effort to better understand the biggest hurdles facing Drupal adoption, we interviewed over 150 individuals around the world that hold different roles within the community. We talked to Drupal front-end and back-end developers, contributors, trainers, agency owners, vendors that sell Drupal to customers, end users, and more. Based on their feedback, we established four goals to help accelerate Drupal adoption.
To become involved with one of these initiatives, click on its "Issue link" in the table above. This will take you to Drupal.org, where you can contribute by sharing your ideas or lending your expertise to move an initiative forward.
Goal 2: Improve the content creator experience
Throughout the interview process, it became clear that ease of use is a feature now expected of all technology. For Drupal, this means improving the content creator experience through a modern administration user interface, drag-and-drop media management and page building, and improved site preview functionality.
Most of these initiative teams meet weekly on Drupal Slack (see the meetings calendar), which gives community members an opportunity to meet team members, receive information on current goals and priorities, and volunteer to contribute code, testing, design, communications, and more.
Goal 3: Improve the site builder experience
Our research also showed that to improve the site builder experience, we should focus on improving the three following areas:
The configuration management capabilities in core need to support more common use cases out-of-the-box.
Composer and Drupal core should be better integrated to empower site builders to manage dependencies and keep Drupal sites up-to-date.
We should provide a longer grace period between required core updates so development teams have more time to prepare, test, and upgrade their Drupal sites after each new minor Drupal release.
We plan to make all of these aspects easier for site builders through the following initiatives:
Core committers + Drupal Security Team + Drupal Association
Core committers and Security team
Proposed, under discussion
Goal 4: Promote Drupal to non-technical decision makers
The fourth initiative is unique as it will help our community to better communicate the value of Drupal to the non-technical decision makers. Today, marketing executives and content creators often influence the decision behind what CMS an organization will use. However, many of these individuals are not familiar with Drupal or are discouraged by the misconception that Drupal is primarily for developers.
With these challenges in mind, the Drupal Association has launched the Promote Drupal Initiative. This initiative will include building stronger marketing and branding, demos, events, and public relations resources that digital agencies and local associations can use to promote Drupal. The Drupal Association has set a goal of fundraising $100,000 to support this initiative, including the hiring of a marketing coordinator.
Megan Sanicki and her team have already raised $54,000 from over 30 agencies and 5 individual sponsors in only 4 days. Clearly this initiative resonates with Drupal agencies. Please consider how you or your organization can contribute.
Fostering community with values and principles
This year at DrupalCon Nashville, over 3,000 people traveled to the Music City to collaborate, learn, and connect with one another. It's at events like DrupalCon where the impact of our community becomes tangible for many. It also serves as an important reminder that while Drupal has grown a great deal since the early days, the work needed to scale our community is never done.
An overview of Drupal's values with supporting principles.
I believe that taking time to highlight community members that exemplify each principle can make the proposed framework more accessible. That is why it was very meaningful for me to spotlight three Drupal community members that demonstrate these principles.
Principle 1: Optimize for Impact - Rebecca Pilcher
Rebecca shares a remarkable story about Drupal's impact on her Type 1 diabetes diagnosis:
Principle 5: Everyone has something to contribute - Mike Lamb
Mike explains why Pfizer contributes millions to Drupal:
Principle 6: Choose to Lead - Mark Conroy
Mark tells the story of his own Drupal journey, and how his experience inspired him to help other community members:
Chances are if you've attended any of the Drupal camps in North America you've run into Kevin Thull. He's the fellow that is dashing from room to room before the first session begins to set up the AV equipment and checking in with presenters making sure they all "push the red button". Because of him, we are all able attend the sessions we miss while busy elsewhere. He is personally responsible for recording over 800 sessions and donating countless hours of his time.
Not only does he record sessions at camps, he also helps organize Midwest Drupal Camp. For this next year he has been charged as their fearless leader. He will be working on their web team, arranging catering, organizing the venue, as well as doing all the audio visual.
This year at DrupalCon Nashville the Drupal Community awarded Kevin the Aaron Winborn award. The Aaron Winborn award is presented annually to an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. Kevin's commitment to capturing knowledge to share with the whole community is truly inspirational. He has provided a platform that helps tie local Drupal Communities together.
The Drupal Community Spotlight Committee's AmyJune Hineline ( volkswagenchick on drupal.org)sat with Kevin before Nashville and asked him some questions about contributing to the Drupal Community.
Ironically, AmyJune had chosen to write this spotlight on Kevin a few weeks before DrupalCon. AmyJune had asked him if he was coming to Nashville and he relayed that he had a prior commitment to attend another conference for his job. Unbeknownst to us, during the interview Kevin knew he had been awarded the honor and managed to keep it a secret. While he did mention that the marketing conference only ran through Wednesday, AmyJune was pleasantly surprised to see him take the stage.
Well, not too surprised, after all he truly deserves the honor.
How long have you been involved in the Drupal community?
I’m not involved with Drupal through my employer, I work in Marketing, but I got into Drupal through freelance.
My first meet up was when the Using Drupal 6 book first came out. I would say that is when I first started getting involved in the community. So, that's close to 10 years now.
I started recording Drupal Camps back in 2013. The official Chicago Camp was having issues and so we as a far western Suburban group decided to have our own camp. I thought I could do some of the logistics and session recordings since that's what I do for work. I had the same setup with video cameras in the back of the room and I spent countless hours rebuilding these presentations. It's a similar process, but it's a very a different presentation between a marketer and someone from the Drupal community giving a presentation on diversity. A marketer might have 20 slides, but a Drupal talk may have 104.
Everybody at the time was telling me I was insane for doing this, but my response was, "Nope, it's important."
In 2014 was the first MIDCamp and we were able to get the DA recording kits. But that was not great either. There was a lot of setup, they were expensive to ship them back and forth, they didn't work terribly well, so that's when Avi Schwab ( https://www.drupal.org/u/froboy) and I started collaborating. He did all the setup for the laptops and I did all the running around from room to room and post production. We brainstormed and I started doing research. The next Suburban Camp is when I had my first test kit for what I am using today.
I saw that you recorded Pacific Northwest Drupal Summit remotely this year? Can you share that experience with us?
That's a funny story. It was the same weekend as Jersey Camp and I tend to favor camps I have already recorded. They had committed before Pacific Northwest Drupal Summit and when Amber Matz saw me at BADCAmp, I explained the conflict. I told her I had started working on the next step and would be shipping the kits to camps. I sat with her and showed her how the kit worked and she said it didn't seem too difficult, and we said "Let's do this".
I got a new case, sent 5 kits to them. It's funny how talking with the organizers of camps helps all of this come together. Because later at New England Camp, I was explaining to one of their organizers how I was shipping kits and he suggested labeling the cables. I thought that was brilliant so I got a label maker and labeled all the cables. I wrote out more a detailed instruction guide, and all these things were things I had been meaning to do.
I sent 5 kits, insured FedEx for around $50, whereas the DA sends this giant pelican case that must cost hundreds of dollars. That was part of the plan originally; we wanted something lightweight and easy to use. I heard they had an 84% capture rate which is a great start. The issue is that non-Macs recordings have no sound and so I have to lay up the backup recording into the video. A lot of times that back up recorder gets turned off or stopped for some reason.
While I was in Florida I started working on pinpointing why non-Mac machines don't have audio. Later, I had mixed success at MIDCamp, I captured a couple, some didn't work, one being an Ubuntu build. At lunch I worked with that presenter to test various setups and we found a setup that worked. Once I can crack that nut, then shipping with even more instructions will increase the capture rates.
Now that you're capturing some camps remote, how does that cut into how much you like to travel?
I do like to travel, but there are a couple of issues. A) I can't be everywhere. B) I am potentially doing 13 or 14 camps this year. Which is cool now, but it may not be cool in couple of years. And C) I don't do Drupal at work and when I first starting doing this I was using all my PTO. I don’t do any Drupal at work, but I brought back all kinds of information and my boss recognized that. She said I could count those as remote days, but of course there's a limit.
There is a balance to be found between visiting the camps and sending the kits remotely.
What are some of your favorite camps?
Everybody asks me that, that question is not fair. I like them all. It's generally the places I know the most people and/or I go ahead of time to play before camp starts. I am not a solo traveller, so if I know a lot of people at the camp I tend to like those: Badcamp, Twin Cities, St. Louis, Texas (cuz of Austin), and Montreal.
What are the things you like to do before a camp that makes it more fun?
HaHaHa, eat and drink all the things. Bar Crawls, Food Crawls, you name it.
Have you given any thought to helping with camps outside the States?
I would like to, but it’s a time and cost issue. The camps now reimburse my travel expenses. To fly to a European camp - I don’t know if that would be in their budget.
It’s interesting, Mauricio Dinarte tailed me for a few camps and he wanted, and he did, get some kits to start recording Nicaragua. One day he tweeted that he saw my kits at Drupal Camp Antwerp. It’s cool to see how these things grow organically. There’s not a camp that goes by where someone from the community doesn’t ask me about how everything works.
Kevin’s not just the guy who reminds us all to push the red button. He is the guy who loans out his phone when a presenter is doing a live demo and needs an internet hotspot. He is the guy spending hours during and after Drupal Camps piecing together audio and video for maximum quality. The Drupal Community has so much to thank him for, the Aaron Winborn award couldn’t have been awarded to anyone more deserving.
“It has become a no-brainer to invite Kevin to Florida DrupalCamp and have him record and post all of our sessions online. He makes it easy for us to share our great content with a world-wide audience by coming prepared, making it easy for presenters, and uploading the video almost immediately. He’s a true asset to the community.” - Mike Anello (Florida Camp)
"His never-ending abundance of energy and positive contributions in the form of Drupal Camp video services in the US is unmatched. At the camps where I’ve spoken or helped organize he has been a great person to work with through the whole process - helpful and organized across the board." - Aimee Degnan Hannaford (BADCamp)
“We appreciated Kevin’s willingness to send recording equipment and documentation to our event so that we could record sessions, even though he couldn’t be there. He was encouraging and helpful all along the way.” Amber Matz (PNWDS Portland)
Thank you Kevin for your contribution to community, for sharing your story with us, and for being a most excellent secret keeper! And thank you to the hundreds of volunteers that make Drupal Camps, Cons, meetups and picnics a success every year. And thank you AmyJune Hineline ( volkswagenchick on drupal.org)for this most excellent Drupal Community Spotlight article!
We would like to thank the CKEditor team for patching the vulnerability and coordinating the fix and release process, and matching the Drupal core security window.
The Drupal 7.x CKEditor contributed module is not affected if you are running CKEditor module 7.x-1.18 and using CKEditor from the CDN, since it currently uses a version of the CKEditor library that is not vulnerable.
The following blog was written by Drupal Association Signature Hosting Supporter, Acquia.
More and more developers are choosing content-as-a-service solutions known as decoupled CMSes, and due to this trend, people are asking whether decoupled CMSes are challenging the market for traditional CMSes.
By nature, decoupled CMSes lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Luckily, Drupal has one crucial advantage that propels it beyond these concerns of emerging decoupled competitors.
Join Dries Buytaert, founder of Drupal and CTO at Acquia, as he shares his knowledge on how Drupal has an advantage over competitors, and discusses his point-of-view on why, when, and how you should implement decoupled Drupal.
Dries will touch on:
His thoughts on decoupled CMSes - where is the CMS market headed and when?
His opinion on whether decoupled CMSes will replace traditional CMSes
The advantages of decoupled Drupal vs. emerging decoupled competitors
Considerations when determining if decoupled Drupal is right for your project
Dries Buytaert is an open source developer and technology executive. He is the original creator and project lead for Drupal, an open source platform for building websites and digital experiences. Buytaert is also co-founder and chief technology officer of Acquia, a venture-backed technology company. Acquia provides an open cloud platform to many large organizations, which helps them build, deliver and optimize digital experiences. A Young Global Leader at the World Economic Forum, he holds a PhD in computer science and engineering from Ghent University and a Licentiate Computer Science (MsC) from the University of Antwerp. He was named CTO of the Year by the Massachusetts Technology Leadership Council, New England Entrepreneur of the Year by Ernst & Young, and a Young Innovator by MIT Technology Review. He blogs frequently on Drupal, open source, startups, business, and the future at dri.es.
The following blog was written by Drupal Association Signature Hosting Supporter, Acquia.
The rapid evolution of diverse end-user clients and applications has given rise to a dizzying array of digital channels to support.
Websites in the past were built from monolithic architectures utilizing web content management solutions that deliver content through a templating solution tightly “coupled” with the content management system on the back-end.
Agile organizations crave flexibility, and strive to manage structured content across different presentation layers consistently in a way that’s scalable.
Accomplishing this efficiently requires that teams have flexibility in the front-end frameworks that dominate the modern digital landscape. That’s why decoupled and headless CMS is taking off. That’s why you’re here. But now you need the right technology to support the next phase of the web and beyond.
A remote code execution vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being completely compromised.
The security team has written an FAQ about this issue.
Upgrade to the most recent version of Drupal 7 or 8 core.
If you are running 7.x, upgrade to Drupal 7.58. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)
If you are running 8.5.x, upgrade to Drupal 8.5.1. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)
Drupal 8.3.x and 8.4.x are no longer supported and we don't normally provide security releases for unsupported minor releases. However, given the potential severity of this issue, we are providing 8.3.x and 8.4.x releases that includes the fix for sites which have not yet had a chance to update to 8.5.0.
Your site's update report page will recommend the 8.5.x release even if you are on 8.3.x or 8.4.x. Please take the time to update to a supported version after installing this security update.
This issue also affects Drupal 8.2.x and earlier, which are no longer supported. If you are running any of these versions of Drupal 8, update to a more recent release and then follow the instructions above.
This issue also affects Drupal 6. Drupal 6 is End of Life. For more information on Drupal 6 support please contact a D6LTS vendor.
Thunder is proud sponsor of the Media and Publishing Summit ahead of the DrupalCon in Nashville. Meet us on 9th April and during the DrupalCon to learn more about Thunder and how it is used in professional publishing.
Thunder is the Drupal 8 distribution for professional publishing. Thunder was designed by Hubert Burda Media and released as open-source software under the GNU General Public License in 2016. As members of the Thunder community, publishers, partners, and developers build custom extensions and share them with the community to further enhance Thunder.
Thunder consists of the current Drupal 8 functionality, lots of handpicked publisher-centric modules with custom enhancements (our own Thunder Admin Theme, the Paragraphs module, the Media Entity module, the Entity Browser module, and lots more), and an environment which makes it easy to install, deploy and add new functionality (e.g. the Thunder Updater).
We at the Thunder Core Team believe that publishers do not compete with each other through technology, but rather through content and brands. That is why the German publisher Hubert Burda Media established the Thunder community which aims to join forces among media companies by sharing code and innovation power. The goal is to innovate faster and spend less money overall by working together.
The Thunder community’s core product is the open-source content management system Thunder. Community members develop useful modules, use them for their own purposes and share them with the community by publishing them under the GNU General Public License. Neither Hubert Burda Media nor the other publishers in the community charge anyone for their contributions.
Any company publishing content professionally is welcome as a member of the Thunder community - both as user and as contributor. Anyone can join by contributing to the distribution. The usefulness and richness of Thunder’s functionality directly benefit from the number of contributors.
Why Drupal was chosen:
For Burda, Drupal is the content management platform of choice. It is a free and open-source content-management framework written in PHP and distributed under the GNU General Public License.
The standard Drupal core already provides the essential features, e.g. user management, menu management, RSS feeds, taxonomy, page layout customization, and system administration. It is easily adaptable and extensible with thousands of modules provided by a global community of users and developers. In addition, developers at Hubert Burda Media have had previous good experiences with Drupal. Drupal is therefore a tried and tested basis and has become even better with Drupal 8.
Describe the project (goals, requirements and outcome):
Thunder started as a way to share innovation and synergies among the many different brands and products within the Burda Corporation to save costs and speed up the time to market. It did not take long until we realized that the model that worked within the very diverse Burda universe would be useful for almost all digital publishers. That was when we decided to open source the distribution.
Due to its open source basis on Drupal 8, all features and functionality within Thunder are available to anyone wishing to benefit from Burda’s industry experience. Individual brands can add modules to tailor the system to their specific needs. Many of those “specific” customizations will prove to be valuable to more than just the organizations they originated from. We therefore designed Thunder in a way that we can easily incorporate those add-ons into the main distribution and share the features among all brands.
We aim at becoming the best open-source content management system for professional publishing. In this, we focus on the creation of content. We want to help editors to create articles, to add media, to build landing pages, in short, to share their stories with the world.
We want Thunder to be a CMS jointly developed by its users and are therefore working towards building a community of publishers, IT agencies, and anyone else who shares our ideas and contributes to Thunder.
Our aim in doing so is to stay very close to the Drupal community and the Drupal core instead of creating a Thunder fork. Whenever we want to implement a new functionality or solve a problem, we try to do this in Drupal core or in the modules Thunder uses instead of fixing things in the distribution.
It’s difficult to measure the time spent on the development of Thunder, as this is an ongoing process. Currently, there are four developers employed by Hubert Burda Media working on the distribution full-time, plus several external developers. They focus on the advancement of Thunder as well as Drupal core and the contrib modules used in the distribution. A community manager is working on coordinating and growing the Thunder community of publishers, developers, and other partners.
Timeline and Milestones:
30th August 2015: Repository and first commits for Thunder
September 2015: playboy.de – the first website running on Thunder
November 2015: instyle.de – the second website running on Thunder as well as proof of concept of the sharing model
17th March 2016: Official press release about Thunder
October 2016: produceretailer.com is the first professional non-Burda website running on Thunder
30th January 2017: Release of Thunder 1.0
March 2016: One year after the official launch of the Thunder initiative, 15 websites (we know of) are running on Thunder.
1st June 2017: Release of Thunder 2.0
20th July 2017: Release of Thunder Admin Theme
20th November 2017: First community event, the Thunder Day in Hamburg
We released Thunder 1.0 in January 2017. One year later, at least 60 professional websites that we know of now run on Thunder. In the meantime, we have also released Thunder 2.0 and the Thunder Admin Theme.
Publishing houses grabbed the idea of working together. The Austrian publisher kurier.at, for example, contributed to the liveblog module used in Thunder and developed a new functionality to split text paragraphs.
In community matters, we talked to more than 300 companies worldwide. We established the “Certified Thunder Integrator” program to help publishers to find IT agencies as well as IT agencies to find customers. As of now, there are more than 20 companies certified or in the certification process.
We aim at bringing people together to share experiences. For this purpose, we introduced a Slack team for the Thunder community as well as several social media accounts. Furthermore, we organized the first community event – the Thunder Day – with around 120 participants in November 2017.
Challenges and how we resolved them:
Distributions such as Thunder face the problem of losing control after the installation. How should a distribution actually deliver features and updates? We thought a lot about this problem and introduced the Thunder Updater, the “Thunder way to keep your site up to date”. Thunder checks if installed configurations have been changed – if not, they can be updated. Otherwise, you will get a message telling you there’s an update pending and what to do if you wish to have it. This functionality is currently an integral part of the distribution but we plan to detach it and publish it as a module on drupal.org soon so that everybody can use it.
Writing an Admin Theme is very difficult because Drupal offers so many possibilities to adapt things: If you change something it can have unexpected effects in unexpected places. To avoid surprises, we developed Sharpeye, a visual regression tool. It takes screenshots and compares them in automated tests. This gives us a good overview. We open sourced the tool and you can download it here: github.com/BurdaMagazinOrg/sharpeye
Technical details, tips, and tricks:
We invested a lot of time into automated testing but it was well worth the effort, not only for Thunder but also for Drupal core and the contrib modules we use since we discovered a lot of bugs there too.
We don’t use a closed issue tracker but publish our tickets on drupal.org, thereby creating transparency. We use Github rather than drupal.org for the development because the developer experience is much better.
In professional publishing, it’s all about the story. It has to be easy to create a story, to extend it, to change its narrative strand, and to enrich it with multimedia content. We use the Paragraphs module for this. Instead of putting all their content in one WYSIWYG body field including images and videos, end-users can now choose on the fly between pre-defined Paragraph Types independent from one another. Paragraph Types can be anything you want from a simple text block or image to a complex and configurable slideshow. This allows editors to structure an article into sub-elements which can easily be created, edited, and reorganized.
Editors want to enrich their articles with pictures, videos, content from social media, and whatever else you might think of. Paragraphs are one part of this, the other is the combination of the Media Entity module and the Entity Browser module. With those modules, editors can easily upload new content but also find and reuse existing entities.
Search engine optimization plays a major role in every editor’s life. Thunder therefore gas a plethora of different adjusting screws, from several meta tags for Facebook, Twitter, and Open Graph up to the simple XML sitemap.
The editor’s daily life is a lot about planning. With Thunder, you can schedule articles, ensuring they will be published at a given date and time. Even more importantly, you can also schedule the time at which an article or a picture should not be shown on the website anymore, e.g. if the contract period for a photograph has ended or an event announcement isn’t useful anymore.
Improved Authoring Experience
Our primary focus is making the editors’ work with Thunder as easy as possible. In order to achieve this, we created the Thunder Admin Theme based on findings of user tests and a survey conducted with editors working with Thunder.
Since we get a lot from the Drupal community, we give our best to contribute back, e.g. by fixing the bugs we find through automated tests and by supporting Drupal events and code sprints with developer time, talks, and sponsoring. Christian Fritsch, a member of the Thunder Core Team, contributed a lot of his time to the media initiative. Ingo R?be, the initiator of Thunder, is a member of the Drupal Association’s Board of Directors.
There will be a security release of Drupal 7.x, 8.3.x, 8.4.x, and 8.5.x on March 28th 2018 between 18:00 - 19:30 UTC, one week from the publication of this document, that will fix a highly critical security vulnerability. The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days. Security release announcements will appear on the Drupal.org security advisory page.
While Drupal 8.3.x and 8.4.x are no longer supported and we don't normally provide security releases for unsupported minor releases, given the potential severity of this issue, we are providing 8.3.x and 8.4.x releases that include the fix for sites which have not yet had a chance to update to 8.5.0. The Drupal security team strongly recommends the following:
Sites on 8.3.x should immediately update to the 8.3.x release that will be provided in the advisory, and then plan to update to the latest 8.5.x security release in the next month.
Sites on 8.4.x should immediately update to the 8.4.x release that will be provided in the advisory, and then plan to update to the latest 8.5.x security release in the next month.
Sites on 7.x or 8.5.x can immediately update when the advisory is released using the normal procedure.
The security advisory will list the appropriate version numbers for all three Drupal 8 branches. Your site's update report page will recommend the 8.5.x release even if you are on 8.3.x or 8.4.x, but temporarily updating to the provided backport for your site's current version will ensure you can update quickly without the possible side effects of a minor version update.
This will not require a database update.
Patches for Drupal 7.x and 8.3.x, 8.4.x, 8.5.x and 8.6.x will be provided.
The CVE for this issue is CVE-2018-7600. The Drupal-specific identifier for the issue is SA-CORE-2018-002.
The Security Team or any other party is not able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at https://www.drupal.org/security, over Twitter, and in email for those who have subscribed to our email list. To subscribe to the email list: log in on drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.
Journalists interested in covering the story are encouraged to email firstname.lastname@example.org to be sure they will get a copy of the journalist-focused release. The Security Team will release a journalist-focused summary email at the same time as the new code release and advisory.
This new version makes Media module available for all, improves migrations significantly, stabilizes the Content Moderation and Settings Tray modules, serves dynamic pages faster with BigPipe enabled by default, and introduces a new experimental entity layout user interface. The release includes several very important fixes for workflows of content translations and supports running on PHP 7.2.
Media in core improved and available to all site builders
In Drupal 8.4, we added a Media API to core that drew on work from the contributed Media Entity module, but the module was hidden from the user interface due to user experience issues. In Drupal 8.5, many of the usability issues have been addressed, and the module now can be enabled normally. Media in Drupal 8.5 supports uploading and playing audio and video files, as well as listing and reusing media.
For an optimal user experience, we suggest enhancing the core feature set with the rich ecosystem of contributed modules that extends the core Media module. In future releases, we will improve the core user experience with a media library and other tools, add WYSIWYG integration, add support for remote media types like YouTube videos, and provide an upgrade path for existing basic File and Image field data on existing sites.
Settings Tray and Content Moderation now stable
Two experimental modules originally added with Drupal 8.2.0 have been steadily improving in past releases and are now stable. The Settings Tray module provides a quick solution to manage settings in context, such as moving items around in a menu block. The Content Moderation module allows defining content workflow states such as Draft, Archived, and Published, as well as which roles have the ability to move content between states. Drupal 8.5.0 also adds support for translations to be moderated independently.
New experimental Layout Builder module
The new experimental Layout Builder module provides display layout capabilities for articles, pages, user profiles, and other entity displays. Layout Builder uses the same " outside-in" user interface that Settings Tray module does, allowing site builders to edit their layouts on the actual page (rather than having to go to a separate form on the backend). The current user interface is a basic implementation but we expect it will improve significantly in the coming months.
Big steps for migrations
After over four years of work, this release marks the Migrate system's architecture stable. The Drupal Migrate and Drupal Migrate UI modules are also considered stable for upgrading monolingual sites. (Multilingual site upgrades are still not fully supported.) Support for incremental migrations is also included in this release. See the migrate announcement for further details on migrating to Drupal 8.
BigPipe by default
The BigPipe module provides an advanced implementation of Facebook's BigPipe page rendering strategy for greatly improved perceived performance for pages with dynamic, personalized, or uncacheable content. The module was added in Drupal 8.1.0 experimentally and became stable in Drupal 8.3.0. Following real-world testing, Big Pipe is now included as part of Drupal 8.5.0's Standard installation profile, so that all Drupal 8 sites will be faster by default. BigPipe is also the first new Drupal 8 feature to mature from an experimental prototype all the way to being part of a standard installation!
Groundwork for a Drupal 8 "Out of the Box" demo
Drupal 8.5.0 includes the groundwork for a new demo profile and theme from the Out of the Box Initiative, which will be a beautiful, modern demonstration of Drupal's capabilities. This will allow us to provide the demo experimentally, possibly in a future Drupal 8.5 release. (The demo profile and theme should not be used on actual production or development sites since no backwards compatibility or upgrade paths are provided.) If you'd like to see this demo in action, you can also see it in the 8.6.x development version.
PHP 7.2 now supported
Drupal 8.5.0 now runs on PHP 7.2, which comes with new features and improves performance over PHP 7.1. PHP 7.2 is now the recommended PHP version to use with Drupal 8.
What does this mean for me?
Drupal 8 site owners
Update to 8.5.0 to continue receiving bug and security fixes. The next bugfix release (8.5.1) is scheduled for April 4, 2018.
Updating your site from 8.4.5 to 8.5.0 with update.php is exactly the same as updating from 8.4.4 to 8.4.5. Drupal 8.5.0 also has updates to several dependencies, including a backwards-compatible update to a Symfony long-term-support release (which will be supported for many years). 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.
Note that Drupal 8 will require PHP 7 starting in March 2019, one year from now. If your site is hosted on PHP 5.5 or 5.6, you should begin planning to upgrade (and consider upgrading to PHP 7.2 now that it is supported). See the Drupal core announcement about the PHP 5 end-of-life for more information.
Minor releases like Drupal 8.5.0 include backwards-compatible API additions for developers as well as new features. Read the 8.5.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.4.x and earlier will be compatible with 8.5.x as well. However, the new version does include some changes to strings, user interfaces, internal APIs and API deprecations. This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.5.0 release candidate for more background information.
After over four years of work with over 570 contributors and 1300+ closed issues, Drupal 8.5.0 releases the Migrate system's architecture as fully stable. This means that developers can write migration paths without worrying for stability of the underlying system.
On top of that the Migrate Drupal and Migrate Drupal UI modules (providing Drupal 6 and 7 to Drupal 8 migrations) are considered stable for upgrading monolingual sites. All of the remaining critical issues for the Migrate Drupal module's upgrade paths and stability are related to multilingual migration support (so multilingual site upgrades are still not fully supported).
Support for incremental migrations is now also available, which means that site owners can work gradually on their new Drupal 8 site while content is still being added to the old site. When migrations (including incremental migrations) are run through the user interface, site owners will now see a warning if some data on the Drupal 8 site might be overwritten. (A similar fix for Drush is not yet available, so be careful not to overwrite data if you run a migration on the command line.)
Upgrade instructions for Drupal 6 and Drupal 7 sites can be found in the Upgrading to Drupal 8 handbook. Your old site can still remain up and running while you test migrating your data into your new Drupal 8 site. If you happen to find a bug, that is not a known migrate issue, your detailed bug report with steps to reproduce is a big help!
Unlike previous versions, Drupal 8 stores translated content as single entities. Multilingual sites with reference fields (node_reference, entity_reference) or multilingual menus can upgrade to Drupal 8 using Drush, executing the desired migrations one by one. In this process you need to create and run a series of additional custom migrations to reflect the new entity identifiers assigned during earlier migrations. There is no automation implemented for this process yet.
Data can be migrated to Drupal 8 also from non-Drupal sources such as CSV, XML, JSON, or directly from 3rd party systems' databases. For instructions and examples, refer to Migrate API handbook.
Huge thanks again to all the contributors who made this possible.
8.5.x makes the Media module available for all, improves migrations significantly, stabilizes the Content Moderation and Settings Tray modules, serves dynamic pages faster with BigPipe enabled by default, and introduces the new experimental Layout Builder module. The release includes several very important fixes for workflows of content translations and supports PHP 7.2. Finally, 8.5.0-rc1 also includes the same security updates that are provided in 8.4.5.
What does this mean to me?
For Drupal 8 site owners
Drupal 8.4.5, a security update and the final release of the 8.4.x series, has also been released this week. 8.4.x sites should update immediately to 8.4.5, but going forward, 8.4.x will receive no further releases following 8.5.0's release date, and sites should prepare to update from 8.4.x to 8.5.x in order to continue getting bug and security fixes. Use update.php to update your 8.4.x sites to the 8.5.x series, just as you would to update from (e.g.) 8.4.2 to 8.4.3. 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.)
If you're an early tester who is already running 8.5.0-alpha1 or 8.5.0-beta1, you should update to 8.5.0-rc1 immediately. 8.5.0-rc1 includes security fixes (the same fixes that were released in Drupal 8.4.5).
Some text changes were made since Drupal 8.4.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.4.x were automatically migrated to 8.5.x. Future bug reports should be targeted against the 8.5.x branch. 8.6.x will remain open for new development during the 8.5.x release candidate phase. The 8.5.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.
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.
In 2017 we saw the passing of J-P, community friend, mentor, leader, and contributor. Within the community J-P's was known for his passions: Drupal, programming culture, gardening, cycling and the environment.We invited people to share their memories of J-P and his impact; we share them with you now in memoriam. This is a moving tribute and a celebration of his life.
We invite you to also share your tributes in the comments section.
J-P Stacey on the Tour de Drupal 2016 Photo by Christian Ziegler
J-P was a bright intelligent, quirky chap, ADORED animals, he would melt at the mention of our pets names, he would happily spend hours cooing over stories of his beloved cat Indie, he'd oblige you in hours and hours of stories about your beloved animals - kae76
Whenever I was with JP he was always smiling. He was always there to help and it was always a pleasure to see JP at Drupal events and chat to him on IRC - aburrows
Nice. My overriding memory of J-P is how nice he was. When he moved up to Sheffield and started attending the Yorkshire meetups he fitted right in straight away. He always found time to ask how people were doing and genuinely cared what they were saying. He was always patient, positive and happy to help others - kmbremner
I remember first meeting J-P at DrupalCamp Oxford in 2012, when I had just started out running a small business and I remember thinking how much of a mad professor he looked, and discussing different parts of Oxford with him. The last time I saw J-P was sharing a meal with at DrupalCamp London 2017 near Euston. Both times J-P was actively seeking to engage people from the edges of the community (all the other Drupalists at the meal were freelancers or small businesses) and I know that was something he was highly instrumental at working with. I actually went back to that restaurant recently, and it seems slightly strange that I won't see J-P at another event - willhallonline
J-P being present just simply makes you happy, such an open genuine chap. Always disappointment around if he can't attend a catch-up, and anticipation if you know he will be there. J-P, always the gentleman, honoured my poor jokes with a titter or a laugh, even if it first met with an understandable groan - waako
I knew J-P, in that we participated together every year as mentors at the Friday Core Sprints at Drupalcon. Last year at Drupalcon Dublin, I asked J-P to be my "mentor mentor" because I was so impressed by his gentle and unruffled style. He organized the team at his table with exemplary grace and good humour. I was particularly struck by how quickly he gathered a group of enthusiastic people around him. Bye J-P, it was a true honour to have known you, if only once a year, in this particular context - michaellenahan
He was *always* cheerful! - greg.harvey
JP always took the time to talk to people and explain things to people who needed help. It's safe to say that helping people was a passion for JP - Ikit-claw
I recall the Friday evening of Drupalcamp London 2017, J-P and I met at Old Street Station and travelled to Kings Cross to meet up with fellow Drupalists for a meal at the Diwana Bhel Poori house for a meal. The trip and the hour long wait there for the rest to join us was filled with fun and interesting conversation. We realised how much we had in common and made each other laugh. That plus stimulating conversation over great food I will remember for a long while - TechnoTim2010
The thing I will always remember best about J-P his determination to stick to his principles; be they in code, in process, in environmental matters or even his house and garden! It was so sweet on occasion to see him struggle when pragmatism meant they couldn’t always be followed but it constantly reminded me to try harder myself. I miss J-P but I know I’ll be a better person for knowing him and looking up to him - rachel_norfolk
I met him via tour de drupal Amsterdam and Barcelona. J-P was cycling a long way alone, Criz and I would cycle the Pyrenees for 2 days and then we met for the final leg to Barcelona and had a really good time. I didn't get to know Stacey too much but felt he was a very calm, positive, free person - dasjo
Working on a project with J-P with him as lead developer and me acting as project manager, what I loved was the fact he would always push back on every story, but as we chatted about options, he'd end up getting excited and committing to even more than I expected to get in the first place - stevecowie
J-P was a brilliant companion on various Tour de Drupal cycle rides from the UK to wherever Drupalcon was being held. His great sense of humour, adventure and unflappable flexibility made him an excellent person to cycle with, and he was great at drawing people in, involving them and making everyone feel at ease. These same characteristics made him great fun to be around at a conference; I remember the "I'll do it if you will" approach that got us into talking at a Drupal unconference, with just a few minutes' notice in his case. He cared about others, and his strong sense of fairness and inclusion as well as pragmatism were of great value when there were difficult decisions to be made - martin_q
JP was involved with the modern web development apprentices (a.k.a. Drupal apprentices) programme in the UK. The last time I met JP was shortly before his holiday trip to Spain. We were scoping out some training days for the apprentices programme, as budget had become available to run 1-day topic-focussed trainings with external specialists. He was looking forward to training apprentices on test-driven development after his holiday - andrewmacpherson
#drupal #sprintweekend Sheffield 2016 Shared on twitter by @rivimey
The Drupaller & mentor
I was aware how deeply knowledgeable he was, and his ability to make that knowledge accessible to others, and his nature to always hear others out, always assuming he hadn't got the answer. He wasn't shy to press someone about a topic which he believed was being overlooked, or underrepresented - kae76
He was excellent at explaining and helping others - aburrows
I remember J-P presenting about Drush Make at DrupalCamp North West 2013. It really opened my eyes to how there was a more efficient way of doing things than I had known before. Years later he was a strong advocate for Composer evangelising the benefits to the local community and beyond - kmbremner
The thing I will remember most about J-P was his passion around open-source software. He was committed to Drupal and passionate about the community. It always seemed that he really cared about the *little* guy. The person starting up, or the newcomer to the community - willhallonline
He was always interested in problem solving, beyond that he was interested in understanding the problem, not solving it for you. He could explain code, like super-intelligent physics jokes, in the most clear manner and help you find direction. He would ask all the right questions about what you needed to achieve - waako
He totally "got" contrib, always looking for the pragmatic solution, always looking to use and/or improve existing code - greg.harvey
JP would take the time to help people learn code and point them in the right direction you could take to him on slack or irc and he would take the time to help you - Ikit-claw
J-P was always willing, if he had time, to help with any coding issues on IRC. He was busy much of the time. I would loved to have collaborated on a project with him, sadly never to be - TechnoTim2010
I’ve learned so much from J-P’s blog posts and always enjoyed our encounters at various events over the years. Highly technically competent and willing to spend time to share skills and knowledge, I saw J-P as part of the very fabric of what makes Drupal Drupal, the reason why I’ve hung around for so long - Steve Purkiss
Time. It didn’t matter how long it took for J-P to work with someone until they understood something - he’d see it through - rachel_norfolk
J-P was the alternative to Drupal stack exchange - stevecowie
JP shared his own learning very freely. After D8 came out JP set about learning the new API - he published what he learned on his blog, and those are some of the best D8 tutorials I've seen. "Did JP figure this out yet?" was often my first question, before approaching the official docs - andrewmacpherson
The future: what would J-P would want us to remember?
J-P would want us to remember the people behind the code; to spend the time helping new members of the community and making them feel welcome. To have a beer and get to know each other on a personal level - kmbremner
Documentation! Joking aside ... I honestly not sure how to answer this, fundamentally the J-P we all knew - cared about a lot of things, the environment, equal rights, good clean code, great clear documentation, meaningful social interactions and impact. But my everlasting memory is how much he held his family and friends in focussed concern - listening and hearing - sharing daft jokes and I personally honor him for his vulnerability he was an open book. This is the lesson I will learn and keep learning from J-P; listening and HEARING the ones you love, open honest vulnerability and there is never a bad time for a cat pun - kae76
Be kind to each other and get involved in the Drupal eco-system - aburrows
I think that the enduring message is that it is not about code. Code is far more ephemeral than community. People's enduring care for the Drupal community is what makes it powerful. And I feel that J-P knew that - willhallonline
He would want us to grow things, to experiment, cycle and to listen & engage with each other - waako
The planet - greg.harvey
I think he would want us to pay forward all the kind gestures he had done for others. If JP ever took the time to help you and see someone stuck who you could help I think he would want people to take 30 minutes to help someone else and encourage them - Ikit-claw
J-P was passionate about Drupal and would want us to share that passion, and help our fellow Drupalists. He was also passionate about Green issues and protecting and improving the environment, I am sure he would be happy I created a Drupal 8 site to support a campaign not to concrete over beautiful countryside, but instead push cycling and other non-destructive solutions -
We should consider our own green credentials and do anything we can for our local environment - TechnoTim2010
Learn, then teach - Steve Purkiss
His garden - rachel_norfolk
Go by your own pace - dasjo
From left to right: Christian, Youri, J-P, Stephen, Martin (Photo by Conor Cahill)
Reflections on Tour de Drupal 2016
Shared by MegaChriz - An evening in Belfast
On a cold Friday evening in Belfast - late September 2016 - J-P, Martin and Stephen arranged to meet me and Christian at a small restaurant in town. The streets were empty - as if everybody was either out of town or at home. But the restaurant was full till the brim - there was no more room inside. J-P, Martin and Stephen were sitting outside on the terrace of the restaurant when I and Christian arrived, having a drink and presumably trying to ignore the cold. Despite the cold, we had to wait for a table to become free inside before we could order some food (outside the ordered food would become cold in minutes, maybe even in seconds). So we sat there for about an hour and still no one came out to make room for us.
J-P had a hard time fighting his hunger and finally said "Maybe I should just go inside and stare at people to make them want to go away". J-P spread his eyes wide-open, pretend to be staring at us. That was one of the funniest moments I had with J-P.
J-P didn't go inside to stare people away, after some more time waiting there finally came room for us and together with Martin and Stephen, J-P ordered a 22 inch pizza.
Tour de Drupal 2016
The next two days we cycled together from Belfast to Dublin. It was a great ride with mostly flat land and sometimes lots of rain! There were also some hills and J-P had a hard time cycling these on his Brompton.
We hadn't arranged a overnight stay between the first and second cycle day, so on the first day J-P and Stephen had to make calls to several guest houses, bed and breakfasts, airbnb's, etc. to find a place for us to sleep. "Next time, I'll book an overnight beforehand," J-P said, "This was way too stressful."
The second day was more windy and because we seemed to be running out of time to get to Dublin the same day we took a shortcut. This was alongside a road where traffic was allowed to reach speeds of 100 km/hour. This was the part of the tour I didn't like much. One time I got blown to the berm, nearly falling off my bike! With time still running out I only got to Skerries as couldn't reach a higher speed (I took the rest by train). Despite that, I'm glad I have been able to cycle with this group.
It was our Tour de Drupal!
The Five Bikers Staring to the Sea. From left to right: Youri, Christian, Stephen, J-P, Martin. (Photo by Martin Quested)
This security advisory fixes multiple vulnerabilities in both Drupal 7 and Drupal 8. See below for a list.
Comment reply form allows access to restricted content - Critical - Drupal 8 - CVE-2017-6926
Users with permission to post comments are able to view content and comments they do not have access to, and are also able to add comments to this content.
This vulnerability is mitigated by the fact that the comment system must be enabled and the attacker must have permission to post comments.
The PHP functions which Drupal provides for HTML escaping are not affected.
When using Drupal's private file system, Drupal will check to make sure a user has access to a file before allowing the user to view or download it. This check fails under certain conditions in which one module is trying to grant access to the file and another is trying to deny it, leading to an access bypass vulnerability.
This vulnerability is mitigated by the fact that it only occurs for unusual site configurations.
A jQuery cross site scripting vulnerability is present when making Ajax requests to untrusted domains (the CVE for this issue in jQuery is CVE-2015-9251). This vulnerability is mitigated by the fact that it requires contributed or custom modules in order to exploit.
For Drupal 8, this vulnerability was already fixed in Drupal 8.4.0 in the Drupal core upgrade to jQuery 3. For Drupal 7, it is fixed in the current release (Drupal 7.57) for jQuery 1.4.4 (the version that ships with Drupal 7 core) as well as for other newer versions of jQuery that might be used on the site, for example using the jQuery Update module.
Language fallback can be incorrect on multilingual sites with node access restrictions - Moderately Critical - Drupal 8 - CVE-2017-6930
When using node access controls with a multilingual site, Drupal marks the untranslated version of a node as the default fallback for access queries. This fallback is used for languages that do not yet have a translated version of the created node. This can result in an access bypass vulnerability.
This issue is mitigated by the fact that it only applies to sites that a) use the Content Translation module; and b) use a node access module such as Domain Access which implement hook_node_access_records().
Note that the update will mark the node access tables as needing a rebuild, which will take a long time on sites with a large number of nodes.
The Settings Tray module has a vulnerability that allows users to update certain data that they do not have the permissions for.
If you have implemented a Settings Tray form in contrib or a custom module, the correct access checks should be added. This release fixes the only two implementations in core, but does not harden against other such bypasses.
This vulnerability can be mitigated by disabling the Settings Tray module.
External link injection on 404 pages when linking to the current page - Less Critical - Drupal 7 - CVE-2017-6932
Drupal core has an external link injection vulnerability when the language switcher block is used. A similar vulnerability exists in various custom and contributed modules. This vulnerability could allow an attacker to trick users into unwillingly navigating to an external site.
The following blog was written by Drupal Association Premium Supporting Partner, DrupalCamp London.
The people surrounding Drupal have always been one of its strongest selling points; hence the motto “Come for the code, stay for the community”. We bring individuals from a multitude of backgrounds and skill sets together to push forward towards a common goal whilst supporting and helping each other. Within the community, there are a number of ways to connect to each other; both online and in person. A good way to meet in person is by attending DrupalCons and DrupalCamps.
A DrupalCamp can be similar to a DrupalCon but is on a much smaller scale. Where a ‘Con has 1,600+ attendees a ‘Camp ranges anywhere from 50-600 people. In Europe alone there were over 50 camps in 2017, including DrupalCamp London.
DrupalCamp London brings together hundreds of people from across the globe who use, develop, design, and support the Drupal platform. It’s a chance for Drupalers from all backgrounds to meet, discuss, and engage in the Drupal community and project. DrupalCamp London is the biggest camp in Europe (followed very closely by Kiev), at ~600 people over three days. Due to its size and location, we’re able to run a wide range of sessions, keynotes, BoFs, Sprints, and activities to take part in.
What happens over the three days?
Friday (CxO day)
Friday ( CxO day) is primarily aimed at business leaders who provide or make use of Drupal services (i.e web development agencies, training companies, clients etc), but naturally, everyone is welcome. Throughout the day we'll have speakers talking about their experiences working with Drupal and Open Source technologies in their sector(s) or personal life. With a hot food buffet for lunch and a free drinks reception at the end of the day, you'll also have ample time to network with the other attendees.
Benefits of attending
Benefits for CTOs, CMOs, COOs, CEOs, Technical Directors, Marketing Directors and Senior Decision Makers:
Understand how leading organisations leverage the many benefits of Drupal
Network with similar organisations in your sector
Learn directly from thought leaders via specific case studies
Saturday/Sunday (Weekend event)
Over the weekend, we have 3 Keynote speakers, a choice of over 40 sessions to attend, BoF (Birds of a Feather) talks, Sprints, great lunch provided (both days) and a Saturday social. With all the activity there is something for everyone to get involved in.
Benefits of attending
Over 500 people attended the weekend event last year and we are expecting it to grow even more this year. Not all attendees are devs either, with a fair share of managers, designers, C-Level, and UX leads there's a great opportunity for all skill sets to interact with each other. Big brands use Drupal (MTV, Visit England, Royal.gov, Guardian, Twitter, Disney) and this is a chance to meet with people from those companies to compare notes, and learn from each other.
As above, the chance to meet so many people from various skill sets is a great way to line up potential interviews and hires for any aspect of your business. At the very least you'll be able to meet interesting people for any future potential hires.
Marketing & Raising company profile
Attending an event with a huge turnout is a great way to meet people and talk to them about what you and your company do. Embedding your name within the tight-knit Drupal community can attract the attention of other companies. Sponsoring the camp means that your logo and additional information can be seen around the camp, in tote bags given to attendees, and online. The social and sponsors stands are the perfect chance to talk to other companies and people attending DrupalCamp, to find out how they use Drupal for their benefit.
DrupalCamp isn't just for Devs, over the weekend there are sessions on a broad range of topics including community & business, UX, and general site building/using Drupal. The technical topics aren’t just Drupal specific either, this gives developers (and others) the ability to learn more about general core coding concepts and methodologies. The methods and techniques learnt help with day to day development and long-term work. In addition to the planned sessions, BoF (birds of a feather) sessions, there are ad-hoc get-togethers where people can talk on any topic, allowing a free discussion to share ideas.
Warm fuzzy feeling/giving back
Drupal (like any open source software) wouldn't survive without the community. Camps and other events allow the members to come together and see ‘first hand’ that they’re giving back to a community that helps power their tech, maintains their interests, and enables them to make a living.
How to get involved?
It’s easy to get involved with DrupalCamp London, check us out on Twitter for updates and you can find out more about the event and buy tickets on our website.
We have had a tradition since 2005. Every new year we have a posting on the predictions for the year ahead for our beloved open source CMS and community. Sometimes this posting went up in december, sometimes in January. But never in February.
Time to start a new tradition, predict the year ahead from February on :-)
Leave a comment if you do think that blogging will get hip again, RSS will gain new ground. What will the roll of the Drupal Association be in the new year? Where will the next DrupalCon be? Will the community grow and in what direction? API first, customer first, mobile first?
Polish your crystal ball and tell us what the future of Drupal wil be.
The following blog was written by Drupal Association Signature Supporting Partner, Open Social by GoalGorilla.
A living style guide - a way to control markup or CSS - has been making a name for itself. And for a good reason; they’re an important tool for web development. They keep developers in sync, communicate design standards, and help organize complex interfaces. In this post, I want to discuss how and why living style guides are important and how to implement one for Open Social using Drupal for software.
We're using a living style guide because it serves as a valuable internal resource for development; we’re able to write reusable and consistent code that's easy to maintain. And it’s a great external resource for client deliverables. Ready to see how to make a living style guide work with Drupal software? Let’s go!
Moving From Static to Dynamic
We didn’t always rely on a living style guide. Open Social was built and maintained using different strategies such as component libraries and atomic designs. These strategies have advantages, such as reusability, facilitating collaboration within the team, and ensuring design consistency. There were, however, disadvantages to a static style of working.
In the past, a component library or style guide was usually graphic-based. The designer would create a visual representation of a component (in PS or Sketch, for example) and then the front-end developer would transfer these visuals to HTML and CSS. This immediately meant double maintenance; for instance, if the markup or CSS changes, the graphics style guide would need to be updated to reflect this change and vice-versa. In our experience, the shelf life of these “static” systems is only a few iterations before the graphic version gets left behind and forgotten due to too much maintenance and not enough return. Yikes.
This is why we decided that it was time for a change. What we needed what a more dynamic system: a living style guide.
A Living Style Guide Is the Best
Any style guide is better than none but a living style guide is the best.
Sharing design capabilities. Our team easily shares design capabilities between designers and front-end developers, which also benefits the backend developers and project managers who work with us.
Less reliance on other team members. The developers refer to the style guide and reuse components for new features without being heavily reliant on the designers and front-end developers for implementation.
Most importantly, the client benefits. The project manager offers new feature ideas and lower-cost solutions to the client, based on reusing and recombining existing components. Inevitably our clients benefit from this, especially when they begin thinking this way themselves.
While this blog post focuses on how we work on Open Social enterprise projects, it is also an accurate reflection of working in the Drupal frontend nowadays. A quick google for “Drupal Living Style Guide” can give you some ideas about the current popularity, challenges, and general atmosphere surrounding the subject. In the next section of the blog, I will take you through the steps of setting up a living style guide with Open Social.
Side note: refer to this GitHub repo for an example of a component library within a Drupal theme folder structure, and package.json with dependencies, gulpfile.js for run KSSnode style guide and generate assets for the Drupal theme.
The Drupal Component Library Module and Twig Namespaces
The living style guide firstly requires the Component Library Drupal module to get up and running. The Drupal components library allows us to create custom twig namespaced paths. This means we are not limited to placing our components in the Drupal theme templates folder (as the current Drupal 8 architecture dictates).
The KSS style guide lives in our theme directory but has no knowledge of Drupal. This is what makes it so flexible. In theory, we can copy the component library directory and use it in other (non-Drupal) projects. A big thanks to John Albin, the maintainer of Zen Theme and KSS node, for paving the way for us to implement our theme and style guide.
Once the namespace has been defined, you can include and extend twig templates from the component library, Drupal’s template override files and other components (like in an atomic design approach) by simply referring to the files like this:
Social Blue comes with the style guide ready to go (read the Social Blue readme and follow the instructions on how to create a custom theme from it). However, because we have copied this to our custom theme folder, the gulpfile that runs the different tasks needs to be updated to reflect the new location in relation to the base theme (socialbase).
Basically, most of the action happens in the gulpfile. Spending some time reading its comments and exploring it really helps you understand the dynamics of linking a Drupal theme with a living style guide.
If we refer to the package.json, we will see which packages we have installed, and by examining the gulp tasks and configuration, we can get a sense of how the style guide is compiled from our component library and theme files.
We are relying on Drupal's theme layer to render the twig files from our components and attach the libraries (our CSS and js). We also rely on the component module to create the namespace allowing us to map Drupal variables with the json variables in our style guide.
The style guide copies Drupal’s theme assets (CSS and js) and has its own twig compiler (see os-builder folder).
The end result is the style guide made up of CSS/js copied from the base theme’s assets folder, our theme’s assets folder, and HTML generated from the twig and json, from our component library. The CSS/js copied from the assets folders need to be included in the gulpfile to be copied into your style guide.
(Side note: a nice little improvement is to have a designated folder, therefore avoiding the need to list each file.)
The Drupal HTML pages and the style guides are not shared. This is important to point out because caching might affect each differently.
Conceptually, we are dealing with 3 layers.
SocialBase component library (as CSS/js already compiled) and Drupal templates (handled by Drupal’s theme layer)
Custom theme extending base component library and drupal template
Diagram of how a component library, KSSNode style guide, and Drupal theme work together to make a living style guide
For front-end developers and designers, a living style guide is becoming an essential part of the web developer’s toolkit.
We are able to focus on the implementation of design components while the backend is being built, thus working in parallel with our team members instead of relying on others to finish before we can start.
We can do browser and accessibility tests on a component level, thus improving the quality of features (current and future). Another benefit (one that deserves a blog post on its own) is implementing visual regression testing on the living style guide to help spot changes in HTML or CSS negatively affecting existing elements.
The time investment needed, especially for a complex project, is nothing compared to the peace of mind knowing adding new elements does not break others.
The following blog was written by Drupal Association Premium Technology Partner, Lingotek.
It wasn’t a question of if, but a question of when and the Drupal.org weekly usage statistics are showing it’s happening now. Usage of Lingotek’s Drupal 8 Module finally caught up to and exceeded that of Drupal 7. Is this the tipping point? Is the community finally making the switch to the latest Drupal module?
The Drupal.org Usage Statistics for Lingotek Translation provides information about the usage of the Lingotek Translation project--Lingotek - Inside Drupal 7 Module and the Lingotek - Inside Drupal 8 Module--with summaries across all versions and details for each release. It shows the week and the number of sites that reported using a given version of the project.
The usage figures reflect the number of sites using the project/item that week. The results can give an idea of how popular the different projects are and may help users choose modules and themes for their own sites. The figures are an indicator of which modules are being used. Note: Only Drupal websites using the Update Status module are included in the data.
In the past 6 months, the Drupal.org weekly statistics showed Drupal 7 usage was still going strong. There were twice as many users using the Drupal 7 version in April, May, June, July, August, and September. But starting in October, Drupal 8 usage began to tick upward. In the first week, only 269 reported using the D8 version. Then the momentum quickly shifted. By the second week of October, they were almost equal with 441 users of Drupal 7 and 420 using Drupal 8; they were a scant 19 users apart. Then came the tipping point.
In the third week of October, Drupal 8 usage overtook that of Drupal 7. In a huge turnaround, 772 reported using Drupal 8 when compared to only 447 using Drupal 7.
Since then, the gap narrowed somewhat, but regained a solid lead once again in early November with 894 D8 users and 416 using the D7 version. We’re predicting the lead is here to stay. The tipping point was inevitable.
The support is likely the result of the growing need for localized content. Multilingual web content is critical to engage a global audience that wants to search, shop, and buy in their own language. The Drupal 8 version, with its built in multilingual capability, makes it easier than ever to create content for a global audience. The module supports translation of any content and configuration, including:
Content entities - nodes, comments, messages, taxonomy terms and even paragraphs (including nested ones)
Configuration entities - fields, blocks, taxonomy vocabularies, views, fields, etc.
Configuration items - site name, system emails, etc.
The Lingotek - Inside Drupal Module is the only Drupal module to integrate a Translation Management System directly into Drupal, allowing the Drupal community to use professional-grade translation technologies (e.g. machine translation, translation memory, CAT tool) without ever leaving the Drupal environment. It is built on Drupal's standard multilingual modules (Locale, content translation, entity translation, internationalization, etc.) and helps Drupal administrators, agencies, and web marketers get a Drupal site multilingual-ready within minutes, instead of days.
Many Drupal users have strong opinions about which is better--Drupal 7 or Drupal 8, but one thing is clear: Drupal 8 is the future. The level of innovation and improved functionality available in each new release will be hard to ignore. These usage statistics reflect that the community has begun wholesale migration to Drupal 8 and that we’ve finally reached the tipping point.
This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.
Over the course of the past seventeen years, I've witnessed the nature of the web change and countless internet trends come and go. As we celebrate Drupal's birthday, I'm proud to say it's one of the few content management systems that has stayed relevant for this long.
While the course of my career has evolved, Drupal has always remained a constant. It's what inspires me every day, and the impact that Drupal continues to make energizes me. Millions of people around the globe depend on Drupal to deliver their business, mission and purpose. Looking at the Drupal users in the video below gives me goosebumps.
Drupal's success is not only marked by the organizations it supports, but also by our community that makes the project more than just the software. While there were hurdles in 2017, there were plenty of milestones, too:
At least 190,000 sites running Drupal 8, up from 105,000 sites in January 2016 (80% year over year growth)
1,597 stable modules for Drupal 8, up from 810 in January 2016 (95% year over year growth)
4,941 DrupalCon attendees in 2017
41 DrupalCamps held in 16 different countries in the world
7,240 individual code contributors, a 28% increase compared to 2016
889 organizations that contributed code, a 26% increase compared to 2016
13+ million visitors to Drupal.org in 2017
76,374 instance hours for running automated tests (the equivalent of almost 9 years of continuous testing in one year)
Since Drupal 1.0.0 was released, our community's ability to challenge the status quo, embrace evolution and remain resilient has never faltered. 2018 will be a big year for Drupal as we will continue to tackle important initiatives that not only improve Drupal's ease of use and maintenance, but also to propel Drupal into new markets. No matter the challenge, I'm confident that the spirit and passion of our community will continue to grow Drupal for many birthdays to come.
Tonight, we're going to celebrate Drupal's birthday with a warm skillet chocolate chip cookie topped with vanilla ice cream. Drupal loves chocolate! ;-)
Note: The video was created by Acquia, but it is freely available for anyone to use when selling or promoting Drupal.
This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.
In this post, I'm providing some guidance on how and when to decouple Drupal.
Almost two years ago, I had written a blog post called "How should you decouple Drupal?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their Drupal architectures. Since that point, Drupal, its community, and the surrounding market have evolved, and the original flowchart needs a big update.
The traditional approach to Drupal architecture, also referred to as coupled Drupal, is a monolithic implementation where Drupal maintains control over all front-end and back-end concerns. This is Drupal as we've known it — ideal for traditional websites. If you're a content creator, keeping Drupal in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional Drupal 8 also remains a great approach for developers who love Drupal 8 and want it to own the entire stack.
What do you intend to build?
The most important question to ask is what you are trying to build.
If your plan is to create a single standalone website or web application, decoupling Drupal may or may not be the right choice based on the must-have features your developers and editors are asking for.
If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use Drupal to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.
Today, Drupal makes it much easier to build applications consuming decoupled Drupal. Even if you're using Drupal as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" Drupal.
Are there things you can't live without?
Perhaps most critical to any decision to decouple Drupal is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled Drupal, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.
For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where Drupal does not exert control over the front end.
How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling Drupal will remove all of the critical linkages within Drupal that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled Drupal can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.
What will the future hold?
In the future, and in light of the rapid evolution of decoupled Drupal, my hope is that Drupal keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. Drupal's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by Drupal grows.
I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in Drupal today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.
Today, developers are beginning to use Drupal not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.
Thankfully, Drupal is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in Drupal 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of Drupal the tools to interact with it in unprecedented ways.
Unlike many other content management systems, old and new, Drupal provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling Drupal, progressively decoupling it, and traditional Drupal — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets Drupal apart from new headless content management systems and most SaaS platforms, and it also shows Drupal's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; Drupal has the answer.
The following blog was written by Drupal Association Premium Supporting Partner, Phase2.
If you’re a marketer considering a move from Drupal 7 to Drupal 8, it’s important to understand the implications of content migration. You’ve worked hard to create a stable of content that speaks to your audience and achieves business goals, and it’s crucial that the migration of all this content does not disrupt your site’s user experience or alienate your visitors.
Content migrations are, in all honesty, fickle, challenging, and labor-intensive. The code that’s produced for migration is used once and discarded; the documentation to support them is generally never seen again after they’re done. So what’s the value in doing it at all?
YOUR DATA IS IMPORTANT (ESPECIALLY FOR SEO!)
No matter what platform you’re working to migrate, your data is important. You’ve invested lots of time, money, and effort into producing content that speaks to your organization’s business needs.
Migrating your content smoothly and efficiently is crucial for your site’s SEO ranking. If you fail to migrate highly trafficked content or to ensure that existing links direct readers to your content’s new home you will see visitor numbers plummet. Once you fall behind in SEO, it’s difficult to climb back up to a top spot, so taking content migration seriously from the get go is vital for your business’ visibility.
Also, if you work in healthcare or government, some or all of your content may be legally mandated to be both publically available, and letter-for-letter accurate. You may also have to go through lengthy (read: expensive) legal reviews for every word of content on your sites to ensure compliance with an assortment of legal standards – HIPPA, Section 508 and WCAG accessibility, copyright and patent review, and more.
Some industries also mandate access to content and services for people with Limited English Proficiency, which usually involves an additional level of editorial content review (See https://www.lep.gov/ for resources).
At media organizations, it’s pretty simple – their content is their business!
In short, your content is an business investment – one that should be leveraged.
SO WHERE DO I START WITH A DRUPAL 8 MIGRATION?
Like with anything, you start at the beginning. In this case that’s choosing the right digital technology partner to help you with your migration. Here’s a handy guide to help you choose the right vendor and start your relationship off on the right foot.
Once you choose your digital partner content migration should start at the very beginning of the engagement. Content migration is one of the building blocks of a good platform transition. It’s not something that can be left for later – trust us on this one. It’s complicated, takes a lot of developer hours, and typically affects your both content strategy and your design.
Done properly, the planning stages begin in the discovery phase of the project with your technology vendor, and work on migration usually continues well into the development phase, with an additional last-sprint push to get all the latest content moved over.
While there are lots of factors to consider, they boil down to two questions: What content are we migrating, and how are we doing it?
WHICH CONTENT TO MIGRATE
You may want to transition all of your content, but this is an area that does bear some discussion. We usually recommend a thorough content audit before embarking on any migration adventure. You can learn more about website content audits here. Since most migration happens at a code & database level, it’s possible to filter by virtually any facet of the content you like. The most common in our experience are date of creation, type of content, and categorization.
While it might be tempting to cut off your site’s content to the most recent few articles, Chris Anderson’s 2004 Wired article, “The Long Tail” ( https://www.wired.com/2004/10/tail/) observes that a number of business models make good use of old, infrequently used content. The value of the Long Tail to your business is most certainly something that’s worth considering.
Obviously, the type of content to be migrated is pretty important as well. Most content management systems differentiate between different ‘content types’, each with their own uses and value. A good thorough analysis of the content model, and the uses to which each of these types has been and will be used, is invaluable here. There are actually two reasons for that. First, the analysis can be used to determine what content will be migrated, and how. Later, this analysis serves as the basis of the creation of those ‘content types’ in the destination site.
A typical analysis takes place in a spreadsheet (yay, spreadsheets!). Our planning sheet has multiple tabs but the critical one in the early stages is Content Types.
Here you see some key fields: Count, Migration, and Field Mapping Status.
Count is the number of items of each content type. This is often used to determine if it’s more trouble than it’s worth to do an automated content migration, as opposed to a simple cut & paste job. As a very general guideline, if there are more than 50 items of content in a content type, then that content should probably be migrated with automation. Of course, the amount of fields in a content type can sway that as well. Once this determination is made, that info is stored in the Migration field.
The Field Mapping Status Column is a status column for the use of developers, and reflects the current efforts to create the new content types, with all their fields. It’s a summary of the Content Type Specific tabs in the spreadsheet. More detail on this is below.
Ultimately, the question of what content to migrate is a business question that should be answered in close consultation with your stakeholders. Like all such conversations, this will be most productive if your decisions are made based on hard data.
HOW DO WE DO IT?
This is, of course, an enormous question. Once you’ve decided what content you are going to migrate, you begin by taking stock of the content types you are dealing with. That’s where the next tabs in the spreadsheet come in.
The first one you should tackle is the Global Field Mappings. Most content management systems define a set of default fields that are attached to all content types. In Drupal, for example, this includes title, created, updated, status, and body. Rather than waste effort documenting these on every content type, document them once and, through the magic of spreadsheet functions, print them out on the Content Type tabs.
Generally, you want to note Name, Machine Name, Field Type, and any additional Requirements or Notes on implementation on these spreadsheets.
It’s worth noting here that there are decisions to be made about what fields to migrate, just as you made decisions about what content types. Some data will simply be irrelevant or redundant in the new system, and may safely be ignored.
In addition to content types, you also want to document any supporting data – most likely users and any categorization or taxonomy. For a smooth migration, you usually want to actually start the development with them.
The last step we’ll cover in this post is content type creation. Having analyzed the structure of the data in the old system, it’s time to begin to recreate that structure in the new platform. For Drupal, this means creating new content type bundles, and making choices about the field types. New platforms, or new versions of platforms, often bring changes to field types, and some content will have to be adapted into new containers along the way. We’ll cover all that in a later post.
Now, many systems have the ability to migrate content types, in addition to content. Personally, I recommend against using this capability. Unless your content model is extremely simple, the changes to a content type’s fields are usually pretty significant. You’re better off putting in some labor up front than trying to clean up a computer’s mess later.
In our next post, we’ll address the foundations of Drupal content migrations – Migration Groups, and Taxonomy and User Migrations. Stay tuned!
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!
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
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.
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.
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.
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.
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".
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."
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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!