Drupal has a Drupal.checkPlain() JavaScript function which is used to escape potentially dangerous text before outputting it to HTML. This function does not correctly handle all methods of injecting malicious HTML, leading to a cross-site scripting vulnerability under certain circumstances.

The PHP functions which Drupal provides for HTML escaping are not affected.

Private file access bypass - Moderately Critical - Drupal 7

When using Drupal's private file system, Drupal will check to make sure a user has access to a file before allowing the user to view or download it. This check fails under certain conditions in which one module is trying to grant access to the file and another is trying to deny it, leading to an access bypass vulnerability.

This vulnerability is mitigated by the fact that it only occurs for unusual site configurations.

A jQuery cross site scripting vulnerability is present when making Ajax requests to untrusted domains. This vulnerability is mitigated by the fact that it requires contributed or custom modules in order to exploit.

For Drupal 8, this vulnerability was already fixed in Drupal 8.4.0 as a side effect of upgrading Drupal core to use a newer version of jQuery. For Drupal 7, it is fixed in the current release (Drupal 7.57) for jQuery 1.4.4 (the version that ships with Drupal 7 core) as well as for other newer versions of jQuery that might be used on the site, for example using the jQuery Update module.

When using node access controls with a multilingual site, Drupal marks the untranslated version of a node as the default fallback for access queries. This fallback is used for languages that do not yet have a translated version of the created node. This can result in an access bypass vulnerability.

This issue is mitigated by the fact that it only applies to sites that a) use the Content Translation module; and b) use a node access module such as Domain Access which implement hook_node_access_records().

Note that the update will mark the node access tables as needing a rebuild, which will take a long time on sites with a large number of nodes.

Settings Tray access bypass - Moderately Critical - Drupal 8

The Settings Tray module has a vulnerability that allows users to update certain data that they do not have the permissions for.

If you have implemented a Settings Tray form in contrib or a custom module, the correct access checks should be added. This release fixes the only two implementations in core, but does not harden against other such bypasses.

This vulnerability can be mitigated by disabling the Settings Tray module.

External link injection on 404 pages when linking to the current page - Less Critical - Drupal 7

Drupal core has an external link injection vulnerability when the language switcher block is used. A similar vulnerability exists in various custom and contributed modules. This vulnerability could allow an attacker to trick users into unwillingly navigating to an external site.

External link injection on 404 pages when linking to the current page - Less Critical - Drupal 7

The following blog was written by Drupal Association Premium Supporting Partner, DrupalCamp London.

The people surrounding Drupal have always been one of its strongest selling points; hence the motto “Come for the code, stay for the community”. We bring individuals from a multitude of backgrounds and skill sets together to push forward towards a common goal whilst supporting and helping each other. Within the community, there are a number of ways to connect to each other; both online and in person. A good way to meet in person is by attending DrupalCons and DrupalCamps.

DrupalCamps

A DrupalCamp can be similar to a DrupalCon but is on a much smaller scale. Where a ‘Con has 1,600+ attendees a ‘Camp ranges anywhere from 50-600 people. In Europe alone there were over 50 camps in 2017, including DrupalCamp London.

DrupalCamp London

DrupalCamp London brings together hundreds of people from across the globe who use, develop, design, and support the Drupal platform. It’s a chance for Drupalers from all backgrounds to meet, discuss, and engage in the Drupal community and project. DrupalCamp London is the biggest camp in Europe (followed very closely by Kiev), at ~600 people over three days. Due to its size and location, we’re able to run a wide range of sessions, keynotes, BoFs, Sprints, and activities to take part in.

What happens over the three days?

Friday (CxO day)

Friday (CxO day) is primarily aimed at business leaders who provide or make use of Drupal services (i.e web development agencies, training companies, clients etc), but naturally, everyone is welcome. Throughout the day we'll have speakers talking about their experiences working with Drupal and Open Source technologies in their sector(s) or personal life. With a hot food buffet for lunch and a free drinks reception at the end of the day, you'll also have ample time to network with the other attendees.

Benefits of attending

Understand how leading organisations leverage the many benefits of Drupal

Network with similar organisations in your sector

Learn directly from thought leaders via specific case studies

Saturday/Sunday (Weekend event)

Over the weekend, we have 3 Keynote speakers, a choice of over 40 sessions to attend, BoF (Birds of a Feather) talks, Sprints, great lunch provided (both days) and a Saturday social. With all the activity there is something for everyone to get involved in.

Benefits of attending

Networking

Over 500 people attended the weekend event last year and we are expecting it to grow even more this year. Not all attendees are devs either, with a fair share of managers, designers, C-Level, and UX leads there's a great opportunity for all skill sets to interact with each other. Big brands use Drupal (MTV, Visit England, Royal.gov, Guardian, Twitter, Disney) and this is a chance to meet with people from those companies to compare notes, and learn from each other.

Recruitment

As above, the chance to meet so many people from various skill sets is a great way to line up potential interviews and hires for any aspect of your business. At the very least you'll be able to meet interesting people for any future potential hires.

Marketing & Raising company profile

Attending an event with a huge turnout is a great way to meet people and talk to them about what you and your company do. Embedding your name within the tight-knit Drupal community can attract the attention of other companies. Sponsoring the camp means that your logo and additional information can be seen around the camp, in tote bags given to attendees, and online. The social and sponsors stands are the perfect chance to talk to other companies and people attending DrupalCamp, to find out how they use Drupal for their benefit.

Learning

DrupalCamp isn't just for Devs, over the weekend there are sessions on a broad range of topics including community & business, UX, and general site building/using Drupal. The technical topics aren’t just Drupal specific either, this gives developers (and others) the ability to learn more about general core coding concepts and methodologies. The methods and techniques learnt help with day to day development and long-term work. In addition to the planned sessions, BoF (birds of a feather) sessions, there are ad-hoc get-togethers where people can talk on any topic, allowing a free discussion to share ideas.

Warm fuzzy feeling/giving back

Drupal (like any open source software) wouldn't survive without the community. Camps and other events allow the members to come together and see ‘first hand’ that they’re giving back to a community that helps power their tech, maintains their interests, and enables them to make a living.

How to get involved?

It’s easy to get involved with DrupalCamp London, check us out on Twitter for updates and you can find out more about the event and buy tickets on our website.

More and more developers are choosing content-as-a-service solutions known as decoupled CMSes, and due to this trend, people are asking whether decoupled CMSes are challenging the market for traditional CMSes.

By nature, decoupled CMSes lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Luckily, Drupal has one crucial advantage that propels it beyond these concerns of emerging decoupled competitors.

Join Dries Buytaert, founder of Drupal and CTO at Acquia, as he shares his knowledge on how Drupal has an advantage over competitors, and discusses his point-of-view on why, when, and how you should implement decoupled Drupal.

Dries will touch on:

His thoughts on decoupled CMSes - where is the CMS market headed and when?

His opinion on whether decoupled CMSes will replace traditional CMSes

The advantages of decoupled Drupal vs. emerging decoupled competitors

Considerations when determining if decoupled Drupal is right for your project

Dries Buytaert

CHAIRMAN, CHIEF TECHNOLOGY OFFICERACQUIA, INC.

Dries Buytaert is an open source developer and technology executive. He is the original creator and project lead for Drupal, an open source platform for building websites and digital experiences. Buytaert is also co-founder and chief technology officer of Acquia, a venture-backed technology company. Acquia provides an open cloud platform to many large organizations, which helps them build, deliver and optimize digital experiences. A Young Global Leader at the World Economic Forum, he holds a PhD in computer science and engineering from Ghent University and a Licentiate Computer Science (MsC) from the University of Antwerp. He was named CTO of the Year by the Massachusetts Technology Leadership Council, New England Entrepreneur of the Year by Ernst & Young, and a Young Innovator by MIT Technology Review. He blogs frequently on Drupal, open source, startups, business, and the future at dri.es.

The following blog was written by Drupal Association Signature Supporting Partner, Open Social by GoalGorilla.

A living style guide - a way to control markup or CSS - has been making a name for itself. And for a good reason; they’re an important tool for web development. They keep developers in sync, communicate design standards, and help organize complex interfaces. In this post, I want to discuss how and why living style guides are important and how to implement one for Open Social using Drupal for software.

We're using a living style guide because it serves as a valuable internal resource for development; we’re able to write reusable and consistent code that's easy to maintain. And it’s a great external resource for client deliverables. Ready to see how to make a living style guide work with Drupal software? Let’s go!

Moving From Static to Dynamic

We didn’t always rely on a living style guide. Open Social was built and maintained using different strategies such as component libraries and atomic designs. These strategies have advantages, such as reusability, facilitating collaboration within the team, and ensuring design consistency. There were, however, disadvantages to a static style of working.

In the past, a component library or style guide was usually graphic-based. The designer would create a visual representation of a component (in PS or Sketch, for example) and then the front-end developer would transfer these visuals to HTML and CSS. This immediately meant double maintenance; for instance, if the markup or CSS changes, the graphics style guide would need to be updated to reflect this change and vice-versa. In our experience, the shelf life of these “static” systems is only a few iterations before the graphic version gets left behind and forgotten due to too much maintenance and not enough return. Yikes.

This is why we decided that it was time for a change. What we needed what a more dynamic system: a living style guide.

A Living Style Guide Is the Best

Any style guide is better than none but a living style guide is the best.

A living style guide consists of a single source of code, thankfully. The style guide’s markup, javascript, and CSS are the same as what was used in production. This provides a wide array of benefits. See below!

Sharing design capabilities. Our team easily shares design capabilities between designers and front-end developers, which also benefits the backend developers and project managers who work with us.

Less reliance on other team members. The developers refer to the style guide and reuse components for new features without being heavily reliant on the designers and front-end developers for implementation.

Most importantly, the client benefits. The project manager offers new feature ideas and lower-cost solutions to the client, based on reusing and recombining existing components. Inevitably our clients benefit from this, especially when they begin thinking this way themselves.

While this blog post focuses on how we work on Open Social enterprise projects, it is also an accurate reflection of working in the Drupal frontend nowadays. A quick google for “Drupal Living Style Guide” can give you some ideas about the current popularity, challenges, and general atmosphere surrounding the subject. In the next section of the blog, I will take you through the steps of setting up a living style guide with Open Social.

Side note: refer to this GitHub repo for an example of a component library within a Drupal theme folder structure, and package.json with dependencies, gulpfile.js for run KSSnode style guide and generate assets for the Drupal theme.

The Drupal Component Library Module and Twig Namespaces

The living style guide firstly requires the Component Library Drupal module to get up and running. The Drupal components library allows us to create custom twig namespaced paths. This means we are not limited to placing our components in the Drupal theme templates folder (as the current Drupal 8 architecture dictates).

The KSS style guide lives in our theme directory but has no knowledge of Drupal. This is what makes it so flexible. In theory, we can copy the component library directory and use it in other (non-Drupal) projects. A big thanks to John Albin, the maintainer of Zen Theme and KSS node, for paving the way for us to implement our theme and style guide.

Once the namespace has been defined, you can include and extend twig templates from the component library, Drupal’s template override files and other components (like in an atomic design approach) by simply referring to the files like this:

Social Blue comes with the style guide ready to go (read the Social Blue readme and follow the instructions on how to create a custom theme from it). However, because we have copied this to our custom theme folder, the gulpfile that runs the different tasks needs to be updated to reflect the new location in relation to the base theme (socialbase).

Compiling the Style Guide

Basically, most of the action happens in the gulpfile. Spending some time reading its comments and exploring it really helps you understand the dynamics of linking a Drupal theme with a living style guide.

If we refer to the package.json, we will see which packages we have installed, and by examining the gulp tasks and configuration, we can get a sense of how the style guide is compiled from our component library and theme files.

The Theory

We are relying on Drupal's theme layer to render the twig files from our components and attach the libraries (our CSS and js). We also rely on the component module to create the namespace allowing us to map Drupal variables with the json variables in our style guide.

The style guide copies Drupal’s theme assets (CSS and js) and has its own twig compiler (see os-builder folder).

The end result is the style guide made up of CSS/js copied from the base theme’s assets folder, our theme’s assets folder, and HTML generated from the twig and json, from our component library. The CSS/js copied from the assets folders need to be included in the gulpfile to be copied into your style guide.

(Side note: a nice little improvement is to have a designated folder, therefore avoiding the need to list each file.)

The Drupal HTML pages and the style guides are not shared. This is important to point out because caching might affect each differently.

The style guide isn’t a layer because it doesn’t know Drupal exists beyond sharing the files in the component library directory. This concept illustrates one of the powerful elements of a dynamic component library - you can copy it from project to project, regardless of the environment, because in the end, all it really is is HTML, CSS, and javascript (see image below).

Diagram of how a component library, KSSNode style guide, and Drupal theme work together to make a living style guide

In Conclusion...

For front-end developers and designers, a living style guide is becoming an essential part of the web developer’s toolkit.

We are able to focus on the implementation of design components while the backend is being built, thus working in parallel with our team members instead of relying on others to finish before we can start.

We can do browser and accessibility tests on a component level, thus improving the quality of features (current and future). Another benefit (one that deserves a blog post on its own) is implementing visual regression testing on the living style guide to help spot changes in HTML or CSS negatively affecting existing elements.

The time investment needed, especially for a complex project, is nothing compared to the peace of mind knowing adding new elements does not break others.

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

It wasn’t a question of if, but a question of when and the Drupal.org weekly usage statistics are showing it’s happening now. Usage of Lingotek’s Drupal 8 Module finally caught up to and exceeded that of Drupal 7. Is this the tipping point? Is the community finally making the switch to the latest Drupal module?

The Drupal.org Usage Statistics for Lingotek Translation provides information about the usage of the Lingotek Translation project--Lingotek - Inside Drupal 7 Module and the Lingotek - Inside Drupal 8 Module--with summaries across all versions and details for each release. It shows the week and the number of sites that reported using a given version of the project.

The usage figures reflect the number of sites using the project/item that week. The results can give an idea of how popular the different projects are and may help users choose modules and themes for their own sites. The figures are an indicator of which modules are being used. Note: Only Drupal websites using the Update Status module are included in the data.

In the past 6 months, the Drupal.org weekly statistics showed Drupal 7 usage was still going strong. There were twice as many users using the Drupal 7 version in April, May, June, July, August, and September. But starting in October, Drupal 8 usage began to tick upward. In the first week, only 269 reported using the D8 version. Then the momentum quickly shifted. By the second week of October, they were almost equal with 441 users of Drupal 7 and 420 using Drupal 8; they were a scant 19 users apart. Then came the tipping point.

In the third week of October, Drupal 8 usage overtook that of Drupal 7. In a huge turnaround, 772 reported using Drupal 8 when compared to only 447 using Drupal 7.

Since then, the gap narrowed somewhat, but regained a solid lead once again in early November with 894 D8 users and 416 using the D7 version. We’re predicting the lead is here to stay. The tipping point was inevitable.

The support is likely the result of the growing need for localized content. Multilingual web content is critical to engage a global audience that wants to search, shop, and buy in their own language. The Drupal 8 version, with its built in multilingual capability, makes it easier than ever to create content for a global audience. The module supports translation of any content and configuration, including:

The Lingotek - Inside Drupal Module is the only Drupal module to integrate a Translation Management System directly into Drupal, allowing the Drupal community to use professional-grade translation technologies (e.g. machine translation, translation memory, CAT tool) without ever leaving the Drupal environment. It is built on Drupal's standard multilingual modules (Locale, content translation, entity translation, internationalization, etc.) and helps Drupal administrators, agencies, and web marketers get a Drupal site multilingual-ready within minutes, instead of days.

Many Drupal users have strong opinions about which is better--Drupal 7 or Drupal 8, but one thing is clear: Drupal 8 is the future. The level of innovation and improved functionality available in each new release will be hard to ignore. These usage statistics reflect that the community has begun wholesale migration to Drupal 8 and that we’ve finally reached the tipping point.

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

Seventeen years ago today, I open-sourced the software behind Drop.org and released Drupal 1.0.0. When Drupal was first founded, Google was in its infancy, the mobile web didn't exist, and JavaScript was a very unpopular word among developers.

Over the course of the past seventeen years, I've witnessed the nature of the web change and countless internet trends come and go. As we celebrate Drupal's birthday, I'm proud to say it's one of the few content management systems that has stayed relevant for this long.

While the course of my career has evolved, Drupal has always remained a constant. It's what inspires me every day, and the impact that Drupal continues to make energizes me. Millions of people around the globe depend on Drupal to deliver their business, mission and purpose. Looking at the Drupal users in the video below gives me goosebumps.

Drupal's success is not only marked by the organizations it supports, but also by our community that makes the project more than just the software. While there were hurdles in 2017, there were plenty of milestones, too:

At least 190,000 sites running Drupal 8, up from 105,000 sites in January 2016 (80% year over year growth)

1,597 stable modules for Drupal 8, up from 810 in January 2016 (95% year over year growth)

76,374 instance hours for running automated tests (the equivalent of almost 9 years of continuous testing in one year)

Since Drupal 1.0.0 was released, our community's ability to challenge the status quo, embrace evolution and remain resilient has never faltered. 2018 will be a big year for Drupal as we will continue to tackle important initiatives that not only improve Drupal's ease of use and maintenance, but also to propel Drupal into new markets. No matter the challenge, I'm confident that the spirit and passion of our community will continue to grow Drupal for many birthdays to come.

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

In this post, I'm providing some guidance on how and when to decouple Drupal.

Almost two years ago, I had written a blog post called "How should you decouple Drupal?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their Drupal architectures. Since that point, Drupal, its community, and the surrounding market have evolved, and the original flowchart needs a big update.

All the ways to decouple Drupal

The traditional approach to Drupal architecture, also referred to as coupled Drupal, is a monolithic implementation where Drupal maintains control over all front-end and back-end concerns. This is Drupal as we've known it — ideal for traditional websites. If you're a content creator, keeping Drupal in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional Drupal 8 also remains a great approach for developers who love Drupal 8 and want it to own the entire stack.

A second approach, progressively decoupled Drupal, offers an approach that strikes a balance between editorial needs like layout management and developer desires to use more JavaScript, by interpolating a JavaScript framework into the Drupal front end. Progressive decoupling is in fact a spectrum, whether it is Drupal only rendering the page's shell and populating initial data — or JavaScript only controlling explicitly delineated sections of the page. Progressively decoupled Drupal hasn't taken the world by storm, likely because it's a mixture of both JavaScript and PHP and doesn't take advantage of server-side rendering via Node.js. Nonetheless, it's an attractive approach because it makes more compromises and offers features important to both editors and developers.

Last but not least, fully decoupled Drupal has gained more attention in recent years as the growth of JavaScript continues with no signs of slowing down. This involves a complete separation of concerns between the structure of your content and its presentation. In short, it's like treating your web experience as just another application that needs to be served content. Even though it results in a loss of some out-of-the-box CMS functionality such as in-place editing or content preview, it's been popular because of the freedom and control it offers front-end developers.

What do you intend to build?

The most important question to ask is what you are trying to build.

If your plan is to create a single standalone website or web application, decoupling Drupal may or may not be the right choice based on the must-have features your developers and editors are asking for.

If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use Drupal to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.

Ultimately, your needs will determine the usefulness of decoupled Drupal for your use case. There is no technical reason to decouple if you're building a standalone website that needs editorial capabilities, but that doesn't mean people don't prefer to decouple because of their preference for JavaScript over PHP. Nonetheless, you need to pay close attention to the needs of your editors and ensure you aren't removing crucial features by using a decoupled approach. By the same token, you can't avoid decoupling Drupal if you're using it as a content repository for IoT or native applications. The next part of the flowchart will help you weigh those trade-offs.

Today, Drupal makes it much easier to build applications consuming decoupled Drupal. Even if you're using Drupal as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" Drupal.

Are there things you can't live without?

Perhaps most critical to any decision to decouple Drupal is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled Drupal, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.

For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where Drupal does not exert control over the front end.

On the other hand, the need for control over the visual presentation of content can hinder developers who want to craft nuanced interactions or build user experiences in a particular way. Moreover, developer teams often want to use the latest and greatest technologies, and JavaScript is no exception. Nowadays, more JavaScript developers are including modern techniques, like server-side rendering and ES6 transpilation, in their toolboxes, and this is something decision-makers should take into account as well.

How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling Drupal will remove all of the critical linkages within Drupal that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled Drupal can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.

What will the future hold?

In the future, and in light of the rapid evolution of decoupled Drupal, my hope is that Drupal keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. Drupal's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by Drupal grows.

I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in Drupal today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.

Today, developers are beginning to use Drupal not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.

Conclusion

Thankfully, Drupal is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in Drupal 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of Drupal the tools to interact with it in unprecedented ways.

Unlike many other content management systems, old and new, Drupal provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling Drupal, progressively decoupling it, and traditional Drupal — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets Drupal apart from new headless content management systems and most SaaS platforms, and it also shows Drupal's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; Drupal has the answer.

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

If you’re a marketer considering a move from Drupal 7 to Drupal 8, it’s important to understand the implications of content migration. You’ve worked hard to create a stable of content that speaks to your audience and achieves business goals, and it’s crucial that the migration of all this content does not disrupt your site’s user experience or alienate your visitors.

Content migrations are, in all honesty, fickle, challenging, and labor-intensive. The code that’s produced for migration is used once and discarded; the documentation to support them is generally never seen again after they’re done. So what’s the value in doing it at all?

YOUR DATA IS IMPORTANT (ESPECIALLY FOR SEO!)

No matter what platform you’re working to migrate, your data is important. You’ve invested lots of time, money, and effort into producing content that speaks to your organization’s business needs.

Migrating your content smoothly and efficiently is crucial for your site’s SEO ranking. If you fail to migrate highly trafficked content or to ensure that existing links direct readers to your content’s new home you will see visitor numbers plummet. Once you fall behind in SEO, it’s difficult to climb back up to a top spot, so taking content migration seriously from the get go is vital for your business’ visibility.

Also, if you work in healthcare or government, some or all of your content may be legally mandated to be both publically available, and letter-for-letter accurate. You may also have to go through lengthy (read: expensive) legal reviews for every word of content on your sites to ensure compliance with an assortment of legal standards – HIPPA, Section 508 and WCAG accessibility, copyright and patent review, and more.

Some industries also mandate access to content and services for people with Limited English Proficiency, which usually involves an additional level of editorial content review (See https://www.lep.gov/ for resources).

At media organizations, it’s pretty simple – their content is their business!

In short, your content is an business investment – one that should be leveraged.

SO WHERE DO I START WITH A DRUPAL 8 MIGRATION?

Like with anything, you start at the beginning. In this case that’s choosing the right digital technology partner to help you with your migration. Here’s a handy guide to help you choose the right vendor and start your relationship off on the right foot.

Once you choose your digital partner content migration should start at the very beginning of the engagement. Content migration is one of the building blocks of a good platform transition. It’s not something that can be left for later – trust us on this one. It’s complicated, takes a lot of developer hours, and typically affects your both content strategy and your design.

Done properly, the planning stages begin in the discovery phase of the project with your technology vendor, and work on migration usually continues well into the development phase, with an additional last-sprint push to get all the latest content moved over.

While there are lots of factors to consider, they boil down to two questions: What content are we migrating, and how are we doing it?

WHICH CONTENT TO MIGRATE

You may want to transition all of your content, but this is an area that does bear some discussion. We usually recommend a thorough content audit before embarking on any migration adventure. You can learn more about website content audits here. Since most migration happens at a code & database level, it’s possible to filter by virtually any facet of the content you like. The most common in our experience are date of creation, type of content, and categorization.

While it might be tempting to cut off your site’s content to the most recent few articles, Chris Anderson’s 2004 Wired article, “The Long Tail” (https://www.wired.com/2004/10/tail/) observes that a number of business models make good use of old, infrequently used content. The value of the Long Tail to your business is most certainly something that’s worth considering.

Obviously, the type of content to be migrated is pretty important as well. Most content management systems differentiate between different ‘content types’, each with their own uses and value. A good thorough analysis of the content model, and the uses to which each of these types has been and will be used, is invaluable here. There are actually two reasons for that. First, the analysis can be used to determine what content will be migrated, and how. Later, this analysis serves as the basis of the creation of those ‘content types’ in the destination site.

A typical analysis takes place in a spreadsheet (yay, spreadsheets!). Our planning sheet has multiple tabs but the critical one in the early stages is Content Types.

Here you see some key fields: Count, Migration, and Field Mapping Status.

Count is the number of items of each content type. This is often used to determine if it’s more trouble than it’s worth to do an automated content migration, as opposed to a simple cut & paste job. As a very general guideline, if there are more than 50 items of content in a content type, then that content should probably be migrated with automation. Of course, the amount of fields in a content type can sway that as well. Once this determination is made, that info is stored in the Migration field.

The Field Mapping Status Column is a status column for the use of developers, and reflects the current efforts to create the new content types, with all their fields. It’s a summary of the Content Type Specific tabs in the spreadsheet. More detail on this is below.

Ultimately, the question of what content to migrate is a business question that should be answered in close consultation with your stakeholders. Like all such conversations, this will be most productive if your decisions are made based on hard data.

HOW DO WE DO IT?

This is, of course, an enormous question. Once you’ve decided what content you are going to migrate, you begin by taking stock of the content types you are dealing with. That’s where the next tabs in the spreadsheet come in.

The first one you should tackle is the Global Field Mappings. Most content management systems define a set of default fields that are attached to all content types. In Drupal, for example, this includes title, created, updated, status, and body. Rather than waste effort documenting these on every content type, document them once and, through the magic of spreadsheet functions, print them out on the Content Type tabs.

Generally, you want to note Name, Machine Name, Field Type, and any additional Requirements or Notes on implementation on these spreadsheets.

It’s worth noting here that there are decisions to be made about what fields to migrate, just as you made decisions about what content types. Some data will simply be irrelevant or redundant in the new system, and may safely be ignored.

In addition to content types, you also want to document any supporting data – most likely users and any categorization or taxonomy. For a smooth migration, you usually want to actually start the development with them.

The last step we’ll cover in this post is content type creation. Having analyzed the structure of the data in the old system, it’s time to begin to recreate that structure in the new platform. For Drupal, this means creating new content type bundles, and making choices about the field types. New platforms, or new versions of platforms, often bring changes to field types, and some content will have to be adapted into new containers along the way. We’ll cover all that in a later post.

Now, many systems have the ability to migrate content types, in addition to content. Personally, I recommend against using this capability. Unless your content model is extremely simple, the changes to a content type’s fields are usually pretty significant. You’re better off putting in some labor up front than trying to clean up a computer’s mess later.

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

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

Katie Graham

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

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

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

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

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

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

Rebecca Rodgers

Passionate | honest | energetic

How did you get your start in technology?

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

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

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

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

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

Laura Munro

Nerdy | organised | creative

How did you get your start in technology?

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

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

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

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

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

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

Kristy Devries

Sassy | passionate | conscientious

How did you get your start in technology?

My whole life I have always wanted to do everything, especially when it came to creative industries. When I was young, I did not have motivation to keep pursuing hobbies, apart from playing rollercoaster tycoon (which has resulted in me now being a bit cautious around theme parks). I was around fourteen years old when I randomly decided that I wanted to learn how to make websites. So I bought two books, one on HTML and the other on PHP and spent hours everyday after school learning. I initially used my HTML and CSS knowledge to spruce up my MySpace profile page and then I bought a domain name and installed the very first version of WordPress, I did not know about Drupal back then (so sorry), and started a blog. I don’t remember what I wrote about but I remember I had random internet blogger friends, I would list their website on my site and vice versa. Those were the days.

After high school, I did a year of an interdisciplinary creative industries bachelor, before deferring and spending the next few years working in hospitality and traveling around the world. One morning, while working in a coffee shop in Europe, I decided that I wanted to pursue a career in technology. I came back to Brisbane with a plan to study and concentrate on my career. After dedicating many nights on an application, making a website resume and sending it off, revamping my website resume, sending that off again and numerous calls later, I landed a job as a junior web developer at a local agency in Brisbane - my first job in this tech industry.

Support can be one of the toughest and sometimes even least rewarding gigs in tech, you seem to really enjoy it… why?

While it can certainly be tough sometimes, the people I work with are a big part of why I enjoy it. There’s a real sense of comradery, especially within Acquia Support. If you’re stuck on a puzzling problem, there’s a global group of amazing people ready to jump in to help you. And provide banter of course.

I also get a chance to work on projects, for example presenting at Drupal South, as part of my role within Support. These projects can involve front end web development, user experience, design, strategy, event planning, which gives me a chance to dabble in a few areas of interest. While we do have an office in Brisbane, we have the flexibility work from home, or work remotely from another country (I spent 2 months in USA this year) so I get to travel as well as develop my career, which one of the reasons I wanted to work in the tech industry.

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

You have leadership aspirations, what makes a good leader in the technology industry?

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

Laura Bell

Security | cat | herder

How did you get your start in technology?

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

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

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

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

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

Hannah Del Porto

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

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

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

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

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

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

Aimee Whitcroft

Open | inquisitive | incorrigible

How did you get your start in data?

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

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

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

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

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

Heike Theis

Strangely | optimistic | human

How did you get your start in technology?

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

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

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

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

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

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

Ruth McDavitt

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

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

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

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

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

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

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

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

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

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

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

Fonda Le

Passionate | goofy | hyperempathetic

How did you get your start in technology?

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

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

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

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

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

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

Donna Benjamin

Curious | connected | caffeinated

How did you get your start in technology?

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

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

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

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

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

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

Rikki Bochow

Happy | quiet | focused

How did you get your start in technology?

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

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

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

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

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

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

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

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

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

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

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

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

Lauri 'lauriii' Eskola, Front-end Framework Manager — Lauri is deeply involved with both the Out-of-the-Box Experience and the JavaScript Framework initiatives. In his role as front-end framework manager, he also reviews and unblocks patches that touch CSS/JS/HTML, which is key to many of the user-facing features in Drupal 8.5's roadmap.

Francesco 'plach' Placella, Framework Manager — Francesco has extensive experience in the Entity API and multilingual initiatives, making him an ideal reviewer for initiatives that touch lots of moving parts such as API-First and Workflow. Francesco was also a regular go-to for the Drupal 8 Accelerate program due to his ability to dig in on almost any problem.

Roy 'yoroy' Scholten, Product Manager — Roy has been involved in UX and Design for Drupal since the Drupal 5 days. Roy's insights into usability best practices and support and mentoring for developers is invaluable on the core team. He would love to spend more time doing those things, ideally supported by a multitude of companies each contributing a little, rather than just one.

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

Constituents at the center

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

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

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

Congratulations Mass.gov

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

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

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

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

What does Pai's draft order say?

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

The consequences of softening net neutrality regulations

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

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

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

What can you can do today

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

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

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

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

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

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

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

How IT people see each other:

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

(Sorry for the potato quality).

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

So how do you find the balance?

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

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

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

How IT people should see each other:

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

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

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

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

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

8.4: The march towards stability

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

8.4: Making more entity types revisionable

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

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

8.5+: Looking forward to workspaces

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

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

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

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

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

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

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

8.4: Stable versions of layout functionality

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

8.4: A Layout API in core

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

8.5+: A Layout Builder in core

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

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

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

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

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

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

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

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

8.4: a Media API in core

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

8.4+: porting contributed modules to the new Media API

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

8.5+: add support for remote video in core

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

8.6+: a Media Library in core

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

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

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

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

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

From Module Mayhem to Built-in Language Support

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

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

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

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

Step 1: Understand Your Site

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

Step 2: Examine Your Theme

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

Step 3: Think About Your Content

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

Step 4: Rein In Your Modules

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

Step 5: Examine Potential Trouble Spots

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

URL Aliases

Taxonomy Terms

Blocks

Fieldable Panels Panes

Mini-panels

Groups

Views

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

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

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

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

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

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

Discovering Drupal

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

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

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

Moving Forward

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

Local Projects

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

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

The Future

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

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

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

Next Spotlight?

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

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

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

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

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

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

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

More and more organizations wanted a headless Drupal so they can use a modern JavaScript framework to build application-like experiences.

Drupal's authoring and site building experience could be improved by using a more modern JavaScript framework.

JavaScript and Node.js were going to take the world by storm and that we would be smart to increase the amount of JavaScript expertise in our community.

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

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

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

Focusing on Drupal's web services instead

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

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

The current state of JavaScript in Drupal

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

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

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

It created a barrier for significantly leveling up the Drupal community's JavaScript skills. In my opinion, we still lack sufficient JavaScript expertise among Drupal core contributors. While we do have JavaScript experts working hard to maintain and improve our existing JavaScript code, I would love to see more experts join that team.

It made it harder to accelerate certain improvements to Drupal's authoring and site building experience.

It made it harder to demonstrate how new best practices and certain JavaScript approaches could be leveraged and extended by core and contributed modules to create new Drupal features.

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

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

Invest more in Drupal's API-first initiative. In 2017, there is no denying that decoupled architectures and headless Drupal will be a big part of our future. We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.

Embrace all JavaScript frameworks for building Drupal-powered applications. We should give developers the flexibility to use their JavaScript framework of choice when building front-end applications on top of Drupal — so they can use the right tool for the job. The fact that you can front Drupal with Ember, Angular, Vue, React, and others is a great feature. We should also invest in expanding the Waterwheel ecosystem so we have SDKs and references for all these frameworks.

Pick a framework for Drupal's own administrative user interfaces. Drupal should pick a JavaScript framework for its own administrative interface. I'm not suggesting we abandon our stable base of PHP code; I'm just suggesting that we leverage JavaScript for the things that JavaScript is great at by moving relevant parts of our code from PHP to JavaScript. Specifically, Drupal's authoring and site building experience could benefit from user experience improvements. A JavaScript framework could make our content modeling, content listing, and configuration tools faster and more application-like by using instantaneous feedback rather than submitting form after form. Furthermore, using a decoupled administrative interface would allow us to dogfood our own web service APIs.

Let's start small by redesigning and rebuilding one or two features. Instead of rewriting the entirety of Drupal's administrative user interfaces, let's pick one or two features, and rewrite their UIs using a preselected JavaScript framework. This allows us to learn more about the pros and cons, allows us to dogfood some of our own APIs, and if we ultimately need to switch to another JavaScript framework or approach, it won't be very painful to rewrite or roll the changes back.

Selecting a JavaScript framework for Drupal's administrative UIs

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

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

There was unanimous agreement that:

Adding a JavaScript framework to Drupal core is a good idea.

We want to have sufficient real-use experience to make a final decision prior to 8.6.0's development period (Q1 2018). To start, the Watchdog page would be the least intrusive interface to rebuild and would give us important insights before kicking off work on more complex interfaces.

While a few people named alternative options, React was our preferred option, by far, due to its high degree of adoption, component-based and unopinionated nature, and its potential to make Drupal developers' skills more future-proof.

This adoption should be carried out in a limited and incremental way so that the decision is easily reversible if better approaches come later on.

Conclusion

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

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

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

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

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

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

What’s new in the Suite?

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

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

Queue on failure. There is now an attempt to push synchronization immediately on entity save and enqueue for asynchronous push only on failure. This feature idea is a great compromise between the previous binary sync/async decision point.

Push queue overhaul, and cron-based push. Drupal 7's asynchronous push left a lot to be desired. Lack of error handling made debugging and troubleshooting difficult to impossible. Lack of optimizations burned unnecessary API calls. Both of these limitations were imposed by Drupal Queue API's fundamental nature. In Drupal 7, our options for extending the Queue system were limited. In Drupal 8, we've implemented a Salesforce Push Queue service, building on Drupal core's overhauled Queue API. We've taken the opportunity to normalize queue items, optimize queue operations, and implement error handling and recovery.

Objectification of Salesforce resources. Moving in the direction of a proper REST PHP SDK, we now have proper classes for Query Result, SObject, Salesforce ID, various REST Responses, and others. This not only allows for simple type-hinting across other classes, but also gives developers consistent and reliable interfaces, and paves the way for even greater extensibility in the future.

Queue settings per mapping. The Suite now allows administrators to assign sync intervals per-mapping, instead of running all sync operations on every cron run. This feature idea will allow administrators to tweak their synchronizations according to business needs, without the need to implement extensive hook-based logic.

A new plugin system for mapping fields. There has been a mapping UI overhaul. Salesforce Mapping Fields now enjoy their own plugin system, allowing for maximum extensibility. For example, "Record Type" is now its own mapping field plugin type, rather than receiving special treatment in the push and pull systems.