Midwest Drupal Camp (MidCamp) 2020, on March 18-21, will be the seventh-annual Chicago-area event that brings together designers, developers, users, and evaluators of the open source Drupal content management software. Attendees come for four days of presentations, professional training, contribution sprints, and socials while brushing shoulders with Drupal service providers, hosting vendors, and other members of the broader web development community.Early-bird Deal!
For 2020, tables will be exclusive to Core sponsors, and the early-bird rate will be $2500, increasing to $3000 on June 1, 2019. Core sponsors will have the option to add on $1000 for "naming rights" to any component of camp they choose—a party, Training Day, Contribution Day, snacks, coffee, or something else.
If you'd like to lock in your table now, send us an email to firstname.lastname@example.org and we'll get an invoice out to you ASAP.
On behalf of the Drupal Association, we’re excited to welcome you to Seattle, DrupalCon, and the Washington State Convention Center. Your week will be packed with opportunities to learn, network, collaborate, and most importantly, have fun... Drupal style!
At this point in the history of the open web, privacy is arguably the key issue in software development. As a range of scandals arising from the misuse of data bring pressure on governments and civil society to take action, it is important for software projects - including Drupal - to take proactive steps to value, resource, and support privacy work.
To date, the Drupal project has largely been reliant on the community to take the lead on privacy work. Development initiatives on privacy issues have mostly centred around contributed modules to implement privacy standards required by the EU’s GDPR privacy legislation.
The status of Drupal’s work on privacy was discussed at great length at Drupal Europe last year with members of the WordPress and Joomla communities, as well as a variety of community members in Drupal who are continuing to focus on privacy beyond GDPR.
As a result, we created the Cross-CMS privacy group, where participants from a number of open source CMSes learn from each other and work to bring our respective software ecosystems towards a common open standards and principles.
For DrupalCon Seattle we would like to present a core privacy initiative that will bring together some of the existing work in contrib as well as the efforts of the others in the cross-CMS group.Cross-CMS Privacy Group
We have representatives from the communities of Drupal, Joomla, WordPress and Umbraco meeting regularly on Wednesdays at 2-3pm UTC. It’s only been a few months, but we feel that we’ve achieved quite a bit. We’ve managed to stick to our weekly meetings and found that everyone involved has a passion for privacy generally, not just compliance with a specific set of laws.
We’ve found that although our software and community ecosystems are different, we’ve had to encounter the same set of problems - we’ve just handled things in differing ways. Different CMS’ have focused on different areas, which gives us much to learn from each other. For example, WordPress has done a great deal of work on privacy policies, whilst Joomla has fantastic export and import tools for site admins to manage, Umbraco has put a lot of effort into a Consent API, data export and handling of sensitive data fields.
We have already achieved a number of deliverables since beginning:
We’ve been working towards a common understanding of how software projects should define privacy that has been influenced by GDPR but aims to go further than mere compliance here: https://github.com/webdevlaw/open-source-privacy-standards (Special thanks to Heather from the WordPress team)
We’ve created a repository for posting minutes, and been producing them weekly here (Special thanks to the Joomla! Team especially Luca and Achilleas): https://github.com/joomla/cross-cms-compliance
We’ve created a structure for auditing software extensions that could be used by a Drupal privacy team to audit common modules here : https://github.com/joomla/cross-cms-compliance/blob/master/audit-your-software-extension.md
We have begun discussing unified standards for file formats for data portability exports and imports, so that users could, in theory, move their data between sites regardless of CMS
We’ve created some internal documents comparing the features of our CMSes with the aim to produce a common blueprint for how software best handles user data and privacy tools. We’ve been compiling some legal examples of times when fines have happened and are working together towards a common goal.
Through our conversations we have become convinced that privacy is no longer just a legal requirement but one of ethical importance. We know that giving users the ability to control their own data, and having means to control their consent, isn’t just about avoiding the proverbial fine. As developers behind some of the largest CMSes in the world, we know that we cannot force website administrators to respect their users’ privacy, but we can at least make it so easy for them to do so that they will need a good reason to not enable these tools.
CMSes can often be the first point of processing an individual’s information. A recent discussion raised by Alan Mac Kenna from the Umbraco CMS community within the group centred on the need to be able to demonstrate accountability for processing not only based on consent, but for other ‘lawful bases’ also, enabling our platforms to become a key source of truth for realising accountability under data protection regulations.
However, putting aside the ethical imperative for privacy tools, there are a number of new legal privacy initiatives currently being worked on (which as of this writing include CCPA, the ePrivacy Regulation revamp, and the growing shape of the eventual US Federal privacy law). Therefore, especially for large organisations and enterprise, core functionality in databases and CMSes will likely be an incentive for future projects and funding.
We feel that the Cross-CMS group will assist their projects to value, resource, and support both the ethical reasons for caring about privacy as well as the business incentives for avoiding legal issues. The more we follow consistent design patterns, open standards, and proactive approaches to legislation, the more all of our clients, users and customers will be protected. Whilst other CMSes will never dictate what Drupal needs to do, we can always benefit from mutual learning and understanding.
We hope that as this initiative grows, we will be able to work in cooperation with regulatory bodies themselves to add further authority to the technical approaches we will take in our software.Drupal Privacy Initiative Goals
We have a number of potential goals for a Drupal privacy initiative:
- We want to have a clear roadmap of what features need to be in the Core of Drupal, so that other modules can extend that functionality, and what features can remain officially supported in Drupal.
- An example is the tools for data erasure and “Right to be forgotten” could be an extension of the existing options given when a site admin cancels a user;
- Whereas tools to make it easier to import user data from other CMSes could exist in contrib but using a data structure that the majority of major CMSes are using.
- We want to define what we currently believe are the essential features required to improve a website’s handling of user data and privacy, including:
- Functionality for logging consent or other legal basis for processing;
- Functionality for handling the exporting and erasure of user data, taking into account that Drupal stores a lot of data in custom fields or other modules.
- A privacy team-supported checklist, existing in contrib, to assist organisations in compliance and privacy issues outside of pure tech/code issues.
- A privacy team which, like the security team, vets submitted modules to see how well they respect privacy requirements, as the WordPress Privacy team does. This could instead be more similar to how the accessibility team operates.
- Potentially other features such as something like the legal module in core which would allow modules to submit wording for privacy policies, such as what cookies they used and how they handle user data.
- Build upon the work Brainsum (Peter) and FreelyGive (Jamie or yautja_cetanu) have done on the GDPR module on drupal.org to bring the essential functionality into core where appropriate.
- We want to create documentation within drupal.org to assist developers, site builders and site administrators alike in understanding the privacy issues which impact Drupal, including understanding what other software does.
We hope to follow this blog post up with some detailed presentations on the state of privacy tools in other CMSs with screenshots and a more detailed plan.
Currently the representatives of Drupal in the Cross-CMS Privacy Group are from two companies which worked on the /project/gdpr module and another individual who has worked on various encryption modules. We hope to open this up at Drupalcon Seattle.
Chris Teitzel is representing the initiative at Drupalcon Seattle. Many of the members of the working group are in Europe and while not in physical attendance, have pledged to make themselves available remotely for any discussions that are required and are willing to help in any way.
Chris hopes to bring together enough people to support this so an official initiative can be created.
In the long term we hope to secure funding for the group to cover travel and accommodation expenses for periodic in-person meetups and other directly relevant activities, such as conferences and workshops. We may also seek funding support for our time and labour contributing to opensource privacy, which is already a considerable commitment. We naturally must be careful to consider the values and ethics of any potential sponsors, particularly those which may have a mixed track record on privacy.Image: Tags: Blog category:
Mike and Matt talk to a conglomerate of Lullabots about their DrupalCon sessions on Thursday, April 11th.
Content management systems like Drupal provide dynamic layout building tools. This article details the challenges associated with trying to deliver the most appropriately sized image in these dynamic layouts.
Stop me if you’ve heard this one before.
You’re working on a big, time-sensitive update to a page. Maybe it’s a landing page, or a home page. Whatever it is, stakeholders are involved, and Big Names are giving input. You’ve got 15 versions of this in draft. Your workflows are performing perfectly and launch is ten days away.
Then, disaster strikes.
DrupalCon2019 is heading to Seattle this year and there’s no shortage of exciting sessions and great networking events on this year’s schedule. We can’t wait to hear from some of the experts out in the Drupalverse next week, and we wanted to share with you a few of the sessions we’re most excited about.Adam is looking forward to:
Government Summit on Monday, April 8th
“I’m looking forward to hearing what other digital offices are doing to improve constituents’ interactions with government so that we can bring some of their insights to the work our agencies are doing. I’m also excited to present on some of the civic tech projects we have been doing at MassGovDigital so that we can get feedback and new ideas from our peers.”Bryan is looking forward to:
Time: Wednesday, April 10th from 1:45 pm to 2:15 pm
Room: 6B | Level 6
“We’re using Gatsby and React today on to power Search.mass.gov and the state’s budget website, and Drupal for Mass.gov. Can’t wait to learn about Decoupled Drupal with Gatsby. I wonder if this could be the right recipe to help us make the leap!”
Time: Wednesday, April 10th from 2:30 pm to 3:00 pm
Room: 612 | Level 6
“Making data available in machine-readable formats via web services is critical to open data and to publish-once / single-source-of-truth editorial workflows. I’m grateful to Wim Leers and Mateu Aguilo Bosch for their important thought leadership and contributions in this space, and eager to learn how Mass.gov can best maximize our use of JSON API moving forward.”I (Julia) am looking forward to:
Time: Wednesday, April 10th from 1:00 pm to 1:30 pm
Room: 607 | Level 6
“I am really interested in learning from Teach for America on how they implemented personalization and integrated across applications to bring applicants a consistent look, feel, and experience when applying for a Teach for America position. We have created Mayflower, Massachusetts government’s design system, and we want to learn what a single sign-on for different government services might look like and how we might use personalization to improve the experience constituents have when interacting with Massachusetts government digitally. ”
Time: Wednesday, April 10th from 4:00 pm to 4:30 pm
Room: 612 | Level 6
“I’m hoping to hear if Chris Strahl has any ‘best-practices’ and ways for project managers to leverage the unique multi-skill abilities that Devsigners and unicorns possess while continuing to encourage a balanced workload for their team. This balancing act could lead towards better development and design products for Massachusetts constituents and I’d love to make that happen with his advice!”Melissa is looking forward to:
Time: Wednesday, April 10th from 1:45 pm to 2:15 pm
Room: 602–604 | Level 6
“Rob Bayliss and Kelly Albrecht will use a survey they released as well as some other important approaches to elaborate on why DevOps is so crucial to technological strategy. I took the survey back in November of 2018, and I want to see what those results from the survey. This presentation will help me identify if any changes should be made in our process to better serve constituents from these results.”
Time: Thursday, April 11th from 2:30 pm to 3:00 pm
Room: 608 | Level 6
“In this session Shweta Sharma will speak to what visual testings tools are currently out there and a comparison of the tools. I am excited to gain more insight into the automated visual testing in faster and quicker releases so we can identify any gotchas and improve our releases for Mass.gov users.
- “How to write for your users (developing: content strategy, information architecture)” — Adam Cogbill @ Government Summit on Monday, April 8th at 1:00 pm
- “The journey users go on when they navigate your content (usability)” — Julia Gutierrez @ Government Summit on Monday, April 8th at 1:45 pm
- “Mass.gov: A Guide to Data-Informed Content Optimization.” — Julia Gutierrez and Mediacurrent on Thursday, April 11th at 11:30 am in Room 611
- “Inside Drush 9” — Moshe Weitzman and Greg Anderson, an Open Source Contributions Engineer at Pantheon, on Thursday, April 11th at 1:45 pm Room 6C
We hope to see old friends and make new ones at DrupalCon2019, so be sure to say hi to Bryan, Adam, Melissa, Lisa, Moshe, or me when you see us. We will be at booth 321 (across from the VIP lounge) on Thursday giving interviews and chatting about technology in Massachusetts, we hope you’ll stop by!
With all the excitement about decoupled Drupal over the past several years, I wanted to take a moment to articulate a few specific factors that make headless a good approach for a project – as well as a few that don’t. Quick disclaimer: this is definitely an oversimplification of an otherwise complex subject, and is based entirely on our experience here at Aten. Others will draw different conclusions, and that’s great. In fact, the diversity of perspectives and conclusions about use cases for headless underscores just how incredibly flexible Drupal is. So here’s our take.First, What is Decoupled?
I’ll keep this real short: decoupled (or headless) Drupal basically means using Drupal for backend content management, and using a separate framework (Angular, React, etc.) for delivering the front-end experience. It completely decouples content presentation (the head) from content management (the body), thus “headless”. There are tons of resources about this already, and I couldn’t come close to covering it as well as others already have. See Related Reading at the end of this post for more info.Decoupled and Progressively Decoupled
For the purpose of this post, Decoupled Drupal means any Drupal backend that uses a separate technology stack for the front-end. Again, there’s lots of great material on the difference between “decoupled” and “progressively decoupled”. In this post, just pretend they mean the same thing. You can definitely build a decoupled app on top of your traditional Drupal stack, and there are often good reasons to do exactly that.Why Decoupled?
Decoupled Drupal provides massive flexibility for designing and developing websites, web apps, native apps and other digital products. With the decoupled approach, designers and front-end developers can conspire to build whatever experience they wish, virtually without limitation. It’s great for progressive web apps, where animations, screen transitions and interactivity are particularly important. Decoupled is all but necessary for native apps, where content is typically managed on a centralized server and published via an API to instances of the app running on people’s devices. In recent years, Decoupled Drupal has gained popularity even for more “traditional” websites, again primarily because of the flexibility it provides.Pros and Cons
I’m not going to list pros and cons per se. Other articles do that. I’m more interested in looking at the specific reasons we’ve chosen to leverage a decoupled approach for some projects, and the reasons we’ve chosen not to for others. I’m going to share our perspective about when to go decoupled, and when not to go decoupled.When to Decouple
Here are a few key questions we typically ask when evaluating a project as a fit for Decoupled Drupal:
- Do you have separate backend and front-end development resources? Because decoupled means building a completely separate backend (Drupal) from front-end (Angular, React, etc.), you will need a team capable of building and maintaining both. Whether it’s in-house, freelance or agency support, Decoupled Drupal usually requires two different development teams collaborating together to be successful. Organizations with both front-end devs and backend devs typically check “yes” on this one. Organizations with a few generalist developers, site builders or web admin folks should pause and think seriously about whether or not they have the right people in place to support a decoupled project.
- Are you building a native app and want to use Drupal to manage your content, data, users, etc.? If yes, we’re almost certainly talking decoupled. See “Why Decoupled?” above.
- Do you envision publishing content or data across multiple products or platforms? Example: we recently built an education product that serves both teachers and their early childhood students. We needed a classroom management app for the former, and an “activity explorer” with links to interactive games for the latter. Multiple products pulling from a single backend is often a good fit for decoupled.
- Is interactivity itself a primary concern? There are plenty of cases where the traditional web experience – click a link, load a new page – just doesn’t do justice. Interactive data visualizations and maps are great examples. If your digital project requires app-like interaction with transitions, animations, and complex user flows, you will likely benefit from an expressive front-end framework like Ember or Angular. In those cases, decoupled is often a great fit.
- Does working around Drupal’s rich feature set and interface create more work in the long run? Drupal ships with a ton of built-in features for managing and viewing content: node edit screens, tabs, subtabs, node view pages, admin screens, and on and on. Sometimes you just don’t need all of that. For some applications, working around Drupal’s default screens is more work than building something custom. In some cases, you may want to take advantage of Drupal’s flexible content model to store content, but need a completely different interface for adding and managing that content. Consider evites as a hypothetical example. The underlying content structure could map nicely to nodes or custom entities in Drupal. The process for creating an invitation, customizing it, adding recipients, previewing and sending, however, is something else altogether. Decoupled Drupal would allow you to build a front-end experience (customizing your invitation) exactly as you need it, while storing the actual content (the invite) and handling business logic (saving, sending, etc.) in Drupal.
- Do you want the hottest technology? Sometimes it’s important to be at the cutting edge. We respect that 100%. Decoupled Drupal provides incredible flexibility and empowers teams to build rich, beautiful experiences with very few limitations. Further, it allows (virtually requires) your teams – both front-end and backend – to work with the very latest development tools and frameworks.
Conversely, here are a few key questions we ask that might rule out Decoupled Drupal for a project:
- First, take another look at the list above. If you answered “no” to all of them, Decoupled Drupal might not be a great fit for your project. Still not sure? Great, carry on...
- Are you hoping to “turn on” features in Drupal and use them more-or-less as-is? One of the major draws for Drupal is the massive ecosystem of free modules available from the open source community. Need Disqus comments on your blog? Simply install the Disqus Drupal module and turn it on. How about a Google Map on your contact page? Check out the Simple Google Maps module. Want to make a slideshow from a list of images? No problem: there are modules for that, too. With Decoupled Drupal, the ability to simply “turn-on” front-end functionality goes away, since Drupal is no longer directly managing your website front-end.
- Do your front-end requirements match Drupal’s front-end capabilities out-of-the-box? We work with a number of research and publishing organizations whose design goals closely align with Drupal’s capabilities. I’m hard pressed to recommend a decoupled approach in those cases, absent some other strong driver (see above).
Jacob Rockowitz: Learn about leveraging Webforms and more at the DrupalCon Seattle Healthcare Summit (#DrupalHealth)
Webforms for Healthcare
I am looking forward to talking about my experiences in implementing webforms for healthcare.
This presentation will be my first time discussing the Memorial Sloan-Kettering Cancer Center's (MSKCC) implementation of the Webform module. I am even going to show the MSKCC project, which inspired me to build the Webform module for Drupal 8. This presentation will approach the topic of "Webforms for Healthcare" from two different angles.
The three big digital concerns for healthcare
First, we are going to explore Webform features and add-ons to address core digital concerns, accessibility, privacy, and security. Accessibility and privacy are important topics that are going to be discussed throughout the Healthcare summit.
The three primary audiences for healthcare
Second, we are going to explore how to leverage Webforms to address healthcare's three primary audiences for Clinical Care, Research, and Education. Each one of the audiences has a different use case and requirements. After twenty years of working in the healthcare industry, I also know that doctors need to be included in all aspects of healthcare.
Join us at the Drupal Healthcare Summit
Join us at the Drupal Healthcare Summit on Tuesday, April 9th. Throughout the day we are going to talk about patient experiences, education, privacy, inclusion, accessibility, and more…
If you can't join us at the Drupal Healthcare Summit, you can watch my pre-recorded practice presentation below…Read More
Views added to Drupal core is one of the most frequently mentioned Drupal 8 benefits. Drupal Views gives us a UI for creating data collections based on any desired criteria. One of the ways to fine-tune the results is to use Drupal Views filters. A level higher from regular filters stand contextual filters that accept dynamic values. This helps us create flexible and interesting solutions. Let’s review Drupal 8 Views contextual filters in more detail.
Due to the constantly evolving nature of the digital, outsourcing has become a very viable solution for managing projects. But, naturally, outsourcing work to remote partners brings about its own unique challenges. In this post, we'll take a look at some of the biggest challenges of remote staffing and the ways to tackle them.READ MORE
Gutenberg is the new editor for WordPress 5.0. It’s a new style of editor/page builder. Instead of writing text in a single text area, you build a page using blocks. A block could be something simple such as a paragraph or an image. Or more complex blocks like a “Media & Text” or adding in columns.
In this tutorial, you’ll learn to install and configure the Gutenberg module, and you’ll learn how to use it on the Page content type.
If you’re keen to have a play with the editor without configuring a Drupal site go to https://drupalgutenberg.org/demo.
The Drupal community has been abuzz for the past two years with talk of "Becoming Headless" or "Decoupling All The Things." The trend raises reasonable questions from end users who feel this means Drupal is moving into a space that no longer represents them. We hear similar concerns from Drupal Commerce users when we talk about delivering headless commerce. However, we don't believe anyone should be worried that improving support for Drupal as a REST API server will detract from efforts to improve its utility as a traditional CMS.
When you remove the default presentation layer from a system, you are bound to find interesting problems. How much logic is embedded in a Drupal field formatter or field widget? What happens when those are not used to render or manipulate an entity’s values? As a quick example, work in the API-First Initiative related to taxonomy terms turned up a validation bug where code restricting parent terms to the same vocabulary only executed in the context of the default entity form. Fixing that bug to prevent invalid relationships via API updates contributed to improving Drupal core overall even though the issue wasn't affecting traditional Drupal usage.
Consider a couple examples of our work toward a fully headless Drupal Commerce improving the modules more generally:Cart should grant "view" access to orders available from a user's cart session
While working on the Cart API module to find ways to use JSON:API, I realized we were missing some entity access control for carts to allow anonymous users to view their orders tracked in their session. With query-level entity access landing in Entity API, fetching orders over JSON:API or GraphQL automatically restricted the returned orders to carts belonging to authenticated users. We realized we needed to update Commerce Cart to support this use case for traditional and headless use cases.Provide a constraint on the Coupons field to verify referenced coupons are available
I set a goal earlier this year to support coupon redemption through our Cart API. I ran into a problem early on while evaluating our code to remember where / how we validate coupons. I knew the code existed and expected it'd be pretty simple to reuse. Unfortunately, it turned out we only put validation logic in the default coupon checkout pane code, meaning a coupon redemption endpoint in the Cart API would have to reproduce the code to support client-side coupon validation. That sort of duplication is bound to lead to bugs or out of sync logic.
What was the solution? Add a validation constraint to our coupon reference field on orders. This constraint contains the code that validates a coupon for an order and ensures its related promotion applies. RESTful Web Services module and JSON:API automatically run validation against entities when they're modified, triggering this check and allowing invalid coupons to be detected right away. This in turn let us simplify our coupon redemption form as well. The final patch is still in progress, but once landed, it will make it easier for any Drupal Commerce site, headless or not, to add their own customizations on top of the default coupon redemption form or write their own.What’s next for 2019?
We've been pretty busy preparing Centarro Toolbox for release at DrupalCon Seattle, so first I expect I'll take a deep breath and celebrate the Drupal 8.7 release. We're planning now how to ensure Drupal Commerce users can harness the power of Layout Builder and Media, and we'll be integrating them into our Belgrade based demo.
Second, we'll continue to improve the developer experience with Drupal Commerce over the various API based modules. Headless Drupal Commerce is already working in the wild. The team behind Spark POS uses JSON:API and Drupal Commerce to handle ZKungFu’s billion dollar business. 1xINTERNET has been pushing React based front-ends for a while and will even be presenting their work at DrupalCon. As project maintainers, we want to empower teams to build similar applications and move our support from product catalog navigation and shopping cart manipulation through to checkout completion and order management.
Electric Citizen is heading to DrupalCon Seattle next week! We're pleased to sponsor again this year, and send several members of the team to represent.
Look for us in the exhibit hall in booth #209, where we'll be sharing some cool EC swag, and looking to make new friends and connections in the Drupal community. This year we'll have some awesome knit hats, handmade in Minnesota, as well as some other goodies.
Keep an eye out for Citizen Dan, Citizen Tim, Citizen Aundrea (DrupalCon newbie!) and Citizen Adam, as we make our way through another DrupalCon.
Axelerant is going to DrupalCon Seattle. Between the 8-12th of April, the Drupal community will get together in Seattle for a slightly different DrupalCon experience, this time with a new focus on content-rich opportunities, bringing in diverse speakers, and greater exchange of information.
OPTASY: Drupal Multisite Setup: Are There (Still) Any Valid Reasons to Use It? Should It Get Removed in Drupal 9.x?
Why would you still want to opt for a Drupal multisite setup? What strong reasons are there for using this Drupal 8 feature?
I mean when there are so many other tempting options, as well:
- you could use Git, for instance, and still have full control of all your different websites, via a single codebase
- you could go with a Composer workflow for managing your different websites
One one hand, everyone's talking about the savings you'd make — of both time and money — for keeping your “cluster” of websites properly updated. And yet, this convenience comes bundled with certain security risks that are far from negligible.
Just think single point of failure...