emGee Software Solutions Custom Database Applications

Share this

Drupal CMS

Issue 439

TheWeeklyDrop - Thu, 05/28/2020 - 01:59
Issue 439 - May, 28th 2020
Categories: Drupal CMS

Should You Upgrade from Drupal 7 to Drupal 9?

Lullabot - Wed, 05/27/2020 - 07:37

Drupal 7, our much-loved CMS that was released in 2011, is nearing the end of its life. No, that's not hyperbole; Drupal 7 is scheduled to reach end-of-life in November 2021. Drupal 8 has been out for a few years, but at the time of this writing, Drupal core usage statistics indicate that only about 350,000 of the more than 1.1 million reporting Drupal core sites are using Drupal 8.x. Over 730,000 of those sites are still using Drupal 7. If your site is one of those 730,000 still on Drupal 7, should you upgrade to Drupal 9? 

Drupal 7 is coming to an end

Whether or not you choose to upgrade to Drupal 9, it's time to acknowledge one very important truth: Drupal 7 is coming to an end. After a decade in service, Drupal 7 will stop receiving official community support in November 2021, and the Drupal Association will stop supporting Drupal 7 on Drupal.org. Automated testing for Drupal 7 will stop being supported via Drupal.org, and Drupal 7 will no longer receive official security support.

Beyond the loss of support for Drupal 7 core, there is less focus on the Drupal 7 version of many contributed modules. Some of them are quite stable and may work well into the future, but others are more neglected. The reality is that once module maintainers have moved their own sites to Drupal 8 or Drupal 9, they may lose interest in spending the time it takes to keep a Drupal 7 version of their code up to date.

Upgrading from Drupal 7 is harder than from Drupal 8

Drupal 8 was released in November 2015. When the Drupal Association announced Drupal 9, they discussed a big change coming to the Drupal ecosystem: Major Drupal version changes would no longer be a substantial replatforming effort, but would instead be a continuation of an iterative development process. In practice, this means that Drupal 9 is built in Drupal 8, using deprecations and optional updated dependencies. The result is that upgrading from Drupal 8 to Drupal 9 is just an iterative change from the final Drupal 8 version. Drupal 9.0 involves the removal of some deprecated code, but introduces no new features; it's a continuation of the fully-tested, stable codebase that is Drupal 8. Basically, Drupal 9.0 is just another release of Drupal 8. 

On the other hand, Drupal 7 has significant differences from Drupal 8 and 9. The jump from Drupal 7 to Drupal 9 can be an enormous undertaking. Third-party libraries replaced huge swaths of custom Drupal code. The procedural code was reworked into object-oriented code. The code changes were massive. Upgrading a Drupal 7 site to Drupal 9 will bring it into the new upgrade paradigm, but there's quite a bit of work to do to get there.  So the question of whether, and how, to make the jump to Drupal 9 is more complicated.

That leaves Drupal 7 sites with a handful of options:

We’ll focus on the first option in this article, and the others later.

Benefits of Drupal 8 and 9

While Drupal 8 is a big change from Drupal 7, it features many developmental and editorial improvements that pay dividends for users who are willing to take the time to learn how to use them.

Lots of contributed module functionality now in core

One of the biggest upsides of Drupal 8 and Drupal 9 versus Drupal 7 is the fact that many of the things that require contributed modules in Drupal 7 are just baked into core now. This includes things like:

  • Layout Builder provides the ability to create customized page layouts that Panels or Display Suite provide in Drupal 7.
  • Blocks have been re-imagined to be fieldable and re-usable, things that require contributed modules like Bean in Drupal 7.
  • You don’t need to install a contributed module and third-party libraries to get a WYSIWYG editor; it’s built into core.
  • Views is in core, and most of the custom lists in core are now fully customizable views.
  • Media handling is not an add-on. It’s an integral feature. To get similar functionality in Drupal 7, you need a half dozen or more complicated contributed Media framework modules, each of which might require quite a bit of additional configuration. You can get a pretty decent media handling experience in Drupal 9 by doing nothing more than enabling the Media and Media Library modules and using the default configuration.
  • Web services are built in, like JSON:API.
  • Customized editorial workflows are now available in core, providing functionality that would have required contributed modules like Workbench Moderation or Workflow.

That’s just to mention a few features; there are many things in core that would require contributed modules in Drupal 7.

Maintaining this functionality is simplified by having more of it in core. Managing fewer contributed modules simplifies the process of keeping them in sync as you update versions and dependencies, and trying to decide what to do when you get a conflict or something breaks. As Drupal 7 development falls by the wayside, this is even more important, as it could take months - or longer - to get updates to Drupal 7 contributed modules, until they’re no longer supported at all after end-of-life.

Having these solutions in core means everyone is using the same solution, instead of splintering developer focus in different directions. And having them in core means they’re well-tested and maintained.

Composer gets us off the island

One of the changes to Drupal since the Drupal 7 release is that Drupal 8 and 9 extensively use third party libraries like Symfony for important functionality, instead of relying on custom Drupal-specific code for everything. That move “off the island” has introduced a need to manage Drupal’s dependencies on those libraries. This is handled with yet another tool, a package called Composer.

You need to manage the dependencies of these new top-level third-party libraries, but each of these libraries has dependencies on other libraries, which have dependencies on more libraries, creating a confusing spiderweb of dependencies and requirements and potential conflicts. Dependency management quickly becomes a maintenance nightmare. It’s a new tool to learn, but Composer is a great dependency manager. Taking the time to learn Composer gives developers a powerful new tool to deal with dependency management.

Composer can do other things. If you add cweagans/composer-patches, it’s also a very useful tool for managing patches from Drupal.org. You can add a patches section to composer.json with links to the patches you want to watch. Composer will automatically apply the patches, and your composer.json file becomes a self-documenting record of the patches in use.

You can read more about Composer in another Lullabot article: Drupal 8 Composer Best Practices.

No more Features for configuration management

In Drupal 7, many sites deploy configuration using the Features module. Depending on who you ask, using Features for configuration management could be regarded as a good thing or a bad thing. Many developers maintain that Drupal 8 (and therefore Drupal 9’s) Configuration Management system, which allows database configuration to be exported to YML files, is much easier than the Drupal 7 Features system. As with Composer, it takes time to learn, but it enables developers who understand the system to accomplish more with less effort. 

Secure PHP support

Drupal 7 sites could be running on deprecated versions of PHP, even as old as 5.3. Drupal 7 sites should already have moved to PHP 7, but could still be running on older, very outdated and insecure, versions of PHP. Drupal 7 currently works with PHP 7.3 but has problems with PHP 7.4. As PHP continues to progress and deprecate older versions, you may find that you can no longer keep your Drupal 7 site running on a secure version of PHP. Drupal 8 runs on PHP 7.0+, and Drupal 9 runs on and requires a minimum of PHP 7.3, so both provide a better window of compatibility with secure PHP versions.

Resistance to migrating to Drupal 8 and 9

There are some reasons why sites delay making this move:

Lack of Drupal 8 versions of Drupal 7 contributed modules

Early in Drupal 8’s release cycle, one of the big complaints about Drupal 8 was that many Drupal 7 contributed modules no longer worked in D8. It did take time for some contributed modules to be updated to Drupal 8. However, many Drupal 7 contributed modules were no longer needed in Drupal 8, because the functionality they provided is now a part of Drupal 8 core.

If you haven’t checked the state of Drupal contributed modules in the last few years, take a look at what’s now available for Drupal 8. You can check the Drupal 8 Contrib Porting Tracker to find the status of popular Drupal 7 modules and see whether they’ve gotten a Drupal 8 stable release. You may find that modules that were missing early on are now available, or that you no longer need some contributed modules because that functionality is now managed in another way.

More importantly, you don’t have to worry about lack of parity in Drupal 8 contributed modules when Drupal 9 is released; as long as the Drupal 8 module in question isn’t built on deprecated code, everything that works in 8.x should continue to work in Drupal 9. And if a D8 module is built on deprecated code, the maintainer should be aware of it. All the code that is being removed in Drupal 9 has already been deprecated in Drupal 8.8, so there won’t be any surprises for module or site maintainers.

Maintenance overhead for small teams

With the introduction of Drupal 8 and Drupal 9, the new paradigm in Drupal development is more frequent, smaller releases. This mirrors a larger trend in software development, where iterative development means frameworks make more frequent releases, and consequently, those releases aren’t supported as long. 

This means you need to commit to keeping your site current with the latest releases. If you’re part of a small team managing a large Drupal site, you may simply not have the bandwidth or expertise to keep up with updates. 

There are some tools to make it easier to keep a site current. There is an Automatic Updates module that might be helpful for small sites. That module is a work in progress, and it does not yet support contributed module updates or composer based site installs. These are planned for Phase 2. But this is a project to keep an eye on. 

You can manage updates yourself using Composer and Drush. Sites of any size can also use  DependaBot, a service that creates automatic pull requests with updates. 

And of course, some web hosts and most Drupal vendors will provide update services for a fee and just take care of this for you.

The new way of doing things is harder

The final complaint that has prevented many Drupal 7 sites from upgrading to Drupal 8 and Drupal 9 is that the new way of doing things is harder. Or, if not harder, different. There’s a lot to unpack here. In some cases, this reflects resistance to learning and using new tools. In other cases, it may be that long-time Drupal developers have a hard time learning new paradigms. Another option may be that developers are simply not interested in learning a new stack, and may no longer want to develop in new versions of Drupal. 

Drupal 6 and 7 have a lot of “Drupalisms,” Drupal-specific, custom ways of doing things, so developers who have been deep into Drupal for a long time may feel the number of things to re-learn is overwhelming. Fortunately, the “new” things, such as Composer, Twig, and PHPUnit are used by other PHP projects, so there is a lot that Drupal 7 developers can learn that will be useful if they work on a Symfony or Laravel project, for example.

Developing for Drupal 8 and Drupal 9 is certainly different compared to Drupal 7 and older versions. Some developers may choose this as a turning point to shift gears into other career paths, developing for a different stack, or making a more substantial change. But with the Drupal 7 end-of-life approaching, developers who don’t want to move to Drupal 8 and Drupal 9 must make some move, just as Drupal 7 sites must move to a modern platform.

Security considerations

In today's world, enterprises have a responsibility to protect their website users' personal data - and they face costly liability considerations if they don't. For many organizations, this means website security is a looming and ongoing concern. It's common for enterprise security policies to require that organizations only use services with ongoing security support. Relative to the Drupal 9 upgrade, this means that many enterprises can't continue to maintain Drupal 7 websites after they stop receiving security support.

But what does “no more security support” actually mean?

When Drupal 7 reaches end-of-life, the Drupal community at large will no longer provide “official” security updates or bug fixes. The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 sites. Automated or manual processes that you currently use to update your sites may no longer work.

There is a bit of nuance to the lack of security support, however. The Drupal 7 ES program involves partnering with a Drupal Association-vetted vendor and assuring that the vendor is coordinating responsible disclosure of security issues and fixes while publicly sharing the work toward those fixes.

Practically speaking, this means that even if you’re not partnered with an ES vendor, you can still get security patches for your site. However, websites using modules that aren’t actively supported by ES vendors won’t have the benefit of a partner to hunt down and fix issues with those modules, security, or otherwise. If you have modules or other dependencies that age out of security updates, such as the end-of-life of the PHP version you’re hosting, you may be left with a website with an increasing number of security holes.

Additionally, after November 2021, Drupal 7 core and Drupal 7 releases on all project pages will be flagged as not supported. As a result, third-party scans may flag sites using Drupal 7 as insecure since they’ll no longer get official security support.

No more bug fixes or active development

Alongside security considerations, a lesser concern of the Drupal 7 end-of-life timeline is an official end to community-at-large bug fixes and active development. Drupal 7 development has already shifted to focus on Drupal 8 over the past several years, with Drupal 7 bugs lingering. For example, take a look at the Drupal.org issue queue for Drupal 7 core bugs; you’ll see issues that haven’t been updated for weeks or months, versus hours or days for Drupal 8/9 development issues.

Questions to ask when migrating from Drupal 7

So how do you decide which path is right for your organization? Here are some questions to ask.

What are the skills and size of your development team?

The shift from Drupal 7 to Drupal 8 and Drupal 9 involved a shift from Drupal-specific paradigms to incorporating more general object-oriented programming concepts. If your team consists of long-time Drupal developers who haven't done a lot of object-oriented programming, this paradigm shift involves a learning curve that does have an associated cost. For some budget-conscious organizations, this may mean it's more economical to remain on Drupal 7 while developers work on skilling up for Drupal 8/Drupal 9 paradigms.

Another consideration is the size of your development team. If your team is small, you may need to engage an agency for help or explore the other alternatives mentioned above.

What are the plans for the site?

How much active development is being done on the site? Are you planning to add new features, or is the site in maintenance mode? What is your budget and plan to maintain the site; do you have developers devoted to ongoing maintenance, or is it one small priority among many competing priorities? 

If you're planning to add new features, the best option is to migrate to Drupal 8 and Drupal 9. Drupal 9 is under active development, and these modern systems may already include the new features you want to add. If not, working in an ecosystem that's under active development generally reduces development overhead. 

What is the life expectancy of the site?

How many years do you expect the current iteration of the site to continue? Are you planning to use the site for three more years before a major redesign and upgrade? Eight more years? Sites with a shorter lifespan may be good candidates for Drupal 7 ES, while sites with longer life expectancies would benefit from upgrading to a modern platform with a longer lifespan.

What code is the site using?

Do an inventory of your site's code. What contributed modules are you using? What do you have that's custom? Drupal 8 upgrade evaluation is a good place to start. 

Some Drupal 7 contributed modules have Drupal 8 and Drupal 9 versions available, while others no longer apply in a world with different programming paradigms. Still, others may now be a part of Drupal 9 core. 

If you're using a lot of custom modules and code, migrating to Drupal 8 and Drupal 9 is a bigger project.  You might be able to mitigate some of that by altering the scope of your new site to take more advantage of the new capabilities of core and the available Drupal 8 contributed modules.

What features do you want?

Make a list of the features that are important to your organization. This should include features that your site currently has that you couldn't live without, and features you'd like to have but currently don't. Then, do a feature comparison between Drupal 8 and Drupal 9, and any other options you're considering. This may drive your decision to migrate, or you may decide that you can live without "must-have" features based on availability.

Where to go from here

Bottom line: with the Drupal 7 end-of-life date coming next year, now is the time to scope your site changes. But where do you go from here? The next few articles in this series explore how and when to upgrade from Drupal 7 to Drupal 9 and alternate solutions if upgrading isn’t a good choice for your organization. Stay tuned!

Categories: Drupal CMS

ARREA-Systems: Jitsi in Drupal

Drupal.org aggregator - Sat, 05/23/2020 - 19:14
Jitsi in Drupal Integration module of Jitsi video conferencing service. Allows to point to a Jitsi Meet server, start a new video session or join existing directly from a Drupal 8 site.
Categories: Drupal CMS

eiriksm.dev: Walktrough: How I am using Github for my blog comments

Drupal.org aggregator - Sat, 05/23/2020 - 02:04

My last blog post was about my journey towards "getting rid" of Disqus as a comment provider, and moving over to hosting my comments on Github. The blog post was rather light on technical details, so here is the full technical walkthrough with code examples and all.

Since I already explained most of the reasoning and architectural choices in that post I will just go ahead with a step by step of the technical parts I think is interesting. If that means I end up skipping over something important, please let me know in the (Github) comments!

Step 0: Have a Gatsby.js site that pulls it's content from a Drupal site

This tutorial does not cover that, since many people have written such tutorials. As mentioned in my article "Geography in web page performance", I really like this tutorial from Lullabot, and Gatsby.js even has an official page about using Drupal with Gatsby.js.

Step 1: Create a repo to use for comments

The first step was to create an actual repository to act as a placeholder for the comments to be. It should be public, since we want anyone to be able to comment. I opted for the repo https://github.com/eiriksm/eiriksm.dev-comments. To create a repository on GitHub, you need an account, and then just visit https://github.com/new

Step 2: Associate blog posts with issues

The second step is to have a way to indicate which issue is connected to which blog post. Luckily I am still using Drupal, so I can just go ahead and create a field called "Issue id". Then, for each post I write, I create an issue on said repo, and take a note of the issue id. For example, this blog post has a corresponding issue at https://github.com/eiriksm/eiriksm.dev-comments/issues/6, so I just go ahead and write "6" in my issue id field.

Step 3: Fetch all the issues and their comments to Gatsby.js

This is an important part. To be able to render the comments at build time, the most robust approach is to actually "download" the comments and have them available in graphql. To do that you can try to use the source plugin for GitHub, but I opted for getting the relevant issues and comments and creating the source myself. Why, you may ask? Well the main reason is because then I can more easily control how the issue comments are stored, and by extension also store the drupal ID of the node along with the comments.

To achieve this, I went ahead and used the same JSONAPI source as Gatsby will use under the hood, and then I am fetching the issue comment contents of each of the nodes that has an issue ID reference. This will then go into the gatsby-node.js file, to make the data we fetch available to the static rendering. Something along these lines:

exports.sourceNodes = async({ actions, createNodeId, createContentDigest }) => { const { createNode } = actions try { // My build steps knows the basic auth for my API endpoint. const login = process.env.BASIC_AUTH_USERNAME const password = process.env.BASIC_AUTH_PASSWORD // API_URL holds the base URL of my Drupal site. Like so: // API_URL=https://example.com/ let data = await fetch(process.env.API_URL + 'jsonapi/node/article', { headers: new fetch.Headers({ "Authorization": `Basic ${new Buffer(`${login}:${password}`).toString('base64')}` }) }) let json = await data.json() // Create a job to download each of the corresponding issues and their comments. let jobs = json.data.map(async (drupalNode) => { // Here you can see the name of my field. Change this to whatever your field name is. if (!drupalNode.attributes.field_issue_comment_id) { return } let issueId = drupalNode.attributes.field_issue_comment_id // Initialize the data we want to store. let myData = { drupalId: drupalNode.id, issueId, comments: [] } // As you can see, this is hardcoded to the repo in question. You might want to change this. let url = `https://api.github.com/repos/eiriksm/eiriksm.dev-comments/issues/${issueId}/comments` // We need a Github token to make sure we do not hit any rate limiting for anonymous API // usage. const githubToken = process.env.GITHUB_TOKEN let githubData = await fetch(url, { headers: new fetch.Headers({ // Hardcoded to my own username. This probably will not work for you. "Authorization": `Basic ${new Buffer(`eiriksm:${githubToken}`).toString('base64')}` }) }) let githubJson = await githubData.json() myData.comments = githubJson // This last part is more or less taken from the API docs for Gatsby.js: // https://www.gatsbyjs.org/docs/node-apis/#sourceNodes let nodeMeta = { id: createNodeId(`github-comments-${myData.drupalId}`), parent: null, mediaType: "application/json", children: [], internal: { type: `github__comment`, content: JSON.stringify(myData) } } let node = Object.assign({}, myData, nodeMeta) node.internal.contentDigest = createContentDigest(node) createNode(node) }) // Run all of the jobs async. await Promise.all(jobs) } catch (err) { // Make sure we crash if something goes wrong. throw err } }

After we have set this up, we can build the site and start exploring the data in graphql. For example by running npm run develop, and visiting the graphql endpoint in the browser, in my case http://localhost:8000/___graphql:

$ npm run develop > eiriksm.dev@0.0.0 develop /home/eirik/github/eiriksm.dev > gatsby develop # ... # Bunch of output # ... ⠀ You can now view eiriksm.dev in the browser. ⠀ http://localhost:8000/ ⠀ View GraphiQL, an in-browser IDE, to explore your site's data and schema ⠀ http://localhost:8000/___graphql

This way we can now find Github comments with graphql queries, and filter by their Drupal ID. See example animation below, where I find the comments belonging to my blog post "Reflections on my migration journey from Disqus comments".

In the end I ended up with the following graphql query, which I then can use in the blogpost component:

allGithubComment(filter: { drupalId: { eq: $drupal_id } }) { nodes { drupalId comments { body id created_at user { login } } } }

This gives me all Github comments that are associated with the Drupal ID of the current page. Convenient.

After this it's only a matter of using this inside of the blog post component. Since this site mix and match comment types a bit (I have a mix of Disqus exported comments and Github comments), it looks something like this:

let data = this.props.data if ( data.allGithubComment && data.allGithubComment.nodes && data.allGithubComment.nodes[0] && data.allGithubComment.nodes[0].comments ) { // Do something with the comments. } Step 4: Make it possible to fetch the comments client side

This is the part that makes it feel real-time. Since the above code with the graphql storing of comments only runs when I deploy this blog, comments can get quickly outdated. And from a UX perspective, you would want to see your own comment instantly after posting it. This means that even if we could rebuild and deploy every time someone posted a comment, this would not be instant enough to make sure a person actually sees their own comment. Enter client side fetching.

In the blog post component, I also make sure to do another check to github when you are viewing the page in a browser. This is because it is not necessary for the build step to fetch it once again, but I want the user to see the latest updates to the comments. So in the componentDidMount function I have something like this:

componentDidMount() { if ( typeof window !== `undefined` && // Again, only doing this if the article references a github comment id. And again, this // references the field name, and the field name for me is field_issue_comment_id. this.props.data.nodeArticle.field_issue_comment_id ) { // Fetch the latest comments using Githubs open API. This means the person using it will // use from their own API limit, and I do not have to expose any API keys client side. window .fetch( "https://api.github.com/repos/eiriksm/eiriksm.dev-comments/issues/" + this.props.data.nodeArticle.field_issue_comment_id + "/comments" ) .then(async response => { let json = await response.json() // Now we have the comments, do some more work mixing them with the stored ones, // and render. }) } } Step 5 (bonus): Substitute with Gitlab

Ressa asked in a (Github) comment on my last blogpost about doing this comment setup with Gitlab:

Do you know if something like this is possible with Gitlab?

Fair question. Gitlab is an alternative to Github, but differs in that the software it uses is itself Open Source, and you can self-host your own version of Gitlab. So let's see if we can substitute the moving parts with Gitlab somehow? Well, turns out we can!

The first parts of the project is the same: Create a field, have an account on Gitlab, create a repo for the comments. Then, to source the comment nodes, all I had to change was this:

--- a/gatsby-node.js +++ b/gatsby-node.js @@ -125,15 +125,25 @@ exports.sourceNodes = async({ actions, createNodeId, createContentDigest }) => { issueId, comments: [] } - let url = `https://api.github.com/repos/eiriksm/eiriksm.dev-comments/issues/${issueId}/comments` - const githubToken = process.env.GITHUB_TOKEN + let url = `https://gitlab.com/api/v4/projects/eiriksm%2Feiriksm.dev-comments/issues/${issueId}/notes` + const githubToken = process.env.GITLAB_TOKEN let githubData = await fetch(url, { headers: new fetch.Headers({ - "Authorization": `Basic ${new Buffer(`eiriksm:${githubToken}`).toString('base64')}` + "PRIVATE-TOKEN": githubToken }) }) let githubJson = await githubData.json() + if (!githubJson[0]) { + return + } myData.comments = githubJson + // Normalize it slightly. + myData.comments = myData.comments.map(comment => { + comment.user = { + login: comment.author.username + } + return comment + }) let nodeMeta = { id: createNodeId(`github-comments-${myData.drupalId}`), parent: null,

As you might see, I took a shortcut and re-used some variables, meaning the graphql is querying against GithubComment. Which is a bad name for a bunch of Gitlab comments. But I think cleaning those things up would be an exercise for the reader. The last part with client side updates was not possible to do in a similar way. The API for that requires authenticating the request. Much like the above code from sourcing the comments. But while the sourcing happens at build time, client side updates happens in the browser. Which would mean that for this to work, there would be a secret token in your JavaScript for everyone to see. So that is not a good option. But it is indeed theoretically possible, and could for example be achieved with a small proxy server, or serverless function.

The even cooler part is that the exact same code also works for a self-hosted Gitlab instance. So you can indeed run open source software and own your own data with this approach. That being said, not using a server was one of the requirements for me, so that would defeat the purpose. In such a way, one might as well use Drupal as a headless comment storage.

I would still like to finish with it all working in Gitlab too though. In an animated gif, as I always end my posts. Even though you are not allowed to test it yourself (since, you know, the token is exposed in the JavaScript), I think it serves as an illustration. And feel free to (Github) comment if you have any questions or feel I left something out.

Categories: Drupal CMS

Danny Englander: Drupal 8 Architecture: How to Add Custom HTML Data Attributes to Menus

Drupal.org aggregator - Sat, 05/23/2020 - 02:00

In a new Drupal 8 build that I am working on, there is a use case for some menu items to have an abbreviation underneath. I wanted to create a content editor friendly way of achieving this in the Drupal menu admin UI. Since I have already implemented the Drupal 8 Link Attributes widget module, I got to thinking that perhaps I could extend the module to handle these abbreviations.

Extending the Link Attributes widget

I was happy to discover that Link Attributes can be extended to any kind of additional HTML attribute you might need for your menu. I came up with the idea that if I could add a new field for the abbreviation, I could turn it into an HTML data attribute for a menu item and then output it with a little jQuery.

There are two pieces to extending the widget within a custom module, my_module.

...
Categories: Drupal CMS

Lullabot: 5 Steps to a More Accessible Website

Drupal.org aggregator - Thu, 05/21/2020 - 08:09

Whether you're a developer or a designer, everyone has a role to play in making websites more accessible and usable for site visitors. Our design and development teams got together to create this checklist of high-priority tasks you can execute to make your site more accessible. These are some of the issues that affect users of assistive technologies the most, so they should be first on your list when you're forming a plan to improve website accessibility.

Categories: Drupal CMS

5 Steps to a More Accessible Website

Lullabot - Thu, 05/21/2020 - 08:09

Whether you're a developer or a designer, everyone has a role to play in making websites more accessible and usable for site visitors. Our design and development teams got together to create this checklist of high-priority tasks you can execute to make your site more accessible. These are some of the issues that affect users of assistive technologies the most, so they should be first on your list when you're forming a plan to improve website accessibility.

Accessibility Checklist

Color Choice - Choose a well-balanced set of complementary colors that meet color contrast standards.

Color Contrast - When combining colors, verify that they have at least the minimum required color contrast.

Link Style - Add at least two differentiators to links for users with visual disabilities

Buttons - Remember color contrast requirements, states (i.e., hover, focus, etc.), and readability when designing and developing buttons for your site.

Forms - Set up your forms for success by including accessible labels, fields, instructions, errors, and alerts.

Color Choice
  • Create a visual design for your site using a balance of colors that isn't too distracting, while also not being too timid. This helps organize the site for all users, especially for those with disabilities. The effective use of color combinations in your website can establish a visual hierarchy, organize content, and draw distinctions between things such as foreground and background, or static areas and areas that are interactive. 
  • Use the primary color palette for things like CTA's, icons, and any place where highlighting areas visually is important.
  • Save secondary colors to highlight less critical information, such as secondary CTA's or backgrounds.
  • Finally, apply neutral colors to things like text and backgrounds, or to tone things down when there are large areas of color.
Twitter's primary blue used for main CTA’s & links. Color Contrast

One of the designer's most important tasks is to check color contrasts. Once you learn how to do this, you can easily integrate this task into your design workflow. When you are checking color contrasts, you should:

Web-based
  • Pull the hex value(s) and go to the WebAIM Contrast Checker tool
  • Enter your hex value(s) into the Foreground Color or Background Color field(s)
  • Using the sliders below the Foreground Color or Background Color, change the color values until the Contrast Ratio is at or above these minimum values:
    • For text that's at or over 18.66px and bold, look for a color contrast of at least 3:1
    • For text under 18.66px, look for a color contrast of at least 4.5:1
  • Pull the new hex value(s) and place them into your page
Desktop-based
  • Download the Colour Contrast Analyser tool from The Paciello Group for Windows/macOS
  • Enter your hex value(s) into the Foreground Color or Background Color field(s)
  • Using the sliders below the Foreground Color or Background Color, change the color values until the Contrast Ratio is at or above these minimums:
    • For text that's at or over 18.66px and bold, look for a color contrast of at least 3:1
    • For text under 18.66px, look for a color contrast of at least 4.5:1
  • Pull the new hex value(s) and place them into your design
Other useful tools
  • Colorblinding: This extension simulates what your website looks like to a visitor with a color vision impairment.
  • ColorZilla: Advanced Eyedropper, Color Picker, Gradient Generator and other colorful goodies
WebAIM Contrast Checker Tool Link Style

Make sure links can be distinguished from regular text. When you use links in body content, they should be visually distinct in two different ways. One of these should be color, but the other differentiator should be independent of color to provide a distinction for colorblind users. When links are placed in the header, footer, or sidebar navigation, this differentiation is not required, although it is recommended. Having links underlined by default and removed on hover/focus is the best option, because most users expect that behavior, and it is also the default behavior of browsers. Other options include highlighting, dots, dashes, an outline, or bolded text.

A focus state is required on all links, so be sure to include it when setting the hover state. This adds a solid border to a link when a user tabs to it using their keyboard, which helps keyboard-only users who use the keyboard to navigate instead of a mouse. 

Make sure horizontal and vertical link groups have enough space to enable users to access them easily. Iconography can also help users, giving them another way to distinguish between links and plain text. Users understand content more quickly when paired with a visual cue, such as an icon. Finally, use descriptive text for links instead of general text like "More" or "Click here." Links should have some context to the content they're related to; however, make sure they are kept short and understandable.

When designing links, think about the following states:

  • Default (unvisited)
  • Visited (already visited)
  • Hover (moused over)
  • Focus (focusable elements via the keyboard tab key, i.e., links, buttons, etc.)
  • Active (clicked on, i.e., tabs or navigation)
  • Disabled (not able to be activated by the user)
 Further reading on link style: Link States Buttons

When we talk about buttons, we're referring to regular form buttons and links that are styled as buttons. When developing for accessibility, form buttons should always be used in forms, and links should be used when you need to redirect the user to another page, site, or an anchor within the page.

Buttons should have a clear and solid border color that meets color contrast against the background color and a background color that meets color contrast against the text. When you hover over a button, there should be a very noticeable differentiation in the background and text color. Inverting the colors is a good option; alternately, darken the background color, and invert the text color.

When designing buttons, think about button sizing for both desktop and touch screen. Minimum touch targets should be comfortable for an adult finger to navigate successfully. The Web Content Accessibility Guidelines (WCAG) specify a minimum size of 44x44 pixels, or larger for users such as children or people with motor difficulties. 

Create button labels that are easy to read. Choose sentence case or title case over uppercase, and make sure the font is big enough for easy readability. Make labels action-oriented, i.e., "Next step," or "Save recipe." Including iconography within your buttons can help users understand actions more quickly. Include button states in all designs. These states provide users with feedback that an action is about to happen. When designing buttons, think about the following states:

  • Default (what a button looks like without any interaction)
  • Hover (on desktop, when a user's cursor is hovering over a button)
  • Active (a user has clicked on, and it is selected)
  • Focus (when a user clicks on or uses a keyboard tab key)
  • Disabled (not active)

Think about the overall button hierarchy within the system regarding primary, secondary, and tertiary buttons. This hierarchy lets users understand what the primary and secondary calls to action are on a page. 

 Further reading on buttons: Button States Forms

When designing forms, these tips can make them more readable and usable:

Group related fields 
  • Group logical sections with clear headings, i.e., Personal information, Contact information, Billing information. 
  • Groups of fields (i.e. checkboxes, radio buttons, etc.) should be contained within a that includes a element. The element holds the title for the grouped fields, which will be displayed on the page.
  • Include ample white space between sections to provide a visual distinction across sections. 
Single column forms
  • Forms are easiest to scan when form titles and fields are stacked in one column and aligned. This allows the eye to quickly scan down a single column instead of zig-zagging across multiple columns.
Form labels
  • For text fields, it is best practice to place labels above corresponding form fields in a form. Place checkboxes and radio buttons to the right of each field.
  • Use a bolded font to help form labels stand out. A flag on whether the form field is required should be placed right after the label as well. This can be a red asterisk, red "REQUIRED" text, or something similar. Form labels can also contain brief instructions for the particular field; for example, Date (mm/dd/yyyy)
  • In addition to a label, each form field should have descriptive helper text and placeholder text. Left-aligning and stacking form labels over their respective fields improve scannability. Keep the labels short and sweet.
  • Don't use placeholder text as a label, as this text isn't available to screen readers. Placeholder text disappears when the user interacts with the field. This can be annoying for users who forget what the placeholder text said. For sighted users, placeholder text offers an excellent opportunity to give users brief instructions, or show them how to format their information.
Form fields
  • Form fields should have a clear, solid border color that meets color contrast against the background color and a background color that meets color contrast against the text within the field.
  • The width of the form field should match the content it will contain. For instance, a date field would have a much shorter width than a name field that must accommodate long names.
Form field states
  • When designing your form fields, include the various field states. These field states give the user visual cues about where they are within the form, and where they're going next.
  • Field states to include are default, focus, feedback, and disabled.
Field States Form instructions
  • Provide a brief list of form instructions directly above all input forms. A note about required fields is recommended, as well as required formats (i.e., dates).
Form alerts and errors
  • Use form errors and alerts to concisely explain to users how to fix issues that prevent them from completing the form. Follow color contrast requirements with these alerts and errors.
  • Display alerts as a summary at the top of the form, including brief steps on how the user can fix the issues. You can also include links directly to the fields containing errors within the form. Display errors with each problematic form field to make it easier for a user to find specific error details. This may be inline, above, or under the field. 
  • When a field has an error, change the form field's border to another color. Red is recommended because it's universally understandable as an error in a form. In addition to a color change, another differentiator should be added to form fields when they receive errors. This could include an error icon within the field or to the left of the error message.
  • Try to keep the form lengths short. If fields aren't required, consider whether those form fields are truly necessary on the form. If you don't need them, leave them out altogether. The shorter the form, the fewer opportunities for errors.
Further reading on forms: Default Form vs. Error Messaging

As designers and developers, we can help make the world more accessible to our users. Half the battle is knowing what needs you should be designing for, and the other half is applying the design during development with the best practices and requirements we've discussed. Let's start today by taking a closer look at our work and finding opportunities to make it more accessible, more usable, and more inclusive for everyone. 

If you would like to ask us any questions about this article, please join us on Slack in the #accessibility channel. We look forward to seeing you there!

Categories: Drupal CMS

wishdesk.com: Drupal 9 upgrade: making your website ready with the latest tools

Drupal.org aggregator - Thu, 05/21/2020 - 07:52
Drupal 9 release is more than just round the corner — the 9th version is already knocking at our doors. Today, let’s discover how to prepare your website for the Drupal 9 upgrade with the help of the latest tools.
Categories: Drupal CMS

Evolving Web: 7 Design Considerations for Accessibility  

Drupal.org aggregator - Thu, 05/21/2020 - 06:16

Designing an attractive and highly functional website has a lot of important considerations, like whether users would intuitively connect more with turquoise or cyan, and whether it works with the branding. However, one often overlooked but important consideration is accessible design, and since it's always easier to fix things that you uncover in the design process, it is best to consider accessible design upfront in the design process.

Here are seven design elements to keep in mind when designing your website so it'll not only look great, but be easy to use for everyone.   

1. Colour Contrast

Colour contrast is important for both low-sighted and color blind users. I also appreciate good contrast when I'm trying to read my phone by the pool in the bright sun at noon after three margaritas. Furthermore, according to WebAIM, poor text contrast is the number one accessibility error in the top 1 million visited sites. For AAA standards, text and background need to be black and white. For AA standards, there is a 4.5:1 ratio to background for text and 3:1 for headings, as well as a 3:1 ratio for non-text contrast. 

The following tools can help you analyze your colour contrast: my preferred contrast checker, aptly named Contrast Checker and the Webaim one, and a browser extension for Firefox and Chrome.  

2. Hierarchy and Layout

Keep the hierarchy and layout of your page logical and organized and everyone will thank you. Make sure key information is visible at a glance and follows a logical hierarchy. There is nothing more frustrating than to have to scroll through an entire page or click a ton of links to get to the important information. It can be even more annoying on a screen reader. If you're not sure on how to proceed, here are some tips on layout on creating accessible layout. And remember, a good general rule is less is more. Cut the clutter and find your inner Marie Kondo.   

3. Fonts

Use a sans-serif font. Sans-serif fonts are clearer and legible at any size, not to mention they scream bold and modern design. Sans-serif fonts are so cool that I once watched an hour-long documentary on Helvetica titled the same. Or maybe that just shows how cool I am? Either way, sans-serif fonts are where it's at because they're simply easier to read. Also, make sure your text is large enough to read; have a text size of at last 16 px. If you need to emphasize information, bold is easier to read than italic or uppercase. Lastly, don't use stylized fonts outside of your logo. This page from Penn State provides a nice list of accessible fonts.   

4. Enable Text Resizing

Ensure your text is resizable so users who have just had their glasses trampled by their obese Saint Bernard can zoom in on your content while looking up opticians. Most modern day browsers support scalability, however be sure not to inadvertently turn off user scalability as a function. Check to make sure your site scales properly. You can easily achieve scalability by using relative sizes such as percent or ems rather than absolute sizes like pixels or points. The Yale accessibility site has a nice guide on how to ensure text is resizable.   

5. Text Spacing

Serifs are out, space is in. Think lovely Scandinavian minimalism. Leaving enough space between lines of text and images helps the user focus more on what is important. Ensure that the line height is at least 1.5 times the font size and that the spacing following paragraphs is two times the font size. Letter spacing (tracking) should be at least 0.12 times the font size and word spacing at least 0.16 times the font size. If I still haven't convinced you of the importance of text spacing, this page might, along with providing more tips.   

6. Links

Ensure links are distinguishable by something other than colour. An underline is standard and does the job. Also, name them something useful, short and descriptive. And definitely not 'Click Here.' All links linking to the same page should have the same description. Be sure to mention if the link opens a new tab or triggers a download, in which case indicate the file type and size, too. Again, the Yale accessibility site has a nice guide on how to make links accessible.   

7. Style Focus

Browsers display a focus ring around currently focused elements. Often, this is turned off because designers find it visually unappealing but it can be essential to those using a keyboard to navigate your site. If you are going to remove the default style focus, then be sure to replace it with something else to denote the focus. Or alternatively, have a style focus which is activated only when using the keyboard to navigate and not the mouse. Here are some more tips on how to implement style focus.   

Need More Accessibility Guidance?

If you follow these seven tips, you'll be well on your way to having a site that is accessible and enjoyable for everyone. And if you need a hand figuring all this out, take our Web Accessibility training, which guides you through this step-by-step. Also, I hear retro is in. Just think how cool your site can be with a sleek retro aesthetic and accessible design.

+ more awesome articles by Evolving Web
Categories: Drupal CMS

Issue 438

TheWeeklyDrop - Thu, 05/21/2020 - 01:34
Issue 438 - May, 21st 2020
Categories: Drupal CMS

Promet Source: Today is Global Accessibility Awareness Day

Drupal.org aggregator - Wed, 05/20/2020 - 21:34
"Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”         - Margaret Mead  
Categories: Drupal CMS

Drupal.org blog: What's new on Drupal.org? - April 2020

Drupal.org aggregator - Wed, 05/20/2020 - 14:52

Read our roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community. You can also review the Drupal project roadmap.

Project News Drupal 9 will be released on June 3rd, 2020

Despite the disruption of a global pandemic, the Drupal community has beaten the odds and Drupal 9.0 is on time for it's scheduled release window on June 3rd, 2020.

Drupal 9 represents the culmination of all of the features developed over the course of the Drupal 8 lifecycle, as well as the realization of the project's commitment to easy upgrades.

Drupal 9 beta 3 is available now, and the first release candidate will be available soon. We encourage you to participate in the Drupal beta test program, to help us ensure a smooth release.

Drupal 9 porting weekend from May 22-23

With the release of Drupal 9 only a couple weeks away, the community is coming together to support the effort to get modules ready for Drupal 9. After a successful Drupal 9 porting on April 28th, nearly 75% of the top 200 most used modules are already Drupal 9 compatible. Never before has so much of the contributed module ecosystem been ready even before the new release.

If you'd like to join in on the Drupal 9 module porting weekend, community member @kristen_pol has written a guide to the event.

New Drupal Brand assets available

The Drupal Association was very pleased to announce a new evergreen Drupal brand in time for the release of Drupal 9.

What does 'evergreen' mean?

The new branding is evergreen in the sense that it is no longer tied to a specific major version of Drupal. Whether for Drupal 9, Drupal 10, and beyond this new brand can remain the consistent identity for Drupal. This parallels the Drupal project's own development philosophy, where major version upgrades should no longer be a difficult process for end users.

With these new brand materials we hope to be able to unify the presentation of Drupal throughout the ecosystem, and help reintroduce Drupal to the world when the project inevitably gains more attention during Drupal 9's release.

We encourage you to begin using the new brand within your own materials as well - to support this effort.

Automated Deprecation Patches to port your module to Drupal 9

The Drupal Association is working together with the Drupal Rector team from Palantir and contributor Tedbow from Acquia to provide automatically generated Drupal Rector patches for all the projects on Drupal.org.

As of April, these patches are already available through DrupalCI. In May we hope to begin having a bot automatically post these fix patches to Drupal.org issues

More Drupal 9 Readiness tools Drupal.org Updates Events listing feature on Drupal.org

As we spoke about in last month's update, we've been working on a Event Listing Content Type on Drupal.org to help replace the aging Groups.Drupal.org subsite, and to support our global community by providing a central repository of events.

The new event listings are nearly ready for user submissions, and to feed existing community tools like Drupical.com.

If you'd like to add your events, reach out to rachel@association.drupal.org to be added as an early event editor for this new feature.

Respectful Advertising

The COVID pandemic and its impact on DrupalCon has only emphasized the need for the Drupal Association to further diversify its revenue sources. We've made significant strides over the last several years, but as we've heard from many of you, that work must accelerate.

We've made a few changes over the course of April to start accelerating this revenue diversification:

In the most noticeable change, we've partnered with CarbonAds, a network that focuses on advertising to technical audiences, to create placements on Drupal.org.

These placements are hidden for Drupal Association members, so this program also helps promote DA membership as well, and does not put advertising in the workspace of our committed supporters.

Enhanced Membership Options

Speaking of membership - we also made some major overhauls to the Drupal Association membership program during the #DrupalCares campaign. Many members of the community reached out to us asking for more options for supporting the Drupal Association through membership, and we were happy to accommodate those requests.

There are now new membership levels for annual renewal, and we've also added a monthly membership option, which is now the default. We hope to continue to expand the membership program and its benefits to further support our fiscal stability in the future. 

A special thanks

———

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

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

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

Categories: Drupal CMS

Bounteous.com: Drupal Hosting Solutions: Acquia vs On-Premise

Drupal.org aggregator - Wed, 05/20/2020 - 11:06
Acquia offers a purpose-built Drupal hosting solution that lets you focus on the most important part – your users.
Categories: Drupal CMS

myDropWizard.com: Drupal 6 core security update for SA-CORE-2020-002

Drupal.org aggregator - Wed, 05/20/2020 - 09:17

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for Drupal core to fix a vulnerability in jQuery. You can learn more in the security advisory:

Drupal core - Moderately Critical - Cross Site Scripting - SA-CORE-2020-002

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

FYI, there was another Drupal core security release made today (SA-CORE-2020-003) but that one doesn't affect Drupal 6.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Categories: Drupal CMS

Amazee Labs: Web maintenance is a mindset, not a milestone. Getting more out of what you have already built.

Drupal.org aggregator - Wed, 05/20/2020 - 09:08
It is easy to forget that your website or application is quite fundamentally the result of a software ecosystem. In the simplest case, a developer uses an IDE to code HTML, CSS, and these days possibly JavaScript. They presumably use a tool to upload the result to a web server, and ultimately the web server serves your website to your audience's web browser.   
Categories: Drupal CMS

Security advisories: Drupal core - Moderately critical - Open Redirect - SA-CORE-2020-003

Drupal.org aggregator - Wed, 05/20/2020 - 08:22
Project: Drupal coreDate: 2020-May-20Security risk: Moderately critical 10∕25 AC:Basic/A:None/CI:None/II:None/E:Theoretical/TD:AllVulnerability: Open RedirectDescription: 

Drupal 7 has an Open Redirect vulnerability. For example, a user could be tricked into visiting a specially crafted link which would redirect them to an arbitrary external URL.

The vulnerability is caused by insufficient validation of the destination query parameter in the drupal_goto() function.

Other versions of Drupal core are not vulnerable.

Solution: 

Install the latest version:

Reported By: Fixed By: 
Categories: Drupal CMS

Security advisories: Drupal core - Moderately critical - Cross Site Scripting - SA-CORE-2020-002

Drupal.org aggregator - Wed, 05/20/2020 - 08:18
Project: Drupal coreDate: 2020-May-20Security risk: Moderately critical 10∕25 AC:Complex/A:Admin/CI:Some/II:Some/E:Theoretical/TD:UncommonVulnerability: Cross Site ScriptingDescription: 

The jQuery project released version 3.5.0, and as part of that, disclosed two security vulnerabilities that affect all prior versions. As mentioned in the jQuery blog, both are

[...] security issues in jQuery’s DOM manipulation methods, as in .html(), .append(), and the others. Security advisories for both of these issues have been published on GitHub.

Those advisories are:

These vulnerabilities may be exploitable on some Drupal sites. This Drupal security release backports the fixes to the relevant jQuery functions, without making any other changes to the jQuery version that is included in Drupal core or running on the site via some other module such as jQuery Update. It is not necessary to update jquery_update on Drupal 7 sites that have the module installed.

Backwards-compatibility code has also been added to minimize regressions to Drupal sites that might rely on jQuery's prior behavior. With jQuery 3.5, incorrect self-closing HTML tags in JavaScript for elements where end tags are normally required will encounter a change in what jQuery returns or inserts. To minimize that disruption in 8.8.x and earlier, this security release retains jQuery's prior behavior for most safe tags. There may still be regressions for edge cases, including invalidly self-closed custom elements on Internet Explorer.

(Note: the backwards compatibility layer will not be included in the upcoming Drupal 8.9 and 9.0 releases, so Drupal 8 and 9 modules, themes, and sites should correct tags in JavaScript to properly use closing tags.)

If you find a regression caused by the jQuery changes, please report it in Drupal core's issue queue (or that of the relevant contrib project). However, if you believe you have found a security issue, please report it privately to the Drupal Security Team.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.7 are end-of-life and do not receive security coverage. Sites on 8.6 or earlier should update to 8.7.14.

The pre-release Drupal versions (8.9 and 9.0) have been updated jQuery to version 3.5.1 as of 8.9.0-beta3 and 9.0.0-beta3.

Reported By: Fixed By: 
Categories: Drupal CMS

InternetDevels: Notify users about new posts on a Drupal website and boost engagement

Drupal.org aggregator - Wed, 05/20/2020 - 07:45

For every website, irrespective of the industry, a blog is a powerful magnet that attracts both visitors and search engines. In order to keep your website fresh, you need to regularly treat your audience to new and tasty content.

Among the tricks to increase blog engagement is to notify users about new posts. Let’s see how to set up content email notifications on a Drupal website.

Read more
Categories: Drupal CMS

TEN7 Blog's Drupal Posts: Drupal Association: Building Tools to Empower the Drupal Community

Drupal.org aggregator - Wed, 05/20/2020 - 06:00
Summary

Heather Rocker and Tim Lehnen discuss the multiple missions of the Drupal Association, turning DrupalCon Global 2020, and the upcoming Drupal 9 release.

Guest

Heather Rocker and Tim Lehnen of the Drupal Association

Categories: Drupal CMS

Pages

1 2 3 4 5 6 7 8 9 next › last »