All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
In preparation for Agaric's migration training at DrupalCon Seattle, we've seen again that getting a development environment suitable for working on Drupal 8 with Composer is a big road block. For that reason, here are instructions for getting it all going, suitable for our training or for working on Drupal in a code sprint, with only one hard requirement: PHP.
Getting a local development going is a problem for everyone, including programmers and people who should be skilled at this. Vagrant and DrupalVM were created to make identical development environments work on any computer. Unfortunately, that's more a pipe dream than a promise, as our own experiences and support requests we've received can attest,
Docker is another attempt to make local development match production environments, and a newer generation of Drupal-adjacent development workflow tools, such as DDEV, Lando, Docksal, and Humpback, build on it. Using an online development environment is also an option, but has too much reliance on working WiFi for conference situations.
The goal is any Drupal development environment—any of the above or anything else—where you can go to your project root directory in a terminal and type, say, composer update and have If you don't have a local development environment of any kind, here is the minimalist approach. All the steps start with opening your terminal.
Thoughts about Drupal 8, Drupal 7, Backdrop, the Drupal Community, DrupalCon's meteoric price increases, DrupalCamps, and the future of the framework/CMS/enterprise experience engine that is Drupal have been bubbling up in the back of my mind for, well, years now.
I am almost always an optimist about the future, and Drupal 8 promised (and usually delivered) on many things:
- Vastly improved content administration
- Views in core, and even better than ever
- Media in core
- Layouts in core
- Modern programming paradigms (fewer #DrupalWTFs)
- 'Getting off the island' and becoming more of a normal PHP application (kinda the opposite of something like Wordpress)
But one thing that has always been annoying, and now is probably to the state of alarming, for some, is the fact that Drupal 8 adoption has still not hit a level of growth which will put it ahead of Drupal 7 adoption any time soon.
Drupal 8 ships with a custom CKEditor build. This build is configured with a build-config.js file. We recently ran into a situation in which we wanted to override this configuration in order to disable a plugin. There is some information in this build-config.js file about replacing it with a non-minified build for development purposes, but nothing about overriding it. Here is how we did it.Christina April 08, 2019
After posting my request for a Webform logo, Jeff Masigan (jeffmasigan) the owner of Pixel Architect Web Design Inc. reached out via Drupal Slack, offering to design the Webform module's logo and even have it printed on tee-shirts for DrupalCon Seattle. It is hard to turn down the prospect of giving out Webform tee-shirts at the Advanced Webform session. Lili, my 10-year-old daughter, is very excited to have Webform tee-shirt added to her growing Drupal tee-shirt collection.
Two other awesome members of the Drupal community, Christian Okpada (ojchris37) and Jürgen Appel, responded with proposals and ideas. While thinking about Jeff's Webform logo tee-shirt offer, I also realized that Jeff and I had met in the Webform issue queue via Issue #3032244: Webform - Route Not Found Exception. This issue was one of those frustrating 'gotcha' problems that we were able to work through and fix. Seeing that Jeff had a history in the Webform issue queue and even earned an issue commit credit, this finalized my decision to work with Jeff and Pixel Architect.
Drupal Seattle was only a few weeks away, so Jeff and I came up with a tight timeline and got to work.First designs
Pixel Architect's designer came up with a bunch of icon and color variations. I initially thought the Webform logo might use a checkbox icon but when I saw the miniaturized contact form; I was sold. First...Read More
For the longest time, web content had one purpose - to get pushed on a web page. But everyone today wants content to be available across the board - on mobile devices, native apps, digital signage, and show up on third-party sites and social networks - if it is to garner the right audience.
Today, personalizing your customer journey is an essential strategy and part of delivering a competitive brand experience. And while some organizations have implemented a range of personalization tools, many have not successfully scaled their personalization strategy across their customers’ journey at every touchpoint.
Accessibility tests can be automated to a degree, but not completely; to succeed at accessibility, it needs to be a mindset shared by developers, UX and front-end folks, business people and other stakeholders. In this article, we will attempt to run tests and produce meaningful metrics which can help teams who are already committed to produce more accessible websites.Premise
Say your team is developing a Drupal 8 site and you have decided that you want to reduce its accessibility issues by 50% over the course of six months.
In this article, we will look at a subset of accessibility issues which can be automatically checked – color contrast, placement of tags and HTML attributes, for example. Furthermore, we will only test the code itself with some dummy data, not actual live data or environment. Therefore, if you use the approach outlined in this article, it is best to do so within a global approach which includes stakeholder training; and automated and manual monitoring of live environments, all of which are outside the scope of this article.Approach
Your team is probably perpetually “too busy” to fix accessibility issues; and therefore too busy to read and process reports with dozens, perhaps hundreds, of accessibility problems on thousands of pages.
Instead of expecting teams to process accessibility reports, we will use a threshold approach:
First, determine a standard towards which you’d like to work, for example WCAG 2.0 AA is more stringent than WCAG 2.0 A (but if you’re working on a U.S. Government website, WCAG 2 AA is mandated by the Americans with Disabilities Act). Be realistic as to the level of effort your team is ready to deploy.
Next (we’ll see how to do this later), figure out which pages you’d like to test against: perhaps one article, one event page, the home page, perhaps an internal page for logged in users.
In this article, to keep things simple, we’ll test for:
- the home page;
- an public-facing internal page, /node/1;
- the /user page for users who are logged in;
- the node editing form at /node/1/edit (for users who are logged in, obviously).
Running accessibility checks on each of the above pages, we will end up with our baseline threshold, the current number of errors, for example this might be:
- 6 for the home page
- 6 for /node/1
- 10 for /user
- 10 for /node/1/edit
We will then make our tests fail if there are more errors on a given page than we allow for. The test should pass at first, and this approach meets several objectives:
- First, have an idea of the state of your site: are there 10 accessibility errors on the home page, or 1000?
- Fail immediately if a developer opens a pull request where the number of accessibility errors increases past the threshold for any given page. For example, if a widget is added to the /user page which makes the number of accessibility errors jump to 12 (in this example), we should see a failure in our continuous integration infrastructure because 12 >= 10.
- Provide your team with the tools to reduce the threshold over time. Concretely, a discussion with all stakeholders can be had once the initial metrics are in place; a decision might be made that we want to reduce thresholds for each page by 50% within 6 months. This allows your technical team to justify the prioritization of time spent on accessibility fixes vs. other tasks seen by able-bodied stakeholders as having a more direct business value.
Because we want to run tests on a continuous integration server, we want to avoid dependencies. Specifically, we want a system which does not require us to install specific versions of MySQL, PHP, headless browsers, accessibility checkers, etc. All our dependencies will be embedded into our project using Docker and Docker Compose. That way, all you need to install in order to run your project and test for accessibility (and indeed other tests) is Docker, which in most cases includes Docker Compose.Principle #2: A starter database
In our continous integration setup, will will be testing our code on every commit. Although it can be useful to test, or monitor, a remote environment such as the live or staging site, this is not what this article is about. This means we need some way to include dummy data into our codebase. We will do this by adding dummy data into a “starter database” committed to version control. (Be careful not to rely on this starter database to move configuration to the production site – use configuration management for that – we only want to store dummy data in our starter database; all configuration should be in code.) In our example, our starter database will contain node/1 with some realistic dummy data. This is required because as part of our test we want to run accessibility checks agains /node/1 and /node/1/edit.
A good practice during development would be that for new data types, say a new content type “sandwich”, a new version of the starter database be created with, say, node/2 of type “sandwich”, with realistic data in all its fields. This will allow us to add an accessibility test for /node/2, and /node/2/edit if we wish.Tools
Don’t forget, as per principle #1, above, you will never need to install anything other than Docker on your computer or CI server, so don’t attempt to install these tools locally, they will run on Docker containers which will be built automatically for you.
- Pa11y: There are dozens of tools to check for accessibility; in this article we’ve settled on Pa11y because it provides clear error reports; and allows the concept of a threshold above which the script fails.
- Chromium: In order to check a page for accessibility issues without actually having a browser open, a so-called headless browser is needed. Chromium is a fully functional browser which works on the command line and can be scripted. This works under the hood and you will have no need to install it or interact with it directly, it’s just good to know it’s there.
- Puppeteer: most accessibility tools, including Pa11y, are good at testing one page. Say, if you point Pa11y to /node/1 or the home page, it will generate nice reports with thresholds. However if you point Pa11y to /user or /node/1/edit it will see those pages anonymously, which is not what we want to test. This is where Puppeteer, a browser scripting tool, comes into play. We will use Puppeteer later on to log into our site and save the markup of /user and /node/1/edit as /dom-captures/user.html and /dom-captures/node-1-edit.html, respectively, which will then allow Pa11y to access and test those paths anonymously.
- And of course, Drupal 8, although you could apply the technique in this article to any web technology, because our accessibility checks are run against the web pages just like an end user would see them; there is no interaction with Drupal.
You are also welcome to fork the project and link it to a free CircleCI account, in which case continuous integration tests should start running immediately on every commit.
A few minutes after running ./scripts/deploy.sh, you should see a login link to a full Drupal installation on a random local port (for example http://0.0.0.0:32769) with some dummy data (/node/1). Deploying this site locally or on a CI server such as Circle CI is a one-step, one-dependency process.
In the rest of this article we will refer to this local environment as http://0.0.0.0:YOUR_PORT; always substitute your own port number (in our example 32769) for YOUR_PORT.Introducing Pa11y
We will use a Dockerized version of Pa11y, dcycle/pa11y, here is how it works against, say, amazon.com:docker run --rm dcycle/pa11y:1 https://amazon.com
No site that I know of has zero accessibility issues; so you’ll see a bunch of issues in this format:• Error: This element's role is "presentation" but contains child elements with semantic meaning. ├── WCAG2AA.Principle1.Guideline1_3.1_3_1.F92,ARIA4 ├── #navFooter > div:nth-child(2) └── <div class="navFooterVerticalColumn navAccessibility" role="presentation"><div class="navFooterVerticalRo...</div> Running Pa11y against a local site
Developers and continuous integration servers will need to run Pa11y against a local site. We would be tempted to run Pa11y on 0.0.0.0:YOUR_PORT, but that won’t work because Pa11y is being run inside its own container and will not have access to the host machine. You could give it access, but that raises another issue: the port is not guaranteed to be the same at every run, which requires ugly logic to figure out the port. Ugh! Instead, we will attach Pa11y to the Docker network used by our Starter site, in this case called starterkit_drupal8site_default (you can use docker network ls to list networks). Because our docker-compose.yml file defines the Drupal container as having the name drupal and port 80 (the default port), we can now run:docker run --network starterkit_drupal8site_default \ --rm dcycle/pa11y:1 http://drupal
This has some errors, just as we expected. Before doing anything else, type echo $?; this will give a non-zero code, meaning running this will make your continuous integration script fail. However, because we decided earlier that we will tolerate, for now, 6 errors on the home page, let’s set a threshold of 6 (or however many errors you get – there are 6 at the time of this writing) instead of the default zero:docker run --network starterkit_drupal8site_default \ --rm dcycle/pa11y:1 http://drupal --threshold 6
If you run echo $? right after, you should get the “passing” exit code of zero. There, we’ve met our threshold, so we will not have a failure!How about pages where you need to be logged in?
The above solution breaks down, though, when you want to test http://drupal/node/1/edit. Although it will produce results, what we are actually checking against here is the “Access denied” page, not /node/1/edit when we are logged in. We will approach this in the following way:
- Set a random password for user 1;
- Use Pa11y to test the temporary file we just created.
In our Drupal 8 Starterkit, we can test the entire process. Start by running the Puppeteer script:./scripts/end-to-end-tests.sh
What does this look like?
Astute readers have realized that using Puppeteer to click through the site to create our dom captures has the added benefit of confirming that our site functionality works as expected, which is why I called the script end-to-end-tests.sh.
To confirm this actually worked, you can visit, in an incognito window:
Yes it looks like you’re logged in, but you are not: these are anonymous webpages which Pa11y can check.
So if this worked correctly (and it should, because we hav it under continuous integration), we can run our Pa11y tests agains all these pages:./scripts/a11y-tests.sh echo $?
You will see the errors, but because the number of errors is below our threshold, the exit code will be zero, allowing our Continuous integration tests to pass.Conclusion
Making a site accessible is, in my opinion, akin to making a site secure: it is not something to add to a to-do list, but rather an approach including all site stakeholders. Neither is accessibility something which can be automated; it really is a team culture. However, approaches like the one outlined in this article, or whatever works in your organization, will give teams metrics to facilitate the integration of accessibility into their day-to-day operations.
Accessibility tests can be automated to a degree, but not completely; to succeed at accessibility, it needs to be a mindset shared by developers, UX and front-end folks, business people and other stakeholders. In this article, we will attempt to run tests and produce meaningful metrics which can help teams who are already committed to produce more accessible websites.
It’s been about a year since Nikki and I HAX‘ed DrupalCon Nashville. Now, Mike and I are about to embark to DrupalCon Seatle to once again, HAX all the things. HAXeditor has come a really long way since the last reveal. In the time since last year:
When I attended my first DrupalCon in San Francisco I brought three suits. At that point, I had been speaking at academic conferences for a decade, and in my experience, conferences were places where attendees dressed formally and speakers literally read their papers (here's a real example from a 2005 Women's and Gender Studies Conference where I spoke).
Midwest Drupal Camp (MidCamp) 2020, on March 18-21, will be the seventh-annual Chicago-area event that brings together designers, developers, users, and evaluators of the open source Drupal content management software. Attendees come for four days of presentations, professional training, contribution sprints, and socials while brushing shoulders with Drupal service providers, hosting vendors, and other members of the broader web development community.Early-bird Deal!
For 2020, tables will be exclusive to Core sponsors, and the early-bird rate will be $2500, increasing to $3000 on June 1, 2019. Core sponsors will have the option to add on $1000 for "naming rights" to any component of camp they choose—a party, Training Day, Contribution Day, snacks, coffee, or something else.
If you'd like to lock in your table now, send us an email to email@example.com and we'll get an invoice out to you ASAP.
On behalf of the Drupal Association, we’re excited to welcome you to Seattle, DrupalCon, and the Washington State Convention Center. Your week will be packed with opportunities to learn, network, collaborate, and most importantly, have fun... Drupal style!
At this point in the history of the open web, privacy is arguably the key issue in software development. As a range of scandals arising from the misuse of data bring pressure on governments and civil society to take action, it is important for software projects - including Drupal - to take proactive steps to value, resource, and support privacy work.
To date, the Drupal project has largely been reliant on the community to take the lead on privacy work. Development initiatives on privacy issues have mostly centred around contributed modules to implement privacy standards required by the EU’s GDPR privacy legislation.
The status of Drupal’s work on privacy was discussed at great length at Drupal Europe last year with members of the WordPress and Joomla communities, as well as a variety of community members in Drupal who are continuing to focus on privacy beyond GDPR.
As a result, we created the Cross-CMS privacy group, where participants from a number of open source CMSes learn from each other and work to bring our respective software ecosystems towards a common open standards and principles.
For DrupalCon Seattle we would like to present a core privacy initiative that will bring together some of the existing work in contrib as well as the efforts of the others in the cross-CMS group.Cross-CMS Privacy Group
We have representatives from the communities of Drupal, Joomla, WordPress and Umbraco meeting regularly on Wednesdays at 2-3pm UTC. It’s only been a few months, but we feel that we’ve achieved quite a bit. We’ve managed to stick to our weekly meetings and found that everyone involved has a passion for privacy generally, not just compliance with a specific set of laws.
We’ve found that although our software and community ecosystems are different, we’ve had to encounter the same set of problems - we’ve just handled things in differing ways. Different CMS’ have focused on different areas, which gives us much to learn from each other. For example, WordPress has done a great deal of work on privacy policies, whilst Joomla has fantastic export and import tools for site admins to manage, Umbraco has put a lot of effort into a Consent API, data export and handling of sensitive data fields.
We have already achieved a number of deliverables since beginning:
We’ve been working towards a common understanding of how software projects should define privacy that has been influenced by GDPR but aims to go further than mere compliance here: https://github.com/webdevlaw/open-source-privacy-standards (Special thanks to Heather from the WordPress team)
We’ve created a repository for posting minutes, and been producing them weekly here (Special thanks to the Joomla! Team especially Luca and Achilleas): https://github.com/joomla/cross-cms-compliance
We’ve created a structure for auditing software extensions that could be used by a Drupal privacy team to audit common modules here : https://github.com/joomla/cross-cms-compliance/blob/master/audit-your-software-extension.md
We have begun discussing unified standards for file formats for data portability exports and imports, so that users could, in theory, move their data between sites regardless of CMS
We’ve created some internal documents comparing the features of our CMSes with the aim to produce a common blueprint for how software best handles user data and privacy tools. We’ve been compiling some legal examples of times when fines have happened and are working together towards a common goal.
Through our conversations we have become convinced that privacy is no longer just a legal requirement but one of ethical importance. We know that giving users the ability to control their own data, and having means to control their consent, isn’t just about avoiding the proverbial fine. As developers behind some of the largest CMSes in the world, we know that we cannot force website administrators to respect their users’ privacy, but we can at least make it so easy for them to do so that they will need a good reason to not enable these tools.
CMSes can often be the first point of processing an individual’s information. A recent discussion raised by Alan Mac Kenna from the Umbraco CMS community within the group centred on the need to be able to demonstrate accountability for processing not only based on consent, but for other ‘lawful bases’ also, enabling our platforms to become a key source of truth for realising accountability under data protection regulations.
However, putting aside the ethical imperative for privacy tools, there are a number of new legal privacy initiatives currently being worked on (which as of this writing include CCPA, the ePrivacy Regulation revamp, and the growing shape of the eventual US Federal privacy law). Therefore, especially for large organisations and enterprise, core functionality in databases and CMSes will likely be an incentive for future projects and funding.
We feel that the Cross-CMS group will assist their projects to value, resource, and support both the ethical reasons for caring about privacy as well as the business incentives for avoiding legal issues. The more we follow consistent design patterns, open standards, and proactive approaches to legislation, the more all of our clients, users and customers will be protected. Whilst other CMSes will never dictate what Drupal needs to do, we can always benefit from mutual learning and understanding.
We hope that as this initiative grows, we will be able to work in cooperation with regulatory bodies themselves to add further authority to the technical approaches we will take in our software.Drupal Privacy Initiative Goals
We have a number of potential goals for a Drupal privacy initiative:
- We want to have a clear roadmap of what features need to be in the Core of Drupal, so that other modules can extend that functionality, and what features can remain officially supported in Drupal.
- An example is the tools for data erasure and “Right to be forgotten” could be an extension of the existing options given when a site admin cancels a user;
- Whereas tools to make it easier to import user data from other CMSes could exist in contrib but using a data structure that the majority of major CMSes are using.
- We want to define what we currently believe are the essential features required to improve a website’s handling of user data and privacy, including:
- Functionality for logging consent or other legal basis for processing;
- Functionality for handling the exporting and erasure of user data, taking into account that Drupal stores a lot of data in custom fields or other modules.
- A privacy team-supported checklist, existing in contrib, to assist organisations in compliance and privacy issues outside of pure tech/code issues.
- A privacy team which, like the security team, vets submitted modules to see how well they respect privacy requirements, as the WordPress Privacy team does. This could instead be more similar to how the accessibility team operates.
- Potentially other features such as something like the legal module in core which would allow modules to submit wording for privacy policies, such as what cookies they used and how they handle user data.
- Build upon the work Brainsum (Peter) and FreelyGive (Jamie or yautja_cetanu) have done on the GDPR module on drupal.org to bring the essential functionality into core where appropriate.
- We want to create documentation within drupal.org to assist developers, site builders and site administrators alike in understanding the privacy issues which impact Drupal, including understanding what other software does.
We hope to follow this blog post up with some detailed presentations on the state of privacy tools in other CMSs with screenshots and a more detailed plan.
Currently the representatives of Drupal in the Cross-CMS Privacy Group are from two companies which worked on the /project/gdpr module and another individual who has worked on various encryption modules. We hope to open this up at Drupalcon Seattle.
Chris Teitzel is representing the initiative at Drupalcon Seattle. Many of the members of the working group are in Europe and while not in physical attendance, have pledged to make themselves available remotely for any discussions that are required and are willing to help in any way.
Chris hopes to bring together enough people to support this so an official initiative can be created.
In the long term we hope to secure funding for the group to cover travel and accommodation expenses for periodic in-person meetups and other directly relevant activities, such as conferences and workshops. We may also seek funding support for our time and labour contributing to opensource privacy, which is already a considerable commitment. We naturally must be careful to consider the values and ethics of any potential sponsors, particularly those which may have a mixed track record on privacy.Image: Tags: Blog category:
Mike and Matt talk to a conglomerate of Lullabots about their DrupalCon sessions on Thursday, April 11th.
Content management systems like Drupal provide dynamic layout building tools. This article details the challenges associated with trying to deliver the most appropriately sized image in these dynamic layouts.
Stop me if you’ve heard this one before.
You’re working on a big, time-sensitive update to a page. Maybe it’s a landing page, or a home page. Whatever it is, stakeholders are involved, and Big Names are giving input. You’ve got 15 versions of this in draft. Your workflows are performing perfectly and launch is ten days away.
Then, disaster strikes.