Feb 25 2020
Feb 25

Table of Contents

Defining decoupled Drupal
--The pros and cons remain largely unchanged
--A competitive advantage for commercial Drupal
Aside: Our stories in decoupled Drupal
GraphQL as a game-changer
--GraphQL queries at scale
--What about JSON:API vs. GraphQL?
--GraphQL v4 and custom schemas
Conclusion

Over the last five years, decoupled Drupal has grown from a fringe topic among front-end enthusiasts in the Drupal community to something of a phenomenon when it comes to coverage in blog posts, tutorials, conference sessions, and marketing collateral. There is now even a well-received book by this author and a yearly conference dedicated to the topic. For many Drupal developers working today, not a day goes by without some mention of decoupled architectures that pair Drupal with other technologies. While Drupal’s robust capabilities for integration are nothing new, there have been comparatively few retrospectives on how far we’ve come on the decoupled Drupal journey.

Recently, your correspondent (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) sat down for a no-holds-barred discussion about decoupled Drupal on Tag1 Team Talks with three other early insiders in the decoupled Drupal mindspace: Sebastian Siemssen (Senior Architect and Lead React Developer at Tag1 and maintainer of the GraphQL module), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), and Michael Meyers (Managing Director at Tag1).

During the conversation, we spoke about the unexpected ways in which decoupled Drupal has evolved and where it could go in the near and far future. In this two-part blog series, we look back and peer forward into decoupled Drupal’s trailblazing and disruptive trajectory in the Drupal ecosystem, starting with Sebastian, who created Drupal’s GraphQL implementation, and Michael, who has witnessed firsthand the paradigm shift in Drupal’s business landscape thanks to the benefits decoupled Drupal confers.

Defining decoupled Drupal

As it turns out, defining decoupled Drupal can be tricky, given the diverse range of architectural approaches available (though these are covered comprehensively in Preston’s book). In its simplest form, decoupled Drupal is an idea centered around the notion of employing Drupal as a provider of data for consumption in other applications. In short, the “decoupling” of Drupal occurs when developers opt to utilize Drupal data by issuing requests to APIs that emit JSON (or XML) rather than through Drupal’s native presentation layer.

As Fabian notes in the webinar, there are multiple “flavors” of decoupled Drupal that have emerged. Fully decoupled Drupal implementations aim to replace the entire presentation layer of Drupal with a distinct application. Progressively decoupled Drupal, an idea first promulgated by Drupal project lead Dries Buytaert in a 2015 blog post, recommends leveraging API calls to provide for components in the existing Drupal front end rather than an entirely separate presentation layer.

The pros and cons remain largely unchanged

Decoupled Drupal presents both advantages and disadvantages that are worth considering for any implementation, and these are also covered in Decoupled Drupal in Practice. Fully decoupled Drupal, for instance, means jettisoning a great deal of what makes Drupal such an effective web framework by limiting its feature set substantially to solely the APIs for retrieving data and an administrative interface for content management.

Though decoupling Drupal inevitably means losing certain functionality, such as contextual links, in-place editing, and layout management, it does confer the opportunity to create something entirely custom atop the data model that Drupal provides, as Sebastian states in our Tag1 Team Talks episode. Nonetheless, while decoupled Drupal does introduce unprecedented flexibility, it also goes beyond a simple separation of the presentation layer from the data layer by rendering Drupal more replaceable. The notion of replaceability does belie an undercurrent of anxiety surrounding decoupled Drupal, and it presents risks for Drupal’s position in the CMS market.

A competitive advantage for commercial Drupal

Nonetheless, from the commercial standpoint and the customer perspective, there is no question that decoupled Drupal is a boon for ambitious digital experiences. For instance, during our conversation, Michael argues that decoupled Drupal actually represents a competitive advantage for Drupal in the commercial space rather than an erosion of its value. The narrative of integration in which Drupal has always trafficked has long been influential in swaying skeptical stakeholders. In short, in this view, Drupal’s core REST API, JSON:API, and GraphQL only strengthen this flexibility to integrate.

As a matter of fact, Tag1 Consulting’s yearslong work with Symantec supports this notion. Together with Tag1, Symantec embarked on a migration from version to version of Drupal in a nontraditional way that was only made possible thanks to decoupled Drupal technologies. By providing multiple front ends across Drupal versions, Symantec and Tag1 succeeded in both accelerating and effectively managing the migration to Drupal 8. Michael notes that from a client standpoint at Tag1, decoupled Drupal has been a valuable and sought-after asset; if anything, it has only increased evaluators’ interest in the platform.

Aside: Our stories in decoupled Drupal

Sebastian, Fabian, and I also reminisced about our respective stories in the decoupled Drupal landscape and how it has impacted the trajectory of our work even today. Arguably among the first in the Drupal community to leverage a decoupled architecture, Fabian admits building a decoupled site that consumed unstyled HTML snippets as far back as 2009, with other data coming from multiple sources. We can certainly forgive the fact that he opted to use Flash for much of the front end in that build.

Early in 2015, Sebastian found that the release of GraphQL by Facebook as a new specification made everything “click” for him as one of the crucial gaps in Drupal’s APIs. That same year, Sebastian began working on GraphQL for PHP, basing much of his ideas on the just recently open-sourced GraphQL JavaScript library. Thanks to Sebastian’s tireless work, the GraphQL module for Drupal first appeared as a codebase on Drupal.org in March 2015 and has since skyrocketed in interest and popularity.

My own journey is much less glamorous, as I assisted Drupal project lead Dries Buytaert with his initial thought leadership on the subject of decoupled Drupal back in 2015. At the time there was considerable hand-wringing about what disruptive advances in the front-end development world could mean for Drupal. Over the course of time, my perspectives have evolved considerably as well, and I believe there are many excellent use cases for monolithic implementations, something I stress in my book about decoupled Drupal. Today, I help run the biggest and oldest conference on decoupled and headless CMS architectures, Decoupled Days, which is now entering its fourth year.

GraphQL as a game-changer

One of the key questions for decoupled Drupal practitioners has been how to leverage the best that Drupal has to offer while also accessing some of the best ideas emerging from the API and front-end development spaces. For instance, among Drupal’s most notable selling points is the fact that not only does Drupal benefit from an excellent administrative interface; it also offers a robust customizable data model that can be crafted and fine-tuned. Entity API and Field API, for instance, have long been some of the most vaunted components of the back-end Drupal developer experience.

Tag1 recently found this with a project that employs Laravel, a more lightweight PHP framework for websites that is far less opinionated than Drupal. Light layers of entities and fields were required for the Laravel project, and Fabian remarks in our recent webinar that these are particularly straightforward to implement and validate in Drupal. GraphQL adds another fascinating dimension to this by allowing Drupal to handle the heavy lifting of important features like field validation while permitting client-tailored queries.

GraphQL queries at scale

Sebastian describes GraphQL as a reversal of the traditional relationship between the server and client. Rather than the client being forced to adhere to what the server provides, the server declares the data possibilities that it is capable of fulfilling, and based on these catalogued possibilities, the client defines exactly what it needs on a per-request basis. The client sends the query to the server in a particular format, which Sebastian characterizes as much like the “JSON you want returned from the API but only the keys.” Thereafter, the GraphQL API inserts the values and returns a response with precisely the same shape.

This brings us to one of the most fascinating aspects of GraphQL within the Drupal CMS, which often utilizes deeply nested relational data structures that are uniquely well-suited for modeling into a graph — which is the very core of what GraphQL does. One of the best aspects of GraphQL, moreover, is its capabilities for schema and query validation, with which we can prevent distributed denial-of-service (DDoS) attacks that attempt to overload queries with many nested layers by checking and analyzing the complexity of queries ahead of time, a task that is much easier thanks to the predictability of GraphQL schemas.

What about JSON:API vs. GraphQL?

While the story of GraphQL has been long-running in the Drupal ecosystem, it’s important to note the other big player in Drupal’s web services: JSON: API, which was just this year introduced into Drupal core. One of the biggest reasons why JSON:API has gained prominence is its relative stability and its high amount of documentation. Sebastian argues that React developers coming from their ecosystem are more likely to be familiar with GraphQL already, which also helps elevate its status within the decoupled Drupal ecosystem.

GraphQL v4 and custom schemas

One of the most anticipated releases of the GraphQL module is GraphQL v4 for Drupal, which means several significant changes for the ever-evolving GraphQL module. In the latest version of the GraphQL module, the GraphQL schema is fully in the control of Drupal developers, which is a substantial change from previous releases. After all, one of the best selling points for using GraphQL in the first place is schema customizability.

According to Sebastian, this means that you can decouple Drupal on the API access and contract level rather than foisting the data model and data internals of Drupal on the resulting GraphQL API, which may cause confusion among developers of consumer applications like React implementations.

Conclusion

Perhaps the most intriguing development in the long-running saga of decoupled Drupal is the diversification and proliferation of a wide range of approaches, like GraphQL, that improve the developer experience in Drupal significantly. Besides its obvious benefits of greater flexibility on the side of developers, moreover, Drupal users and agency customers are also discovering the advantages of decoupled Drupal for a variety of use cases.

As we recently discussed during our conversation, a mix of both nostalgia and forward thinking, decoupled Drupal is here to stay. Whereas in years past this statement may have caused considerable anxiety in the Drupal community, today it is emblematic of the ongoing explosion of options and capabilities that decoupled Drupal engenders for Drupal developers. But in the second installment in this two-part series, Fabian, Sebastian, and I discuss some of the anxieties and worries we share about decoupled Drupal, before attempting to predict what could come next for this fast-evolving paradigm.

Special thanks to Fabian Franz, Michael Meyers, and Sebastian Siemssen for their feedback during the writing process.

Photo by Jesse Bowser on Unsplash

Feb 25 2020
Feb 25

DrupalCon always puts on an excellent program, including over 200 sessions by experienced professionals from all over the world. We're excited to announce that we'll be giving two of them this year!

JavaScript is Coming to Eat You

After presenting at numerous conferences nationwide, Citizen Tim is returning home to give his extremely well-received talk about JavaScript frameworks, and the future of content management systems. 

Battle for Online Privacy

This one is mine (aka Citizen Dan). Online privacy is a big concern for everyone, or at least it should be– as private citizens using today's technology, and as responsible professionals building the web. Some people claim privacy is already dead! I will be highlighting what's at stake, how new laws may affect your websites, and best practices we can all start following today. 

Feb 25 2020
Feb 25

We use the word integration a lot when we’re talking about building large-scale digital platforms. The tools we build don’t stand in isolation: they’re usually the key part of an entire technology stack that has to work together to create a seamless user experience. When we talk about “integrating” with other services, usually we’re talking about moving information between the digital platform we’re building and other services that perform discrete tasks.

Platforms are not encapsulated monoliths. For just about any feature you could imagine for a platform, there may be a third-party service out there that specializes in doing it and you can optimize (for cost, output, functionality, ease of use, or many other reasons) by choosing to strategically integrate with those services. When we architect platforms (both big and small), we’re usually balancing constraints around existing vendors/service providers, existing data sets, and finding cost and functionality optimizations. It can be a difficult balancing act!

Some examples of integrations include:

  • On a healthcare website, clicking the “Make an Appointment” button might take you to a third-party booking service.
  • On a higher-education website, you might be able to view your current class schedule, which comes from a class management system.
  • On a magazine site, you might not even know that you’re able to read the full article without a paywall because the university network you’re browsing from integrates with the publisher’s site to give you full access.
  • On a government website, you might be able to see the wait time for your local Department or Registry of Motor Vehicles.

In short: an integration is a connection that allows us to either put or retrieve information from third-party data sources.

What Drives Complexity in Integrations

The main factors that drive complexity in integrations:

  1. Is it a Read, Write, or Read/Write integration?
  2. What is the data transportation protocol?
  3. How well-structured is the data?
  4. How is the data being used?

Read, Write or Read/Write

When we talk about reading and writing, we’re typically talking about the platform (Drupal) acting on the third party service. In a Read-only integration, Drupal is pulling information from the third-party service and is either processing it or else just displaying it along with other information that Drupal is serving. In a Write-only integration, Drupal is sending information to a third-party service, but isn’t expecting processed data back (the services will often send status messages back to acknowledge getting the data, but that’s baked into the process and isn’t really a driving factor for complexity). The most complex type of integration is a Read/Write integration: where Drupal is both writing information to a third-party service and also getting information back from that third-party service for processing or display.

Access Control

It is impossible to separate the idea of accessing information from the question: is the data behind some type of access control? When you’re planning an integration, knowing what kind of access controls are in place will help you understand the complexity of the most basic mechanics of an integration. Is the data we’re reading publicly accessible? Or is it accessible because of a transitive property of the request? Or do we have to actively authenticate to read it? Write operations are almost always authenticated. Understanding how the systems will authenticate helps you to understand the complexity of the project.

Transportation Protocol

In thinking about the transportation protocol of the data, we expand this definition beyond the obvious HTTP, REST, and SOAP to include things like files that are FTP’ed to known locations and direct database access where writing our own queries against a data cache. The mechanics of fetching or putting data affect how difficult the task can be. Some methods (like REST) are much easier to use than others (like FTP’ing to a server that is only accessible from within a VPN that your script isn’t in).

REST and SOAP are both protocols (in the wider sense of the word) for transferring information between systems over HTTP. As such, they’re usually used in data systems that are meant to make information easy to transport. When they’re part of the information system, that usually implies that the data is going to be easier to access and parse because the information is really designed to be moved. (That certainly doesn’t mean it’s the only way, though!)

Sometimes, because you’re integrating with legacy systems or systems with particular security measures in place, you cannot directly poll the data source. In those cases, we often ask for data caches or data dumps to be made available. These can be structured files (like JSON or XML, which we’ll cover in the next section) that are either made available on the server of origin or are placed on our server by the server or origin. These files can then be read and parsed by the integrating script. Nothing is implied by this transportation method: the data behind it could be extremely well structured and easy to work with, or it could be a mess. Often, when we’re working with this modality, we ask questions like: “how will the file be generated?”, “can we modify the script that generates the file?”, and “how well structured is the data?”. Getting a good understanding of how the data is going to be generated can help you understand how well-designed the underlying system is and how robust it will be to work with.

Data Structure

When data folks use phrases like “data structure,” I think there’s a general assumption that everyone knows exactly what they mean. It is one of those terms that seems mystical until you get a clear definition, and then it seems really simple.

When we talk about the data structures in the context of integrations, we’re really talking about how well-organized and how small the “chunks” of data are. Basically: can you concisely name or describe any given piece of information? Let’s look at an example of a person’s profile page. This could be a faculty member or a doctor or a board member. It doesn’t matter. What we’re interested in finding out is this: when we ask a remote system to give us a profile, it is going to respond with something. Those responses might look like any of the following:

  • Composed (“pre-structured”) response:
    Name: Jane Doe, EdD.
    Display Name: Samantha Doe, EdD
    
  • Structured Response:
    First Name: Samantha
    Last Name: Doe
    Title: EdD.
    
  • Structured Response, with extra processing needed:
    First Name: Jane
    Last Name: Doe 
    Title: EdD. 
    Preferred Name: Samantha
    

All of these responses are valid and would (presumably) result in the same information being displayed to the end user but each one implies a different level of work (or processing) that we need to do on the backend. In this case: simpler isn’t always better!

If, for example, we’re integrating with this profile storage system (likely an HR system, or something like that) so we can create public profiles for people on a marketing site, we may not actually care what their legal first name for HR purposes is (trust me, I’m one of those folks who goes by my middle name—it’s a thing). Did you catch that in the third example above this person had a preferred name? If the expected result of this integration is a profile for “Samantha Doe, EdD.”, how do we get there with these various data structures? They could each require different levels of processing in order to ensure we’re getting the desired output of the correct record.

The more granularly the information is structured, the easier it is to process for the purpose of changing the information.

At the other end of the spectrum is data that will require no processing or modification in order to be used. This is also acceptable and generally low complexity. If the origin data system is going to do all of the processing for us and all we’re doing is displaying the information, then having data that is not highly granular or structured is great. An example of that might be an integration with a system like Twitter: all you’re doing is dropping in their pre-formatted information into a defined box on your page. You have very little control over what goes in there, though you may have control over how it looks. Even if you can’t change the underlying data model, you can still impact the user’s experience of that information.

The key here, for understanding the complexity of the integration, is that you want to be on one extreme or the other. Being in the middle (partially processed data that isn’t well-structured) really drives up effort and complexity and increases the likelihood of there being errors in the output.

Data Usage

One of the best early indicators of complexity is the answer to the question “how is the data being used?” Data that is consumed by or updated from multiple points on a site is generally going to have more complex workflows to account for than data that is used in only one place. This doesn’t necessarily mean that the data itself is more complex, only that the workflows around it might be.

Take, for example, a magazine site that requires a subscription in order to access content (i.e., a paywall). The user’s status as a subscriber or anonymous user might appear in several different places on the page: a “my account” link in the header, a hidden “subscribe now!” call to action, and the article itself actually being visible. Assuming that the user subscription status is held in an external system, you might now be faced with the architectural decisions: do we make multiple calls to the subscription database or do we cache the response? If the status changes, how do we invalidate that cache throughout the whole system? The complexity starts to grow.

Another factor in the data usage to consider is how close the stored data is to the final displayed data. We often refer to this as “data transformations.” Some types of data transformations are easy and while others push the bounds of machine learning.

If you had data in a remote system that was variable in length (say, items in a shopping cart), then understanding how that data is stored AND how that will be displayed is important. If the system that is providing the data is giving you JSON data, where each item in the cart is its own object, then you can do all kinds of transformations with the data. You can count the objects to get the number of items in the cart; you can display them on their own rows in a table on the frontend system; you can reorder them by a property on the object. But what if the remote system is providing you a comma-separated string? Then the display system will need to first transform that string into objects before you can do meaningful work with them. And chances are, the system will also expect a csv string back, so if someone adds or removes an item from their cart, you’ll need to transform those objects back to a string again.

All of this is rooted in a basic understanding: how will the data I’m integrating be used in my system?

Come back on Thursday for Part 2, where we’ll provide a framework to help you make sure you’re asking the right questions before embarking on a complex integration project. 

Complex Adaptive System by Richard Ricciardi licensed under CC BY-NC-ND 2.0.

Feb 25 2020
Feb 25

Having been working in software quality assurance for over 10 years, I have helped many organisations to set up internal QA teams and a vigorous QA process from scratch.  It’s both a rewarding and challenging task! 

As part of Microserve’s commitment to producing high-quality work for our clients, I joined the team in 2018, tasked with building a QA team and creating a suite of processes. One of our values as a business is ‘excellence as standard’. Prioritising quality in this way would ensure that we would provide our clients with the excellence we strive for. 

An arrow pointing down a road

Where to start?

For me, the starting point of anything is the hardest part. On joining Microserve, I decided the best approach would be to:

  1. Identify and log what is trying to be achieved
  2. List the steps needed to get there and then question, how do you know if you have achieved what you set out to do?

That may seem oversimplified, but that’s what QA is; understanding complex needs and translating it into something that can be broken down, understood and tested.

What is trying to be achieved?

So, first things first…..what do we want to achieve? 

For the Microserve QA team our overall goal is to “proactively and systematically test code changes and ensure bad code isn’t being delivered into the end product.”

What are the steps needed?

Once we had defined what the QA team were trying to achieve, we then began mapping out how we could provide the best support to our development team, and therefore the best product to our clients. 

I’m a great believer in iterative change - I have found from experience the best way is to take little steps to make big changes. It’s impossible to achieve everything all at once and it’s important to realise that sometimes things may not always go exactly as planned.

We started forming our processes by: 

  • Understanding the environments needed to provide a platform for the test phases to be executed on, so that code can be monitored and tested safely through the development cycle.
  • Decide on the test phases to be run against each environment and the scope for each.
  • Incorporate the test phases: Ensure the application lifecycle management tool has a workflow that incorporates the QA phases and activities.
  • Choose a Test Management tool where test cases and test phases can be managed and executions tracked.
  • Understand the team: Get to know everyone and understand their role, skills and how they work.
  • Get to know the software/product: How can you test something if you have no idea how it works?  Write regression test packs so that you have a log of how the system works and what it is meant to do.
  • Define a defect management process: that enables defects to be logged and tracked efficiently.

While this isn’t everything that needed to be done, this was a great place to start to get an understanding of how we can make better processes. 

A crowd of people gathering

Taking our team on the journey

As humans, we are programmed to fear change and it’s not always easy to get buy-in from everyone. One of the key aspects of setting up any new team is to take others along the journey with you and constantly provide updates as to why we are doing these things and how they can contribute and help. Here at Microserve, our team was really encouraging of these process improvements, and helped me to understand the whole landscape which helped to make our QA team a success.

The measure of success

We wanted to make sure that the process we were putting together was working. It was critical that: 

  • Defects were being discovered earlier in the process and not in the latter stages of the life cycle. This would save clients time, effort and money. 
  • Everyone understood the QA process and its value. Both internally and externally. 
  • The QA process was integrated into the development workflow and did not become a bottleneck or blocker. 
  • Clients have confidence in the product being delivered to them.

The work is never done

There is more to our QA team than just testing code. Our team is constantly assessing processes, tools and ensuring gaps are filled.  We pride ourselves in the fact that we are always looking at ways we can improve these vital areas of our client delivery service. 

Working in development is an ever-evolving and fast-paced environment, and there are always new ideas, techniques and tools available. It’s vital that we adapt and customise our offering and process to the different needs of clients, projects and deadlines. 

I am thrilled with the work the QA team have done over the past 18 months. The QA team and the process we have created ensures that we deliver high-quality work to our clients, and products that the whole team are proud of.

Feb 25 2020
Feb 25

As developers we often find ourselves working on projects where we have to implement certain features for which we are not provided with a design. Reasons for that can differ quite a lot, but most of the time the client does not have the resources to hire a designer to solve this predicament for us or the project is limited by a very tight deadline. 

Whatever the reason might be, in the end it’s up to us to find a solution which will be best suited for the project itself and of course for the end user who will be using the final product. 

In my opinion every developer, be it a front-end or even a back-end developer, should know the basic principles of good UI/UX design. By no means am I an expert on this subject but I would like to share with you the basic principles that I follow while working on projects which have little or no designs prepared for the developer.

Wireframe everything!

Yeah, you read it right - you should wireframe everything! For those who don’t know what wireframing is, it’s just a simple method of laying out the content and functionality of the feature you are working on, on a page which takes into account the end user’s needs and the user’s flow, how they interact with different elements and where they end up. This helps you out to plan ahead and reduce wasted time when marking up and styling your code. 

Keep your wireframes loose

The most important thing here is to plan and not to make it all pretty. The layout and the user flow come first before making things easy on the eyes! Make sure with the client or teammates who are working with you that your wireframes capture the essence of the feature you are developing. Once approved, you can take the additional time and make everything look nice and pretty. This can be an enormous timesaver. Plan ahead and lose less time with refactoring!

Wireframes can be simple sketches drawn in your notebook or different creations made in software like Photoshop, Adobe XD, Sketch and so on. I would recommend using Freehand by InVision, because you have the ability to collaborate, be it with your client or a teammate. If you have a graphic tablet, even better, you can just plug it in and you have the same result as sketching on a piece of paper.

Example of a mobile view wireframe made with Freehand by InVision

Composition

By composition I of course mean that you need to keep an eye on how you align your elements. 

A simple example of that could be that you have a title and a paragraph and each of them has a different alignment. Let’s say that the title is aligned to the left and the paragraph is centered. In this case the alignment is odd, the user could be confused and the content is harder to read. 

A simple example of a correct/wrong alignment

Size does matter

This is a common mistake that I see people make. You need to keep the size of buttons and other UI elements in consistent proportions on the whole page, whatever the case. Use contrast to make them distinguishable by the level of their importance. A button is still a button and you don’t have to scale them up in order to make them feel more important.

Example of using contrast instead of scale to demonstrate importance of UI elements

Spacing and typography 

Once upon a time we were using dividers in order to achieve a better division between different elements. But users tend to evolve and can distinguish between elements better than a few years back. So instead of using dividers I recommend the usage of whitespace, just space things a little more and the user will not miss them. 

As I mentioned before, the final design should be easy to read. Spacing of typography plays a major role in that. When dealing with Headings and a body text I usually tend to follow the ½ rule. It’s quite simple. You just take the height of the heading, divide it by two and use that value as the space between the bottom of the heading and the top of the body text. It looks clean and works for most use cases.

Example of good spacing

Outro

These were just a few simple examples of how to improve your designs, but you would be surprised how often I see these mistakes. There is much more that I didn’t mention. Color theory or Typography are both huge topics by themselves and I wanted to avoid writing a long blog post which would bore you to death.

I sincerely hope that these few tips will help you out in your daily development life, improve your current workflow and most importantly lead to less refactoring of your code which will in the long run save your and the clients time.

Feb 24 2020
Feb 24

I post updates on LinkedIn and to backers of the Drupal Recording Initiative, but I suppose blasting these via Planet Drupal is also a good idea. Well, at least until Drupal.tv adds that functionality (you can track that issue here).

Enjoy!

And if you find these session recordings valuable, please consider supporting my efforts. The US is fairly well covered...so now it is time to focus on the rest of the world.

Feb 24 2020
Feb 24

The Drupal Association is seeking partners to help us advance the next phase of the Automatic Updates initiative.

The first phase of this work was generously sponsored by the European Commission, and supported by other partners including: Acquia, Tag1Consulting, Mtech, and Pantheon.

In this first phase, we accomplished a great deal:

  • Display of security PSAs directly in Drupal's admin interface
  • Automated readiness checks, to ensure that a site is prepared for updates
  • Automatic updates for Drupal Core in both Drupal 7 and Drupal 8.

But while this work laid the foundation, a great deal of work yet remains. The next phase hopes to add support for:

  • Sites managed using Composer
  • Automatic updates with Contributed modules
  • A front-end controller providing support for easy roll-back

The Drupal Association needs partners in order to move this work forward. We're looking both for organizations who can provide financial support, and teams who have expert developers who can contribute to development.

If you are interested, you can find a detailed scope of the remaining work attached to this post.

Download the Request for Sponsors

Contact: [email protected] with questions.

Feb 24 2020
Feb 24

How do we encourage those capable of giving back to Drupal to start doing so and once they are contributing how do we encourage them to do more? Dries highlighted this conundrum during his keynote at DrupalCon Amsterdam 2019.

Promoting Makers

Whilst various mechanisms exist to recognise contributions in Drupal, if we are to cultivate and grow contribution culture we need to move beyond the current status quo. At DrupalCon the Contribution Recognition Committee was proposed and self nomination invited.

“The purpose of this committee is to recommend solutions for how we recognize contributions to the Drupal project made by both individual and organizational contributors, and to advise the Drupal Association on how to weight each type of contribution relative to the others.” Tim Lehnen, Chief Technology Officer Drupal Association.

What have we achieved so far?

For several months now, newly appointed committee members have been researching and discussing contribution culture within Drupal and open source. To ensure recommendations are truly representative of organisation and individual contributions we are keen to canvas opinions and perspectives from far and wide.

Share your opinions, ideas and perspectives

An online survey is available now for those using or contributing to Drupal so they can provide insights which will be considered in our recommendations as a committee. I encourage you to participate and help us to reach members of the Drupal community in your local area.

We especially encourage non-code contributors to respond, as these viewpoints have been historically under-represented.

Complete the survey today

Feb 24 2020
Feb 24
Debug Academy and DrupalCon logo overlooking Minneapolis Minnesota skyline

It is a tradition at Debug Academy to take time out of our busy schedules to attend DrupalCon. We do it because we enjoy immersing ourselves in a community of like-minded individuals that come together with a common cause, like the continuous improvement of open source projects/code. It also gives us the opportunity to meet new people and reconnect with alumni, colleagues, and community friends.

Debug Academy Drupal experts are teaming up to share a variety of tips, tricks, and Drupal insights to help progress the careers of our community members. We are looking forward to continuing to help people advance in their own journey, beyond the doors of Debug Academy, by giving training sessions and talks at DrupalCon. 

Training

Make sure you get to Minneapolis early, because Debug Academy team members will be leading three training sessions at this year’s DrupalCon.

Elevate your Drupal 8 application with ReactJS

In this training Debug Academy CEO, Ashraf Abed, will lead a working session to boost a section of our Drupal 8 website by building a ReactJS App. We'll modify an existing Drupal 8 website to prepare it for integration with a decoupled application. Come ready to understand the benefits of ReactJS within Drupal and how using the Rect app in conjunction with Drupal core and contrib, we can elevate your Drupal 8 application.

Training Details:
May 18th
9am - 5pm

Drupal 8 and ReactJS training full description.

Register now for Elevate your Drupal 8 application with ReactJS at DrupalCon.

Advanced ReactJS development for Drupal 8

Debug Academy CEO, Ashraf Abed will lead an all-day training to take your ReactJS skills a step further in Drupal. Don’t miss out on a day packed with techniques for dealing with non-trivial scenarios you may encounter when using ReactJS in Drupal.

Training Details:
May 19th
9am - 5pm
Advanced ReactJS for Drupal 8 full description.
Register for advanced ReactJS at DrupalCon now.
 

Advanced module development with OOP

Drupal Web Developer & Instructor, Lisa McCray, and Senior Drupal Developer Omar Abed will lead an all-day training for Drupal 7 experts making the leap to Drupal 8. We’ll take the knowledge you have of Drupal 7 and apply that to building a non-trivial Drupal 8 module. At the end of the training, you’ll leave with a better understanding of Drupal 8 module development through Object Oriented Programming (OOP).

Training Details:
May 19th
9am - 5pm
Advanced module development full description.
Register for Advanced module development with OOP at DrupalCon now.
 

Sessions

Now that the session announcements have been made, we want to invite you to join us for the sessions we will be giving this year. 

What goes into contributing? Drupal.tv case study and how you can help.

Debug Academy CEO, Ashraf Abed, and Drupal Web Developer & Instructor, Jack Garratt, are going to explore the depths of contribution via an analysis of Drupal.tv as a project.

Drupal.tv is a free community resource with many Drupal conference videos. In this session, you will learn how Drupal.tv was built by Debug Academy students, the social side of credibly contributing for the first time, and the non-code collaboration involved. Even Dries Buytaert played a role in getting Drupal.tv where it is today.

I choose YOU! Module selection without tears or fears.

Drupal Web Developer & Instructor Jack Garratt and Senior Drupal Developer Omar Abed are co-leading a session on the path to proper module selection. This talk will dive into the deep world of Drupal contributed modules and explore methodologies associated with picking the one that works best for you.

See You Soon

After every DrupalCon we leave with far more knowledge than we had going in, and far more connections and contributors than we ever thought possible...every single time. That’s why we can’t wait to join everyone again this year for DrupalCon 2020 in Minneapolis.
 

Feb 24 2020
Feb 24

This blog will outline the differences between the last migration and the upcoming shift to Drupal 9, what it means that Drupal 7 will be end-of-life by 2021, and why there has never been a better time to migrate to Drupal 8, which will make the transition even easier. 

Migrating from Drupal 7 to Drupal 8 was challenging

Migrating between Drupal 7 and Drupal 8 was challenging for several reasons. Drupal 8 contained a completely new codebase, without any of the code from Drupal 7. Although Drupal was never compatible between major versions, the transition from 7 to 8 was especially difficult. However, the advantages of Drupal 8 remain clear. By sharing code with other PHP projects, such as Symfony, Drupal 8 elevated to a modern enterprise-level technology able to support emerging web technologies and trends. 

Understandably, not all Drupal projects were migrated from version 7 to 8, and many people and companies have remained wary of such a large shift, opting to wait until Drupal 9 is released. 

End of Life 

Drupal 7 has already been frozen, meaning no new features have been added for quite some time. Currently, updates only include security patches, released when a potential vulnerability is identified by the Drupal Security Team. Drupal 8 is dependant on Symfony 3, which will also be end-of-life by 2021, meaning that no new security releases will be issued after that time for projects that aren’t on Drupal 9. While extended support can be sourced from third-party companies, active Drupal projects need a migration plan soon, which will ensure sites are safe and solutions are cost-effective. 

An easier transition for Drupal 9

After the big transition between 7 and 8, the Drupal Community has taken steps to ensure future versions, including Drupal 9, will be less painful With the addition of semantic versioning numbers and periodic smaller updates, there will be no major feature updates or additions between Drupal 8.9 and Drupal 9.0. Smaller updates have also enabled the  Drupal project to sync release schedules with Symfony, to take advantage of the latest patches. Updating from 7 to 8 before the Drupal 9 release is advantageous: providing extra time and saving money in the long run. 

Instead of a new and separate codebase, Drupal 9 has been built inside Drupal 8 by adding new functionality as backwards-compatible code, marking old code as deprecated, as well as introducing new features. Once the code is confirmed to be stable, the deprecated code is phased out. Thus, the major shift between Drupal 8.9 and Drupal 9 will be this elimination of deprecated code and updating Drupal’s dependencies -- although there are also new features to look forward to. While it’s true that projects using deprecated code will need to make changes, the process is simpler and transparent. In fact, we already know what code will be deprecated and you can run a simple tool to identify what parts of your site will need to be updated prior to release. In some cases, you can even convert certain modules automatically. 

Taking these simple steps, the update between Drupal 8 and Drupal 9 will be similar to any other routine update. 

The importance of maintenance 

Regular maintenance updates ensure that your projects stay fresh and modern as well as progress seamlessly through new versions and security releases. Amazee Labs offers full-service bespoke and automated maintenance services, as well as consulting for specific migrations and upgrades. While a transition as big as the transition from Drupal 7 to Drupal 8 won’t happen again, we can help you make sure that you never have to worry about an update again. 

Talk to us today to learn more!
 

Reference Articles 

Need more resources? Check out these articles to learn more about Drupal 9

Feb 24 2020
Feb 24

Migrate, a module integrated into the Drupal 8 Core, is a powerful solution for setting up data import processes from any data source (CSV, XML, Database, JSON, etc.) to a Drupal 8 project. The purpose of this post is not to explore all the facets of Migrate, as they are numerous and are already covered in many blog posts or official documentation, but rather to address a particular point: how to programmatically launch a migration?

Indeed it is recommended to use Drush to launch the different migration processes that are available. But in some cases, such as on a limited hosting that does not have drush, or as part of a continuous migration process, or rather a continuous data import from a third-party system to Drupal 8, it may be necessary to be able to trigger the migration processes from the code of a module, and not from a drush command at the server level.

The snippet below will allow us to start one (or more if necessary) migration process (here with the system name my_migrate_id) programmatically. Please note that in case of an error during the execution of the process, we take care to change the migration status in order to be able to restart it later.

    $manager = Drupal::service('plugin.manager.migration');
    $migration_ids = ['MY_MIGRATE_ID'];
    foreach ($migration_ids as $migration_id) {
      $migration = $manager->createInstance($migration_id);
      // update existing entity imported.
      $migration->getIdMap()->prepareUpdate();
      $executable = new MigrateExecutable($migration, new MigrateMessage());

      try {
        // Run the migration.
        $executable->import();
      }
      catch (\Exception $e) {
        $migration->setStatus(MigrationInterface::STATUS_IDLE);
      }
    }

So, for example, to set up a continuous integration of third-party content with migrate, all we have to do is to place this snippet within a hook_cron() and we will then be able to launch it at regular intervals without any more manual intervention.

Feb 24 2020
Feb 24

Every contribution makes Drupal shine brighter! The InternetDevels team knows it so we decided to hold ID Drupal Contribution Day on Saturday, 22. We gathered to improve a bunch of modules and make them ready for a smooth Drupal 9 upgrade. Let’s see how it was.

Attentive and helpful Contribution Day mentors

Every Drupal code sprint or similar event needs special gurus who curate the work of newcomers and help everyone. You will easily recognize them — they usually have a beard ;) However, the most important quality of our mentors is their big experience in teaching at our Drupal 8 courses and mentoring Drupal interns.

These two guys (both named Vova) are among our best developers, active contributors, and maintainers of Drupal modules. So they understand the importance of contributions and are always glad to engage new people in it!

ID Drupal Contribution Day — mentors

Working on Drupal issues

So after one of the mentors gave an introductory speech, we got to work. At ID Drupal Contribution Day, there were issues to every skill level and of a different character — improving the stability of modules, fixing their coding standards, writing documentation guides on drupal.org, etc.

We worked with the UpTime Widget, Stripe API, Media Watermark, Readme, Registration Confirm Email Address, Twig Tweak, Webform modules (many of which are maintained by our mentors) and other contributed Drupal modules.

The special achievement is two patches to Drupal 8 core made by one of our mentors, Vova, in the area of coding standard improvements for the DrupalDateTime and LocalTaskManager classes.

ID Drupal Contribution Day — working on issues

Getting ready for Drupal 9

As the scheduled release of Drupal 9 is getting closer, it’s easy to notice more “Drupal 9 preparation” tasks on all recent code sprints. ID Drupal Contribution Day had tasks on preparing the modules for Drupal 9 as well:

  • removing the deprecated code with the help of the DrupalCheck and other tools
  • adding the core_version_requirement key in the *.info.yml files (that we described in detail after the release of Drupal 8.7.7).

Pizza contributes to the contributors’ work!

Helpful mentors, interesting issues, great modules… all this is vital for a successful code sprint, but something is missing. Another important component of a code sprint is pizza! It came in very handy to replenish the energy of our contributors.

ID Drupal Contribution Day — pizza

Great prizes: tickets to DrupalCamp Kyiv 2020

At the end of the ID Drupal Contribution Day, all active participants received a nice gift — a ticket to Drupal Camp Kyiv 2020. It’s a chance to feel the spirit of the Drupal community, get valuable knowledge, and come back inspired for new contributions.

ID Drupal Contribution Day — prizes

Let the contributions go on!

It’s great to see this never-ending circle of sharing to Drupal when experienced contributors bring new ones in! InternetDevels development company and Drupal Ukraine Community enjoy making this happen.

See you on the next code sprints and let’s use every chance to give back to Drupal!

Feb 24 2020
Feb 24

24 . February . 2020

Views and Facets modules give you some advanced sorting options for your catalogue of products when building your ecommerce store. But sometimes all those algorithmic options are not what the client wants, they want to custom sort their merchandizing in the way that best promotes their products.

One of our clients has exactly that same need! They want to showcase their bikinis like they would do on their brick and mortar stores, where a professional visual merchandiser would sort the clothing rack in an appealing way that, being pleasant to the customers eye, would bring out the best of each piece.

As everything Drupal-related, there are several ways of accomplishing the same objective. We choose the one that was easier and most intuitive to our client, but also the one that was easier for us to replicate on other projects. The modules that appeared in our radar were DraggableViews, Sortableviews and Weight. We settled on Weight — the oldest of them all (created in 2005!) — mainly because it allows us to add a new weight field to the product entity, and the drag and drop experience was simpler and better when compared to Sortableviews. Initially, DraggableViews was our first choice because it worked so well on Drupal 7, however, on Drupal 8 the module is still very buggy. Both the Sortableviews and the Weight modules are compatible with Search API (which is very important when building Drupal Commerce stores), because they both store weights directly on entity fields, enabling Search API to have them indexed. Sortableviews has the additional advantage of allowing you to choose any integer field to store weights, where Weight only works with its own field type.

We want to change this, into this:

Let’s build that custom sort view!

1. Add a Weight field to the product entity.

2. Create a new view of Products and add the required fields.

3. Save the View and open its page.

As you can see you will have a drag and drop interface to reorder the rows. When settling on the intended order, you should click the Save button and all your products will have its weight field updated to the new value!

And, Voilà!

I hope you enjoyed this small tutorial.

By José Fernandes

Feb 24 2020
Feb 24

The first stable release of Smart Date delivered on my original vision for the module, namely, the need for a more app-like editor experience and intelligent formatting of dates and times in Drupal.

Thanks to feature requests and input from others in the Drupal community, it also included several enhancements that I had not originally thought for it to include - such as structured markup for more customizability, support for zero duration events, and better deduplication in formatting time and date ranges.

It was mid-2019 when we shared the first stable release of Smart Date. In the months since it’s been great to see its growing adoption by the Drupal community. 

What's New In Smart Date 2.0

Smart Date 2.0 is the latest major release (February 2020) of the Smart Date module. It contains many new features and optimizations inspired by and directly supported through Drupal’s active community and contributions of code. 

Recurring Events Made Easier in Drupal

Many websites - including a number of sites built by Digital Echidna - use the excellent Recurring Date Field module to handle recurring events. The only downside is that this module stores recurring instances separately, which changes how views need to be built to show them and requires special integration with other modules. 

Smart Date 2.0 stores the generated instance as standard field values. A single view lists recurring and non-recurring dates together. Any other modules that already work with Smart Date (such as Fullcalendar View) will work with Smart Date’s recurring dates:

screen view of recurring dates editor

Ready for Fullcalendar View 3.0

Speaking of calendars, at this point in time, using Smart Date with Fullcalendar View requires a patch. Mingsong, the maintainer of Fullcalendar View, plans for the 3.0 release to include an API to support additional integrations. Smart Date 2.0 has already implemented this API, and will work with Fullcalendar View 3.0 when it’s released.

Ability to Assign Timezones to Dates

We heard from the Drupal community that they wanted the ability to assign timezones to dates. For example, when building a site that lists concert tour dates, each event needs to show with the time in the local time zone. With Smart Date 2.0, a widget supports assigning these kinds of localized time zones on a per-date basis. When displayed, it shows the date in its specified timezone, but also reflects the site or user’s time, for the same date.

More Display Options for Date Values

For recurring dates, a special formatter now shows a translatable output of the recurring rule, with a configurable number of previous and upcoming instances:

date value display options

Smart Date users also requested that it allow the display of the start time and duration instead of the range from start to end. Thanks to Drupal’s object-oriented architecture, this was pretty easy to implement. Examples:

date options

Optimized for Claro and Adminimal

An exciting part of Drupal’s 8.9 release was the inclusion of the new Claro admin theme. Besides a design refresh, Claro is also built for accessibility. Smart Date 2.0 works as well with Claro as it does with Seven, and has also been tweaked to work well with the popular Adminimal admin theme.

Tested for Accessibility

Developing for inclusion is something of a passion for us at Digital Echidna, so this release includes accessibility improvements, for both the core widget and recurring dates elements.

Ready for Drupal 9

This release has been tested with the most current tools available to be ready for Drupal 9. It will likely need a few more tweaks before the planned release of Drupal 9 on June 3, 2020 but we will do our best to have Smart Date ready!

Bonus... A Module Starter Kit

We now also created a Smart Date Starter Kit to get you up and running quickly. If you just want to test it out, or maybe want to drop a simple implementation into a site build you’re working on, this starter kit will create an Event content type with an associated view to show upcoming and recent events in different tabs.

Community Contributions

I’m extremely grateful for all the positive feedback we’ve received so far, how the Drupal community has embraced Smart Date, and how they have helped it address a far broader set of use cases than I could have ever imagined on my own.

In that spirit, I want to introduce you to one of the community members who has been a passionate contributor to Smart Date on a variety of issues, Stefan Korn. Stefan is an Acquia Certified Drupal Developer and a freelancer in central Germany.

I recently connected with Stefan over email (I live and work in Canada) to ask him a few questions about his experience using Smart Date. 

This following is a transcript of our interview. 

When did you start using Drupal, and what got you into it?

I started using Drupal in 2011, starting with my first few projects in D6 but quickly turning to D7. A customer asked me about my opinion on Drupal and so I took a look and soon got hooked with Drupal.

What types of sites or other applications do you like using it for?

I am using it for all kind of sites, from brochure websites to eCommerce and bigger web sites. I am actually more or less only working with Drupal, so you name it …

Other than helping with modules, are there other ways you participate in the Drupal community?

I have occasionally been to Drupal Meetups in the Rhein/Main area (Frankfurt, Germany). I am participating in Drupal Stackexchange and a German Drupal forum, but not too frequently. Due to my freelance work I am in contact with several organizations, companies, agencies and people that are using Drupal.

How did you first hear about Smart Date?

I was searching for a more flexible date solution for D8 and was weighing between Smart Date and Datetime Extras. Smart Date made it and I am happy about that. It was even before 2.x and the cool recurring date feature, so the best part was still to come.

What were your first impressions?

First impression was very good, it solved the problem I was encountering with the core date (displaying the date exactly to my customers liking, using all day option).

You’ve contributed a lot of code fixes. Do you find it challenging to find the time for this work?

Yes, it’s challenging to find the time and since I am a self-employed freelance developer I also need to look at where to get the “Bucks” from and that’s sometimes difficult to align with code contribution …

Have you launched any sites yet with it?

There is one site that should be launched soon and I am planning to use it for a project of my own too.

Are there any changes or new features you’d like to see in the next major version?

I am generally into having a very good UI for the entering dates (quick and intuitive). I am also curious about views integration, which I haven’t tested very deeply so far.

Are there other pain points you’ve encountered in using and managing times and dates in Drupal?

Not specifically, I think the core datetime truly lacks some features to make it a viable solution in a project that is using dates and times at its core. So there is really a need for Smart Date.

[end of transcript]

The Path Forward

It’s so exciting to see Smart Date continue to evolve. I’m looking forward to seeing where the ongoing engagement with the Drupal community will take it next.

Feb 24 2020
Feb 24

Take the time to audit existing content and content types. This is a great time to find and alleviate pain points in the content management process by combining, re-working, or removing content types.

This is a crucial exercise for getting buy-in and alignment from all of the project stakeholders, from editorial, business, and engineering. This detailed spreadsheet will surface important migration considerations that would otherwise have gone unnoticed until development was well underway. 

Plan ahead. Seriously — most issues we have seen pop up from a Drupal 8 build could have been worked out early on with proper planning. One important maxim of web development to never forget: The later you identify an issue, the more expensive it is to fix. In software, it is easy to save hours of planning with weeks of coding.

Ask why 

Good engineers keep asking about the what until all of the ambiguity is gone and they have a complete mental model of the problem. Good engineers are driven to build things the right way, with craft, and with care. The difference between good engineers and great engineers is that they take the time to stop and ask why.

Use this migration as an opportunity to reevaluate your site's technical architecture. One of the worst outcomes of a migration is moving over all of the existing bad architecture to a new platform. After you understand how something works, be sure to ask why it works that way.

We recently worked with a client that was upgrading a Drupal 7 site that featured a crucial distributor finder directory experience. This map-driven experience is powered by a list of several thousand distributors stored in a third-party, priority tool with limited functionality. In the technical planning, we talked through how the data integration worked, who managed the data, and what the current state of the data was. Because the platform lacked support for custom fields, we were hamstrung in terms of how the new experience could work in Drupal 8.

However, halfway through one of our team members asked, “Why do you store the data in this tool?” And of course, it turns out, no one on the client team has any idea why this tool was being used. And only a few people use the tool on their team. We were aware the client was also using HubSpot for some other use cases. So we asked, “Why not bring this data into HubSpot, simplify the integration work, since your site already has to integrate with HubSpot, and use custom fields to track the data better so the experience can be improved?” That opened the floodgates to all kinds of great possibilities, and what ended up being a far- improved distributor- finding experience. 

Here’s the point: Get out of your headspace. Go offsite. Use giant sticky notes or a whiteboard. Think about the user journeys and desired business outcomes first. Think about what will help get the client team promoted. And don't be too focused on the tech. Part of being a zealous advocate for your client's technology is to be the catalyst of perspective.

Don’t forget you are building a content management system…to manage content

Conduct an informal internal user test and watch how content editors are using the current site. Have the content editors record their screens while they are asked to do the tasks that they normally do. See if there is any confusion, or if content editors have trained themselves to workaround bad authoring experiences. Ask content editors about the most frustrating part of using this website, or what's on their website wishlist. The experience will be illuminating.

Use this information to inform how you rebuild your authoring experience. As you plan this out, go back to these content editors and to review your plans and make sure nothing was missed. You should absolutely do this for your website end users too, but content editors are often an afterthought.

Perform a technical audit

Are there features that aren't used, or features that have ballooned to the point they're used too widely? Is there code that's been plaguing developers for years, or code no one has been brave enough to touch? Are there security issues or performance concerns? Flushing out these issues and formulating an approach to solve them at the start of the project will help ensure a smooth update process by making sure the right issues are being addressed, and aren’t carried over into the new codebase.

Keep your eyes on Drupal 9

Drupal 9 is right around the corner. Unlike previous Drupal upgrades, upgrading from Drupal 8 to 9 should be a non-event. If it isn’t, you are likely to blame. Be sure to make good Drupal 8 architectural decisions that won’t complicate a future move to Drupal 9. Our Drupal 9 Readiness Guide is a great place to start.

Feb 23 2020
Feb 23

Every site has a lot of weekly / daily attempts to abuse your forms to submit their bad content, create users, login... Here we will try to ban some of those IPs directly in the server firewall, so they can't even reach Drupal.

At first, this method might not be applicable for you. If you have a professional hosting / PaaS, your provider could (should ?) already take care of this. At least globally, maybe not specifically for Drupal attacks. For this method, you must have be able to log on your server with a user that has admin rights. This post is especially written for Debian Buster, but it should be more or less the same for other Debian versions. For other distributions, you might have to tweak some things.

Then, as you will see in the conclusion, I tend to think that this method is not sustainable in the long term. This really has to be taken as an experiment.

I also want to mention that this blog post is heavily inspired by Integrate Honeypot with Fail2ban. Basically it was my starting point and I'm mostly complementing it here.

Step 1: Drupal configuration

Let's start on the Drupal side of things. You will need to enable the Syslog module (Core). Like the name suggests, this module will write the Drupal system logs into the linux syslog. In Debian, this log is /var/log/syslog. Now, among other logs, each time a login attempt fails, it will be recorded in the syslog.

Then, if you want you can also protect the login form with Honeypot as well. You can also protect other forms such as the user registration form and the global contact form. The important part is to be sure to have the option Log blocked form submissions checked on Honeypot configuration.

Step 2: Fail2Ban configuration on your server

Fail2Ban is available in the Debian repositories:

sudo apt install fail2ban

It's advised to never edit the Debian configuration files, so we will create only .local files. Let's start with the global jails configuration:

sudo nano /etc/fail2ban/jail.d/global.local

[DEFAULT]
ignoreip = 127.0.0.1 1.2.3.4
findtime = 3600
bantime = 31536000
maxretry = 2

Replace 1.2.3.4 by your own IP(s) before anything else! Otherwise you could loose access to your remote server.

Then you can set global variables that will override the too low default values.

  • findtime (in seconds) will parse the logs for the last specified seconds. Do not enter a huge value here because this could impact the server performance.
  • bantime (in seconds) is the time for which the IPs will be banned. Don't hesitate here to have a big number. Here it's 1 year.
  • maxretry is the number of times an attempt can be retried.

Now let's define a configuration for Drupal jails:

sudo nano /etc/fail2ban/jail.d/drupal.local

#[drupal-auth]
#enabled = true
#port = http,https
#filter = drupal-auth
#logpath = /var/log/syslog

[drupal-auth-custom]
enabled = true
port = http,https
filter = drupal-auth-custom
logpath = /var/log/syslog

[drupal-honeypot-auth]
enabled = true
port = http,https
filter = drupal-honeypot-auth
logpath = /var/log/syslog

[drupal-honeypot-contact]
enabled = true
port = http,https
filter = drupal-honeypot-contact
logpath = /var/log/syslog

The first jail and filter, drupal-auth, already exists by default in Debian when installing Fail2Ban. However, I found that the regex was not working for me everytime. I still enabled it in the beginning. I added a custom version that works better, drupal-auth-custom, and I deactivated the first one. Finally I added 2 jails and filters with Honeypot.

Finally, we have to create the filters that we declared in those jails. The first filter also exists after Fail2Ban installation, so let's create the 3 others:

sudo nano /etc/fail2ban/filter.d/drupal-auth-custom.local

# Fail2Ban configuration file for Drupal failed login attempts
# Author: Tipi Koivisto
# taken from fail2ban drupal module <a href="https://www.drupal.org/project/fail2ban">https://www.drupal.org/project/fail2ban</a>
[Definition]
# Option: failregex Notes.: regex to match the password failure messages in the
# logfile. The host must be matched by a group named "host". The tag ""
# can be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P[\w\-.^_]+) Values: TEXT
failregex = \|\d*\|user\|\|.*Login attempt failed for \s?
# Option: ignoreregex Notes.: regex to ignore. If this regex matches, the line is
# ignored. Values: TEXT
#ignoreregex =

sudo nano /etc/fail2ban/filter.d/drupal-honeypot-auth.local

# Fail2Ban configuration file for Drupal Honeypot blocked form submissions
# copied from Author: Tipi Koivisto
[Definition]
# Option: failregex Notes.: regex to match the password failure messages in the
# logfile. The host must be matched by a group named "host". The tag ""
# can be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P[\w\-.^_]+) Values: TEXT
failregex = \|\d*\|honeypot\|\|.*\|Soumission bloquée pour user_.*
# Option: ignoreregex Notes.: regex to ignore. If this regex matches, the line is
# ignored. Values: TEXT
#ignoreregex =

sudo nano /etc/fail2ban/filter.d/drupal-honeypot-contact.local

# Fail2Ban configuration file for Drupal Honeypot blocked form submissions
# copied from Author: Tipi Koivisto
[Definition]
# Option: failregex Notes.: regex to match the password failure messages in the
# logfile. The host must be matched by a group named "host". The tag ""
# can be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P[\w\-.^_]+) Values: TEXT
failregex = \|\d*\|honeypot\|\|.*\|Blocked submission of contact_message_contact_form.*
# Option: ignoreregex Notes.: regex to ignore. If this regex matches, the line is
# ignored. Values: TEXT
#ignoreregex =

Notice that in /etc/fail2ban/filter.d/drupal-honeypot-auth.local, I had to use the french translation of the message because that's how Honeypot logs it for me. Also, you might have another form ID in /etc/fail2ban/filter.d/drupal-honeypot-contact.local

At last, restart the Fail2Ban service:

sudo systemctl restart fail2ban

Testing it

Careful if you try to pretend to be a hacker to see if your configuration works, you could be banned from your own server! I would just recommend to wait a little bit for real cases.

See if the jails are all active (you should have 5 with the default sshd jail):

sudo fail2ban-client status

See the status of a jail and if it has banned IPs:

sudo fail2ban-client status drupal-auth-custom

Test a jail filter:

sudo fail2ban-regex /var/log/syslog /etc/fail2ban/filter.d/drupal-auth-custom.local

One last word: when you test fail2ban-regex, if you find matches, those will not be banned. Same thing when you restart the server: already processed logs will not be taken into account. One would have to reset Fail2Ban's database or do other hacky things but it's not really worth it. After all, you've lived with those unbanned IPs for a while now, right ?

Results after 48 hours

After 48 hours I have:

  • 3 IPs banned by drupal-auth
  • 9 IPs banned by drupal-auth-custom which include the 3 above. That's why I deactivated drupal-auth and use only the custom version.
  • 0 IPs banned by drupal-honeypot-auth (I will have to check that it works).
  • 10 IPs banned by drupal-honeypot-contact

So a total of 19 IPs and they are all different.

Conclusion

For now I'm happy with this method but it should not be sustainable in the long term. With already 19 different IPs in 48 hours, if it goes on at the same rate for 1 year I will have around 3500 Iptables rules. This without counting the bans with the standard sshd jail. This should slow down too much my server.

Most importantly, I'm only banning on the basis of 3 Drupal specific rules, which miss the huge part of other attack attempts.

I'll keep the experiment going on for some time, just to see. In the end, I think that it might not be worth the effort. Configuring a more robust system would probably imply to use IPset which can handle large amounts of IPs. Also, it might be interesting to import or sync IP blacklists collected by a service and to contribute to this service data with your Fail2Ban. At this point, work is starting to add up and either you are really passionate about this, or you just take a very good hosting provider.

Feb 22 2020
Feb 22

Here is a quick tip if you want to create a step definition that has an argument with multiple lines. A multiline string argument if you like.

I wanted to test that an email was sent, with a specific subject, to a specific person, and containing a specific body text.

My idea was to create a step definition that looked something like this:

Then an email has been sent to "[email protected]" with the subject "Subject example" and the body “one of the lines in the body

plus this is the other line of the body, after an additional line break”

So basically my full file is now this:

@api @test-feature
Feature: Test this feature
  Scenario: I can use this definition
    Then an email has been sent to "[email protected]" with the subject "Subject example" and the body “one of the lines in the body

    plus this is the other line of the body, after an additional line break”


My step definition looks like this:

  /**
   * @Then /^an email has been sent to :email with the subject :subject and the body :body$/
   */
  public function anEmailHasBeenSentToWithTheSubjectAndTheBody($email, $subject, $body) 
  {
      throw new PendingException();
  }

Let’s try to run that.

$ ./vendor/bin/behat --tags=test-feature

In Parser.php line 393:
                                                                                                                                                    
  Expected Step, but got text: "    plus this is the other line of the body, after an additional line break”" in file: tests/features/test.feature  

Doing it that way simply does not work. You see, by default a line break in the Gherkin DSL has an actual meaning, so you can not do a line break in your argument, expecting it to just pass along everything up until the closing quote. What we actually want is to use a PyString. But how do we use them, and how do we define a step to receive them? Let’s start by converting our step definition to use the PyString multiline syntax:

@api @test-feature
Feature: Test this feature
  Scenario: I can use this definition
    Then an email has been sent to "[email protected]" with the subject "Subject example" and the body
    """
    one of the lines in the body

    plus this is the other line of the body, after an additional line break
    """

Now let’s try to run it:

$ ./vendor/bin/behat --tags=test-feature                                                                                        
@api @test-feature
Feature: Test this feature

  Scenario: I can use this definition                                                                 # tests/features/test.feature:3
    Then an email has been sent to "[email protected]" with the subject "Subject example" and the body
      """
      one of the lines in the body
      
      plus this is the other line of the body, after an additional line break
      """

1 scenario (1 undefined)
1 step (1 undefined)
0m0.45s (32.44Mb)

 >> default suite has undefined steps. Please choose the context to generate snippets:

A bit closer. Our output actually tells us that we have a missing step definition, and suggests how to define it. That’s better. Let’s try the suggestion from the output, now defining our step like this:

  /**
   * @Then an email has been sent to :email with the subject :subject and the body
   */
  public function anEmailHasBeenSentToWithTheSubjectAndTheBody2($email, $subject, PyStringNode $string)
  {
      throw new PendingException();
  }

The difference here is that we do not add the variable name for the body in the annotation, and we specify that we want a PyStringNode type parameter last. This way behat will know (tm).

After running the behat command again, we can finally use the step definition. Let's have a look at how we can use the PyString class.

  /**
   * @Then an email has been sent to :email with the subject :subject and the body
   */
  public function anEmailHasBeenSentToWithTheSubjectAndTheBody2($email, $subject, PyStringNode $string)
  {
      // This is just an example.
      $mails = $this->getEmailsSomehow();
      // This is now the important part, you get the raw string from the PyStringNode class.
      $body_string = $string->getRaw();
      foreach ($mails as $item) {
          // Still just an example, but you probably get the point?
          if ($item['to'] == $mail && $item['subject'] == $subject && strpos($item['body'], $body_string) !== FALSE) {
              return;
          }
      }
      throw new \Exception('The mail was not found');
  }

And that about wraps it up. Writing tests are fun, right? As a bonus, here is an animated gif called "Testing".

Feb 21 2020
Feb 21

Horray! Today is the day. We are officially announcing our return to DrupalCon 2020 in Minneapolis. We're sorry we kept you waiting so long, but we were still finalizing some moving pieces. With the recent announcement of accepted sessions for this year's DrupalCon, the cat is finally out of the bag.

This year we will be fully immersed in all things Drupal and open source. Some of our team will be leading sessions, some mentoring, and some manning a booth. Whatever it is, we're excited for another fun conference filled with amazing opportunities to learn and grow from fellow community members. We're honored to be able to be involved, to be sponsoring, and to be part of a community that has proven time and time again to be inclusive and open to curious minds.

Accepted Sessions

We'll start first by telling you what exactly it is we'll be talking your ears off about this year. While we're in Minneapolis for DrupalCon 2020 you can look forward to a diverse lineup of topics. Although the full schedule is to be determined, and don't worry we'll update you on when you can hear one of our sessions a little later, we're anxious to let you know what we know. For now, here are the topics you can expect to hear from our team.

Build Healthy Multilingual Relationships: Nest Entities Correctly

First up, we have CEO Aimee Hannaford teaming up with Christian López Espínola from Lingotek to give a great session about multilingual relationships...in a matter of tech speak of course!

As component-based design principles evolve, the actual implementation in Drupal can be performed in many ways. Most, if not all, component-based site building approaches rely on Entity Relationships. Adding multilingual support that is Correct and Predictable can be a challenge to configure. In this session, we'll surface best practices of Multilingual configuration with entity relationships.

You can read the full session description for healthy multilingual relationships on the DrupalCon website.
 

Progressively Enhance your Workflow with CI: A Roadmap

Next, we have another duo working together, architects Jonathan Daggerhart and Ryan Bateman. Together they are teaming up to provide a clearer pathway to integrating CI into your project process.

Adding Continuous Integration (CI) services to projects is often seen as an expensive and time consuming operation. At worst, clients may even perceive CI as an expensive set of developer tools that rarely benefit a project in any meaningful way. However, by changing our perspective and looking at CI as a progressive enhancement, slowly adding more and more helpful automations to our projects, CI can become the time-saving technology many projects desperately need.

You can read the full session description for progressive CI workflow on the DrupalCon website.

Getting Started With Nightwatch.js For Automated Testing

Architect Jonathan Daggerhart will be leading a solo session built around the capabilities of Nightwatch.js and Drupal. By the end of this session, you should be very familiar with the capabilities of Nightwatch.js, how you can use it for functional testing of any website (including your Drupal sites), as well as use it for unit testing your contributions to Drupal.

You can read the full session description for Nightwatch.js and Drupal on the DrupalCon website.

Preparing yourself and your site for Drupal 9

Last, but certainly not least, we have CTO Kristen Pol leading a session on a particularly hot subject...how do you prepare yourself for Drupal 9? The release of Drupal 9 is fast approaching, hopefully on June 3, 2020 but, worst case, by December 2020. Drupal 9 is a large departure from previous major releases. The only changes between Drupal 9 and the last release of Drupal 8 is it will have deprecated code removed and 3rd party dependencies updated. This will make it the easiest upgrade ever.

You can read the full session description to prepare youself, and your website, for Drupal 9 on the DrupalCon website.

Women In Drupal Sponsorship

We are proud and honored to be part of a community that acknowledges a safe space for women. As a woman-owned business, we are excited to be sponsoring the Women in Drupal Lunch again for DrupalCon 2020. Last year we led a Q&A session with those who attended our lunch to get each other talking about the ups and downs we've had along the journey to success within the tech community. To prepare yourself for what that might sound like this year, you can read some reflections from our owners about what it's like to be a woman in technology from our post last year on women's equality.

With all of that said, we're looking forward to another great opportunity to connect with the women, and those who support them and identify as them, in our community. We can't wait to see you all again. Also, we'd like to take this as an opportunity to welcome all newcomers too. The more the merrier!

We're Feeling Boothy

We have made one of the biggest commitments ever this year, by having a booth for the entire duration of DrupalCon. We wanted to make sure you'd always be able to find us while we're there. Whether you have questions about services we offer, a session we've given, or you're just looking for an old friend to say hello to, now you'll know exactly where to find us!

Our team cannot express enough just how excited we are to be returning for another DrupalCon. We hope you all share the same excitement as we do, and look forward to the journey we're about to embark on together. 

Feb 21 2020
Feb 21

The accepted sessions for the next DrupalCon are here—and what an impressive lineup!

Curated content for the 45-minute sessions is packed with compelling insight, information, and your chance to learn the latest in Drupal. Read on for a sampling of sessions. 

Feb 21 2020
Feb 21
Reading time 3 mins clock

Mobile apps.

Why are they still such a popular request when we’re well served by web browsers and responsive themes these days?

Is delivering a mobile app a huge amount of work to develop and maintain?

The many forms of mobile application

Any website being developed these days is built on top of a responsive framework allowing pages to adapt and re-layout content based on the size of the viewing device. 

Perfect for mobile and tablet devices alongside traditional desktop screens. 

So why are mobile apps still chased after by people?

What’s wrong with their responsive website?

Often the case is simply about being present on a person’s phone screen - an icon shining back at them as a reminder about the service available. Many website companion mobile apps are nothing more than a re-purposed pile of content from the website or a form-based user interface to search the information from the website.

So if the desired mobile app isn’t technically demanding what’s the best way to get it built and deployed so that your customers or visitors can benefit? There are three directions you can take...
 

Native

Apple (iOS) and Android devices have their own flavour of a mobile app, also known as a native app, which is the best possible way to deliver a great mobile experience making full use of the hardware in someone’s pocket.

However, the time and cost to find dedicated skilled developers and maintain two versions of a mobile app, which is often a simple companion to a website, is often out of the reach of most project budgets.

Hybrid

The solution to the double development time and cost is building the application using the same technologies as the website (HTML5, JavaScript, CSS) and embedding it inside of a web browser wrapped in a native application for Android and iOS.

It’s one set of code and a much simpler development process that can often be implemented by the same team that built the website. There are many toolkits and templates to generate simple applications such as Cordova and ReactNative.

PWA

Progressive Web Applications (PWA) are being pushed as the future direction that mobile apps should be heading in - a fusion of the existing websites responsive theme with additional JavaScript to speed up the reaction of pages for the user and handling times when there’s no Internet connection on the device.

It’s the quickest way to get a mobile app deployed and your icon on a user’s phone screen.
 

If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.

Apple Inc.

Where does a CMS like Drupal fit into this?

A digital experience platform (DXP), such as Drupal 8, works as a great content store thanks to its built-in data modelling toolkit. But what makes the Drupal CMS shine is the ability to expose the data model via industry-standard API formats such as RESTful, JSON and GraphQL - meaning whatever type of mobile app is decided on - the backend content that powers your mobile app can be driven by Drupal and kept separate from your app. 

This is commonly known as running the CMS in Headless mode if it is not also powering the website.

Two people on phones by You X Venture on Unsplash

Where to go first?

Drupal has a variety of mobile app approaches freely available to use, modify and learn from. Although some of the content is a little out of date, the Drupal.org site has a reasonable summary of options. Some pointers to get going for each type of mobile app are:

No matter what form of mobile app you decide on, Drupal 8 provides a solid platform for serving your data to a multitude of user interfaces - be in mobile apps, websites, smart televisions, information boards or simple input into another system.

The components and plugins needed are mostly bundled with the default Drupal install - or a free simple module installation away. There’s nothing stopping you getting stuck in with some experimentation to decide where you want to head with Drupal as your backend.
 

Struggling to know what's best for you? We'd love to chat with you and explore options relevant to you and your business.

Let's Chat

Feb 20 2020
Feb 20

Join us on March 19th for an Amazee Labs Webinar about Advanced BDD with Cypress

This session will build on the basics of Behaviour-Driven Development (BDD) and Cypress.io covered in our last webinar. We will take an in-depth look at how and when scenarios are written, common beginner mistakes and general workflow improvements. 

Topics will include:

  • Writing good scenarios
  • Establishing personas
  • Using tags to organize test runs
  • The screenplay pattern - organizing step implementations

Beginners to Experts – all are welcome. Please join us! 

Date: 19 March 2020
Time: 5 pm CEST

Register online now!
 

Watch our previous Webinars:

Feb 20 2020
Feb 20

We talk with Jacob Rockowiz about the Webform variants and A/B testing and Ted Bowman about Drupal 9 info.yml files.

URLs mentioned

DrupalEasy News

Sponsors

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Feb 20 2020
Feb 20

As a creative digital agency based in Amsterdam, we’ve gotten used to having two languages of conduct: Dutch and English. We switch back and forth without even noticing and have learned to read, write and conduct business in both languages effortlessly. Our clients are mostly Dutch, but many cater to an international audience or operate beyond borders, so by now there quite a few multilingual websites in our portfolio.

Despite the potential complexities multilingual websites may pose, Drupal has always been notoriously adamant about supporting all languages - including those with non-latin scripts and those read from right to left. Whereas multilingual sites in Drupal 7 often required a plethora of internationalization and translation modules, combined with some custom code, Drupal 8 was going to solve all our multilingual headaches once and for all. Or did it?

Everything is perfect. Almost.

Admittedly, Drupal 8 has made it easier than ever to support multiple languages. Its architectural overhaul simplified the structure, thereby making internationalization of content much more logical and efficient. A lot of internationalization functionality was moved to core in order to improve maintenance and support. And of course, to enable Drupal site builders to create multilingual sites out of the box.

So Drupal 8 solves every pet-peeve you could’ve had with multiple languages in a single site perfectly and for good. Right? Not quite. Things are never exactly how we (or our clients) want them and that’s fine. That’s why there are Drupal Developers.

Sleek and minimal will do.

Let’s talk about the language switcher in Drupal 8. It can be enabled, placed as a block in the region of your choice and it pretty much works. It shows all added languages written out fully, like so:

  • English
  • Nederlands

However, as we like our site sleek and minimal and consider our visitors tech-savvy, we would like to customize the links and determine exactly where and how the language switcher links get rendered.

Customize the language block

In order to control the output of the language switcher block, we want to be able to render the necessary links only. We don’t need a block title or any of those pesky elements, we just want an HTML list with links, for example:

<ul class="language-switcher-language-url links">
  <li hreflang="en" class="en">
    <a href="https://www.thesavvyfew.com/" class="language-link" hreflang="en">en</a>
  </li>
  <li hreflang="nl" class="nl is-active">
    <a href="https://www.thesavvyfew.com/nl" class="language-link is-active" hreflang="nl">nl</a>
  </li>
</ul>

Luckily, Drupal 8’s Twig templating system makes it pretty easy to render exactly what we want. Just place this in the page.html.twig of your custom theme where you want your language switcher links:

{ # Language switcher # }
{{ drupal_block('language_block:language_interface', wrapper=false) }}

Changing the link labels

Although it’s probably best practise to fully write out the available languages - English, Nederlands, Francais - we could do with some more sleek minimalism. Besides, we consider our visitors as tech-savvy, so we can probably suffice with showing only the language codes as our links: EN and NL.

Let’s tackle this one with a preprocess function. Just paste this code in your CUSTOMTHEMENAME.theme and the links in your switcher should magically transform into language codes:

/**
 * Use language code for the language switcher
 */
function CUSTOMTHEMENAME_preprocess_links__language_block(&$variables) {
  foreach ($variables['links'] as $i => $link) {
    // @var \Drupal\language\Entity\ConfigurableLanguage $linkLanguage
    $linkLanguage = $link['link']['#options']['language'];
    $variables['links'][$i]['link']['#title'] = $linkLanguage->get('id');
  }
}

Don’t forget to change CUSTOMTHEMENAME to the name of your custom theme.

Hide links for untranslated content

Once the language switcher is enabled and placed, it’s always there. Even when there is no translated version of the page you are viewing, there is a link to the translation of that page. Which doesn’t exist and will just lead you back to the same node, possibly on an unaliased path. That’s bad for SEO and worse for usability.

Let’s fix this by only rendering translation links when translations really do exist. We’re going to create a custom module. Let’s call it “untranslated”.

Our untranslated.info.yml file looks like this:

name: Untranslated
type: module
description: "Disables language switcher links for untranslated content."
package: Custom
core: 8.x

dependencies:
  - language

And untranslated.module looks like this:

<?php

/**
 * @file
 * Hide language switcher links for untranslated languages on an entity.
 */
use Drupal\Core\Entity\ContentEntityInterface;

/**
 * Implements hook_language_switch_links_alter().
 */
function untranslated_language_switch_links_alter(array &$links, $type, $path) {
  if ($entity = untranslated_get_page_entity()) {
    $new_links = array();
    foreach ($links as $lang_code => $link) {
      try {
        if ($entity->getTranslation($lang_code)->access('view')) {
          $new_links[$lang_code] = $link;
        }
      }
      catch (\InvalidArgumentException $e) {
        // This language is untranslated so do not add it to the links.
      }
    }
    $links = $new_links;

    // If we're left with less than 2 links, then there's nothing to switch.
    // Hide the language switcher.
    if (count($links) < 2) {
      $links = array();
    }
  }
}

/**
 * Retrieve the current page entity.
 *
 * @return Drupal\Core\Entity\ContentEntityInterface
 *   The retrieved entity, or FALSE if none found.
 */
function untranslated_get_page_entity() {
  $params = \Drupal::routeMatch()->getParameters()->all();
  $entity = reset($params);
  if ($entity instanceof ContentEntityInterface) {
    return $entity;
  }
  return FALSE;
}

Now enable this module and your untranslated links should magically vanish until you publish a translation of your page.

There’s been some debate about whether you should remove the links to untranslated content as we demonstrate here or go for a less radical approach and add css classes in order to display links as grayed out or apply strikethrough. This decision will depend on your particular case or client.

The rest of the customizations we applied were just styling, so we’ll leave those up to you and your designers.

Have fun out there!

___

A big thank you to these very helpful references:

Feb 20 2020
Feb 20

As a creative digital agency based in Amsterdam, we’ve gotten used to having two languages of conduct: Dutch and English. We switch back and forth without even noticing and have learned to read, write and conduct business in both languages effortlessly. Our clients are mostly Dutch, but many cater to an international audience or operate beyond borders, so by now there quite a few multilingual websites in our portfolio.

Despite the potential complexities multilingual websites may pose, Drupal has always been notoriously adamant about supporting all languages - including those with non-latin scripts and those read from right to left. Whereas multilingual sites in Drupal 7 often required a plethora of internationalization and translation modules, combined with some custom code, Drupal 8 was going to solve all our multilingual headaches once and for all. Or did it?

Everything is perfect. Almost.

Admittedly, Drupal 8 has made it easier than ever to support multiple languages. Its architectural overhaul simplified the structure, thereby making internationalization of content much more logical and efficient. A lot of internationalization functionality was moved to core in order to improve maintenance and support. And of course, to enable Drupal site builders to create multilingual sites out of the box.

So Drupal 8 solves every pet-peeve you could’ve had with multiple languages in a single site perfectly and for good. Right? Not quite. Things are never exactly how we (or our clients) want them and that’s fine. That’s why there are Drupal Developers.

Sleek and minimal will do.

Let’s talk about the language switcher in Drupal 8. It can be enabled, placed as a block in the region of your choice and it pretty much works. It shows all added languages written out fully, like so:

  • English
  • Nederlands

However, as we like our site sleek and minimal and consider our visitors tech-savvy, we would like to customize the links and determine exactly where and how the language switcher links get rendered.

Customize the language block

In order to control the output of the language switcher block, we want to be able to render the necessary links only. We don’t need a block title or any of those pesky elements, we just want an HTML list with links, for example:

<ul class="language-switcher-language-url links">
  <li hreflang="en" class="en">
    <a href="https://www.thesavvyfew.com/" class="language-link" hreflang="en">en</a>
  </li>
  <li hreflang="nl" class="nl is-active">
    <a href="https://www.thesavvyfew.com/nl" class="language-link is-active" hreflang="nl">nl</a>
  </li>
</ul>

Luckily, Drupal 8’s Twig templating system makes it pretty easy to render exactly what we want. Just place this in the page.html.twig of your custom theme where you want your language switcher links:

{ # Language switcher # }
{{ drupal_block('language_block:language_interface', wrapper=false) }}

Changing the link labels

Although it’s probably best practise to fully write out the available languages - English, Nederlands, Francais - we could do with some more sleek minimalism. Besides, we consider our visitors as tech-savvy, so we can probably suffice with showing only the language codes as our links: EN and NL.

Let’s tackle this one with a preprocess function. Just paste this code in your CUSTOMTHEMENAME.theme and the links in your switcher should magically transform into language codes:

/**
 * Use language code for the language switcher
 */
function CUSTOMTHEMENAME_preprocess_links__language_block(&$variables) {
  foreach ($variables['links'] as $i => $link) {
    // @var \Drupal\language\Entity\ConfigurableLanguage $linkLanguage
    $linkLanguage = $link['link']['#options']['language'];
    $variables['links'][$i]['link']['#title'] = $linkLanguage->get('id');
  }
}

Don’t forget to change CUSTOMTHEMENAME to the name of your custom theme.

Hide links for untranslated content

Once the language switcher is enabled and placed, it’s always there. Even when there is no translated version of the page you are viewing, there is a link to the translation of that page. Which doesn’t exist and will just lead you back to the same node, possibly on an unaliased path. That’s bad for SEO and worse for usability.

Let’s fix this by only rendering translation links when translations really do exist. We’re going to create a custom module. Let’s call it “untranslated”.

Our untranslated.info.yml file looks like this:

name: Untranslated
type: module
description: "Disables language switcher links for untranslated content."
package: Custom
core: 8.x

dependencies:
  - language

And untranslated.module looks like this:

<?php

/**
 * @file
 * Hide language switcher links for untranslated languages on an entity.
 */
use Drupal\Core\Entity\ContentEntityInterface;

/**
 * Implements hook_language_switch_links_alter().
 */
function untranslated_language_switch_links_alter(array &$links, $type, $path) {
  if ($entity = untranslated_get_page_entity()) {
    $new_links = array();
    foreach ($links as $lang_code => $link) {
      try {
        if ($entity->getTranslation($lang_code)->access('view')) {
          $new_links[$lang_code] = $link;
        }
      }
      catch (\InvalidArgumentException $e) {
        // This language is untranslated so do not add it to the links.
      }
    }
    $links = $new_links;

    // If we're left with less than 2 links, then there's nothing to switch.
    // Hide the language switcher.
    if (count($links) < 2) {
      $links = array();
    }
  }
}

/**
 * Retrieve the current page entity.
 *
 * @return Drupal\Core\Entity\ContentEntityInterface
 *   The retrieved entity, or FALSE if none found.
 */
function untranslated_get_page_entity() {
  $params = \Drupal::routeMatch()->getParameters()->all();
  $entity = reset($params);
  if ($entity instanceof ContentEntityInterface) {
    return $entity;
  }
  return FALSE;
}

Now enable this module and your untranslated links should magically vanish until you publish a translation of your page.

There’s been some debate about whether you should remove the links to untranslated content as we demonstrate here or go for a less radical approach and add css classes in order to display links as grayed out or apply strikethrough. This decision will depend on your particular case or client.

The rest of the customizations we applied were just styling, so we’ll leave those up to you and your designers.

Have fun out there!

___

A big thank you to these very helpful references:

Feb 20 2020
Feb 20

Drupal Camp London is a 3-day celebration of the users, designers, developers and advocates of Drupal and its community! Attracting 500 people from across Europe, after Drupalcon, it’s one of the biggest events in the Drupal Calendar. As such, we're pleased to sponsor such an event for the 6th time!

Drupalcamp weekend (13th-15th March) packs in a wide range of sessions featuring seminars, Birds of a feather talks, Sprints and much more. Over the weekend there are 3 Keynotes addressing the biggest upcoming changes to the technical platform, its place in the market, and the wider Drupal community.

Check out all of the accepted sessions on the Drupal Camp London website here. Or keep reading to see our highlights…

CXO Day - Friday 13th of March

From Front Room to Front Runner: how to build an agency that thrives, not just survives - Talk from Nick Rhind

Few digital agency start-ups reach their first birthday, let alone celebrate over 16 years of success. Our CEO Nick Rhind will be sharing anecdotes and advice from 2 decades of building the right teams to help his agency group, CTI Holdings, thrive.

Catch up with Nick, or any of our team attending Drupal Camp by connecting with them on LinkedIn, or via our contact form.

Come dine with us - Agency Leaders Dinner London

Hosts Paul Johnson (CTI Digital), Piyush Poddar (Axelerant), and Michel Van Velde (One Shoe) cordially invite agency leaders to join them for a night of meaningful discussions, knowledge sharing, and of course great food, excellent wine, and the best company you could ask for. Details of the dinner can be found here.

DCL Agency Leaders Dinner 2020

Agency Leaders Dinner London

Drupal Camp Weekend

Drupal in UK Higher Education - A Panel Conversation

Paul Johnson, Drupal Director at CTI Digital, will be hosting influential bodies from the Higher Education community as they discuss the challenges facing universities in a time of light-speed innovation and changing demand from students. In addition, they will explore the role Drupal has played in their own success stories and the way open source can solve problems for other universities. Drupal camp panel details available here.

The Panellists:

Adrian Ellison, Associate Pro Vice-Chancellor & Chief Information Officer University of West London - Adrian has been involved in Registry, IT and Library Services in higher education for over 20 years. He joined UWL in 2012 from the London School of Economics, where he was Assistant Director of IT Services. Prior to that, he was IT Director at Royal Holloway, University of London, and held several roles at the University of Leeds.

Adrian is a member of the UCISA Executive Committee, representing the voice of IT in UK education. He has spoken about information technology at national and international conferences and events and co-wrote the Leadership Foundation for Higher Education’s 'Getting to Grips with Information and Communications Technology' and UCISA’s ‘Social Media Toolkit: a practical guide to achieving benefits and managing risks’.

Billy Wardrop, CMS Service Support Officer at Edinburgh University - Billy is a Senior Developer with 15+ years experience and the current technical lead for the migration to Drupal 8 at The University of Edinburgh. He has worked with many platforms but his passion lies in developing websites and web applications using open source such as Drupal, PHP, JavaScript and Python. Billy is an advocate in growing the open-source community. As part of his role in the university, he regularly mentors at events and encourages software contribution. 

Iain Harper Head Of Digital, Saïd Business School, University of Oxford - Iain started his career at leading medical insurer MPS, developing their first online presence. He then ran digital projects at a leading CSR consultancy business in the Community before joining the Civil Service. Iain worked with the Government Digital Service on Alphagov, the precursor to GOV.UK. He then joined Erskine Design, a small digital agency based in Nottingham where he supervised work with the BBC on their Global Experience Language (GEL). He now leads the digital team at Oxford University’s Saïd Business School.

Open source has won. How do we avoid dying from success? - A Panel Conversation

Drupal, founded on a philosophy of open source, has steadily grown into a global community, a feat some may label as having achieved ‘Success’. Drupal users and contributors will be discussing the sustainability of Drupal and the future of open source in an open panel session.

What are the challenges faced by different roles? How can we make the whole ecosystem fair and future proof? What does an open source business model look like? 

Join host Paul Johnson and Drupal panellists for this thought provoking discussion on the future of open source. More details on the session are available here.

Why should you attend Drupal Camp?

Share useful anecdotes and up-to-date knowledge 

Discover the latest in UX, design, development, business and more. There’s no limit to the types of topics that could come up...as long as they relate to Drupal that is!

Meet peers from across the industry

From C-Level and Site managers to developers and designers over 500 people attended last year. Meet the best and brightest in the industry at talks and breakouts.

Find your next project or employer

A wide variety of business and developers attend Drupal Camp, make the most of it by creating connections to further your own career or grow your agency team.

Feb 20 2020
Feb 20

DrupalCamp London is a great event for all Drupal agencies. It is a conference that brings together hundreds of Drupal experts from around the world. It's a great opportunity to meet people who use, develop, design and support the Drupal platform. Therefore, as usually we will be there this year as well.

Droptica is a sponsor of DrupalCamp London 2020

We are proud to sponsor and participate in this year's DrupalCamp London. The event will take place on March 13-15, 2020 in London.

Sponsor graphic

DrupalCamp London is expected to attract over 500 specialists from around the world. Join it you want to discover Drupal or learn about what's new in Drupal 9.

From our part, two lectures will be presented by Maciej Lukianski. As follow:

  1. Droopler 2.0 - business websites on Drupal
  2. Training PHP developers in Drupal (how we do it in Droptica)

Don't miss it! :)

We are part of the Drupal community

We are a leading Polish Drupal agency supporting the Drupal community. As an avid supporters of Open Source technology, we engage in initiatives, supporting new modules, and sponsoring or organizing local Drupal meetings as much as possible.

Let's meet at our stand

We invite everyone to the capital of Great Britain to join talented minds in Drupal during the three-day DrupalCamp in the heart of London. We also cordially invite you to visit our Droptica stand, where Drupal's personalized mascot will be waiting for you to grab.

Learn more about DrupalCamp London and how to participate here: https://drupalcamp.london/.

Can we count on your presence? :)

 

Feb 20 2020
Feb 20
Main picture blog post DrupalCamp London 2020 DrupalCamp London is a great event for all Drupal agencies. It is a conference that brings together hundreds of Drupal experts from around the world. It's a great opportunity to meet people who use, develop, design and support the Drupal platform. Therefore, as usually we will be there this year as well. Droptica is a sponsor of DrupalCamp London 2020 We are proud to sponsor and participate in this year's DrupalCamp London. The event will take place on March 13-15, 2020 in London.
Feb 20 2020
Feb 20

Your browser does not support the audio element. TEN7-Podcast-Ep-082-Mike-Gifford-Accesibillity-Is-a-Journey.mp3

Summary

Mike Gifford’s mission is to build better and more inclusive software. He’s a Drupal 8 Core Accessibility Maintainer, founder of OpenConcept, an accessibility consulting firm, and all-around gem of the Drupal community. Mike’s been spearheading website accessibility improvements for over a decade, and we’re thrilled to have him on our podcast. You’ll learn a lot from this episode!

Guest

Mike Gifford of OpenConcept Consulting

Highlights

  • What is accessibility?
  • The four pillars of accessibility: POUR
  • Designing for 80%
  • Permanent, temporary, and situational disabilities
  • How Mike got started fixing Drupal accessibility issues
  • Drupal’s Accessibility Maintainers
  • Rachel Olivero, and the Drupal Olivero project
  • Pivoting OpenConcept Consulting from a Drupal shop to a consultancy
  • How OpenConcept eats its own dog food
  • The future of accessibility is personalization
  • The preferences framework widget
  • Establish trust by showing individual needs of website visitors are important
  • Accessibility and fonts
  • How do you help users when we can’t see their cues?
  • How accessible is Drupal Core?
  • Frontend pages AND backend pages must be made as accessible as possible
  • How are other CMSes and frameworks doing with regards to accessibility?
  • We are all affected by some sort of disability

Links

Transcript

IVAN STEGIC: Hey everyone! You’re listening to The TEN7 Podcast, where we get together every fortnight, and sometimes more often, to talk about technology, business and the humans in it. I’m your host Ivan Stegic. My guest today is Mike Gifford, Founder and President of OpenConcept Consulting, Inc. in Ottawa, Canada. OpenConcept is a web development agency specializing in Drupal, much like ours, and a benefit corporation, a B corp. Mike is also Drupal’s core accessibility maintainer and has been since 2012. Hey Mike, welcome. It’s great to have you on the podcast.

MIKE GIFFORD: It’s great to be on once again. It’s been a while, but definitely enjoy having an opportunity to talk again with you about Drupal and accessibility and things involved with digital tech.

IVAN: I love it. I can’t believe it’s been almost three years ago, episode 6. We’re coming up to episode 84. Wow. It’s been a long time. I feel like we’ve just scratched the surface.

MIKE: Absolutely. It’s amazing how time passes when you’re busy serving client needs and keeping up with changes in the Drupal community.

IVAN: Busy having fun I think, is what we call it. [laughing] So, let’s talk about accessibility. People throw that word around quite a bit, don’t they? I think we believe we know what it means, and some people say, “Oh your site has to be ADA compliant.” Other people say, “Yeah, we need WCAG or WCAD compatibility.” Why don’t we start with the definition for accessibility? What do we mean in our industry when we talk about that for a website?

MIKE: So, essentially it means removing barriers to make sure the people are able to access your content, whatever disabilities they have or whatever tools and devices they’re using to go off and to access it. The World Wide Web Consortium’s Web Accessibility Initiative broke this down into four main pillars that they’re using for the WCAG 2.0 framework, and I think to summarize it quite nicely:

Let’s make sure that your web content is perceivable so that people can understand it and read it and absorb the information.

Let’s make sure that it’s operable so if you’ve got some sort of interface people are working with, then the people can interact with the web forms, and they can engage with it, and click on the buttons and navigate the website.

Let’s make sure that it’s understandable. This is one that particularly government websites fail on. And there’s very, very few websites that really excel at plain language and making sure that things are written so that people can absorb the information on the flow and eliminate all that technical jargon and information that gets in the way of comprehension.

Finally, let’s make sure that it’s robust. So many websites work great if you’re in a dark room with a really new monitor that’s sitting there, but if you’re on your phone and navigating on a bright day, you’re going to have a hard time going off and viewing the information, accessing the information. So, let’s think about this in the real world situations that people engage with technology on. It’s not always going to be in that ideal environment where those light-gray-on-dark-gray backgrounds work.

You really need to be able to think about the context with which people are using the technology. So that’s how I think about technology within the web accessibility framework.

IVAN: And that’s POUR right? P-O-U-R. Perceivable, Operable, Understandable, Robust.

MIKE: That’s right. And there’s a whole bunch of criteria that you can use to evaluate your website based on that. It’s an interesting framework that’s designed to be technology agnostic. It doesn’t really matter what kind of technology you’re working with, whether it’s a PDF file or whether it’s a website—those principles are things that you can use to guide your thinking around accessibility.

IVAN: So those are high-level principles. That’s how we want to design from a design-first perspective so that the context of the design itself is available and accessible from anyone using the site.

MIKE: That’s right. There’s some really interesting work being done by people looking at inclusive design, and this isn’t a new movement, but there’s some neat work that Jutta Treviranus has set up to look at designing for the fringes. So often people think about the 80/20 rule, and it’s like, Well let’s just go off and design for that 80%, and then worry about that additional 20% later. We won’t necessarily factor that into the equation. Whereas, if you look at the fringes and design for the extremes, then you can be confident that everyone’s needs are going to be met, and you can work ahead to see that you’re able to deal with it.

And also, the 80/20 rule is a great concept for many things, but it doesn’t make a lot of sense. Like, how many businesses would just write off 20% of the United States? Would you get rid of New York and New Jersey? Whatever you think about them, would you just eliminate selling to those as potential customers, because it’s inconvenient for some reason? Probably not. It’s a large chunk of the population to ignore. So, thinking about the fringes and accessibility early on in the design process really allows you to go off and to serve a much broader range of the population than most people are aware of.

IVAN: The 80/20 rule is by definition exclusive. You are actually saying we’re excluding one-fifth of the population because we choose to.

MIKE: Because that’s inconvenient.

IVAN: Cause it’s inconvenient.

MIKE: Yeah. There’s really neat work done by Microsoft actually with the Inclusive Design Toolkit, and what they’ve done is try to look at, not just people with permanent disabilities, but to try and extend the definition out more broadly so that you have people that have permanent disabilities. But then there’s people who have temporary disabilities, and then there’s people who have situational disabilities. So, for example, a temporary disability might be you left your glasses at home, so you’re having trouble reading stuff at the office. Or, you’re in a situation where you’re taking medication, and so your eyesight may not be as good while you’re on this particular medication. Or, maybe you’ve broken your dominant arm, so you’re trying to navigate the mouse with your left hand, and it’s just not as good as it was with your dominant hand.

There are things like that, that are temporary issues that we all undergo as part of living in a complex world. But the situational ones are things like you’re in a noisy environment and you can’t use Siri to go off and interact, because Siri can’t cancel out all the noise that is coming from the area. Or, you’re in a situation where you want to use your laptop outside on a sunny day, and you can’t because there just isn’t enough contrast in the pages to be able to read the information effectively. So, again, thinking about all of these different ways that people interact, even if they’re not defined as having their disability, but there are times and places where everyone has a disability.

IVAN: Context is important, isn’t it?

MIKE: Yeah.

IVAN: You’re so passionate about accessibility. And besides it being the right thing to do, to be inclusive, to think about others that might not have the same abilities as you do. How did that happen? How did you get to be so passionate? Where did your start in accessibility come from?

MIKE: I think a huge part of my background came from having a good friend who has cerebral palsy, who is a real champion for disability rights and who schooled me on some of the theory about how to think about disability, and to think about the abilities that I have. So that certainly is a really key element to it. I started making changes to the Drupal community, getting them involved in affecting Drupal. And it suddenly became addictive because many people who work in the accessibility field go off and address a particular issue, and they fix a particular issue for a particular website. But that’s not what I was focusing my time and energy on. I was focusing my time and energy on fixing Drupal, which is 3% of the web.

So, I was able to go off, working with a whole team of other people to transition Drupal from being a reasonably good standards-compliant CMS to being by far the best, most accessible content management system out there, because of some of the work that I was spearheading. It was interesting to go off and look at ways of supporting people, and so the first Drupal Accessibility Maintainer was Everett Zufelt, who also taught me a great deal. When he was contributing the most to the Drupal community, he was working with me as staff at OpenConcept.

So, I was able to go off and learn from him as a blind user, and to learn what his experiences were with Drupal and review my own assumptions about what was possible, and how to address that. Everett is no longer an accessibility maintainer, but in Drupal 8 there are two other accessibility maintainers, Andrew MacPherson and Rain Breaw, who are taking on a role of pushing things ahead and addressing the accessibility community within Drupal.

So, we’re going to be having regular office hours and I think, it is the last Tuesday of every month.

IVAN: I’ve just been so impressed with the amount of accessibility that Drupal has garnered in the last five years. It’s just been so nice to see the improvements that have happened. Of the maintainers, do we have any maintainers that have disabilities that have the inclusive perspective of actually using the web and being able to maintain Core from a disability perspective?

MIKE: Actually no, and that’s an area where we could actually use a lot of additional work. I don’t think that either Andrew or Rain have a disability, at least not that I’m aware of. But we haven’t had enough people in the Drupal community who have disclosed their disabilities and who have stepped up to get involved in the Drupal community. We had a few people who have done that. Everett is one. Vincenzo Rubano was another. He came to DrupalCon Portland from Italy. And as an individual, Vincenzo has contributed more to the Drupal 8 accessibility than all of the governments in the world combined, and this is what he did in the year before he started university. So, it’s quite an amazing accomplishment in many ways, and also, why is it that governments around the world are not doing more on accessibility? It’s a bit baffling.

But the last person we’ve had to sort of highlight in terms of people with disabilities who have been involved with the accessibility team, was Rachel Olivero, who unfortunately died last year. So, that was a sad thing. She was quite involved in the diversity community within Drupal and had gone to two other DrupalCons and unfortunately, she died suddenly and is no longer with us.

IVAN: I recall that. That was devastating news that we’d heard. I’d had such a wonderful dinner with her at that DrupalCon that we both attended on trivia night.

MIKE: Yes.

IVAN: I think she was part of the National Association of the Blind, if I’m not mistaken.

MIKE: That’s right. She was working with the National Federation of the Blind and transferred a few different roles, but had actually just launched their Drupal 8 website and had made a lot of advancements in that, and it was really nice to see that, and she had also made a couple contributions to the Drupal community with accessibility bugs that she had identified. There is now the Olivero project within Drupal with the new themes which is going to be coming out with Drupal 9. I’m looking forward to going off and seeing that, a theme that’s being named in her honor. So, that’s lovely.

IVAN: That’s really lovely. We will link to that from the podcast episode page. So, if you’re listening, do visit the website for more information . Now, OpenConcept is focused on accessibility as a core part of your business, isn’t it?

MIKE: Yes, it is. We’re actually in a position where we’re pivoting from being a Drupal shop where that’s primarily what we do, to actually having a role as a digital agency and doing more consultation and support work with others. Because of the work that I’ve done on accessibility, we’ve been able to take systems perspective to accessibility and sustainability and security and really look at this at a higher level and to step back and address these issues. So, we’re doing more work as a digital agency going ahead, and not just as a Drupal shop.

IVAN: Well that’s a wonderful development for you. You certainly have the wherewithal and the knowledge to be providing that kind of consulting, so I love to hear that evolution. I love the fact that your website itself, openconcept.ca, eats its own dog food, so to speak. There’s a widget drawer at the top of some sort of preferences. I haven’t seen that before. It allows anyone to be able to change, essentially, the design and the contrast and the typeface, and everything you would to make the site more accessible, I would guess. Tell me about that preferences pane.

MIKE: Our own website is one that often doesn’t get as much attention as we’d like to. So, we started a process to rebuild our website, and I’ve had to put that on hold because of some other issues. But, yeah, our website, we’ve definitely built it for accessibility, but accessibility is a journey, you need to be able to invest in that on a regular basis. So, I’d like to be doing more with our website than we are.

But specifically about the widget that we have on our website, I realize that one of the our challenges with the WCAG process is that it’s building a single website, and meeting the needs of everyone through a single website. But unfortunately, disabilities are such that that doesn’t really make any sense. There are people who have low vision, and need high contrast. There’s people who have dyslexia, they need low contrast. That’s just sort of one example. There’s people who get really frustrated when they see Comic Sans as a font. There’s other people who, the best way that they can read content is with having Comic Sans or Openyslexic or some other customized font.

So, how do you try to give people the range of exposure to go off and absorb information in a way that suits their needs? And having a single site, that is not going to be able to achieve all of those goals. So, we see that the future of accessibility is really towards providing personalization. Yes, you want to go off and meet a minimum standard requirement. You want to make sure that your default website is meeting the base level, the Perceivable, Operable, Understandable, Robust guidelines that are being set forth in WCAG 2.1—actually, because the latest one is WCAG 2.1. So, that’s the goal that people should be aiming for. But, if you can extend it to even more people by going off and allowing individuals to have personal choices.

The IDRC, which is the Inclusive Design Research Centre in Toronto, put forward a preferences framework widget that we’ve incorporated in our website. We did this because we were working with the Canadian National Institute of the Blind, which is the equivalent of the NFB in the US, or the RNIB in the UK, and we wanted to incorporate that within their website.

So, we first tested it on our website and looked to make sure that we could work through the bugs and unknowns and uncertainties with that tool on our website, before we went off and implemented it with our clients. Again, that idea of eating your own dog food and evaluating this and building the best practice by demonstrating the best practice is something that we wanted to be able to do.

So, we implemented this widget and have contributed back to the IDRC, because the preferences framework is an open source widget that we were able to build on and incorporate into Drupal as a Drupal module. There’s now Drupal 7 and Drupal 8 implementations of the preferences framework.

IVAN: If you design a site so that it’s meeting these accessibility parameters in WCAG 2.1, then do you need the preferences framework?

MIKE: You don’t for the legislation. If your goal is to try and make sure that you’re just checking a box, and that you’re meeting the requirements and you’re not going to get sued, then no, you don’t need to worry about the widget. But if your goal is actually increasing the use and participation and usability of your site, if your goal is improving usability, then this widget is actually quite useful to go off and to give your users the ability to provide a custom interface, or custom display for the site. And there are ways that people can override the CSS pages that are custom built to their own browser, but that’s more complicated than most users would go off and know how to do, and often it is something that doesn’t work well with the website.

But, if you build in this framework then you can evaluate, Well, how does it work with the dark background? How does it work with the light background? How does it work with a yellow/black high contrast mode? And your developers and designers can evaluate some basic ideas to make sure that your SVG files show up appropriately, that you’re able to go off and provide a good experience for somebody, even if they do need to invert the color scheme. It’s useful to do that even for the number of people who are now preferring to use dark mode for their websites.

IVAN: How do you deal with marketers and brand stewards of corporations and organizations who will, I’m sure, inevitably say something like, “That preferences pane destroys our brand. It’s not consistent with what our brand guidelines say.” How do you deal with that kind of pushback?

MIKE: I think I would say that if something like this destroys your brand, then your brand is not very strong. You want to be able to go off and have some control over your presentation, your site, the default settings, but ultimately a brand is about establishing trust with the customer. And there’s no better way to establish trust with your customer than to demonstrate that their individual needs are important to you, and that you can serve their individual needs.

So, what could possibly be better than having a widget on their website that says, You can buy your Nike runners even if you're blind or if you’re dyslexic. We’re going to make it easy for you to buy our products and give you the support you need, however it is that it serves you best. And you’re not to get stuck on stupid proprietary fonts or highly custom color combinations that were approved by some highly paid branding office. Ultimately the brand has to be strong enough that the trust and that care for the user shines through, and I think that this preferences framework is a part of that.

IVAN: I’ve been tracking the variable fonts recently. I know they’ve been around for quite a while now, but they’ve only recently been getting more traction, I would guess. Do you know anything about variable fonts and how they affect or not affect accessibility? I would imagine there’d be a relationship there.

You have more control over the kerning and the size. They’re somewhat different than regular fonts that have specific sizes. A nd when you say bold for example, they go to a specific bold typeface. You can actually change the size and characteristics of these variable fonts with CSS. And I would imagine that would be highly useful from an accessibility perspective.

MIKE: Fonts are definitely an interesting area and it’s amazing to see the changes in the web that make it look more attractive, more compelling. But there isn’t a lot in WCAG to address fonts. Sometimes it just comes down to a matter of judgment. A lot of times fonts are too narrow to be easily read, and there’s no standard way to evaluate how thick or how thin a font can be without affecting the accessibility of it. And, as our monitors get more and more refined, you can create thinner and thinner fonts.

So, I think we are going to get to the point where fonts are going to be more easily evaluated, but some of it comes down to even just base readability. Like, all the debates have happened between, you know, is Helvetica better than Arial? Better than Times? There’s a lot of studies on this, but again there’s nothing in the standards that we’re looking at that say, This is the best font, or This is the way that you’re going to address fonts in meeting accessibility. Because it’s hard to pin down, hard to go off and quantify, and so much about WCAG is about making it quantifiable.

It’s not just about opinions. It’s about a quantifiable, demonstrable barrier that you’re able to address. I can see that with variable fonts, one of the neat opportunities there is to be able to say, How would you use something like the preferences framework to allow a user to go off and customize the fonts?

IVAN: Exactly.

MIKE: Let’s say you want to have a fat font for this. The font doesn’t need to be larger, it just needs to be bolder, just make everything bolder. And you could with this, very easily go off and have a setting that allows users to have that ability to build that in, and to think about ways—or just switching fonts entirely. You can either stick with just making the font that was chosen customizable, to go off to meet your specific user’s needs. Or you can go off and say, Let’s give them the option to pick from five or six other fonts that might meet their needs and allows them to more easily absorb the information. Because ultimately what we want is the ability for an author to communicate to another person.

So, how do you communicate that information so that the author or presenter is able to go off and convey as rich in information as possible for the person receiving that information to absorb. And, if you were doing it in a face-to-face conversation, we can know how to go off and slow the pace of our speech, or to speak more loudly if somebody has hearing impairments. We know how to do that because of personal cues that allow people to change their presentation for a particular individual.

But it’s harder on the web when you’ve got technology mediating that communication, and we don’t have those personal cues to guide us. So we need to actually give that opportunity for feedback to the user and encourage them to select preferences that allow them to choose something that allows them to more easily use your website.

IVAN: The standard that we’re looking at right now is WCAG 2.1, and people usually say that [level] A is the bare minimum. AAA is, Are you insane, do you have a lot of money? What is the goal of doing AAA? And AA is usually the one that organizations land on, if I’m not mistaken, to describe it loosely. Where are we at with Drupal for accessibility? For Drupal Core? And what’s next?

MIKE: So, just a bit of a correction. In the United States, the standard is still the revised Section 508 standard, which is pegged to WCAG 2.0 AA, and more or less that is the standard. Internationally, we’ve moved on from WCAG 2.0 AA, because that was the standard written in 2008.

IVAN: I didn’t realize it was that old.

MIKE: Yeah, so the original Section 508 that was in place up until January of 2017 was written in 1997, so that was how old the standard was for the Section 508. Which is still better than the—actually no, it wasn’t better than the WCAG 1.0—these are old, old standards. But WCAG 2.1 was released in 2018, so it’s a much more current guideline, and WCAG 2.2 should be released later this year. And the plan is to go off and make these releases much more regular, in order to keep up with the pace of technology. Waiting a decade or two between updates of accessibility standards truly does leave out a lot of people. So, the standards are evolving.

So, as far as where Drupal is, we’ve done a good job at Drupal Core of meeting WCAG 2.0 AA for both the frontend web pages and for the administrative pages. It’s not perfect, and there’s a lot of known issues in the accessibility queue, but we’ve addressed a lot of the base issues that people run into.

Because Drupal 8 has a lot of interactive elements, there’s content that changes on the fly with JavaScript, and we need to be able to add more instances for support for this, so that we can alert screen reader users that the screen has changed. So, ARIA live is something that was introduced in Drupal 8. There’s a Drupal JavaScript function called Drupal.announce() that allows developers to go off and to codify how screen readers are alerted to changes to dynamic content on the page. So, we need a lot more work done to implement that in Drupal 8. Drupal 8 has done a lot of work on ATAG 2.0. ATAG 2.0 is the Authoring Tool Accessibility Guidelines, and this essentially says, we’re going to look at the authoring experience, and Drupal is an authoring tool, and we’re going to say, part A of ATAG is Let’s make sure that the authors with disabilities can actually be publishers of content and not just consumers of content. Right?

And this something really that Everett Zufelt went off and drove home to us, is that we couldn’t just go off and rely on making the frontend pages accessible, we also needed to make the backend pages accessible, or people like Everett were not going to be able to publish content using Drupal. So, we went and, in Drupal 7, made some big advances in addressing the backend accessibility. That’s been carried over in Drupal 8, and that’s part of ATAG part A, it’s just sort of making that the authoring interface be as accessible as possible.

Part B is actually I think more interesting and more useful, particularly for institutions, and I’m sad to see that there isn’t more attention paid to Part B of ATAG, because that’s about how do we use these systems to make it easier for authors to create accessible content? And how if we don’t think about the authoring experience, like we can’t expect authors to be accessibility experts; we need to think through the tools and the technology that they use to support and guide users in doing the right thing.

We need to set good defaults for accessibility in the authoring tool, so that when the millions of users are adding new content to Drupal, the 3% of Drupal websites around the world, it’s a huge number of people that have used Drupal on a regular basis that need to be involved. And if you don’t have the system helping authors make the right decisions, then it should be no surprise that you have accessibility issues being added by authors who are not familiar with best practices.

But if you get the tools involved in setting up proper constructs, then you can limit the damage that users can do. You can guide them to make the right decisions. And there’s a lot more that can be done in that space. We’ve done more than anyone else, but we have not done enough in that space.

IVAN: I like to hear that we’ve done more than anyone else, but I’d be even happier to hear that “everyone else” is close on our heels, and equally accessible. So, before we close, I wanted to hear your assessment of other competitors, other CMSes and frameworks out there, and what their accessibility is looking like. How do they compare? Let’s talk about maybe a couple of the open source ones we all know and love, like WordPress, and maybe talk about React or Gatsby, any of the things that come to mind for you. How do they compare?

MIKE: So, I was really quite hopeful with the WordPress community up until the Gutenberg debacle that came out. When I was in Holland in the fall, I had a great meeting with one of the WordPress accessibility leads that had stepped down because of how that was handled. It was a really interesting presentation that she and I had with others in Holland around accessibility. So, I’m less optimistic about the future of WordPress accessibility than I was, because of leadership issues within the WordPress community.

But there’s lots of good people involved in creating accessible themes in WordPress and that’s great. But it does require it to be a priority for the leadership in order for it to be really ingrained in the community, and that’s one of the things that Drupal has really stood out in.

 I’m really impressed by Gatsby and with Marcy Sutton and others who have a really deep ingrained passion for accessibility that they’re building into the process. So, if you’re building a Gatsby site, or a Gatsby page, accessibility checks are now just part of the process of doing a Gatsby build. And just having that as a framework is just built into the process of how you build a good Gatsby website. That’s so wonderful. Marcy was involved in the Axcore team, which is an automated accessibility engine that the Deque folks built a while back, and it’s really been taking off. And the Microsoft community is jumping on board with that, and Microsoft has built a tool called Accessibility Insights that uses that.

There’s also the Google Lighthouse tool that uses Axcore as well. So, it’s nice to go off and see that that’s built into Gatsby, and that there’s a commitment to that from senior levels in the Gatsby community.

I hadn’t really seen a lot of other examples where content management systems are taking this seriously. I do think that Microsoft is an organization that we do really need to be aware of, both because of their interest in open source and their passion for accessibility, and that has really been a real transition in the last two or three years.  

IVAN: Yeah, who saw that coming?

MIKE: Yeah, like what the heck? So, they’re incredible leaders in the space and making a lot more money because of it, and that’s both wonderful and fascinating. I certainly did not see that coming [laughing]. I was definitely not one of the people that expected this. But it’s quite wonderful, and I think it will be neat to see what Microsoft comes up with, and I’m not sure there’s enough money in the world to go off and make SharePoint accessible [laughing].

IVAN: [laughing] Yeah, SharePoint doesn’t have a great, stellar accessibility. I mean, even for the rest of us, the user experience could be better.

MIKE: That’s right, but it is interesting that Microsoft has made a cultural shift in how they think about both open source and accessibility, and sustainability, for that matter. They’re committed to being carbon negative by 2030, so they are making some big bold leadership commitments in the tech space, and I think that they will pay off for Microsoft, and I think that is something that others will follow, but I haven’t seen a lot from most other, like React itself, I haven’t seen a lot of pickup and movement around this. I haven’t seen Angular or Core.

IVAN: What about Sitecore or any of the proprietary CMSes?

MIKE: I don’t think it’s part of the process. They’re not looking at building it accessible by default and partly that’s because clients are not demanding it. There are not enough organizations who are demanding accessibility as part of the default system. I think this is changing. The governments in Europe are starting to be aware of this and looking at Drupal and looking at that as a model, but it’s not being incorporated into the procurement process. So sales folks are not hearing this is something they’re not losing their contracts around it.

IVAN: Yeah, and you would expect there to be a more vocal demand. As you know there was this report from the World Health Organization in 2011 that said that about 15% of the world’s population lives with some form of disability. And it’s probably higher than that, that’s almost 10 years ago that that report was done. So, you would think that there was a demand, that corporations would see this, and would move in that direction, but I guess not.

MIKE: That’s only the people with permanent disabilities that they were addressing. They weren’t making it either temporary or situational. If you’re looking at temporary or situational, it’s a higher percentage.

IVAN: Right. We all experience high sunlight when we go out and use our phones, don’t we?

MIKE: That’s right. It’s a universal thing. Unless you don’t go outside [laughing].

IVAN: Right. [laughing] and the same thing with getting older, we all lose our eyesight as we’re getting older. Our vision becomes impaired and so there’s that to think about as well.

MIKE: That’s right, and you’ve got the aging baby boomer population. You think about the gray tsunami, all of those ideas require us to think differently about the web, because it’s not just the way that we see color change as we age, the way that we navigate websites changes. Disability is just part of life. We do not have the abilities we did when we were 20. This should not be a shocker to anyone right?

IVAN: I wish I had those abilities still, Mike. [laughing] It’s been so great talking to you. I feel like we didn’t even cover some of the things I wanted to get to, talking about the government and your work with the Canadian government and how you’ve been keeping track of the Accessible Canada Act. Would you come back sooner than the next three years, and we could have another recording and another episode, and we can get into those ideas as well?

MIKE: I would absolutely be keen on doing that, and then hopefully it’ll be something that’ll be done in person as well, which will be way more fun than doing it remotely.

IVAN: You know what, that would be great. Next time you’re in Minneapolis, I know you won’t be here for DrupalCon this year, but next time you are, let’s do that.

MIKE: That’d be great. And who knows, maybe I’ll find a way to get to DrupalCon. Maybe I’ll make that possible but it’s not in the cards right now, but, yeah, it’d sure be a lot of fun.

IVAN: That would be so much fun. Thank you so much for spending your time with me today. It’s been a great pleasure talking to you.

MIKE: No problem.

IVAN: Mike Gifford is Founder and President of OpenConcept Consulting Inc. in Ottawa, Canada. You can find them at openconcept.ca. They’re a web development agency that specialize in Drupal and are pivoting to be more of a strategic consulting firm. They’re also a B Corp. Mike is Drupal’s core accessibility maintainer, one of the few of them, and you could find him online @mgifford on Twitter. You’ve been listening to the TEN7 podcast. Find us online at ten7.com/podcast. And if you have a second, do send us a message. We love hearing from you. Our email address is [email protected]. Until next time, this is Ivan Stegic. Thank you for listening.

Feb 20 2020
Feb 20

My appreciation for form API in Drupal is on the same level as my attempt to avoid it when it comes to user facing forms. Both are pretty high. The reasons I love it are because it’s extendible and security is built in. I’ve worked with a few other frameworks in different languages, and my impression is that Drupal’s form API is significantly more advanced than any other solution I’ve seen.

The reason I try to avoid it, on the other hand, is mainly because it’s hard to create forms that satisfy the end users, and achieve their expectations. Basically, forms are bulky, and going with a mix of JS/Ajaxy solutions is often a pain. Having a JS form (i.e. some JS widget that builds and controls the entire form), that POSTs to a RESTful endpoint takes more code, but often times provides a more streamlined user experience.

Not sure why and how, but over the years we’ve been tasked quite a few times with creating form wizards. It’s frequently used for more complex registrations, like for students, or alumnus applying for different programs. In the early Drupal 7 days we went with CTools’ wizard, and then switched to Elm (i.e. a JS form) along with RESTful endpoints. Drupal 8 however has one major feature that makes it very appealing to work once more with form API - that is “Form modes.”

This post has an example repo, that you should be able to reliably download and run locally thanks to DDEV. I will not try to cover every single line of code - but rather share the concepts behind our implementation, with some references to the code. The audience is intermediate-level Drupal developers, that can expect to have a good sense of how to use Form modes to build wizards after reading this post and going over the code.

Before diving in, it’s important to recognize that “wizards” come in many flavors. I personally hold the opinion that a generic module cannot be (easily) built to accommodate all cases. Instead, I look at Drupal 8 with its core and a couple of contrib modules as the “generic” solution to build complex - sprinkled with lots of custom business logic - wizards.

In our case, and for demonstration purposes, we’ve built a simplified “Visa application” wizard – the same you may find when visiting other countries. As an aside, I do wish some of the countries I’ve visited lately would have implemented a similar solution. The experience of their wizards did bring me to tear some of the remaining hair I’ve still got.

Our objectives are:

  1. A user can have only a single Visa application.
  2. Users should have an easy overview of the state of their application.
  3. Sections (i.e. the wizard pages) must be completed to be able to submit it to final processing; however, it doesn’t have to happen in a single go. That is, a user can save a partial draft and return to it later.
  4. After a user “signed” the last section, the application is locked. The user can still see what they have submitted, but cannot edit it.
  5. A site admin should have easy access to view and edit existing applications.

With the above worthy goals, we were set for the implementation. Here are the two main concepts we’ve used.

Sections as Form Modes

In Drupal 7 we could define View modes for a node (well, for any entity, but let’s be node centric for now). For example, a “Teaser” view mode, would show only the title and trimmed body field; And a “Full” view mode would show the entire content. The same concept was applied to the node forms. That is, the node add/edit form we know, is in fact a “Default” form mode. With Drupal 8, we can now define multiple form modes.

That’s pretty big. Because it means we can have multiple forms, showing different fields - but they are all accumulated under a single node.

For each wizard “page” we’ve added a section: section_1, section_2, etc. If you have the example repo running locally, you can see it in:

https://form-wizard-example.ddev.site:8243/admin/structure/display-modes/form

Form modes configuration page.

Next we have to enable those form modes for our Visa application content type.

https://form-wizard-example.ddev.site:8243/admin/structure/types/manage/visa_application/form-display

Enable form modes for the content type.

Then we can see those form modes enabled, allowing us to setup fields and disable others under each section.

https://form-wizard-example.ddev.site:8243/admin/structure/types/manage/visa_application/form-display/section_1

Configure fields under each form mode.

It’s almost enough. However, Drupal still doesn’t really know about those sections, and so we have to explicitly register them.

The next ingredient to our recipe, is having our wizard page controller recognize which section needs to be rendered. Drupal 8 has made it quite elegant, and it requires only a few lines to get it. So now, based on the URL, Drupal serves us the node form - with the correct form mode.

Faux Required is Not Required

One of our goals, as often requested by clients, was to allow saving the application in a draft state. We can easily do it by not checking the “required” option on the field settings, but from a UX perspective - how could a user know the field would eventually be required? So we’ve decided to mark the “required” fields with the usual red asterisk, along with a message indicating they are able to save a draft.

As for the config of the field, there is a question: should the fields be marked as required, and on the sections be un-required? Or should it be the other way around? We have decided to make it optional, as it has the advantage that a site admin can edit a node – via the usual node edit form – in case of some troubleshooting, and won’t be required to fill in all the fields (don’t worry – we’ll cover the fact that only admins can access directly the node view/edit/delete in the “Access” section).

So to reconcile the opposing needs, we came up with a “faux-required” setting. I have entertained the idea of calling it a “non-required required” just to see how that goes, but yeah&mldr; Faux-required is a 3rd party setting, in field config lingo.

https://form-wizard-example.ddev.site:8243/admin/structure/types/manage/visa_application/fields/node.visa_application.field_first_name

Faux required setting in the field configuration page.

By itself it doesn’t do much. It’s just a way for us to build our custom code around it. In fact, we have a whole manager class that helps us manage the logic, and have a proper API to determine, for example, the status of a section – is a section empty, partially filled, or completed. To do that we basically ask Drupal to give us a list of all the faux-required fields that appear under a given Form mode.

Access & Application Status

We need to make sure only site-admins have direct access to the node, and we don’t want applicants to be able to edit the node directly. So we have a Route subscriber that redirects to our own access callback, which in turn, relies on our implementation of hook_node_access.

As for knowing in which status the application is, we have a single required field (really required, not faux-required) - a field called “Status” with New, Locked, Accepted and Rejected options. Those are probably the most basic ones, and I can easily imagine how they could be extended.

With this status, we can control when the form is editable by the user or disabled and without submit buttons. Having to write $form['#disabled'] = TRUE; and knowing it will disable any element on the form, is one of the prettiest parts form API.

Theming that Freaking Required Symbol

The subtitle says it all. Theming, like always and forever, is one of the hardest parts of the task. That is, unlike writing some API functions and having the feeling - “that’s the cleanest way possible,” with theme I often have the feeling of “it works, but I wonder if that’s the best way”. I guess the reason for this is that theming is indeed objectively hard to get “right.”

Anyway, with a bunch of form alters, preprocess and process functions callback we were able to tame the beast.

Field Groups

Many fields in different sections can make the job of site admins (or the ones responsible for processing or supporting the applications) quite hard. Field group is a nice way to mimic the structure of the sections both to the default node form, as well as the node view.

https://form-wizard-example.ddev.site:8243/node/1/edit

Wizard section appear as fieldsets in the regular node edit page.

Summary

Form modes in Drupal 8 are a very useful addition, and a cornerstone in our implementation of wizards. I encourage you to jump into the code of the example repository, and tinker with it. It has lots of comments, and if you ignore some of the ugly parts, you might find some pretty ones hidden there: Extending the complex inline entity form widget with custom logic to be more user friendly, use Form API states for the “other” option and getting that to work with faux-required, implementing Theme negotiator, our DDEV config and more&mldr;

And finally, if you spot something you have a better idea for, I’d love to get PRs!

Feb 19 2020
Feb 19

Our normally scheduled call to chat about all things Drupal and nonprofits will happen TOMORROW, Thursday, February 20, at 1pm ET / 10am PT. (Convert to your local time zone.)

This month, in addition to our usual free-for-all, we'll be talking about hosting on Pantheon. There has been a lot of discussion in the community and on the Drupal Slack #nonprofits channel about some of the pricing changes they have implemented. If you would like to discuss and contribute to the conversation, please join us.

We will also have an update on our community's plans for the upcoming Nonprofit Technology Conference (20NTC).

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

This free call is sponsored by NTEN.org but open to everyone.

REMINDER: New call-in information -- we're on Zoom now!

  • Join the call: https://zoom.us/j/308614035
    • Meeting ID: 308 614 035
    • One tap mobile
      • +16699006833,,308614035# US (San Jose)
      • +16465588656,,308614035# US (New York)
    • Dial by your location
      • +1 669 900 6833 US (San Jose)
      • +1 646 558 8656 US (New York)
  • Follow along on Google Docs: https://nten.org/drupal/notes
  • Follow along on Twitter: #npdrupal

View notes of previous months' calls.

Feb 19 2020
Feb 19

Content collaboration has long been table stakes for content management systems like WordPress and Drupal, but what about real-time peer-to-peer collaboration between editors who need direct interaction to work on their content? The WordPress Gutenberg team has been working with Tag1 Consulting and the community of Yjs, an open-source real-time collaboration framework, to enable collaborative editing on the Gutenberg editor. Currently an experimental feature that is available in a Gutenberg pull request, shared editing in Gutenberg portends an exciting future for editing use cases beyond just textual content.

Yjs is both network-agnostic and editor-agnostic, which means it can integrate with a variety of editors like ProseMirror, CodeMirror, Quill, and others. This represents substantial flexibility when it comes to the goals of WordPress to support collaborative editing and the potential for other CMSs like Drupal to begin exploring the prospect of shared editing out of the box. Though challenges remain to enable truly bonafide shared editing off the shelf in WordPress and Drupal installations, Gutenberg is brimming with possibility as the collaboration with Tag1 continues to bear significant fruit.

In this Tag1 Team Talks episode that undertakes a technical deep dive into how the WordPress community and Tag1 enabled collaborative editing in the Gutenberg editor, join Kevin Jahns (creator of Yjs and Real-Time Collaboration Systems Lead at Tag1), Michael Meyers (Managing Editor at Tag1), and your host Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for an exploration of how CMSs around the landscape can learn from Gutenberg's work to empower editors to collaborate in real-time in one of the most exciting new editorial experiences in the CMS world.

[embedded content]

Feb 19 2020
Feb 19

Why business should go for it?

  • Law. There are many lawsuits already and plaintiffs always win and get money. For example, Californian Bag’n Baggage was forced to pay $4,000 to the plaintiff who wasn’t capable to shop on their inaccessible website. Oftentimes, there is a special accessibility law in a particular country. Check the link to the government policies in the block Useful links.
  • Morals. It’s the inclusion century, let’s keep up with it.  Your users are many different unique people, so make sure that they have access to your services.
  • Lost profit. As long as you want to make money, you ought to remember that, according to World Health Organization, “about 15% of the world's population lives with some form of disability”. It’s 1,1 milliard of people - a huge market.

What businesses are the most vulnerable to be sued? 

According to 3PlayMedia, these industries are in danger of being sued:

  • retail
  • food service
  • travel
  • banking

If you have an app that considers users actively communicate with it - double-check the accessibility standards.

Accessibility and Drupal

Now that you’ve recognized yourself among those who need an adapted website, what technical solution should you go for?

We often advise using the Drupal CMS as it has many accessibility features out-of-the-box and the Drupal Community actively contribute new functionality. 

So what Drupal has?

  • Special markup in HTML, for example, the language tags
  • Images descriptions and alt descriptions
  • Built-in responsive images 
  • Headings can be used for page-level navigation
  • Controlled tab order that enables non-visual users and non-mouse users to access all the elements on the page

There are also contributed modules for Drupal 8. Check the link in the block Useful links.


Accessibility best practices


Here we would like to address some common-sense practices that you should take into account from the very first stage of development.

According to WCAG 2.1 (Web Content Accessibility Guidelines), your website or app should be perceivable, operable, understandable, robust.

There are 3 levels of accessibility: A, AA, AAA. Usually, implementing AA accessibility requirements is enough for the law. Below we will list some A and AA practices that are being violated the most from our experience.

1. All content should be perceivable

  • All non-text content should have a text equivalent if possible.
  • You should create captions for audio and video.
  • The reading sequence should be understandable and obvious, otherwise - programmatically determined.
  • It’s supposed to be a poor practice to rely on color, shape, sound to operate the content. Some people don’t recognize colors, some have hearing impairments, some cannot comprehend a way too much-complicated logic due to aging or mental diseases.
  • A contrast ratio of text and images should be at least 4.5:1.
  • Text size can be resized 2 times bigger without any assistive devices

2. The content should be operable

  • To cut a long story short, all functionality must be operable through a keyboard 
  • If there are time limits for some actions, they can be turned off (for example, a photo carousel)
  • No more than 3 flashes per second - don’t provoke falling sickness

3. The content should be understandable

  • Navigational mechanisms that are repeated throughout the website should occur in the same order
  • Components with the same functionality should be identified the same way throughout the website
  • If an error occurs, it should be identified to a user

4. The content should be robust and compatible with different assistive technologies. For example, elements do not contain duplicate attributes, and any IDs are unique. Attributes of user interface components can be programmatically determined.

Write and publish an accessibility statement on your website: here you may specify how exactly you improved accessibility and how you address this topic in general. Probably, you have an accessibility professional in your team or you hold accessibility audit frequently.

Find an elaborated description in the PDF in the drop-down banner.


Useful links

  1. Web Accessibility Laws & Policies
  2. Web Content Accessibility Guidelines (WCAG) 2.1
  3. Drupal 8 accessibility features
  4. Drupal 8 modules for extending accessibility
Feb 18 2020
Feb 18

Paragraphs is a new way of content creation. It allows the site builders to make things cleaner and can give more editing power to the end-users.
“Paragraphs” is a very popular module in drupal, used for handling content. It is similar to content fields and provides a wide range of options for designs, layout, and grouping of content as per the requirements.

Types of Drupal Paragraphs & Its Usage?

Paragraphs can be of different types. They can be anything from an image to a video, or a simple text to a configurable slideshow. 
Instead of putting all the data in one body field, we can create multiple Paragraphs Types with different structures. This allows the end user to choose between pre-defined Paragraphs Types. By using Paragraphs, we can create multiple featured Paragraphs, allowing the end users to pick the one most suitable for their needs. 
The Drupal Paragraphs module is easily manageable for non-technical users, while also offering Drupal developers the ability to control the appearance of the elements at the theme level.

How to use Drupal 8 Paragraphs module

1. Install and Enable Drupal Paragraphs module.
 

drupal paragraph module

Drupal Paragraphs module requires Entity Reference Revision module. To work with drupal paragraph module, install and enable Entity Reference Revision module.
 

drupal paragraph field


2. Create a new Paragraphs Type

  • To take the advantages of Drupal Paragraphs module, create at least one Paragraphs Types.
  • Navigate to Structure > Paragraphs types.
  • Click on “Add paragraph types”.
  • On the next page, there are three fields to be filled.  Label, Paragraph type icon and description. The Label field(mandatory), is the name given to the paragraph type created. If required, icon and the description of the paragraph can be given.
     
add-paragraph-module
  • After editing, click on “save and manage fields”.
  • In manage fields, click on “Add field”.
  • Here you can add more fields as per the requirement. These fields include text fields, image fields, boolean etc.. This is similar to adding fields in content type.
  • After adding the field, click on “save and continue”.
  • On clicking “save and continue”, you will be guided to the “Field settings” tab. For any of these fields, there are settings such as, maximum length and allowed number of values. This is useful to allow more than one value for some fields when it is required. 
paragraph-module
  • Click on “save field settings”.
  • In the next tab we can set the title for the field which is displayed when the new content is created.
  • Then click on “save settings”.
  • Now the field created can be seen inside Paragraphs Types.
manage field in paragraphs modules


3. Add Paragraphs to the content type:

  • Navigate to Structure > Content type. Choose the content type for which the created paragraph is required.
  • Go to “manage fields” of the content type and click “add field”.
  • To use Paragraphs, open the “Select a field type” dropdown list and select “Paragraph” under “Reference revisions”. After selecting “Paragraph” give a label name for the field which is used while creating the content. After labeling, click on “save and continue”.
  • On the next page, there are two settings “Type of item to reference” and “Allowed number of values”. “Type of item to reference” should be set to “Paragraph” and under “number of values”, it is better to set it to “Unlimited” so that we can value innumerable times. Click “Save field settings”.
type of the paragraphs-module
  • Clicking “Save field settings” will take us to the next tab where there are options to choose the paragraphs type to be used in this content type. If we want a particular paragraph type to be used, check on the paragraph that is required. Else, click ”Save settings” without checking the paragraph types. This will give dropdown during the content creation and we can use any paragraphs that are created.
     
reference-type
  • By clicking “Save settings” we can see the field with type entity reference revisions.

4. Adding contents to the content type having drupal paragraphs.

  • Go to Content > Add content, and choose the content type to which paragraph is added.
  • You will see a paragraph field with all the fields added to the paragraphs. There are two more options: They are “remove” and “Add (title of the field referred to the paragraph)”. To add multiple values of the same structure, click on add, and to remove paragraph, click on remove.
demo-paragraph-module

Features of Paragraphs module

  1. Allows the editor to create different structures on each page.
    If there are different structures on the same page or different pages, paragraphs can be used. For ex. There is an image with text on the top and slideshow on the bottom. We can use Paragraphs to make this less complicated.
  2. Allows the editor to change the order of the paragraphs.
    If there is a change in display, like there is an image on the top followed by title and description, and you want to change it to title to the top followed by image and description. Such changes can be done using paragraphs easily. 
    Go to “manage display” of the paragraphs used and change the order, which will change the display order of all the content wherever the paragraph is used.
  3. Paragraphs can be nested
    One paragraph field can be referred to in another paragraph field. While selecting field to paragraphs, select “Paragraph” under “Reference revisions” and select which paragraphs type you want to add.
     
Feb 18 2020
Feb 18

In today’s fast-paced digital environment, time is one of our most precious, if not the most precious, commodities. One would then figure that we would value it and manage it well, right? 

Well - not really. While most of us understand the importance of time and its limited amount, we somehow fail to put this understanding into practice and waste our time on distractions and procrastination rather than taking the reins and living the life we’ve always dreamt of living. 

Even if we dedicate our time to the things that matter, we quickly realize that there are just not enough hours in a day to cover all the important fields, i.e. work, family, hobbies and personal care. This is why good time management is even more important to a happy and fulfilled life.

In this post, I’ll further discuss the importance of time management and give you some tips on how to effectively manage your time and get more out of your life. By the end of the post, you’ll be one step closer to having full control over how and where you spend your time.

Why is time management so important?

If we don’t take control over how we spend our time, all areas of our lives suffer. Either we procrastinate by binge watching Netflix and endlessly scrolling through social media feeds, or we stretch ourselves too thin by trying to juggle everything - both cases can lead to health problems, i.e. depression/anxiety and burnout, respectively. 

That’s why it is crucial to, on the one hand, have clearly set goals and schedules, and, on the other, maintain a healthy work-life balance by not allowing your work to start seeping into your you-time. 

If we don’t make these plans and take care of keeping our work and personal life separate, we’re starting to damage our relationships and thus overall diminishing our quality of life. 

In the end, we and we alone own our time - and we must learn how to effectively manage it. Achieving this, we’ll be more efficient and productive, and have more opportunities in life while greatly reducing stress and avoiding a poor professional reputation. 

It’s not something new

The science behind time management isn’t some groundbreaking new trend; it was a popular topic of Ancient Roman philosophers which then resurged at the end of the 19th century with the industrial era after being sidelined during the Middle Ages. I doubt anyone today could’ve put it as nicely as Seneca did over two millennia ago:

Then the start of the 20th century and the concurrent rise of capitalism brought new advances to time management. Frederick W. Taylor, the first “time management guru”, was able to increase production from 12.5 to 50 tonnes of steel per day - but, seeing how he used this much higher figure as the new daily standard, this wasn’t exactly beneficial to the workers.

Just a few decades later, in 1930, British economist John Maynard Keynes made the prediction that the work week would have been reduced to only 15 hours in the following hundred years. Now, a mere 10 years until the end of that hypothetical timeframe, it is clear that this is not the case - all the more reason, then, to become the master of your time.

How to effectively manage your time

There’s an abundance of time management tips out there; trying to follow all of them right from the get-go, however, would likely just have the adverse effect and cause you even more time-related issues. 

So, as a general rule of thumb, remember that “less is more”, but also keep in mind that not everyone is the same and that different approaches work for different people. Some prefer following a set of just a few guidelines, while others would be left immobilized without at least 20. 

Here are some tips that have helped me personally and can serve as a great starting point:

  • Set goals the right way,
  • find a good time management system and/or tool,
  • audit your time for seven days straight,
  • spend your morning on MITs (most important tasks),
  • follow the 80-20 rule (the Pareto principle),
  • instill keystone habits into your life,
  • schedule email response times,
  • eliminate bad habits, or at least reduce the amount of time spent on them.

Once you get the hang of it, you can start working even more intently on mastering your time:

  • Take frequent breaks while working,
  • meditate or exercise every morning,
  • at the end of each day, make a to-do list for the next day,
  • find inspiration when you’re feeling lackluster,
  • get a mentor who can guide and support you,
  • turn off social media notifications,
  • and, finally - declutter and organize.

In the end, the most important thing is to incorporate these rules into your routine. The results likely won’t be visible immediately, so it’s important to persevere and not throw in the towel immediately. Once you internalize them and make them an integral part of your life, they’ll become intuitive and you’ll really start seeing the benefits of following them.

Real-life example of the importance of valuing time

Some time ago I was present for a call between a client and one of our developers. The client is from overseas, which means quite a big time difference. It was supposed to be a short, 15 minute-ish meeting intended to keep all sides updated on the progress of the project that week.

Unfortunately, it quickly became apparent that the client’s project manager wasn’t adequately prepared for the meeting - they were trying to get answers to our developer’s questions on the fly by contacting their CTO, which stretched the meeting into 45 rather than the intended 15 minutes. 

Worst of all, the developer did not get any of her questions answered, while both of us had to prolong our workday to accommodate the call while the project manager was scrambling to find answers in-house. 

This could easily have been avoided with proper preparation: you should always have a predefined meeting agenda, which enables you to go through the issues quickly. Then send a follow-up email to everyone involved with a recap of the meeting and steps to go forward. Even saving just 30 minutes is something most people will greatly appreciate.

In conclusion

I think we can all agree on how important time management is to all aspects of our lives. If you were not convinced before, or just never really knew how to get started, I hope this post has helped you realize this importance and put this mindset into practice. 

In case you want to learn more about and really dive deep into managing your time, I highly recommend Nir Eyal’s excellent book Indistractable which will help you tackle one of the major obstacles to effective time management - distraction.

If, however, you’re looking for something shorter, this Harvard Business Review article by Erich C. Dierdorff is another great resource with useful insights. 

Time is your most valuable asset, and those who understand and live by this are primed for a successful and happy life. I wish you the best of luck on your journey of mastering your time!

If you'd like to work with experienced developers who always value their clients' time, reach out to us and we'll craft the perfect team for your project's needs. 

Feb 18 2020
Feb 18

In the first part of our two-part blog series on Drush 10, we covered the fascinating history of Drush and how it came to become one of the most successful projects in the Drupal ecosystem. After all, many of us know many of the most common Drush commands by heart, and it’s difficult to imagine a world without Drush when it comes to Drupal’s developer experience. Coming on the heels of Drupal 8.8, Drush 10 introduces a variety of new questions about the future of Drush, even as it extends Drush’s robustness many years into the future.

Your correspondent (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) had the unique opportunity to discuss Drush’s past, present, and future with Drush maintainer Moshe Weitzman (Senior Technical Architect at Tag1), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), and Michael Meyers (Managing Director at Tag1), as part of the Tag1 Team Talks series at Tag1 Consulting, our biweekly webinar and podcast series. In the conclusion to this two-part blog series, we dig into what’s new in Drush 10, what you should consider if you’re making a choice between Drush and Drupal Console, and what the future for Drush might hold in store for Drupal’s first CLI.

What’s new in Drush 10

Drush 10 is the version of Drush optimized for use with Drupal 8.8. It embraces certain new configuration features available as part of the upcoming minor release of Drupal, including the Exclude and Transform APIs as well as config-split in core. Nevertheless, the maintainers emphasize that the focus of Drush 10 was never on new additive features; instead they endeavored to remove a decade’s worth of code from Drush and prepare it for many years to come.

To illustrate this fact, consider that Drush 9 was a combination of both old APIs from prior versions of Drush and all-new APIs that Drush’s maintainers implemented to modernize Drush’s commands. Therefore, while Drush 9 commands generally make use of the newly available APIs, if you call a site with Drush 9 installed from Drush 8, it will traverse all of the old APIs. This was a deliberate decision by Drush’s maintainers in order to allow users a year to upgrade their commands and to continue to interoperate with older versions. As a result of the removals of these older approaches, Drush 10 is extremely lean and extremely clean, and it interoperates with sites having Drush 9 but not those with earlier versions.

How should developers in the Drupal community adopt Drush 10? Moshe recommends that users upgrade at their earliest convenience through Composer, as Drush’s maintainers will be able to offer the best support to those on Drush 10.

Why Drush over Drupal Console?

One key question that surfaces frequently concerning Drupal’s command-line ecosystem is the distinction between Drush and a similar project, Drupal Console, and when to use one over the other. Though Drush and Drupal Console accomplish a similar set of tasks and share similar architectures because they both depend on Symfony Console, there are still quite a few salient differences that many developers will wish to take into account as they select a command-line interface to use with Drupal.

Commands, for instance, are one area where Drush and Drupal Console diverge. Command authors will find that commands are written quite differently. Drush leverages an annotated command layer on top of Symfony Console where developers employ annotations to write new commands. Drupal Console instead utilizes Symfony Console’s approach directly, with a few methods attached to each command. However, this is a minor consideration, as there is little to no difference in the CLI’s functionality, and it is merely a stylistic preference.

Drush and Drupal Console also differ significantly in their approaches to testing. Whereas Drupal Console performs unit testing, Drush prefers functional testing, with a full copy of both Drupal and Drush in their test suite. All Drush CLI commands are run on a real, fully functional Drupal site, whereas Drupal Console opts to leverage more mocking. There are admittedly many advantages to both approaches. But perhaps the most important distinction is of a less technical variety: Drupal Console has seen a bit less contribution activity as of late than Drush, which is an important factor to consider when choosing a CLI.

The future of Drush: Drush in core?

Though Moshe and Greg have committed themselves to maintaining and supporting Drush in the future, there are doubtlessly many questions about Drush’s roadmap that will influence decision-making around Drupal.

Drush’s inclusion in core has long been a key talking point with a variety of potential resolutions. Drupal already has two CLI commands in it unrelated to Drush, namely the site-install and quick-start commands, which are seldom used as they have limited coverage of key use cases. For instance, site-install only installs Drupal successfully on SQLite databases and lacks consideration for configuration. Drush’s maintainers are keen on considering a version of Drush in core, and an active discussion is ongoing.

Moreover, now that the starter template for Drupal projects is now deprecated in favor of core-recommended, there is an opportunity for Drush 10 to serve as a key dependency in those starter templates, initially as a suggested dependency and eventually as a required one. Some of the key commands that a hypothetical Drush in core would encompass include enabling and uninstalling modules as well as clearing caches and logging in as a user. In the not-too-distant future, a Drupal user could start a Drupal project and immediately have Drush and all its commands available from the very outset.

Conclusion

Drush 10 is an inflection point not only in the history of Drupal but in how Drupal developers interact with Drupal on a daily basis. Thanks to its leaner, faster state, Drush 10 marks a new era for remote interactions with Drupal. Because Drush 10 has tracked closely to the Drupal 8 development cycle, many of the core changes present in Drupal 8.8 are reflected in Drush 10, and the ongoing discussion surrounding the potential of Drush in core will doubtlessly continue apace.

For many of us in the Drupal community, Drush is more than a cherished tool; it is one of the primary entry points into Drupal development. With the help of your contributions, Drush can reach even greater heights. Moshe recommends that new contributors get started with improving Drush’s documentation and content concerning Drush, whether it comes in the form of blog posts or step-by-step tutorials that make learners’ experiences much better. The Drush maintainers are always happy to link to compelling content about Drush, to address bugs and issues in Drush’s issue queue, and to offer co-maintainership to prolific contributors.

While this was an exhaustive look at Drush 10, it by no means includes all of the insights we gathered from Moshe, and we at Tag1 Consulting encourage you to check out our recent Tag1 Team Talk about Drush 10 to learn even more about Drush’s past, present, and future.

Special thanks to Fabian Franz, Michael Meyers, and Moshe Weitzman for their feedback during the writing process.

Photo by Bill Oxford on Unsplash.com

Feb 17 2020
Feb 17

I was recently reading an interesting blog post concerning web accessibility. It seemed insightful and informative, until I came upon a link to “download a PDF …” for more information. 

But wait. These PDFs were not accessible.

I shouldn’t have been surprised. This kind of thing happens all the time. As the concept of web accessibility enters the mainstream as a “must-have,” the bigger picture is often getting missed.

Free training: Making PDFs Web Accessible

The PDF Problem

People are sometimes reluctant to accept that PDF’s are included in the scope of web accessibility requirements. It’s not uncommon for organizations to have hundreds of inaccessible PDFs on a site, or to have multiple links off to inaccessible PDFs. The surface of this challenge has barely begun to be scratched.

It’s true that PDFs can be remediated and made accessible, and WCAG 2.1 provides steps for creating accessible PDFs. Generally speaking, though, the process of making PDFs accessible is time-consuming and cumbersome. In the current accessibility climate, the most efficient approach is a mindset shift away from PDFs as the standard for document saving, and toward a realization that properly structured HTML files are the most accessible document type.

PDF Proliferation

When marketing an event online or promoting a product, a PDF is viewed as the go-to solution for saving a file. Organizations design and link offsite to PDFs that serve as digital posters for downloading and printing. 

It’s not uncommon for trifold brochures to be saved as a PDF and posted to a site -- not a good UX and abysmal for accessibility. 

PDF’s are also relied upon in organizational governance. Meeting notes or agendas tend to be created as Word docs and then saved as PDFs.Governments, healthcare providers, corporations, educational institutions, and large organizations of every kind, have hundreds if not thousands of PDFs on their site that they are just now realizing need to be remediated for ADA accessibility. 

Automation: Not the Answer

Automated remediation tools serve as only a partial solution, at best. For one thing, automated tools cannot be counted on to accurately create alt text for images. That’s a task that will always call for human judgment. 

A bigger issue is the fact that content on a WCAG compliant web page is required to be structured within the H1 to H6 HTML hierarchy of headings. Headings on a PDF promotional page or product announcement cannot be counted on to follow any particular logic that either a screen reader or automated remediation tool can make sense of. 

PDF Evaluation and Prioritization

An accessibility audit on a site that includes hundreds of PDFs functions akin to triage, with each PDF being evaluated as necessary or not for remaining on the site, followed by a strategic evaluation as to whether it makes more sense to remediate the PDF for WCAG compliance or convert it to an HTML file.  

This exercise proves to be strategically valuable for many reasons. I’ve yet to encounter a website that does not benefit from an overall inventory and focus on clearing out the “clutter.” 

As is the case with all initiatives designed to ensure WCAG compliance, inventory and auditing of PDFs for accessibility sets the stage for more sustainable web strategies, greater inclusivity, and better UX for all.

There’s much more to learn. Please join me next month for our upcoming training where we will cover the PDF accessibility requirements within the broader scope of WCAG compliance.

Register NOW

Making PDFs Web Accessible
Wednesday, March 18, 12 p.m. - 1 p.m. CST


 

Feb 15 2020
Feb 15

This month for SC DUG I gave a talk on the importance of self-directed learning for professional development as a developer — or really any other modern career. It was an extension and revision of my December blog post on the same topic. The presentation runs a hair over 30 minutes, and parts of the discussion are included as well.

[embedded content]

We frequently use these presentations to practice new presentations, try out heavily revised versions, and test out new ideas with a friendly audience. If you want to see a polished version checkout our group members’ talks at camps and cons. So if some of the content of these videos seems a bit rough please understand we are all learning all the time and we are open to constructive feedback.

If you would like to join us please check out our up coming events on MeetUp for meeting times, locations, and remote connection information.

Feb 14 2020
Feb 14

When creating an e-commerce platform for a given industry, one needs to adapt the system to specific types of products. Every product type has different characteristics, e.g. size, colour, etc. Check out how easily you can customise Drupal Commerce to sell any type of product.

We are happy to tell you how to easily add attributes to products for several selected industries. We are a Drupal agency and we deal with it every day.

Attributes are the characteristics of given product types. For example, when you sell your own original T-shirts, thanks to the attributes you do not have to add separate products when you want to add another shirt size or colour. You create one product, add a size and colour attribute, and create other versions of the same product.

Thanks to this, the customer can easily add to the basket the product variant they are interested in, without having to switch to another subpage with a different product.

Adding Product Variant E-commerce Platform

Product attributes in Drupal Commerce

This post is a continuation of the series covering the Commerce module used to add an e-commerce platform to Drupal Previous part from the basic Commerce configuration.

You add new attributes to the product variation. The product variation is associated with a reference to the product. Thanks to this, you create one product, e.g. a T-shirt with the Droptica logo, and you add variations with different attributes to it. The attribute can be the T-shirt's colour or size. Every variation can also have a different price.

Start by creating a new type of product – T-shirt
From the admin menu Commerce → Configuration → Products → Product types

E-commerce creating a new type of product

Add a new product.

→ enter label
→ check that the product should have many variations
→ Product variation type – by checking Create new, a new variation type will be created automatically with the same name as the product type, in this case – T-shirt. You can also choose an already existing variation type.

product variation type

If you set Create new in the variation field, after saving the new product type, by going to 
Commerce → Configuration → Products → Product variation types you will see a new variation type.

new variation type

Product attributes for a T-shirt/clothing store

Two typical attributes for this type of store are colour and size.

Colour.

The standard solution for colour choice is to create a linked colour, where – after clicking it – the appropriate variation of the product loads.

solution for colour

Drupal Commerce lets you achieve this effect very simply.

The list of attributes and the option of creating them is available in
Commerce → Product Attributes

Lista atrybutów

Add a new attribute by clicking the Add product attribute button

add its name – Colour
element type – for now, set the Select list,
and the product variation, to which it is to be linked – T-shirt,

Add product attribute button

After saving, add colour values as you like.

add colour values

Now create a new T-shirt product and add some variations to it to see how the attributes work. Set different prices for different variations – you will see then that after changing the attribute the price will change automatically.

The colour attribute can be found in the product variation creation form.

colour attribute

When you go to the main product page, the colour selection list will be visible. 

the colour selection list

Change a selection list to links with colours

To achieve this effect, you need to add a new module – Colour Field

After enabling the module, add a new field to the colour attribute.

You can do it in the same way as you would for any other entity in Drupal.

Go to Commerce → Product Attributes 

And choose the Manage fields link

Product attributes

Add a new Colour field

Colour field

Save the settings

color settings for color

The next step in the configuration is to change the display of the colour field in the tab for managing the appearance of the form, as well as the appearance of the field when the product is viewed.

Managing the form appearance

Set for both fields to be visible. This makes it possible to set the name of the colour and its HEX value when editing the attribute.

manage form display

Managing the display.

In this case, you leave only the colour display and hide its name. In the format set – Colour switch. 

Thanks to this, coloured squares with colours to choose from will appear. By clicking the settings cogwheel sign you can change the size of these squares or replace them with ovals. 

manage display

The last step is to change the settings in the attribute itself.

Go to its edit options.

Change the Element type to Rendered attribute and add hex values for individual colours. 

editor color

After saving the settings on the page, the products – instead of an attributes/selection list – will be linked coloured squares.

Attributes for an electronics store

Laptops are one of the products found in electronics stores.

Typical attributes for this product type are:

  • pre-installed operating system
  • RAM amount
  • SSD capacity

and some others, but for the purposes of this post, I will show you how to add these three.

Attributes are added in the same way as in the previous example concerning a T-shirt store.

The result of the configuration will be:

  • operating system selection list
  • clickable RAM amounts to choose from
  • radio buttons with SSD capacity selection

Image laptop

I assume that the store has already added the product type and the product variation – Laptop

Configuration for the operating system attribute.

the operating system attribute

RAM attribute configuration

RAM attribute configuration

SSD capacity attribute configuration

SSD capacity attribute configuration

Summary

As you can see, attributes can be added to the products in a Drupal Commerce-based store in a very quick and easy way. By implementing them, you will help the potential customers find the right product faster and give yourself a chance to increase the turnover.

Feb 14 2020
Feb 14

We can’t predict the Drupal core security update releases because security updates can arrive at any time and we need to keep our sites updated. People from other parts of the world stay awake during security updates.

Let’s look at the numerous sites built for small businesses today. If a site maintainer is present to manage these updates then there’s no problem at all. But what if there is no maintainer?

Many a time people have questions like:

  1. “Has anyone built the script which will download, backup, and install the updates?”
  2. “Why upgrade, with all security updates which pop up? It seems like I need to upgrade every month.”

New updates arrive frequently. It is a part of the software world be it open source or commercial. The Drupal security team is an awesome team that provides security releases as quickly as possible rather than leaving you with an insecure site. 

There have been talks since the past few years about automating the Drupal core updates, thus a Drupal core strategic initiative was formed “Automatic Updates”. If successful, it would secure a lot of vulnerable Drupal sites. 

Currently, the Automatic Update feature is being developed as a contributed module and eventually, it will be shipped into Drupal core as an experiment and finally if all goes well it could land as a new Drupal core feature. 

Since the work for Automatic Updates is so vast, tasks are being worked in phases. 

Currently, Automatic Updates is divided into the following two phases out of which, phase I is now stable.:

Objectives of Phase I

  • Providing a JSON feed of Drupal PSAs from Drupal.org

  • Displaying PSAs in the Drupal admin interface

  • Providing an extensible update readiness check system

  • Generating update packages from Drupal.org

  • Securing the update packages with a signing system

  • Applying the updates, manually or automatically, with roll-back

In this first phase, the Automatic Updates module includes the Public Service Announcement and Readiness Check features and can apply In-Place Updates manually or on cron. Updates that contain database updates will cause a rollback of the update.

Objectives of Phase II

  • Providing an A/B front-end controller for more robust testing/roll-back features

  • Supporting contributed module automatic updates

  • Supporting composer-based site installs

The goal is to implement a secure system for automatically installing updates in Drupal, lowering the total cost of ownership of maintaining a Drupal site, and improving the security of Drupal sites.

Public service announcements (PSAs)

Announcements for highly critical security releases for core and contrib modules are done infrequently. When a PSA is released, site owners should review their sites to verify if they are up-to-date with the latest releases and that the site is in a good shape to update quickly once the fixes are provided to the community.

Drupal.org provides a JSON feed of Drupal Public Security Announcements to be consumed by the automatic updates module.

That feed includes values for the following: 

  • Project type (core, module, theme, etc) 

  • Project: the short name of the project the PSA is for

  • Title: The title of the PSA

  • Is_psa: The flag which indicates that the post is a PSA (and not another kind of Security Advisory) 

  • Link: The link to the full PSA on drupal.org

  • Insecure: Metadata about what versions of the affected project are known insecure

  • pubDate: The date the PSA was published

Update Checklist

List all checklists which are checked whether a site is ready for an upgrade or not. 

Eg: pending hook updates, changes made in drupal core files. Etc

Demonstrating Automatic Updates

Step 1: First, check if the update is available or not

Drupal 9 automatic updates

Step 2: Configuring Automatic Updates

Drupal 9 automatic updates

Step 3: Now examine the PSAs and Readiness checks in the configurations

Click on ‘Manually run the readiness checks link’ under READINESS CHECKS.

Drupal 9 automatic updates

Step 4: Under Errors found of the status report page, you can see the checks failed message with reasons

drupal 9 automatic updates

 

Drupal 9 automatic updates

Wish to contribute to Automatic Updates?

Feb 14 2020
Feb 14

Consider a small-mid size Drupal Project. Usually what happens is that once development is complete, sites (Drupal or Wordpress or any other framework) are left forgotten. This leaves the site vulnerable to attack, especially when a new Drupal security release is announced as it exposes the vulnerability publicly. It is good if a site is properly maintained & updated at regular intervals. But not at all recommended if left unattended.

Many a time people have questions like:

  • “Has anyone built the script which will download, backup, and install the updates?”
  • “Why upgrade, with all security updates which pop up? It seems like I need to upgrade every month.”

What if we had a process where Drupal could automatically update itself removing the vulnerability altogether. 

There have been talks since the past few years about automating the Drupal core updates, thus a Drupal core strategic initiative was formed “Automatic Updates”. If successful, it would secure a lot of vulnerable Drupal sites. 

Currently, the Automatic Update feature is being developed as a contributed module and eventually, it will be shipped into Drupal core as an experiment and finally if all goes well it could land as a new Drupal core feature. 

Since the work for Automatic Updates is so vast, tasks are being worked in phases. Currently, Automatic Updates is divided into the following two phases out of which, phase I is now stable.

Objectives of Phase I

  • Providing a JSON feed of Drupal Public service announcements from Drupal.org

  • Displaying PSAs in the Drupal admin interface

  • Providing an extensible update readiness check system

  • Generating update packages from Drupal.org

  • Securing the update packages with a signing system

  • Applying the updates, manually or automatically, with roll-back

In this first phase, the Automatic Updates module includes the Public Service Announcement and Readiness Check features and can apply In-Place Updates manually or on cron. Updates that contain database updates will cause a rollback of the update.

Objectives of Phase II

  • Providing an A/B front-end controller for more robust testing/roll-back features

  • Supporting contributed module automatic updates

  • Supporting composer-based site installs

The goal is to implement a secure system for automatically installing updates in Drupal, lowering the total cost of ownership of maintaining a Drupal site, and improving the security of Drupal sites.

Public service announcements (PSAs)

Announcements for highly critical security releases for core and contrib modules are done infrequently. When a PSA is released, site owners should review their sites to verify they are up to date with the latest releases and the site is in a good state to quickly update once the fixes are provided to the community.

Drupal.org provides a JSON feed of Drupal Public Security Announcements to be consumed by the automatic updates module.

That feed includes values for the following: 

  • type (core, module, theme, etc)

  • project: the short name of the project the PSA is for

  • title: The title of the PSA

  • is_psa: The flag which indicates that the post is a PSA (and not another kind of Security Advisory) 

  • link: The link to the full PSA on drupal.org

  • insecure: Metadata about what versions of the affected project are known insecure

  • pubDate: The date the PSA was published

Readiness Checks

Below are possible points that should be checked to decide whether a site is ready for an upgrade or not. 

Sites can’t receive automatic updates in case 

  • If they don’t have sufficient disk space.

  • If sites are placed on a read-only file system.

  • If sites have un-run database updates(Pending database updates)

  • Any modifications made to the Drupal core source code. 

When PSA is released and the site is failing readiness checks, it is important to resolve the readiness issues so the site can quickly be updated.

 

A quick look at how to use Automatic Updates

Step 1: First, check if the update is available or not by going to “Reports » Available Updates” from the administration pages.

Drupal 9 automatic updates

Step 2: Install & Configuration of automatic updates contrib module. Go to “Config » System » Automatic Updates”.

Drupal 9 automatic updates

Step 3: Now check the PSAs and Readiness checks in the configurations. Notice the PSA shown in the messages section.

PSA notification

 

Step 4: Click on the “Manually run the readiness checks” link under READINESS CHECKS.

  If the Readiness check has failed a list of error failed checks are shown in messages. These error messages with reasons can also be found under “Errors found” of the status report page.

 

drupal 9 automatic updates

 

Drupal 9 automatic updates

Step 5: If Readiness check shows “No issues found. Your site is ready for automatic updates”. It means our site is ready for an automatic upgrade.

Readiness check done

Step 6: Click on the “manually update now” link inside the “Experimental” section to upgrade the site.

update successful

drupal version updated

Wish to contribute to Automatic Updates?

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web