If this tutorial is not what you were looking for, you still have any questions, suggestions or concerns - feel free to let us know. Please help us to serve you better!

Your Name

Your Email

Your Message (required)

captcha

Drupal News and Updates

This page will show you the most recent Drupal templates updates and Drupal Community news.

Drupal Templates News and Updates

December 3, 2012. The New Word In Creating Drupal Stores

December 03 2012 | Category: Drupal Updates

The creators of Drupal Commerce decided to bring their favorite CMS to masses. When speaking with one of TemplateMonster’s Drupal developers, he said: “I can’t understand, why users don’t use Drupal, it’s so simple…” Commerce Guys, those who created Drupal Commerce stores, got to be thinking that way.

Read More

May 03, 2012 – Drupal 7.14 released

May 09 2012 | Category: Drupal Updates

(Russian) В этой заметке вы узнаете о проблемах сопутствующих обновлению ядра Drupal 7.14.

Read More

Responsive Drupal templates

April 09 2012 | Category: Drupal Updates

Responsive Drupal templates include several layout options – each is optimized for proper screen resolution.

Read More

Drupal 6.19 templates

April 26 2011 | Category: Drupal Updates

Drupal templates starting from #30278 are compatible Drupal 6.19

Drupal 6.19 release anouncement is available here. You can also check the release notes to see the updates…

Read More

Drupal 7 templates are available

April 26 2011 | Category: Drupal Updates

Drupal templates starting from #32668 are compatible with Drupal 7

Drupal 7 features:

  • Vastly improved administrative user interface thanks to the D7UX movement
  • Flexible content and custom fields
  • Better visual presentation and theming with Render API
  • Accessibility is greatly improved
  • Image support is now included
  • Automated code testing
  • Improved database support
  • Better distribution support
  • Support for the Semantic Web through
Read More

Drupal 6.17 compatible templates

June 22 2010 | Category: Drupal Updates

Drupal templates starting from #29476 are compatible with Drupal 6.17

Drupal 6.17, a maintenance release fixing issues reported through the bug tracking system, is now available for download. There are no security fixes in this release. Upgrading your existing Drupal 6 sites is recommended. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement.

Highlights …

Read More

Drupal Themes are Now Available!

April 04 2008 | Category: Drupal Updates

After having launched Joomla and Mambo CMS templates last fall we have noticed that even though these two product types are strikingly popular the audience still wants more. Therefore in response to this growing demand for various CMS products we have decided to be so kind and to launch a new CMS designs range which we have chosen to be …

Read More

Drupal News and Updates

Drupal 8.1.3 and 7.44 released

15 June 2016, 7:32 pm

Drupal 8.1.3 and 7.44, maintenance releases which contain fixes for security vulnerabilities, are now available for download.

See the Drupal 8.1.3 and Drupal 7.44 release notes for further information.

Upgrading your existing Drupal 8 and 7 sites is strongly recommended. There are no new features or non-security-related bug fixes in these releases. For more information about the Drupal 8.1.x release series, consult the Drupal 8 overview. More information on the Drupal 7.x release series can be found in the Drupal 7.0 release announcement.

Security vulnerabilities

Drupal 8.1.3 and 7.44 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

To fix the security vulnerabilities, please upgrade to either Drupal 8.1.3 or Drupal 7.44.

Change log

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

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

Update notes

See the 8.1.3 and 7.44 release notes for details on important changes in each release.

Known issues

See the 8.1.3 and 7.44 release notes for details on known issues affecting each release.

Security information

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

Drupal 8 and 7 include the built-in Update Manager module, which informs you about important updates to your modules and themes.

Bug reports

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

Why test?

The goal of automated testing is confidence: confidence in application stability, and confidence that new features work as intended. Continuous integration as a philosophy is about speeding the rate of change while keeping stability. As the number of contributing programmers increase, the need to have automated testing as a means to prove stability increases.

This post is focused on how the automated testing infrastructure on Drupal.org works, not actually writing tests. Much more detail about how to write tests during Drupal development can be found in community documentation:

Categories of testing

DrupalCI essentially runs two categories of tests:

Functional tests (also called blackbox testing) are the most common type of test run on DrupalCI hardware. These tests run assertions that test functionality by installing Drupal with a fresh database and then exercising that installation by inserting data and confirming the assertions complete. Front-end tests and behavior driven tests (BDD) tend to be functional. Upgrade tests are a type of functional tests that run a full installation of Drupal, then run upgrade commands.

Unit tests run assertions that test a unit of code and do not require a database installation. This means they execute very quickly. Because of its architecture, Drupal 8 has much more unit test coverage than Drupal 7.

These test categories can be broken down further into more specific test types.

What testing means at the scale of Drupal

Drupal 8, with its 3,000+ core contributors and 7,288 contrib developers (so far), needs testing as a means to comfortably move forward code that everyone can trust to be stable.

Between January and May 2016, 90,364 test runs were triggered in DrupalCI. That is about 18,000 test runs requested per month. Maintainers set whether they want tests to run on demand, with every patch submitted, or nightly. They also determine what environments those tests will run on; there are 6 combinations of PHP and database engines available for maintainers to choose from.

The majority of these test runs are Drupal 8 tests at this point. (19,599 core tests and 47,713 contrib project tests were run during those 5 months.) Each test costs about 12 cents to run on Amazon Web Services. At the time of writing this post, we averaged around $2,000 per month in testing costs for our community. (Thank you supporters!)

An overly simple history of automated testing for Drupal

Automated testing first became a thing for Drupal contributed projects during Drupal version 4.5 with the introduction of the SimpleTest module. It was not until Drupal 6 that we started manually building out testbots and running these tests on Drupal.org hardware.

In Drupal 7, SimpleTest was brought into Drupal Core. (More information about what that took can be reviewed in the SimpleTest Roadmap for Drupal 7.)

In Drupal 8, PHPUnit testing was added to Drupal Core. PHPUnit tests are much faster than a full functional test in SimpleTest—though runtest.sh still triggers a combination of these test types in Drupal 8.

The actual implementation of automated testing was much more complicated than this history suggests. The original testbot infrastructure that ran for 7 years on Drupal.org hardware was manually managed by some fiercely dedicated volunteers. The manual nature of that maintenance led to the architecture of DrupalCI, which was meant to make it easier to test locally at first and later focused on autoscaling on powerful hardware that could plow through tests more quickly.

DrupalCI's basic structure

In The Drupal.org Complexity, we could see the intricate ways that Drupal's code base interacts with other parts of the system.

Representation of the relationships between services and sites in the Drupal.org ecosystem.

We could further break out how systems like DrupalCI are interrelated.
Highlighted relationships between testing and other services.

DrupalCI is a combination of data stored on Drupal.org, cron jobs, drush commands, and most importantly a couple of Jenkins installations to manage all the automation.

Jenkins is the open source automation server project that makes most of the system possible. We use it for automating our build process and deploying code to our dev, staging and production environments. It automates just about anything and is used by companies small and large to run continuous integration or continuous deployment for their applications. It's considered a "best practice" solution alongside options like Travis, CircleCI, and Bamboo. They all have slightly different features, but automation is at the core of most of these DevOps tools.

To provide continuously integrated tests, you need to trigger those tests at a moment when the tests will have the greatest value.

The three triggers for running a test job are when a patch is added to an issue comment, when code is committed to a repository or daily on a cron. Maintainers can specify which triggers are associated with which branches of their projects and which environments should run those tests.

For core these settings look something like this:

Screenshot of the automated testing settings for Drupal Core.

This detail allows for specific tests to run at specific times per the Drupal.org Testing Policy for DrupalCI.

To make this automation happen, we have an installation of Jenkins (Infrastructure Jenkins below) that is polled by Drupal.org once per minute with testing jobs to be queued.

These jobs live in a database record alongside Drupal.org.

The infrastructure jenkins instance polls Drupal.org once per minute looking for new jobs to queue.

Infrastructure Jenkins speaks to the CI Dispatcher (also Jenkins) where the testing queue regularly passes those jobs to available testbots. CI Dispatcher uses an Amazon Web Services EC2 plugin to spin up new testbots when no existing testbot is available. Each testbot can spin up Docker containers with the specific test images defined by the maintainer. Theses containers pull from DockerHub repositories with official combinations of PHP and database engines that Drupal supports.

The CI Dispatcher maintains the queue of jobs to run. When a job is ready, it uses an EC2 plugin to use an existing testbot or spin up a new bot as needed.

After a testbot is running, the CI Dispatcher is in constant communication with the bots. You can even click through to the console on CI Dispatcher and watch the tests run. (It's not very exciting—perhaps we should add sound effects to the failures—but it is very handy.)

Once the testbot has been spun up, the CI Dispatcher listens to it for results.

Once per minute, Drupal.org polls the CI Dispatcher for test status. It responds with pending, running, failed or passed. Failed and passed tests are then pulled back into Drupal.org for display using the Jenkins JSON API.

 pending, running, failed, passed. All the results are pulled back into Drupal.org using the Jenkins' JSON API.

Tests can also be run on demand at the patch, commit or branch level using the handy "add test" and "retest" links.

Why did we build this ourselves? Why not use [insert testing platform here]

Lot's of people have asked why we don't use TravisCI, CircleCI or some other hosted testing solution. The short answer is that most publicly available testing systems require Github authentication and integration.

Additionally, our testing infrastructure is powerful because of its integration with our issue queues. Read the aforementioned The Drupal.org Complexity for more information.

Another reason to run our own testing is scale. To get through all of the core tests for Drupal 8 in an acceptable amount of time (about 44 mins on average), we run very large testbots. These bots have 2 processors with 8 hardware cores. With hyperthreading, that means we have 32 hardware execution threads—about 88 EC2 compute units. They are not exactly super computers, but they are very performant.

We average nearly 18,000 test runs per month. During our peak usage we spin up as many as 25 testbot machines—though usually we cap at 15 bots to keep costs under control. This helps us plow through our testing needs during sprints at DrupalCons and large camps.

We have explored using an enterprise licensed version of either Github or CircleCI with our own hardware to tackle testing. That same consideration has been given to SauceLabs for front-end testing. Right now, there is not a cost savings to tackle this migration, but that does not rule it out in the future. Testing services continues to evolve.

Accelerating Drupal 8

In my first months as CTO, I was told repeatedly that the most important thing for us to work on was testing for Drupal 8. In those early days as I built out the team, we were mostly focused on catching up from the Drupal 7 upgrade and tackling technical debt issues that cropped up. In DrupalCon Austin, I had members of my team learn how to maintain the testbot infrastructure so that we could take over the process of spinning up bots and dealing with spikes in demand.

By early 2015, we had optimized the old testbots as much as they were going to be optimized. We moved them to AWS so we could spin up faster machines and more bots, but there were features that were waiting on the new DrupalCI infrastructure that were blocking key development on Drupal 8.

In March of 2015, we invited all the community developers that had helped with DrupalCI to the Drupal Association offices in Portland and sprinted with them to figure out the remaining implementation needs. The next couple of months involved tweaking DrupalCI's architecture and cutting out any nice to have features to get something launched as soon as possible.
It is no coincidence that from the time of DrupalCI's launch until the release of Drupal 8, progress was rapidly accelerated.

I am immensely proud of the work of all the community members and staff that worked directly with core maintainers to unblock Drupal 8 development and make it faster. This work was critical.

Thank you to jthorson, ricardoamaro, nick_schuch, dasrecht, basicisntall, drumm, mikey_p, mixologic, hestenet, chx, mile23, alexpott, dawehner, Shyamala, and webchick. You all made DrupalCI. (And huge apologies to all those I'm undoubtedly leaving out.) Also thank you to anyone who chimed in on IRC or in the issue queues to help us track down bugs and improve the service.

What's next for testing Drupal

Most of the future state of testing is outlined in the Drupal.org Testing Policy for DrupalCI.

Key issues that we still need to solve are related to concurrent testing improvements and new test types to support. While we have PhantomJS integrated with the test runner, there are optimizations that need to happen.

Testing is not an endpoint. Like much of our work, it is an ongoing effort to continuously improve Drupal by providing a tool that improves how we test, what we test, and when we test.

Picture of Matthew LechleiderMatthew Lechleider (Slurpee) has been active in the Drupal community for over a decade, and his hard work has directly led to an incredible amount of community growth. The founder of a Chicago Drupal User Group and our community’s chief advocate for the Google Summer of Code and Google Code-In programs, Matthew has been a key part of growing the Drupal project and our global community. Here's his Drupal story.

“In 2005, I was a full-time university student working at an internet service provider so I could put myself through school,” Matthew said. “I was working as a network/systems person, and since I was at an ISP we had a lot of people calling us and asking the same questions over and over. At the time, I knew bit about web development and programming, and I thought, ‘I bet I could make a website that would answer these people’s questions.’ And that’s how I found Drupal. I proposed it to my boss, and the next thing I knew I was working on a full-time project getting paid to work with Drupal 4. I built the website and it was really popular— and we noticed that the phone calls went down. We were tracking our support calls at the 24-hour call center, and when people called for help, we would refer them to the website as a resource. So it really was a big help."

After that, the next steps were logical for Matthew. He put together a Drupal meet-up at his Chicago-based company. The group grew quickly each month, and in no time at all, people were asking about training and “Introduction to Drupal” classes. "I started teaching those classes,” Matthew said, "and then next thing you know, people were asking for private trainings and businesses were asking me to come to their offices and train new Drupal developers. When the people I was training came back with advanced questions, I realized how much money they were making, so in 2008 I went from being a network engineer to focusing on Drupal full-time. Since then, I’ve started a Drupal business and worked on some very big projects."

"I never thought I would be a web developer, but I fell into Drupal, saw how great and easy it was, and decided it was a good thing to be a part of,” Matthew added.

Over his time in Drupal, Matthew has converted a lot of Chicagoan web developers into Drupal users. “It's pretty cool to be part of something bigger than yourself,” Matthew said. “It's like a big tidal wave — I feel like I’ve been riding this Drupal wave for a long time. I didn’t think I’d still be work with Drupal this many years later."

Why Slurpee?

Many people in the community know Matthew only by his user username, Slurpee. But how did he come by that handle?

"I was probably eight or nine years old, learning about computers, and I had some nicknames I was playing around with. But it’s like that movie ‘Hackers’: you have to have your handle, you have to have your identity. It was the middle of a hot July in the summer, and as I was figuring out what I should call myself, I realized I had bout 20 empty slurpee cups surrounding my computer. I really do like slurpees. So that’s where that came from."

Drupal 8

As a long-time Drupal user and evangelist, Matthew is incredibly excited for Drupal 8.

" I have a traditional programming background in computer science, and Drupal wasn’t always the most professional CMS,” Matthew said. “Now, I’m very excited about Drupal 8— it’s like Drupal grew up and went to college and got a graduate degree. Drupal 8 is the way Drupal should have been a long time ago. I’ve built some of the biggest Drupal projects in the world, and when you’re talking to those kinds of massive clients, it’s hard to sell systems like Drupal four, five, and six. They’re out paying the big money for the huge enterprise solutions, and Drupal 8 is big. It’s ready to go, and I really think it's on par with everything else these days."

When asked about his favorite Drupal 8 feature, Matthew said, “As I work with big sites, it’s been a big struggle to deal with continuous integration, which is resolved in Drupal 8. As a person with a sysadmin background, I think integration is probably the thing that will save the most headaches. It’s going to be a very cool tool to work with."

Google Summer of Code and Google Code-In

Matthew is also heavily involved in several of Google’s student coding programs, and runs point on keeping Drupal in the Google Summer of Code (GSoC) and Google Code-In (GCI) programs.

“I’m a bit younger than other people in the community, and I started with Drupal when I was 19 years old or so. I was going to college when I got into Drupal, and I remember talking to people about it at school... and nobody had any clue about it, not even my teachers,” Matthew said. “Fast forward several years: I was working in the community, specifically on the VoIP Drupal module suite. At the time, we had a student come to us about GSoC —this was in 2012— and he said, ‘hey, I want to work on this project for you guys as part of the GSoC. Can you be a mentor?’ I said sure, and that’s all I was that first year. The next year, nobody wanted to organize GSoC for Drupal, so I stepped up and said that I liked the program and would get the ball rolling. I spent a lot of time revamping the things that Drupal does with Google, got us accepted back into the program, and we’ve been participating every year since, both in the Google Summer of Code, which is for university students, and the Google Code-In, which is for students ages 13 through 17.

“Getting back to what I said earlier about being a student, when nobody knew what Drupal was, it was a bit harder to get involved. Knowing that there’s a program like this in schools around the world, pushing these projects to students, I think it’s critical for us to participate. If we want this project to continue to be successful, we have to focus on younger people. They’re the ones who are adapting and changing the tech as we know it, and if they don’t know about Drupal, they won’t use it. But if we embrace these kids and show them how awesome Drupal can be — we have impressive students doing impressive stuff— it’s great for everyone. That’s why I think it’s super important that we spend so much time on the GSoC and GCI programs."

For those who are interested in getting involved, there are both GSoC and GCI Drupal Groups, a documentation guide for GCI, and a guide for the GSoC students who are just getting started. There is also a #drupal-google IRC channel on free node.

“It’s fairly easy to get involved,” Matthew said. “If you’re interested in helping, join the groups — we send out lots of updates — or you can can contact me directly. You can find us on IRC, or if you know of a student who wants to get involved, all they need to do is read the documentation. It covers everything. We spent a lot of time on that documentation,” Matthew said.

Being part of something bigger

When asked what drives him to participate and organize the community, Matthew’s answer was simple.

"Honestly, it’s all about being part of something bigger than myself,” he said. "I’ve been participating in computer hacker nerd groups since I was a kid, and back then (in the 90s) it was fairly difficult to find out about these kinds of groups. I attended something called 2600 — does anyone else remember that? — I thought it was so cool to be a part of something like that. I’ve been in IRC every day for over 20 years participating in communities, and it’s so exciting to be part of a huge thing bigger than myself. Now I’m getting recognized for it in Drupal, which is cool,” he added.

"Drupal is by far the largest community I’ve participated in from that point of view, and it’s been an exciting ride. Honestly, I thought it would have been over by now — I’ve been part of the community for over 10 years and that’s a long time — but I’m excited to see where it goes. For me, Drupal is more of a lifestyle than a career. Technically I’m a web developer, but I spend so much of my time volunteering and going to events. I can go to a DrupalCon in another country and see my friends from all over the world. Seeing how mature our community has become over the past decade continues to excite me, and and I plan to be part of this for as long as possible."

“The money’s not bad either,” he added. “I live a comfortable life working from home. I like to travel a lot, go to music festivals, or go on Phish tour for weeks at a time, but I can still work. I have a mobile hotspot, and just bring my laptop with me. I can’t tell you how many times I’ve been set up at a camping spot in the middle of nowhere, working on my laptop, or how many times I’ve been in a random country looking for internet so I can get some work done.”

“Working remotely, or working from home, gives me a lot of freedom. It lets me go to the skate park when all the kids are at school— I skateboard, and bring my board with me when I travel — and there’s time for me to go running every day. It’s actually one of my favorite activities, my running break — halfway through the day, I get up and I go running. It helps me keep my sanity."

"I also like to snowboard,” Matthew continued. “I’ve been skateboarding since I was 5 — since I could walk and talk I’ve been skateboarding — and I started snowboarding a couple years after that. Going to DrupalCon Denver was exciting, and there was a DrupalCon snowboard trip. Lots of people went to Breckenridge together, and that’s the other cool thing about the community: these people are fun, they like to go out and do things together."

Helping camps and communities around the world

After a decade in the Drupal community, Matthew has a lot of great memories of traveling, teaching, and sharing.

“I was invited to organize the first DrupalCamp in Sri Lanka and hold training classes there,” Matthew said. “It’s an island just off the coast of India, and when I went in 2012, they had just finished having a civil war. I was one of the only foreigners there, and there was military presence walking around. I wasn’t allowed to leave my hotel unless the Drupal people came and picked me up, and they were absolutely wonderful. They were so nice and appreciative, and so many people were incredibly smart and really talented. After I did a training or presentation, they all had a million questions and we ended up talking for hours. And that was when I had an ‘aha!’ moment and really felt like I was part of something bigger. It drove home that it’s my responsibility to spread the word of Drupal as much as possible."

“That was actually one of the trainings that I did when I was traveling a lot” Matthew added. “I literally traveled for years living out of hostels, and couch surfing. I was being contracted at the time to go teach Drupal in Europe, Asia, and Australia."

And for Matthew, one of his proudest accomplishments is Drupal’s participation in the GSoC and GCI programs.

"I think it’s cool that I maintain Drupal’s relationship with Google,” he said. "It’s Google. They’re the biggest tech company ever, and I have this relationship with multiple people at their offices. They’re all super nice and it’s great that they’re pushing this open source stuff. They want our community's feedback, and I think it’s really cool that I can represent Drupal with Google. They’re trying to give us money and get us to do more with the students. It’s something I think is really great."

The importance of networking

When asked if he had any advice for new Drupal users, Matthew had several thoughts to share.

“Find your local communities and participate,” he advised. “Go to as many events as you can. If you have to drive a couple of hours to go to a Drupal camp, do it. If there isn’t a local community in your area, start one. If you go to meetup.com and post a similar topic, even if just one other person shows up, that’s cool and the community will grow. Drupal is a software, but it helps to get some face time in with other people. Network. Go out. Have some coffee (or beer). Hang out. Bring your laptop and start sharing ideas— you’ll be surprised at how welcoming the Drupal community is. I can’t tell you how many times I’ve sat at the bar until the bar kicked us out just helping people fix websites and giving free training.

“If you’re struggling, it’s important to network with other groups — non-Drupal groups — like a web-dev group or an open source group or a Linux group or something. That’s what helped me when I did the first Drupal camp for Chicago 2008. We were thinking 100 people might show up, but we did a lot of networking. I contacted every tech user group in Milwaukee, Detroit, southern Illinois, and Minnesota. I found every group that was related to web or open source or Drupal, and I contacted every one of their organizers. Within a couple weeks we had over 200 registrations, and people were emailing us about hotels and hotel accommodations. It was a big wow moment for us."

As for those who are involved in the community and want to do more, Matthew has a few tips.

“If you want to teach training, my advice is not to focus on the curriculum. Everywhere I go, everyone wants me to submit my curriculum. I’ve taught a lot of classes, and I’ve learned that every group of students is going to be different. I can’t tell you how many times I had a curriculum and thought I was going to go through the whole thing, and instead I wind up talking about something else. Make sure you understand your students, and teach them what they want to learn about.

“And it’s not even all that difficult,” he added. “Here’s what I do for Global Training Days. You know what happens when you make an event that’s free anything? You get all sorts of people registering. So I keep the classes as small as possible — so whenever anybody registers for the event, I don’t give them the address unless they give me their phone number. When someone registers, I call them and ask them, 'what do you want to get from this training,' 'what is your experience,' — and I can’t tell you how many people have thanked me for that. Requiring a phone call with the registration helped keep the classes smaller, and limit it to people who were actually new to Drupal and would be in proper context of attending a GTD. So, that’s my advice — know your audience. Don’t assume everyone knows about Drupal. Don’t worry about a set curriculum — go with what you students are actually looking to gain from the experience."

For those who are looking for more tips, tricks, and knowledge from Matthew, his wisdom will soon be available at your fingertips in paperback form.

“I’m working with Packt publishing on a collection of ‘Drupal 8 Administration Cookbook Recipes.’ They’re step-by-step tutorials that teach admins to do everything from getting started with Drupal to doing advanced site building stuff, and it's coming out in later this summer. I’m pretty excited about it! I’ve always read a lot of the Drupal books and I’m excited to make a contribution. I started on my own but have had a Drupal business for several years, and have had several people who have worked for me. The book is literally just a collection of all the same questions every client always asks. It’s almost like a tell-all: here’s step-by-step documentation for how to do everything. Now stop asking us,” he added with a laugh.

Front page news: 

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

DrupalCon New Orleans Logo

The team is back from New Orleans and thankful for the time we had to spend with the community, attending sessions, presenting sessions of our own, and sprinting with you throughout the Con. As individuals, we’re all members of the community, and as an organization we're proud to hold the home of the community in trust.

Because of DrupalCon North America, May is always a busy month for the Association engineering team. We're preparing our sessions, ensuring that the testbots will be running smoothly for DrupalCon sprints, and polishing new features and ideas to share with the community. Here's what's new:

Drupal.org updates

Composer repositories moving towards stable

Drupal.org Composer Logo

At the end of April, we launched the Alpha of our Composer façade, providing Composer repository endpoints on Drupal.org for Drupal 8 and Drupal 7. At DrupalCon New Orleans, we gave a presentation on the architecture of the Composer façade, and our plans for next steps. We also received some great feedback from users who helped us test the alpha release, and in May we've focused on moving Composer from an alpha release to a more stable environment suitable for use on production Drupal sites. We'll be following up soon with a more detailed blog post about Composer, when that more stable release is available.

If you want to help test the Composer service, you can learn more about Drupal.org's Composer repositories.

New documentation content types

As previewed in our session at DrupalCon New Orleans, we're modernizing Drupal documentation with two new content types: Guides, and Documentation Pages. Documentation Pages will be organized in Guides, which will be curated by maintainers. We're also bringing a new visual design to documentation, re-organizing documentation by major version of Drupal, and developing a call-outs feature to help highlight key information like best practices or important changes in minor versions.

In May, we made an initial deployment of these content types to Drupal.org, though access is presently restricted to administrators while we work with the Documentation Working Group to sort out our initial migration plan. In June, we hope to deploy a migration tool, allowing users to convert existing documentation Book Pages and their children into the new Guides and Documentation Pages.

CKEditor

We've also deployed CKEditor to Drupal.org. The WYSIWYG editor is now available on the Section, Page, and Post content types, as well as the incoming Documentation Guide and Documentation Page types. CKEditor brings a more robust editorial experience to Drupal.org, and as it gets wider use we’ll expand it to additional content types. We also want to allow time for the Dreditor maintainers to update to support the change. As a long-term goal, we hope that some of the features of Dreditor may be reimplemented as CKEditor plugins and directly available to every Drupal.org user without the use of a 3rd party browser extension.

Sustaining support and maintenance

DrupalCon Dublin full site launched

DrupalCon Dublin Logo

At DrupalCon New Orleans, we launched the full site for DrupalCon Dublin. The call for papers is open now, as is registration, so submit your sessions and purchase your tickets soon. DrupalCon New Orleans had the most sessions submissions ever for a DrupalCon, and the standard of quality was incredibly high. We're hoping that DrupalCon Dublin will see just as many wonderful submissions.

DrupalCon Baltimore announced!

DrupalCon Baltimore Logo

As is tradition, we also revealed the location of the next DrupalCon North America. In 2017, DrupalCon will be in Baltimore! At the closing session, the engineering team launched the splash page for the upcoming event, with travel information, hotels, and important dates.

And if your organization would like to sponsor DrupalCon Baltimore, you can find more information and our prospectus on the site as well.

Infrastructure

We made several tweaks to Drupal.org infrastructure in May as well. We updated the Git Twisted daemon, which serves as the backend for the Drupal.org Git repositories and packaging process. We rebuilt our staging infrastructure at OSU/OSL. And finally, with the generous support of new Technology Supporting Partner OpsGenie, we updated our internal pager rotation for infrastructure alerts.

———

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

We also want to say a special thanks to the departing leadership team at the Drupal Association: our former executive director, Holly Ross, who is moving on after building an incredible team and a great culture throughout the entire organization; Matt Tsugawa, our CFO; and Josh Mitchell, who has lead and mentored the engineering team.

Megan Sanicki, our former COO, is taking on the mantle of Executive Director and we're looking forward to where her leadership will take us

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

The Aaron Winborn Award was created in 2015 after the loss of one of one of the Drupal community’s most prominent members, Aaron Winborn, to Amyotrophic Lateral Sclerosis (also referred to as Lou Gehrig's Disease in the US and Motor Neuron Disease in the UK). Aaron’s commitment to the Drupal project and community made him the epitome of our unofficial motto: "Come for the code, stay for the community". The Community Working Group with the support of the Drupal Association came together to honor Aaron's memory by establishing the Aaron Winborn Award, which annually recognizes an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community.

Nominations were opened in March, giving community members the opportunity to nominate people they believe deserve the award, which were then voted on by the members of the Community Working Group, along with previous winners of the award.

We are pleased to announce that the 2016 recipient of the Aaron Winborn Award is Gábor Hojtsy. During the closing session of DrupalCon New Orleans, Community Working Group members presented the award to Gábor. The award was accompanied by a free ticket to DrupalCon, which he donated to Bojhan Somers.

Gábor was described in his nomination as an "amazing community connector" who is passionate about empowering others, stepping aside and allowing others the space and support to lead, and celebrating even the small wins that people who work with him achieve. The stellar work and leadership he displayed on the D8 Multilingual Initiative, managing sprints, Drupal events and setting up localize.drupal.org are just a few of the ways that this tireless Drupal contributor has been making an enormous impact in our community for more than a decade.

We hope you will join us in congratulating Gábor, who has demonstrated personal integrity, kindness, and above-and-beyond commitment to the Drupal community in abundance.

Front page news: 

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

We'll see you at DrupalCon!

DrupalCon New Orleans is about to get underway next week, and the Drupal Association will be there to talk about some of our recent work, to collaborate with the community, and to present some exciting things that are coming soon. We'll be giving a variety of presentations as part of the Drupal.org track, so if you'll be attending DrupalCon in New Orleans, please join us!

Laissez les bon temps roulez!

Drupal 8.1.0 released

On April 20th, the Drupal core maintainers released Drupal 8.1.0. This is the first release of the new Drupal release cycle in which new features of Drupal will be released much more rapidly than during the Drupal 7 cycle. The Drupal 8.1 release includes: an experimental UI for the Migration module for migrating from Drupal 6 or 7, BigPipe for improving the perceived rendering time of Drupal 8 sites, support for JavaScript automated testing, improved support for Composer, and much more.

The Drupal Association supported the release in several ways. We updated Drupal.org to use Composer to package Drupal Core's dependencies. We updated api.drupal.org to reflect the new point release, and the development branch for 8.2.x. We also bulk updated issues opened against Drupal Core 8.1.x to be open against 8.2.x moving forward. Finally, we updated DrupalCI to support JavaScript testing with PhantomJS. As this new, faster Drupal release cycle continues, we'll continue to refine the process and tools that the core developers use to make this process more efficient.

Drupal.org updates

Composer repository alpha

We're very happy to announce the alpha release of Drupal.org's Composer repositories. One of our Community Initiatives for 2016, adding Composer repositories to Drupal.org, has been a concerted effort here at the Association for the past several months. Composer is the tool for dependency management in PHP, and by using Drupal.org's Composer endpoints you can use Composer to manage Drupal modules and themes.

The Drupal.org Composer façade also handles the translation of Drupal.org versioning into the semver format that Composer needs, which should also allow the community to move forward choosing a semver format for contrib. For example, we could now fairly easily support a Platform.Major.Minor.Patch versioning scheme until the semver standard itself supports the same.

As the current release is an alpha, we don’t recommend relying on the Drupal.org Composer repositories in a production environment quite yet. If you would like to help us test the system, you can start with our documentation for the Drupal.org Composer repositories, and then leave us feedback in the Project Composer issue queue.

Our work on Composer specifically, like many of the initiatives we undertake, was made possible through the support of our generous sponsors. If you would like to sponsor our work on Drupal.org, please consider our Supporting Partner Program.

PhantomJS testing in DrupalCI

A key milestone for core developers in Drupal 8.1 was adding the ability to test the front end, by using PhantomJS for JavaScript testing. After some concerted work by dawehner, pfrenssen, alexpott, and several others on the Drupal core side, isntall here at the Drupal Association was able to get PhantomJS properly running on the DrupalCI testbots.

More work will continue to improve our ability to test the front-end, and Drupal 8 continues to be among the most thoroughly tested open source projects in the ecosystem today.

Visual design system for Drupal.org

In April, our lead designer, DyanneNova, outlined the new design system and principles we’re using in all of our work to improve Drupal.org. Our most significant undertaking is the long term restructuring of Drupal.org, which will be implemented in an iterative way as we work through the many different content areas of Drupal.org. The next area of Drupal.org to receive updates, as previewed in the post above, will be Documentation.

Documentation

In our March update, we teased some of the upcoming Documentation features, and talked about the usability testing we performed at DrupalCamp London, and in the Drupal Association office here in Portland. In April, we took our observations from the usability testing, and began implementing these new features. We'll be previewing these upcoming changes in more detail at DrupalCon New Orleans next week, so stay tuned!

Sustaining support and maintenance

Infrastructure

In April, we began the build-out of a new staging infrastructure for Drupal.org, part of the continual process of upgrading and refining the tools we use to develop Drupal.org. At the same time, we've updated several of our management and automation tools to keep our stack running smoothly. Work refining our pre-production environments will continue into May.

Maintenance and Bug Fixes

No month is complete without a bit of time spent on maintenance and bug fixes. In April, we spent some time cleaning up spam on archived sites of past DrupalCons, removed unneeded comment render cache code, fixed some bugs with featured job credits on Drupal Jobs, and worked on our payment processor implementation for our European DrupalCons.

———

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

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

How is Drupal 8 doing?

28 April 2016, 7:46 pm

Republished from buytaert.net

The one big question I get asked over and over these days is: "How is Drupal 8 doing?". It's understandable. Drupal 8 is the first new version of Drupal in five years and represents a significant rethinking of Drupal.

So how is Drupal 8 doing? With less than half a year since Drupal 8 was released, I'm happy to answer: outstanding!

As of late March, Drupal.org counted over 60,000 Drupal 8 sites. Looking back at the first four months of Drupal 7, about 30,000 sites had been counted. In other words, Drupal 8 is being adopted twice as fast as Drupal 7 had been in its first four months following the release.

As we near the six-month mark since releasing Drupal 8, the question "How is Drupal 8 doing?" takes on more urgency for the Drupal community with a stake in its success. For the answer, I can turn to years of experience and say while the number of new Drupal projects typically slows down in the year leading up to the release of a new version; adoption of the newest version takes up to a full year before we see the number of new projects really take off.

Drupal 8 is the middle of an interesting point in its adoption cycle. This is the phase where customers are looking for budgets to pay for migrations. This is the time when people focus on learning Drupal 8 and its new features. This is when the modules that extend and enhance Drupal need to be ported to Drupal 8; and this is the time when Drupal shops and builders are deep in the three to six month sales cycle it takes to sell Drupal 8 projects. This is often a phase of uncertainty but all of this is happening now, and every day there is less and less uncertainty. Based on my past experience, I am confident that Drupal 8 will be adopted at "full-force" by the end of 2016.

A few weeks ago I launched the Drupal 2016 product survey to take pulse of the Drupal community. I plan to talk about the survey results in my DrupalCon keynote in New Orleans on May 10th but in light of this blog post I felt the results to one of the questions is worth sharing and commenting on sooner:

Survey drupal adoption


Over 1,800 people have answered that question so far. People were allowed to pick up to 3 answers for the single question from a list of answers. As you can see in the graph, the top two reasons people say they haven't upgraded to Drupal 8 yet are (1) the fact that they are waiting for contributed modules to become available and (2) they are still learning Drupal 8. The results from the survey confirm what we see every release of Drupal; it takes time for the ecosystem, both the technology and the people, to come along.

Fortunately, many of the most important modules, such as Rules, Pathauto, Metatag, Field Collection, Token, Panels, Services, and Workbench Moderation, have already been ported and tested for Drupal 8. Combined with the fact that many important modules, like Views and CKEditor, moved to core, I believe we are getting really close to being able to build most websites with Drupal 8.

The second reason people cited for not jumping onto Drupal 8 yet was that they are still learning Drupal 8. One of the great strengths of Drupal has long been the willingness of the community to share its knowledge and teach others how to work with Drupal. We need to stay committed to educating builders and developers who are new to Drupal 8, and DrupalCon New Orleans is an excellent opportunity to share expertise and learn about Drupal 8.

What is most exciting to me is that less than 3% answered that they plan to move off Drupal altogether, and therefore won't upgrade at all. Non-response bias aside, that is an incredible number as it means the vast majority of Drupal users plan to eventually upgrade.

Yes, Drupal 8 is a significant rethinking of Drupal from the version we all knew and loved for so long. It will take time for the Drupal community to understand Drupal's new design and capabilities and how to harness that power but I am confident Drupal 8 is the right technology at the right time, and the adoption numbers so far back that up. Expect Drupal 8 adoption to start accelerating.

Comment on buytaert.net

Front page news: 

Applaud the Drupal Maintainers

22 April 2016, 4:18 pm

Republished from buytaert.net

Today is another big day for Drupal as we just released Drupal 8.1.0. Drupal 8.1.0 is an important milestone as it is a departure from the Drupal 7 release schedule where we couldn't add significant new features until Drupal 8. Drupal 8.1.0 balances maintenance with innovation.

On my blog and in presentations, I often talk about the future of Drupal and where we need to innovate. I highlight important developments in the Drupal community, and push my own ideas to disrupt the status quo. People, myself included, like to talk about the shiny innovations, but it is crucial to understand that innovation is only a piece of how we grow Drupal's success. What can't be forgotten is the maintenance, the bug fixing, the work on Drupal.org and our test infrastructure, the documentation writing, the ongoing coordination and the processes that allow us to crank out stable releases.

We often recognize those who help Drupal innovate or introduce novel things, but today, I'd like us to praise those who maintain and improve what already exists and that was innovated years ago. So much of what makes Drupal successful is the "daily upkeep". The seemingly mundane and unglamorous effort that goes into maintaining Drupal has a tremendous impact on the daily life of hundreds of thousands of Drupal developers, millions of Drupal content managers, and billions of people that visit Drupal sites. Without that maintenance, there would be no stability, and without stability, no room for innovation.

Comment on buytaert.net

Front page news: 

Drupal 8.1.0 is now available

20 April 2016, 7:48 am

Drupal 8.1.0, the first minor release of Drupal 8, is now available. With Drupal 8, we made significant changes in our release process, adopting semantic versioning and scheduled feature releases. This allows us to make extensive improvements to Drupal 8 in a timely fashion while still providing backwards compatibility. Drupal 8.1.0 is the first such update.

What's new in Drupal 8.1.x?

Drupal 8.1.0 comes with numerous improvements, including CKEditor WYSIWYG enhancements, added APIs, an improved help page, and two new experimental modules. (Experimental modules are provided with Drupal core for testing purposes, but are not yet fully supported.)

Experimental UI for migrations from Drupal 6 and 7

Drupal 8.1.0 now includes the Migrate Drupal UI module, which provides a user interface for Drupal core migrations. Use it to migrate Drupal 6 or 7 sites to Drupal 8. The user guide on migrating from Drupal 6 or 7 to Drupal 8 has full documentation. Note that the Drupal 8 Migrate module suite is still experimental and has known issues. Read below for specific information on migrating Drupal 6 and Drupal 7 sites with 8.1.0. (Always back up your data before performing a migration and review the results carefully.)

Migration related modules in Drupal 8.1.0

BigPipe for perceived performance

The Drupal 8 BigPipe module provides an advanced implementation of Facebook's BigPipe page rendering strategy, leading to greatly improved perceived performance for pages with dynamic, personalized, or uncacheable content. See the BigPipe documentation.

CKEditor WYSIWYG spellchecking and language button

New CKEditor features in Drupal 8.1.0

Drupal 8.0.0 included the CKEditor module (a WYSIWYG editor), but it was not previously possible to use your browser's built-in spell checker with it to check the text. With Drupal 8.1.0, spellchecking is now enabled within CKEditor as well.

Another great improvement is the addition of the optional language markup button in CKEditor. When configured to appear in your editing toolbar, it allows you to assign language information to parts of the text, which is useful for accessibility and machine processing.

Improved help page with tours

Drupal 8.0.0 included a new system for help tutorials called tours with the core Tour module. In Drupal 8.1.0, we made these tours easier to discover by listing them in the administrative help overview at /admin/help.

Improved help page in Drupal 8.1.0

The help overview page is also more flexible now, so contributed modules can add sections to it and themes can override its appearance more easily. You can read more about the new system in the change record for the updated help page, or refer to the Tour API documentation for how to add tours for your modules.

Rendered entities in Views fields

Drupal 8.1.0 now includes a rendered entity field handler for Views, which allows placing a fully rendered entity within a view field. For example, this feature could be used to display a rendered user profile for each node author in a table listing node content. (This feature was provided by the Entity contributed module in Drupal 7, but had not yet been available in Drupal 8.)

Support for JavaScript automated testing

Drupal 8.1.0 adds support for automated testing of JavaScript, which will mean fewer bugs with Drupal's JavaScript functionality in the future as we write new tests for it. (Read more about how to run the JavaScript tests.) There are also other improvements to the testing system, including improved reporting of PHPUnit and other test results.

Improved Composer support

Starting with Drupal 8.1.x, Drupal core and its dependencies are packaged by Composer on Drupal.org. This means that sites and modules can now also use Composer to manage all of their third-party dependencies (rather than having to work around the vendor directory that previously shipped with core).

Developer API improvements

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

What does this mean to me?

Drupal 8 site owners

Update to 8.1.0 to continue receiving bug and security fixes. The next bugfix release, 8.1.1, is scheduled for May 4, 2016.

Updating your site from 8.0.6 to 8.1.0 with update.php is exactly the same as updating from 8.0.5 to 8.0.6. Modules, themes, and translations may need small changes for this minor release, so test the update carefully before updating your production site.

Drupal 6 site owners

Drupal 6 is not supported anymore. Create a Drupal 8 site and try migrating your data into it as soon as possible. Your Drupal 6 site can still remain up and running while you test migrating your Drupal 6 data into your new Drupal 8 site. Note that there are known issues with the experimental Migrate module suite. If you find a new bug not covered by one of these issues, your detailed bug report with steps to reproduce is a big help!

Drupal 7 site owners

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

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

Translation, module, and theme contributors

Minor releases like Drupal 8.1.0 are backwards-compatible, so modules, themes, and translations that support Drupal 8.0.x will be compatible with 8.1.x as well. However, the new version does include some string changes, minor UI changes, and internal API changes (as well as more significant changes to experimental modules like the Migrate suite). This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.1.0 release candidate for more background information.

State of Drupal 2016 survey

13 April 2016, 3:21 pm

Reposted from buytaert.net

I've been writing a lot about what I believe is important for the future of Drupal, but now it is your turn. After every major release of Drupal I do a "product management survey" to get your ideas and data on what to focus on for future releases of Drupal (8.x/9).

The last time we had such a survey was after the release of Drupal 7, six months into the development of Drupal 8. I presented the results at DrupalCon London in 2011. The results informed the Drupal community at large, but were also the basis for defining initiatives for Drupal 8. This time around, I'm hoping for similar impact, but also some higher-level strategic thinking about how Drupal should respond to various market trends.

Take the State of Drupal 2016 survey now

It shouldn't take more than 10-15 minutes to fill out the survey. We'd like to hear from everyone who cares about Drupal: content managers, site owners, site builders, module developers, front-end developers, people selling and marketing Drupal, etc. Whether you are a Drupal expert or just getting started with Drupal, every voice counts! Best of all, with Drupal 8's new 6-month release cycle, we can act on the results of this survey much sooner than in the past.

I will be presenting the results during my DrupalCon New Orleans keynote (the video recording of the keynote, the presentation slides and the survey results will be downloadable on my blog after). Please tell us what you think about Drupal; your feedback will shape future versions of Drupal.

Front page news: 

A new design system for Drupal.org

12 April 2016, 1:17 am

As mentioned in our previous post, one of the initiatives we are working on this year is building a new visual system for Drupal.org.

It has been 7 years since Mark Boulton worked on a design plan for Drupal.org. Since then the web has come a long way. So has Drupal. Drupal.org needs a modern design, and the Product team at the Drupal Association has been working steadfastly on a plan to make that happen.

Building on insights from our user research and content strategy work, we have begun laying out a foundation for the future design system for the site.

Goal

Update Drupal.org to reflect the flexibility, modernity, and community of Drupal itself.

Design Principles

Before we started work on the design for Drupal.org we needed to iron out our process and the principles we wanted to keep in mind throughout our work.

To that end, tvn and I holed up for a weekend design retreat, which resulted in tons of post-it notes about what Drupal.org design looks like, what it should look like, and what we can learn from others -- to develop the design principles that will move Drupal.org forward.

Working on design principles for http://t.co/H0d2MHDCaS with @DyanneNova pic.twitter.com/XVZ0bgPlTe

— tvn (@tvnweb) July 25, 2015

After much deliberation, condensing, rewriting, and discussion with the wider Engineering and Communication teams, these are the principles we found to be our best guiding mantras:

Start with user needs.
We only design for real people. We verify their needs and let that information be our guide when designing anything.

Keep it simple. Focus.
We do less, but better. We focus on the areas we can have the most impact. Our designs are simple and clean, and our messages are clear. We strive for brevity and avoid clutter.

Be consistent. Re-use.
Our designs should be part of a consistent, cohesive system. We don’t introduce new patterns if we can re-use or improve any of the existing ones.

Be accessible.
Our designs should be usable by anyone, on any device or screen size, on a high speed connection or a slow network, by people with different native languages, and regardless of their accessibility needs.

Be relevant. Try new things.
Our designs are relevant and fresh. We keep up with the latest trends and are not afraid to try something new.

Iterate quickly.
We do small and quick iterations, continuously improving the experience. We experiment and test out different approaches.

Use Data.
We use data to support and drive our decisions. This includes analytics, data from testing and experiments, data gleaned through user research methods including interviews, surveys, and so on.

Work openly. Be honest.
Our designs are honest and authentic, and our intentions are transparent. We call things what they are. We respect our community values. We communicate openly and often.

Engage and empower.
We design experiences that unite our users and empower them to collaborate and do great things, because they can.

Be friendly.
We create friendly and welcoming environments. We want our users to feel welcome and supported.

Design Vision

Once we had our design principles in place we needed to move from those abstract guidelines to actual design plans for the website.

After DrupalCon Barcelona, we set aside time for another design retreat. This time tvn lost her voice on day 2, so miming and typing became a fun part of the workflow.

Our first step was to create a mood board of inspirational user interfaces to give us a beginning design language and a starting point for discussion.

Then we began our work with style tiles. I created four first drafts, informed by our mood board. One was softer, with varying shades of blue. At the other extreme was a largely monochrome design, with only tiny hints of the Drupal blue. After a few rounds of reviews and revisions we came up with the following visual system, which we feel matches our goals and gives a general idea of the mood, colors, and visuals we plan to move towards.

drupal.org style tile

The general mood here was inspired by the idea of builders and makers working together to build something larger. We combine blueprint textures, single-width line icons, and an open typeface to make Drupal.org feel like the home to a continually improving framework.

We’ve kept the Drupal blue, and tweaked our green to bring it to a cooler shade. We’ve added darker tones for every color to give us more opportunity for high contrast.

The end goal is to make Drupal.org a useful space for contributors and users alike with a consistent quality of design throughout the site.

To that end, we’ve started work on a pattern library which will categorize all of the different design patterns used on Drupal.org. As we build out new patterns for new features they will be added to the library as well. The styles will be automatically inherited from the theme, which will make maintenance of the library as simple as adding relevant content to a page.

Iterative Approach

To support our current prioritization we knew we would need to use a very iterative process for launching design updates. Our strategy is to make design updates as we can when a new feature is prioritized. As each area of the site is functionally improved, it receives visual improvements as well. You’ve seen some of these updates already in the Drupal 8 launch and in the smaller updates to Drupal.org since last November.

drupal 8 landing page

drupal 8 landing page

With the Drupal 8 launch came a re-styled header for Drupal.org.

drupal 8 header and membership drive

Release pages also received a small update to the download area, with clearer calls to action.

Shortly after that, we held a membership drive with a banner and a front page region highlighting community members. And just a few weeks ago we set up a new banner for promoting community elections to the Board, which can also be used for any important announcements going forward.

Next Steps

Our next big project is Documentation. We’ve been toiling away on these features for months now as part of our overall content restructure work. After the first pass of wireframes and design mockups, we collected input from documentation users via usability testing held remotely and in person at the Drupal Association office in Portland, Oregon, and at DrupalCamp London. Based on all the feedback, we've done a few revisions on our initial ideas and designs. We've spoken with a wide range of community members, from newcomers to masters, and their input was invaluable for arriving at a design that really works for the user.

documentation page

You can see some of the new patterns we’ve begun work on in this mockup, such as the documentation section header and tags. We also have a pattern for related content which isn’t visible in the image. In our usability testing, we found that wayfinders were incredibly important to the experience of documentation, so we spent considerable time on improving the breadcrumbs and menu navigational patterns before arriving at what you see above.

How to get involved

There are a number of ways to get involved in improving Drupal.org. You can read more about general volunteering here.

If you’re interested in joining our usability testing sessions held both remotely and in person at major Drupal events, please fill out this form and we’ll reach out to you when the next session is being planned.

To post an issue about design on Drupal.org, use the project issue queue at Drupal.org Design. This issue queue will replace the Bluecheese theme queue going forward as a central place to report issues or inconsistencies with Drupal.org design. Meta discussions of design on Drupal.org are also welcome in the queue.

If you’d like to participate in quick design discussions about Drupal.org and be available to give feedback on upcoming design decisions, join us on Slack at channel #drupalorg-design.

As we incrementally roll out new features, you’ll see Drupal.org move ever closer to our updated visual system. Thanks for coming along for the ride!

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

Drupal.org updates

Syntax Highlighting

A WYSIWYG editor(CKEditor) is coming to Drupal.org soon to improve the editorial experience- and to take advantage of the same functionality that made CKEditor the choice for Drupal 8 core. However, as a stepping stone to that goal, we need to ensure that the formatting of <code> blocks throughout Drupal.org is preserved.

This has lead us to using Prism.js for syntax highlighting on Drupal.org. You can see this change in any <code> or <?php> block throughout the site, such as this example of function hook_field_info_alter(); below:

function hook_field_info_alter(&$info) {
  // Change the default widget for fields of type 'foo'.
  if (isset($info['foo'])) {
    $info['foo']['default widget'] = 'mymodule_widget';
  }
}

This is the first step, but with a better syntax highlighting library in place, we are pushing hard to make CKEditor itself available on Drupal.org.

Documentation Usability Testing

In March members of the Drupal Association engineering team also spent time doing usability testing with a prototype of our new Documentation content type. This testing, performed with a representative sample of users of different experience levels with Drupal, helped validate our design direction for new Documentation pages and Documentation Guides on Drupal.org, and gave us some valuable feedback for further refining our design as we move into implementation. While we're not yet ready to share all the details of the new Documentation experience, we're very excited to share this with the community soon.

Release File Hashes

A file hash can be used to verify the integrity of a file downloaded from a trusted source. Drupal.org provided an md5 hash on the list of a project's releases (here's the release listing for Drupal core, for example), but we have expanded the file hash options to include: md5, sha-1, and sha-256.

Because many users do not use file hashes, these hashes are not displayed by default. Any user who does want to access these file hashes can do so from a toggle on the sidebar of a release page. Your preference for what file hash to view will be saved in your browser's local storage and displayed on all other release pages. The new sha-1 hashes will also be used in upcoming Composer integration.

Communications channels

Taking advantage of the new Sections and Blogs on Drupal.org, we're gradually working on improving our communication channels. It starts with the Drupal blog, and the Drupal.org blog (which you're reading now!) - but will soon affect all the ways we communicate about Drupal the software and Drupal.org the site.

You can learn more about communication channels here.

2016 Elections Complete

”Hands

Lastly, but certainly not least - the 2016 election for the Drupal Association At-Large board member ended in March. For the first time, we promoted the voting process to all eligible voters with a targeted banner on Drupal.org. This gave us the broadest reach we've ever had when electing a board member, and the most ballots submitted. You can learn more about the elections process and the final vote here.

Congratulations Shayamala Rajaram - and thank you for supporting the community by joining the board!

Sustaining support and maintenance

Drupal.org Outages

Unfortunately our work in March was disrupted on several occasions by a particularly tricky series of outages. Seemingly at random one of the Drupal.org webnodes would experience cache corruption and begin serving 500 errors. The issues did not seem to be related to a recent change, a singular area of the site, or an increase in traffic. After some diligent sleuthing we began to see some patterns in the cache corruption.

In the end, we were able to determine that all the outages were linked to the same bug in Drupal core's handling of SchemaCache. Drupal.org has been patched and since then no cache corruption incidents have recurred. With a bit more community review (you can help!), hopefully the fix will be committed to core so other affected sites will not encounter the same issue that we did.

More Improvements and Bug Fixes

We made a few other infrastructural improvements and bug fixes in March as well. Not the least of these was deploying dedicated beanstalkd queue servers, to improve the reliability of Drupal.org job queues, especially when recovering from disruption.

We also fixed a regression on groups.drupal.org caused by the upgrade to PHP 5.4 the previous month. A bug in the date chooser caused the date of an event to be reset whenever the event was edited- an issue that we know was frustrating to many in the community who organize local events.

Lastly, we fixed an issue on jobs.drupal.org to make it easier for companies to renew their featured job listings (without having to reach out to us for manual support). We're seeing a marked increase in the Drupal Jobs interest since the launch of Drupal 8 and we'll continue to improve the Drupal Jobs platform to foster the Drupal ecosystem.

———

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

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

The first release candidate for the upcoming Drupal 8.1.0 release is now available for testing. With Drupal 8, we made major changes in our release process, adopting semantic versioning and scheduled releases. This allows us to make significant improvements to Drupal 8 in a timely fashion while still providing backwards compatibility. Drupal 8.1.0 will be the first such update, expected to be released April 20.

8.1.x includes an experimental user interface for migrating from Drupal 6 and 7, the BigPipe module for increasing perceived site performance, and more. You can read a detailed list of improvements in the announcements of beta1 and beta2.

What does this mean to me?

For Drupal 8 site owners

The final bugfix release of 8.0.x has been released. 8.0.x will receive no further releases following 8.1.0, and sites should prepare to update from 8.0.x to 8.1.x in order to continue getting bug and security fixes. Use update.php to update your 8.0.x sites to the 8.1.x series, just as you would to update from (e.g.) 8.0.4 to 8.0.5. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

Drupal 8 release cycle diagram, showing the 8.1.x beta and RC phases beginning as 8.0.x nears its end in April, and 8.0.x support ending when 8.1.x is released.

For module and theme authors

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

For translators

Some text changes were made since Drupal 8.0.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.0.x are automatically migrated to 8.1.x after the final 8.0.x patch release. Future bug reports should be targeted against the 8.1.x branch. 8.2.x will remain open for new development during the 8.1.x release candidate phase. For more information, see the release candidate phase announcement.

Your bug reports help make Drupal better!

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

Note that there are known issues with the experimental Migrate module suite, especially the incomplete Drupal 7 to Drupal 8 migration path. If the bug you find is not covered by one of these issues, your detailed bug report with steps to reproduce is a big help!

Restructuring Drupal.org

6 April 2016, 4:33 pm

In this post I'd like to talk about one of our major projects for 2016, which comes as a follow up to the content strategy project of 2015.

Content restructure

Last year we presented our findings from the content strategy developed by Drupal Association staff in collaboration with Forum One. This year we're focusing on bringing as many of those ideas to life as we can. We call this implementation phase 'content restructure'. We'll look at one area of the site at a time, audit its content, change the way it is created and stored (content type) if needed, redesign the way it looks and reorganize it into a more usable and findable structure, improving content quality and giving content creators better tools to maintain it along the way.

The backbone of the new content structure are 'sections' or top level groupings of content. We created infrastructure to make those possible and have already launched the first few.

Together with sections we've been rolling out blogs to improve how we communicate about specific topics on Drupal.org. Recently, I talked in more detail how blogs and sections fit into our overall plan of making it easier to communicate important announcements and news to the Drupal community.

Our current focus is Documentation area of the site. We're working on a complete revamp that will change the way documentation looks and works, and will change the way users can navigate and improve documentation. We're working closely with the Documentation Working Group and performing rounds of usability testing to ensure the changes we are working on will improve the user experience across the board. More details on this can be found in the issue queue.

A big part of the content restructure plan is a content audit and migration. This is especially true for documentation revamp, where we have thousands of pages to migrate into the new system. We'll be turning to the community to help us with this effort. Not only because that's too many pages for a small team like ours to migrate on our own, but also because we need subject matter experts to look at a lot of the pages and evaluate how accurate they are, whether they should be migrated or archived, and so on.

More than just content

Along with the content restructure project, we'll be doing important work that complements and supports it, though each component is not a discrete project on its own.

Developing visual design system

The current Drupal.org design is based on branding and design work done in 2008 by Mark Boulton Design and Leisa Reichelt. They did a great job, but even the most beautiful site will age. Since more than seven years have elapsed since the last redesign, it's time to update the site for a more contemporary look.

Our quest towards updating Drupal.org visually started in 2014 with the user research project, which brought us user personas. The next big step was the content strategy project, which laid the groundwork for the content restructure work discussed above.

Building on what we learned about our users, and how to structure our content to best serve their needs, this year we'll be introducing the new visual design system for the site. There will not be a single, comprehensive launch, where you wake up and suddenly Drupal.org looks completely different. We'll do it iteratively, in parallel with the content restructure, by redesigning the specific area of the site we are focusing on at a given time. This approach lets us introduce visual changes sooner, and iteratively improve and refine them as we go. In fact, you've already seen some of the elements of the new visual system appear with the Drupal 8 launch.

Later this week, our designer DyanneNova will share a bit more details about the work we've already done towards the new system and our next steps.

Updating content style guide

Along with restructuring content we also want to improve the quality of the existing content during migrations, as well as the quality of the content that will be created in the future. To this end, we'll be taking a look at the content style guide, and plan to refresh and update it. We also anticipate expanding the guide to add information about specific content types and communication channels.

Capturing user engagement and contribution

Another aspect of our content restructure work will touch on user engagement and contribution. As we go area through area of the site, redesigning it and improving its content, we'll be looking at what type of user engagement and contributions happen in that area. We'll be looking for opportunities to better capture them, and subsequently better recognize and display those contributions. For example, right now 'documentation edits' count on user profiles show the number of edits user has done to 'book page' content type items, which may or may not be documentation. We'll make that calculation more precise to display the actual documentation edits. We'll also be able to display specific parts of documentation a user maintains, similar to projects they maintain.

Increasing sustainability

An ongoing challenge at the Drupal Association is ensuring we have sustainable revenue to support our work for the community. As we do this work, we will be looking into improving existing revenue opportunities and introducing new ones to make Drupal.org more sustainable. We will also work closely with partners who may be willing to sponsor specific improvements to Drupal.org on behalf of the community.

Other initiatives

The content restructure is not the only project we are working on right now. Some of the other initiatives will be described in future posts. Check our Roadmap to see all the things in progress.

And if you happen to be at DrupalCon New Orleans this May, come to our session to get further updates on some of the topics discussed in this blog.

Republished from Buytaert.net

At DrupalCon Mumbai I sat down for several hours with the Drupal team at Pfizer to understand the work they have been doing on improving Drupal content management features. They built a set of foundational modules that help advance Drupal's content workflow capabilities; from content staging, to multi-site content staging, to better auditability, offline support, and several key user experience improvements like full-site preview, and more. In this post, I want to point a spotlight on some of Pfizer's modules, and kick-off an initial discussion around the usefulness of including some of these features in core.

Use cases

Before jumping to the technical details, let's talk a bit more about the problems these modules are solving.

  1. Cross-site content staging — In this case you want to synchronize content from one site to another. The first site may be a staging site where content editors make changes. The second site may be the live production site. Changes are previewed on the stage site and then pushed to the production site. More complex workflows could involve multiple staging environments like multiple sites publishing into a single master site.
  2. Content branching — For a new product launch you might want to prepare a version of your site with a new section on the site featuring the new product. The new section would introduce several new pages, updates to existing pages, and new menu items. You want to be able to build out the updated version in a self-contained 'branch' and merge all the changes as a whole when the product is ready to launch. In an election case scenario, you might want to prepare multiple sections; one for each candidate that could win.
  3. Preview your site — When you're building out a new section on your site for launch, you want to preview your entire site, as it will look on the day it goes live. This is effectively content staging on a single site.
  4. Offline browse and publish — Here is a use-case that Pfizer is trying to solve. A sales rep goes to a hospital and needs access to information when there is no wi-fi or a slow connection. The site should be fully functional in offline mode and any changes or forms submitted, should automatically sync and resolve conflicts when the connection is restored.
  5. Content recovery — Even with confirmation dialogs, people delete things they didn’t want to delete. This case is about giving users the ability to “undelete” or recover content that has been deleted from their database.
  6. Audit logs — For compliance reasons, some organizations need all content revisions to be logged, with the ability to review content that has been deleted and connect each action to a specific user so that employees are accountable for their actions in the CMS.

Technical details

All these use cases share a few key traits:

  1. Content needs to be synchronized from one place to another, e.g. from workspace to workspace, from site to site or from frontend to backend
  2. Full revision history needs to be kept
  3. Content revision conflicts needs to be tracked

Much of this started as a single module: Deploy. The Deploy module was first created by Greg Dunlap for Drupal 6 in 2008. In 2012, Greg handed over maintainership to Dick Olsson who created the first Drupal 7 version (7.x-2.x) with many big improvements. Later, Dave Hall created a second Drupal 7 version (7.x-3.x) which more significant improvements based on feedback from different users. Today, both Dick and Dave work at Pfizer and have continued to include lessons learned in the Drupal 8 version of the module. After years of experience working on Deploy module and various redesigns, the team has extracted the functionality in a set of modules:

Multiversion

This module does three things: (1) it adds revision support for all content entities in Drupal, not just nodes and block content as provided by core, and (2) it introduces the concept of parent revisions so you can create different branches of your content or site, and (3) it keeps track of conflicts in the revision tree (e.g. when two revisions share the same parent). Many of these features complement the ongoing improvements to Drupal's Entity API.

Replication

Built on top of Multiversion module, this lightweight module reads revision information stored by Multiversion, and uses that to determine what revisions are missing from a given location and lets you replicate content between a source and a target location. The next two modules, Workspace and RELAXed Web Services depend on replication module.

Workspace

This module enables single site content staging and full-site previews. The UI lets you create workspaces and switch between them. With Replication module different workspaces on the same site can behave like different editorial environments.

RELAXed Web Services

This module facilitates cross-site content staging. It provides a more extensive REST API for Drupal with support for UUIDs, translations, file attachments and parent revisions — all important to solve unique challenges with content staging (e.g. UUID and revision information is needed to resolve merge conflicts). The RELAXed Web Services module extends the Replication module and makes it possible to replicate content from local workspaces to workspaces on remote sites using this API.

In short, Multiversion provides the "storage plumbing", whereas Replication, Workspace, and RELAXed Web Services, provide the "transport plumbing".

Deploy

Historically Deploy module has taken care of everything from bottom to top related to content staging. But for Drupal 8 Deploy has been rewritten to just provide a UI on-top of the Workspace and Replication modules. This UI lets you manage content deployments between workspaces on a single site, or between workspaces across sites (if used together with RELAXed Web Services module). The maintainers of the Deploy module have put together a marketing site with more details on what it does: http://www.drupaldeploy.org.

Trash

To handle use case #5 (content recovery) the Trash module was implemented to restore entities marked as deleted. Much like a desktop trash or recycle bin, the module displays all entities from all supported content types where the default revision is flagged as deleted. Restoring creates a newer revision, which is not flagged as deleted.

Synchronizing sites with a battle-tested API

When a Drupal site installs and enables RELAXed Web Services it will look and behave like the REST API from CouchDB. This is a pretty clever trick because it enables us to leverage the CouchDB ecosystem of tools. For example, you can use PouchDB, a JavaScript implementation of CouchDB, to provide a fully-decoupled offline database in the web browser or on a mobile device. Using the same API design as CouchDB also gives you "streaming replication" with instant updates between the backend and frontend. This is how Pfizer implements off-line browse and publish.


Switching between multiple workspaces

This animated gif shows how a content creator can switch between multiple workspaces and get a full-site preview on a single site. In this example the Live workspace is empty, while there has been a lot of content addition on the Stage workspace in.


Deploying a workspace

This animated gif shows how a workspace is deployed from 'Stage' to 'Live' on a single site. In this example the Live workspace is initially empty.

Conclusion

Drupal 8.0 core packed many great improvements, but we didn't focus much on advancing Drupal's content workflow capabilities. As we think about Drupal 8.x and beyond, it might be good to move some of our focus to features like content staging, better audit-ability, off-line support, full-site preview, and more. If you are a content manager, I'd love to hear what you think about better supporting some or all of these use cases. And if you are a developer, I encourage you to take a look at these modules, try them out and let us know what you think.

Thanks to Tim Millwood, Dick Olsson and Nathaniel Catchpole for their feedback on the blog post. Special thanks to Pfizer for contributing to Drupal.

Comment on Improving Drupal's content workflow on Buytaert.net

Front page news: 

Last year, in honor of long-time Drupal contributor Aaron Winborn, whose battle with Amyotrophic lateral sclerosis (ALS) (also referred to as Lou Gehrig's Disease) came to an end, the Community Working Group, with the support of the Drupal Association launched the Aaron Winborn Award.

This year the nominations are open until 10th April 2016 (Midnight GMT).

This annual award recognizes an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. It will include a scholarship and stipend to attend DrupalCon and recognition in a plenary session at the event.

The inaugural Aaron Winborn Award was given to Cathy Theys at DrupalCon Barcelona - see the announcement on the Drupal Association blog.

Thanks to Hans Riemenschneider for the suggestion, and the Drupal Association executive board for backing this idea and the budget. We feel this award is a fitting honor to someone who gave so much to Drupal both on a technical and personal level.

If you know someone amazing who should benefit from this award you can make your nomination here:

https://www.drupal.org/aaron-winborn-award

Front page news: 

Republished from buytaert.net

The authoring experience improvements we made in Drupal 8 appear to be well-received, but that doesn't mean we are done. With semantic versioning in Drupal 8, we can now make more UX changes in follow-up releases of Drupal 8. So now is a good time to start moving Drupal's user experience forward.

The goal of this post is to advance the conversation we started over a month ago in a blog post talking about the concept of turning Drupal outside-in. In today's blog post, we'll show concrete examples of how we could make site building in Drupal easier by embracing the concept of outside-in. We hope to provide inspiration to designers, core contributors and module maintainers for how we can improve the user experience of Drupal 8.2 and beyond.

What is outside-in?

In Drupal you often have to build things from the ground up. If you want to make a list of events you need to wade through 20 different menu options to a user interface with configuration options like "boolean" and "float", build a content type, content, and then a view. Essentially you need to understand everything before you can build anything.

In an "outside-in" experience – or what Kevin OLeary (Director of Design on my team at Acquia) calls Literal UI – you can click anything on the page, edit its configuration in-place, and watch it take effect immediately.

Over the past few years Drupal has adopted a more outside-in approach, the most obvious example being Drupal 8's in-place editing. It enables you to edit what you see with an uninterrupted workflow, faster preview, and removes the need to visit the administration backend before you can start editing.

To evaluate how outside-in can be applied more broadly in order to make Drupal easier to use, Kevin created a few animated gifs.

Example #1: editing menu items

The current inside-out experience

Editing menu options in Drupal has already become more outside-in with contextual links. The contextual links take away some of the guesswork of finding the proper administration UI, but once you arrive at the configuration page there is still a lot of stuff to take in, only some of which is relevant to this task.



The current inside-out experience for editing a menu item in Drupal

The current inside-out experience for editing a menu item: adding a menu link and changing its position involves 2 separate administration pages, 4 page refreshes and more than 400 words of text on the UI.

Anyone familiar with Drupal will recognize the pattern above; you go to an administration UI, make some changes, than you go back to the page to see if it worked. This context switching creates what UX people call "cognitive load". On an administration page you need to remember what was on the site page and vice-versa.

To complete this task you need to:

  1. Find the contextual link for the menu (not simple since it's on the far side of the page)
  2. Choose the correct option "edit menu"
  3. Find and click the "add link" button
  4. Type the menu link name
  5. Type the menu link path beginning with a forward slash
  6. Understand that this change needs to be saved
  7. Scroll to the bottom of the page
  8. Save the link
  9. Find the link in the list of links
  10. Understand that dragging up/down in this abstraction is equivalent to moving right/left in that actual page
  11. Scroll to the bottom of the page
  12. Save the menu

The problem is not just that there are too many pages, clicks, or words, it's that each step away from the actual page introduces new opportunities for confusion, error and repetition. In user testing, we have seen users who were unable to find the contextual link, or to understand which option to choose, or to find the "add link" button, or to add a path, or drag-drop links, or to save before leaving the UI. When these things happen in context feedback about whether you are "doing it right" is immediate.

The proposed outside-in experience



The proposed outside-in experience for editing a menu item in Drupal

The proposed outside-in experience for editing a menu item. Rather than moving out-of-context to an administration page to get the job done, configuration happens right on the page where you see the effect of each action. You start adding a menu item simply by selecting the menu on the page. Both the menu item and the item's path are in focus to reinforce the connection. As you type a path is proposed from the link text.

Now all you need to do is:

  1. Click the menu on the page
  2. Find and click the "add link" button
  3. Type the name of the menu item
  4. Revise the menu item's path if needed
  5. Drag the link to its new location
  6. Close the drawer

One important aspect of this approach is that all actions that produce a visible change have bi-directional control and bi-directional feedback. In other words, if you can drag something in the configuration drawer you should also be able to drag it on the page, and the changes should happen simultaneously.

Example #2: adding a block to a page

The current inside-out experience

The process of adding a block can be difficult. Once you discover where to go to add a block, which is in itself a challenge, the experience requires a lot of reading and learning, as well as trial and error.



The current inside-out experience for adding a block

The current inside-out experience for adding a block. Not all steps are shown.

To complete this task you need to:

  1. Figure out where to go to place a block
  2. Go to /block-layout
  3. Go to /display-regions to find out where the region is on the page
  4. Go back to /block-layout
  5. Find the region and click "add block"
  6. Find the block you want to place and click "place block"
  7. Configure the block
  8. Read about how blocks can appear on multiple pages and for different content types and roles
  9. Read what content types are
  10. Read what roles are
  11. Read what a "path" is
  12. Read how to find the path for a page
  13. Go back to the page and get its path
  14. Go back to /block-layout and add the path to the visibility settings
  15. Drag your block to the position where you want it
  16. If your blocks are arranged horizontally, learn that "up and down" in the block layout UI will mean "left and right" on the actual page
  17. Find the"back to site" link
  18. Go back to the page to see if you did it right

Eventually you'll use what you just learned, but Drupal makes you learn it first instead of just showing what is immediately necessary. Both the task and the learning can be simplified by bringing the configuration closer to the object you are configuring.

The proposed outside-in experience



The proposed outside-in experience for adding a block

The proposed outside-in experience for adding a block. Everything happens on the actual page rather than on an administration page. Places where things can be added appear on hover. On click they show thumbnails that you can filter with autocomplete.

Now all you need to do is:

  1. Choose where to place the block
  2. Find the block you want to place
  3. Place the block
  4. Close the drawer

The "plus" button, the drop target (blue dotted rectangle) and the autocomplete are all commonly understood patterns used by other software. The task requires no or little explanation as the interactions reveal the process. By starting with selecting the location of where to place the block, we avoid the need for drag-and-drop and the complexity of dragging a block on a page that requires scrolling.

Principles and patterns

These examples show the principle that rather than taking the site builder to a separate administration backend, the experience should begin with the actual page and show how the changes will be seen by the end-user. The patterns shown here are less important. For example the animated gifs above show two different approaches to the options panel and there are certainly others. The important thing is not yet where the panel comes from or how it looks, but that the following criteria are met:

  • An option panel is triggered by direct interaction.
  • When triggered it only shows options for what you selected.
  • It primarily shows configuration options that produce a visible change to the page. More complex options could be accessed through an 'Advanced options' link.

The ideas in this post are meant to provide some food for thought and become the seed of some patches for Drupal 8.2. Rather than dive right into development, we're looking to the Drupal community to take these designs as a starting point to prototype and user-test more outside-in experiences in Drupal.

The next post in this series will cover outside-in experiences with more complex contexts and the problem of "leaky abstractions". If you don't want to miss the next blog post, make sure to subscribe. In the mean time, I'd love to hear what you think!

Special thanks to Kevin OLeary for advocating outside-in thinking. Thanks to Preston So, Gábor Hojtsy, Angie Byron, Bojhan Somers and Roy Scholten for their feedback.

Continue the conversation on buytaert.net

Front page news: 

How should you decouple Drupal?

22 March 2016, 3:38 pm

Republished from buytaert.net

With RESTful web services in Drupal 8 core, Drupal can function as an API-first back end serving browser applications, native applications on mobile devices, in-store displays, even in-flight entertainment systems (Lufthansa is doing so in Drupal 8!), and much more. When building a new website or web application in 2016, you may ask yourself: how should I decouple Drupal? Do I build my website with Drupal's built-in templating layer or do I use a JavaScript framework? Do I need Node.js?

There is a lot of hype around decoupled architectures, so before embarking on a project, it is important to make a balanced analysis. Your choice of architecture has implications on your budget, your team, time to launch, the flexibility for content creators, the ongoing maintenance of your website, and more. In this blog post, I'd like to share a flowchart that can help you decide when to use what technology.

Decoupled decision flowchart


This flowchart shows three things:

First, using coupled Drupal is a perfectly valid option for those who don't need extensive client-side rendering and state management. In this case, you would use Drupal's built-in Twig templating system rather than heavily relying on a JavaScript framework. You would use jQuery to take advantage of limited JavaScript where necessary. Also, with BigPipe in Drupal 8.1, certain use cases that typically needed asynchronous JavaScript can now be done in PHP without slowing down the page (i.e. communication with an external web service delaying the display of user-specific real-time data). The advantage of this approach is that content marketers are not blocked by front-end developers as they assemble their user experiences, thus shortening time to market and reducing investment in ongoing developer support.

Second, if you want all of the benefits of a JavaScript framework without completely bypassing Drupal's HTML generation and all that you get with it, I recommend using progressively decoupled Drupal. With progressive decoupling, you start with Drupal's HTML output, and then use a JavaScript framework to add client-side interactivity on the client side. One of the most visited sites in the world, The Weather Channel (100 million unique visitors per month), does precisely this with Angular 1 layered on top of Drupal 7. In this case, you can enjoy the benefits of having a “decoupled" team made up of both Drupal and JavaScript developers progressing at their own velocities. JavaScript developers can build richly interactive experiences while leaving content marketers free to assemble those experiences without needing a developer's involvement.

Third, whereas fully decoupled Drupal makes a lot of sense when building native applications, for most websites, the leap to fully decoupling is not strictly necessary, though a growing number of people prefer using JavaScript these days. Advantages include some level of independence on the underlying CMS, the ability to tap into a rich toolset around JavaScript (e.g. Babel, Webpack, etc.) and a community of JavaScript front-end professionals. But if you are using a universal JavaScript approach with Drupal, it's also important to consider the drawbacks: you need to ask yourself if you're ready to add more complexity to your technology stack and possibly forgo functionality provided by a more integrated content delivery system, such as layout and display management, user interface localization, and more. Losing that functionality can be costly, increase your dependence on a developer team, and hinder the end-to-end content assembly experience your marketing team expects, among other things.

It's worth noting that over time we are likely to see better integrations between Drupal and the different JavaScript frameworks (e.g. Drupal modules that export their configuration, and SDKs for different JavaScript frameworks that use that configuration on the client-side). When those integrations mature, I expect more people will move towards fully decoupled Drupal.

To be performant, fully decoupled websites using JavaScript employ Node.js on the server to improve initial performance, but in the case of Drupal this is not necessary, as Drupal can do the server-side pre-rendering for you. Many JavaScript developers opt to use Node.js for the convenience of shared rendering across server and client rather than for the specific things that Node.js excels in, like real-time push, concurrent connections, and bidirectional client-server communication. In other words, most Drupal websites don't need Node.js.

Decoupled delivery architectures


In practice, I believe many organizations want to use all of these content delivery options. In certain cases, you want to let your content management system render the experience so you can take full advantage of its features with minimal or no development effort (coupled architecture). But when you need to build a website that needs a much more interactive experience or that integrates with unique devices (i.e. on in-store touch screens), you should be able to use that same content management system's content API (decoupled architecture). Fortunately, Drupal allows you to use either. The beauty of choosing from the spectrum of fully decoupled Drupal, progressively decoupled Drupal, and coupled Drupal is that you can do what makes the most sense in each situation.

Special thanks to Preston So, Alex Bronstein and Wim Leers for contributions to this blog post. We created at least 10 versions of this flowchart before settling on this one.

Continue the conversation on buytaert.net

Front page news: 

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

Drupal.org updates

Drupal 6 is now end of life

”Druplicon”

As of February 24, 2016, Drupal 6 is at end of life (EOL). To support the end of life process for this version of Drupal, Association staff are ensuring that users are prompted to update to the final version of Drupal 6, and that site owners are made aware of the implications of EOL. Because the community at large no longer supports Drupal 6, site owners are encouraged to move to Drupal 7 or 8, or to work with one of the Drupal 6 Long Term Support vendors.

Our board's director at-large election

”Hands

In February, self-nominations opened for a single director at-large position on the Association board. This is one of two such seats on the board that are decided by community election.

Now that nominations have closed, you can review candidate profiles and watch the Meet the Candidate webinars. Voting will run from March 7-18, and will be promoted to all eligible voters with a banner on Drupal.org.

Composer support for Drupal

Logo: WizardCat.com

In February, we continued the community initiative to support Composer on Drupal.org. Over the last several months, we’ve been working closely with members of the community, as well as with the maintainer of Composer and Packagist.org.

Drupal.org will provide two Composer endpoints: one for Drupal 7 projects, and one for Drupal 8. These separate endpoints will allow Drupal.org to translate Drupal-style contrib version numbers into the true semantic versioning that Composer expects. This will also help support a transparent movement to a more semantic versioning for contrib projects on Drupal.org.

We hope to provide a beta of this Drupal.org Composer support in March.

Manage your Drupal.org notifications

In January, we updated Drupal.org to allow users to follow many more content types, including Forum Topics, Posts, Case Studies, and documentation Book Pages. However, now that users are able to receive email notification for activity on a wide variety of content on Drupal.org, we also needed to provide some better tools for managing those notifications.

Follow notifications UI

A new tab now appears on every user's profile called "Notifications," which allows the user to configure, per content type, whether they want to receive email notifications when following that content, or simply add it to the their tracker (the “Your Posts” part of the Dashboard).

More insight into organization contributions

For some time now, the Drupal.org Marketplace has displayed recent issue credits attributed to the organizations that provide Drupal services to our ecosystem. However, there’s been no way to see the contributions attributed to non-service providers (that is, organizations that don’t sell Drupal services).

Until now. The drupal.org/organizations view now shows all organizations ranked by attributed issue credits, whether they’re a Drupal service provider, a customer, or even a community organization like a DrupalCamp. To promote this greater visbility, we've also highlighted the top 10 contributing customers of Drupal. We hope to continue to improve the many ways we track and display user and organization contributions, and would love your feedback.

Content restructure: Documentation

In 2015, we did a tremendous amount of work developing a comprehensive content strategy for Drupal.org. In 2016, we’re making great strides in implementing that strategy through a content restructure. The main idea behind the content restructure is the reorganization of our content into sections that can each have their own maintainership, governance, and related content.

Perhaps the most critical new section is Documentation. The new Documentation section will bring easier navigation, maintainership of documentation guides, better related content, and more relevant metadata to documentation on Drupal.org. We’re doing usability testing of our prototype of this new section now.

Sustaining support and maintenance

DrupalCon Asia: A landmark moment

DrupalCon Asia logo

February was also the time for DrupalCon Asia—at last! The event held at IITB in Mumbai hosted over 1,000 attendees, 82% of whom were first-time DrupalCon attendees. With Association staff both in Mumbai and providing remote support it was an incredibly challenging, colorful, rewarding, and enlightening event.

We're proud to have brought the Asian community the DrupalCon they deserved. As the second largest region of users on Drupal.org, behind only the United States, we expect tremendous things from this vibrant community.

Jobs.drupal.org—tweeting the best opportunities in Drupal

Fostering and promoting the Drupal ecosystem is an important part of the Association’s mission. Drupal powers the best of the web, from single-installation to large-scale enterprise sites. Drupal Jobs provides companies a way to find the best Drupal talent, and provides Drupal developers a way to find open source-friendly careers. We recently updated jobs.drupal.org so that new positions are tweeted from the @drupaljobs handle.

DrupalCI: troubleshooting a PHP 5.6 garbage collection bug

DrupalCI Logo

Our infrastructure team investigated a random failure in Core branch tests that happened when testing against PHP 5.6. Whenever a random failure like this appears on our testing infrastructure, it’s important for us to track down the cause. Is it a problem in testbot configuration, an unusual kind of regression introduced in code or in the test itself, or a bug in an underlying part of the stack, like PHP itself? For now, we believe the issue is related to PHP garbage collection, and we’re trying to reproduce it so that we can open a bug for PHP.

Upgrading Drupal.org servers to PHP 5.4

PHP 5.3 limitations may have caused some recent instability (like the outages on the weekend of February 14). Because of this instability, we upgraded our production and pre-production servers to PHP 5.4. We’d previously held off on this upgrade due to two sub-sites: qa.drupal.org (QA) and groups.drupal.org (GDO). However, we used this opportunity to statically archive QA (now that it is superseded by DrupalCI), and to upgrade outdated parts of GDO to work with PHP 5.4.

———

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

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

Richard Burford (psynaptic) was an active contributor in the Drupal community. After he joined the community in late 2006, he actively encouraged, organized, and mentored other community members, while also posting more than 1,100 commits.

On February 11, Richard unexpectedly passed away while jogging. He’s survived by his wife, Sara, and their three children, William (aged 2), and twins Lucy and Kate (age 1). This spotlight has been a collaborative community project, and showcases just a few of the many qualities and contributions admired most about Richard.

Richard Burford at DrupalCon Paris
(Photo taken by Dan Smith (galooph) outside a bar at DrupalCon Paris.)

"I got to know psynaptic through #drupal-uk (back when it was still #drupaluk). He was kind, generous and funny," said James Panton(mcjim). " There were lots of late-night chats on IRC where we talked about Drupal, music, anything really. We were​ all very​ excited when he could make it to Manchester for the UK’s first DrupalCamp. He was even kinder, funnier, and more generous in real life"

Richard was active both in his local community, and in the wider Drupal world.

"I first met Richard at DrupalCamp Manchester, my first ever DrupalCamp," said Simon Poulston (soulston). "Richard instantly stood out with his insatiable energy, positivity and that beaming smile we all came to know. That Manchester trip resulted in our trip to DrupalCon Paris where we both made some amazing new friends from the community and had a truly epic time. We worked on projects together over the next few years, roomed at camps together, shared music, and remained friends ever since."

As it turned out, DrupalCon Paris was an important point in Richard's Drupal journey: it was there that he made numerous lasting friendships, and it started his journey to multiple DrupalCons around the world.

"Rich and I both started working with Drupal around the same time and quickly became friends, first on the #drupal-uk IRC channel before actually meeting for real at DrupalCon Paris," said Stella Power (stella). "He was a great guy. Not only was he always willing to help out, but he was also good company, always smiling and great fun to hang out with."

Alex Pott (alexpott) had a similar story to tell. "I went to DrupalCon Paris knowing nobody in the Drupal community. Richard was the first person I met. How lucky was that? Meeting someone so warm, generous and talented is one of the reasons I haven't missed a DrupalCon since."

"I knew how clever, knowledgeable, and helpful Richard was from seeing him online," said Elliot Ward (Eli-T). "But when I shared a room with him at DrupalCon Copenhagen, I found out how much fun he was as well. In that week Richard taught me so much: how to contribute back, how to roll a patch, how to advocate in the issue queues, and what a chicken parmo was. He went out of his way to introduce me to so many people that week, many of whom I've worked with since. That was when I realized how important the community is in Drupal—all because of the actions of one man looking out for someone he'd never met before."

"Always such a great part of the Drupal community"

Even when he wasn't fostering global connections, Richard was still actively helping out his community. A founding member of England's Drupal North East group, Richard left his mark on the Drupal community in every way he could.

"We met at DrupalCons across the world several times, and at DrupalCon Copenhagen we decided that it was ridiculous that we hadn't actually met back home. That was when we started the Drupal North East group together," said Adam Hill (adshill). In the time since the group was founded, Drupal North East has grown into a thriving community with over 100 members. "Richard has left a legacy of being one of the motivated troopers who rallied the Drupal community in his own area of the world," Hill said. "But he did so much more too, supporting people across the world with his generous nature and amazing spirit."

"He was always so helpful and such a great part of the Drupal community here in the UK," agreed Mike Bell (mikebell_). "We will miss him dearly."

Regardless of where he was, Richard's helpfulness was always on display. Whether he was helping new Drupalers find their feet on IRC, evangelizing Drupal with his local user group, or participate in a DrupalCon, Richard was always an important source of information and good cheer.

"I first met Richard and his [then] newlywed wife, Sara, at DrupalCon Denver. I was fairly new to Drupal at the time," said Alex Burrows (aburrows). "He welcomed me into the group, and we wound up attending many parties together, having good laughs, and drinking lots of beer. He was down to earth and always lightened up the conversation. It was a pleasure, and meant a lot."

Mike Carter (budda) agreed. "At DrupalCamps and Cons you couldn't miss Richard towering above the Drupal crowd, happy to chat with all. On IRC, he was always happy to help others with their Drupal questions. He was dedicated, knowledgeable, and enthusiastic about whatever challenge was brought to him."

Justine Pocock (wigglykoala) benefited from Richard's mentoring, and thanks him for some of the best guidance she's ever received. "When I first started with Drupal, I went into IRC trying to figure out what this CMS thing did. Richard (psynaptic) was one of the first people to help me there and show me the way. He was also one of the first to tell me to shut up and get my head down with learning Drupal—which actually is one of the most valuable pieces of advice I've been given! I've always (and will always) look up to Richard as a truly dedicated person."

"Fierce, dedicated, focused, and generous, Richard impressed me as he impressed and helped so many of us in the Drupal community," agreed Jeffrey A. McGuire (horncologne).

"He seemed to have near-limitless energy for getting things done ‘the right way’"

That fierce dedication helped Richard develop a reputation in the community of being an extremely passionate advocate not only for the project, but for programming and web development in general.

"I'll never forget the day that Richard introduced me to Drupal," said his longtime friend Dan Traynor (hitby). "We built a Teacher's Toolkit (in Drupal 5!) in a few hours and I was a convert. From that point on we attended a few DrupalCons together where he introduced me to many amazing developers. That forged my love for Drupal and the community. I can honestly say that without Rich I'm not sure I'd still be in the web development game."

"Richard inspired me to take my business forward in the ‘right’ way, by paying attention to detail and expressing my belief in the craft of programming," said Hill (adshill). "He was someone who clearly believed in the pleasure and value of giving, and he gave so much."

"Richard started contributing to the Textmate project during the pre-PHPStorm era, and he really made it shine," said Moshe Weitzman (moshe-weitzman). "He eventually took it over and maintained it as Drupal core and contrib grew and grew. Maintenance is a non-trivial and often unrewarding task, and it spoke a lot to his character that he would step up like that."

In addition to maintaining the Textmate project, Richard maintained Drupal Contrib API, and worked in a variety of technical roles within the Software Development, Web Design, Drupal Training, and Music Production industries. Most recently, Richard worked at Acquia as a senior software engineer.

"I’ve spoken with many people in recent days about Richard, and many described him as their favourite person in the company," said Alan Evans (alan-evans) of Acquia. "He was hugely popular: always the first person to offer a warm-hearted welcome to newcomers, or help people out with questions. And he had a talent for keeping the team in good spirits with his quick wit and laughter.

"Richard seemed to have near-limitless energy for getting things done ‘the right way’ and would pursue that goal with enviable zeal. His perfectionism didn’t necessarily agree with everyone all of the time, but he was greatly respected for having the courage to stick to his guns," he added.

"He was always there when you needed him"

Whether he was helping with code or with housework, Richard's belief in doing things the right way always shone through. He was always there for those who needed him. Now, the community is paying that love forward.

Poulston (soulston) said of his friend, "Richard was a shining example to us all of how one person truly can make a difference. He helped me and many other people countless times, and you could tell that genuinely enjoyed helping people be the best they could at whatever they did, be it music or code. That’s not only a talent, but a trait of a beautiful human being."

"Rich was always there when you needed him," agreed Traynor (hitby). "His need for perfection pushed into every area of his life. He once came to help me wallpaper a room, a task that I imagined would take about a day. Three days later we finished. I've never seen wallpaper so smooth! Thinking about it, Rich got me into many things: mountain biking, vaping (yes, I have him to thank for quitting smoking as well), music...the list goes on. The world was a better place with him in it and I'm proud to be able to have called him a friend." He added, "I love you Rich, Sara, William, Lucy, and Kate."

Hill (adshill) had wishes of peace for Richard's family as well. "Sara, I only met you twice, and you may not remember us," he said, "but my girlfriend Ieva and I send all our love to you and the kids. We hope you gain strength from knowing that we all saw how special Richard was too —and that he will be missed by friends from across the world."

"Richard was a good friend, a proud family man, and an excellent developer: a larger-than-life personality that left a lasting impression with those he met," agreed Evans (alan-evans). "I know a visit to a DrupalCon (or even the office) is not going to be the same without him. We all miss him very much."

But perhaps everyone's feelings about Richard were best summed up by Pott (alexpott), who said simply: "Richard is one of the brightest stars I've ever met. I count myself lucky to have known him."

Whether you knew Richard personally or were introduced to him for the first time through this spotlight, Richard’s friends would like to encourage you to consider donating to the GoFundMe page that was set up in Richard's memory, benefitting his wife and children.

The Drupal community has lost a valued collaborator and advocate in Richard, but his contributions both to the project and to people’s lives will always live on.

Special thanks to the following Drupal community members for their help with this community spotlight: