Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 8 hours 42 min ago

Jacob Rockowitz: Sponsor a Feature

21 May 2019 - 4:46am

Three years ago, I started to talk about "coming to an agreement within the Drupal community and sponsoring a Webform feature." In that blog post, I discussed creating a reusable and free-to-use agreement template with a defined process which could make it easier for organizations to sponsor feature requests. Now I want to share my current process for handling sponsored feature requests to the Webform module for Drupal 8.

For the past three years, organizations have reached out to me for paid support and feature requests. Adding the ability to import submissions was a feature request paid for by Kennesaw State University. Only two parts of my transaction with Kennesaw State University were publicly visible, the issue on Drupal.org (#2902977) and a blog post.

Sharing my process for handling paid feature requests will hopefully clarify how organizations can sponsor a feature for the Webform module and other Drupal and Open Source projects.

Steps for sponsoring a feature

Sponsoring a feature can be broken down into four key steps:

  • Communication

  • Documentation

  • Agreement

  • Payment

Communication

Good communication is one of the keys to the success of any Open Source project. Currently, there are several approaches to initiating the communication process for a sponsored feature.

The easiest and most immediate way to start a sponsored feature request is to create a user...Read More

Categories: Drupal

Srijan Technologies: The Modern Guide to Building the Right Content Strategy with Drupal

21 May 2019 - 3:00am

To keep up with consumer demand, businesses need to tactically rethink and reform the way they produce and manage content. 

What you need is a way to stand out in the consistent content chaos. To make that happen, you need a strategy that can help:

  • push out content intuitively
  • transform disorganized assets into a comprehensive manner
  • manage real-time collaboration effectively

And that’s where the role of a CMS is important.

Here’s a comprehensive guide to building the right content strategy with Drupal, focusing primarily on the technological aspect, which will help you build and establish the right notes with your audience.

Categories: Drupal

Agiledrop.com Blog: Optimizing Images with Drupal 8 Core Features

21 May 2019 - 1:27am

In this post, we’ll take a look at what you need to consider when preparing images for the web and how Drupal 8 can help you make this process automatic.

READ MORE
Categories: Drupal

Drupal Association blog: Announcing the Drupal Community Working Group Review Panel

20 May 2019 - 12:00pm

The Drupal Community Working Group (CWG) consists of volunteers who help promote the health of the Drupal community; maintain and uphold the Drupal Code of Conduct; and act as an escalation point to help mediate conflict between community members.

In December of 2018, following extensive input and feedback from the community, the CWG proposed a new charter to Dries and the board of the Drupal Association. This new charter changed the oversight of the group from the project lead (Dries) to a three-person Review Panel consisting of the two community-elected members of the Drupal Association Board along with an independent representative from a different open source project who is appointed by the full Association Board. The new charter also included an expanded mandate to focus on proactive measures for community health. Dries supported these changes as did the Association Board.

An important next step following these changes was to fully appoint the CWG Review Committee. The Drupal Association worked in the first part of 2019 to identify candidates for the third party seat of this panel.

At DrupalCon Seattle we were pleased to announce that the Review Panel is fully staffed. The current members are now:

Suzanne Dergacheva

Member of the Drupal Association Board. Elected by the community to a two-year term in 2018, Suzanne is a community leader and co-founder of Evolving Web.

Ryan Szrama

Member of the Drupal Association Board. Elected by the community to a two-year term in 2017, Ryan is a longtime community member and contributor to Drupal, as well as the founder and CEO of Centarro.

Jono Bacon

Jono Bacon is an experienced community strategist, speaker, author, and podcaster —and has consulted with a number of proprietary and open source organizations on community strategy and culture. The third seat of the panel has a term set by the board of the Drupal Association upon appointment, typically lasting 2 years.

What is the role of the Review Panel?

The Review Panel's mandate includes approving the appointment of new members of the CWG and acting as the escalation point for Community Working Group issues. The CWG Review Panel serves as the final escalation point for CWG matters, though in exceptional cases where an issue may represent a significant concern to the whole project, the panel may escalate an issue to the full Drupal Association Board.

The Review Panel’s mandate only extends to issues that are appealed to it if one of the involved parties feels a decision of the CWG is unreasonable. The Review Panel is not responsible for reviewing decisions that take place outside of the CWG process (such as Drupal.org terms of service violations, DrupalCon Code of Conduct violations resolved directly by Association staff, or other issues that have been escalated to the full board of the Drupal Association). Requests to review those decisions must be referred to the party that made the decision.

The Review Panel is not involved in the CWG’s day-to-day activities; only matters that are brought to it as part of the appeals process, or at the discretion of the CWG. The Review Panel may, however, consult with the members of the Community Working Group to help them develop programs for proactively supporting community health.

How do the Drupal Association and the CWG work together?

Under its new charter, the CWG is able to draw upon the resources of the Drupal Association, including legal advice and protection. It is also better equipped to proactively address the needs of the Drupal community.

For example, at DrupalCon Seattle the CWG presented a workshop on developing strategies for effective and inclusive group communication with the help of funding from the Drupal Association. The CWG is also currently soliciting feedback from the community as it prepares to review and update the Drupal Code of Conduct.

These are among the first of what we hope will be many initiatives to promote the health and well-being of the Drupal community, and to enhance volunteer leadership skills and sustainability as we continue to help make the Drupal community one of the most compassionate, inclusive, and intentional communities in open source.

Categories: Drupal

Lullabot: Behind the Screens: Behind the Screens with Adam Bergstein

20 May 2019 - 12:00am

For years, SimplyTest.me has provided a once-and-done tool for testing Drupal, and Adam Bergstein has recently taken over maintainership. In this episode we find out why, how you can help, and coffee!

Categories: Drupal

Ramsalt Lab: The ultimate guide for faster Drupal: Part 2: Aggregation, CDN and Image Optimization

19 May 2019 - 11:44pm
  • We are on our journey to master the Drupal performance, after having our previous Part 1: Caching published a couple of weeks ago, we've been lucky enough to get into Issue 386 of TheWeeklyDrop newsletter, Planet Drupal, and got much love and good feedback on Twitter.

    If you haven't already read the first part of the series, the ultimate guide for faster Drupal: Part 1 Caching, please feel free to read that article too.


    Note: You don't necessarily have to do all of these, some items listed here are replaceable with each other as well, so proceed with caution!

    Faster Drupal - Part 2: Aggregation and CDN
    • The one and the only holy grail: Advanced CSS/JS Aggregation
      On every Drupal optimization post you’d read you have to setup and configure AdvAgg module, but you gotta do what you gotta do!
      AdvAgg features and core benefits are listed on the module page completely, so go ahead and read them all, configure it the way that works best for you and move on
      Advanced CSS/JS Aggregation Drupal module

      Note: If you have Mod Pagespeed you might not need AdvAgg module, make sure that you don't overlap your own work

      But that’s not all, if you are on Drupal 7, you should consider checking Speedy module as well, in some areas, this might work a bit better so make sure to check it out as well
      Speedy module

    • For good JavaScript minification in Drupal, you can use modules such as minify but we’d like to recommend minifyJS instead, they listed the differences and benefits on their module page so check it out
      Drupal MinifyJS module

    • CDNize the whole project, as much as you can! You may use CDN module too

    • Move JavaScript to the footer if necessary, some JS files need to be rendered in the head based on the use case and what does the JS do! Also in Drupal 8, it’s quite easy to append your necessary library (Read it JS files) in the footer in twig template files

    • Consider if you can make your own scripts defer/async (a new challenge when it comes to Drupal js aggregation)

     

    Okay, this round was much easier thanks to AdvAgg module for taking care of half of the things we need to do for us! Note that on the frontend side you can Uglify, Minify and make sure everything that you code, will become compressed, whether it’s CSS, JS or even images or SVG files! Now let's get to it, Image optimization. 

    Image optimization
    • Drupal 8: Use the Responsive Image module wherever possible and create the appropriate styles. It uses the <picture> tag which is what we really want

    • One might say we have one too many image optimization modules in Drupal, which is a good thing! For that we tested some, experienced with some of them and here’s what we suggest: Use blazy and lazyload_images (Drupal 8 that uses IntersectionObserver instead of scrolling events), Also consider: lazyloader and image_lazy_loader when using the picture module for responsive images in Drupal 7. There is also a lazy loading option that works well

    • Image optimization: for main images/icons used in the design (Yes you can optimize SVG files as well), also the best tool for that is not in Drupal, try ImageOptim desktop app, Also there’s an API-based service available with a Drupal 7 module, take a look here, might worth setting/selling this up to clients

      Also in the same context, we can use ReSmush.it which is free (But should donate some beer to them)
      Drupal 7 Module, Drupal 8 Module

    • Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which means faster downloads and less data consumption. There's a really good module that help you serve WebP, it's called, you guessed it; WebP.

    • Serve WebP images with your web server with the MOD PageSpeed by Google for Apache and Nginx.
      Or conditionally serving WebP images with Nginx.
       

    Bonus tip: Even favicons should be optimized. Sometimes people ignore the weight of a favicon file. You shouldn’t! 

     

    For the next week, we will be covering subjects regarding Drupal database/web server tweaks & improvements, stay tuned.

     

    Written by Sohail Lajevardi
    Developer at Ramsalt Lab

     

    Categories: Drupal

    Promet Source: Great Websites are Created before the First Line of Code is Written

    19 May 2019 - 2:44pm
    When you’re surrounded by a team of awesome developers, you might think that a statement such as, “Great Websites are Created before the First Line of Code is Written,” isn’t going to be met with a lot of enthusiasm. As it turns out, our developers tend to be among the greatest supporters of the kind of Human-Centered Design engagements that get all stakeholders on the same page and create a roadmap for transformative possibilities. 
    Categories: Drupal

    Spinning Code: SC DUG May 2019

    19 May 2019 - 12:45pm

    For this month’s SC DUG, Mauricio Orozco from the South Carolina Commission for Minority Affairs shared his notes and lessons learned during his first DrupalCon North America.

    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 connection information.

    Categories: Drupal

    Srijan Technologies: Site Owner’s Guide to a Smooth Drupal 9 Upgrade Experience

    18 May 2019 - 11:39pm

    While upgrading to the latest version is always part of the best practice, the process can be staggering.

    Drupal 8.7 is already here and 9 will be released in a year, in June 2020.

    Although a lot of discussion is happening around the upgrade and possibilities it brings along, the final product can only be as good as the process itself.

    The good and important news is that moving from Drupal 8 to Drupal 9 should be really easy — radically easier than migrating from Drupal 7 to Drupal 8.

    As a site owner, here’s what you need to know about the new release and what to take care of to make the process easier without many glitches.

    Categories: Drupal

    Clemens Tolboom: Working on a Drupal module using composer

    18 May 2019 - 2:10am

    Altering Drupals composer.json to fetch a particular Drupal module git checkout.

    Categories: Drupal

    Palantir: 10 Tips for Publishing Accessible Content

    17 May 2019 - 4:00pm
    10 Tips for Publishing Accessible Content brandt Fri, 05/17/2019 - 18:00 Alex Brandt May 20, 2019

    Content editors can help make the web a more accessible place, one published moment at a time.

    Although web accessibility begins on a foundation built by content strategists, designers, and engineers, the buck does not stop there (or at site launch). Content marketers play a huge role in maintaining web accessibility standards as they publish new content over time.

    “Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.” - W3

    Why Accessibility Standards are Important to Marketers

    Web accessibility standards are often thought to assist audiences who are affected by common disabilities like low vision/blindness, deafness, or limited dexterity. In addition to these audiences, web accessibility also benefits those with a temporary or situational disability. This could include someone who is nursing an injury, someone who is working from a coffee shop with slow wifi, or someone who is in a public space and doesn’t want to become a nuisance to others by playing audio out loud.

    Accessibility relies on empathy and understanding of a wide range of user experiences. People perceive your content through different senses depending on their own needs and preferences. If someone isn’t physically seeing the blog post you wrote or can’t hear the audio of the podcast you published, that doesn’t mean you as a marketer don’t care about providing that information to that audience, it just means you need to adapt in the way you are delivering that information to that audience.

    10 Tips for Publishing Accessible Content

    These tips have been curated and compiled from a handful of different resources including the WCAG standards set forth by W3C, and our team of accessibility gurus at Palantir. All of the informing resources are linked in a handy list at the end of this post. 

    1. Consider the type of content and provide meaningful text alternatives.

    Text alternatives should help your audience understand the content and context of each image, video, or audio file. It also makes that information accessible to technology that cannot see or hear your content, like search engines (which translates to better SEO).

    Types of text alternatives you can provide:

    • Images - Provide alternative text.
    • Audio - Provide transcripts.
    • Video - Provide captions and video descriptions in action.

    This tip affects those situational use cases mentioned above as well. Think about the last time you sent out an email newsletter. If someone has images turned off on their email to preserve cellular data, you want to make sure your email still makes sense. Providing a text alternative means your reader still has all of the context they need to understand your email, even without that image.

    2. Write proper alt text.

    Alternative text or alt text is a brief text description that can be attributed to the HTML tag for an image on a web page. Alt text enables users who cannot see the images on a page to better understand your content. Screen readers and other assistive technology can’t interpret the meaning of an image without alt text.

    With the addition of required alternative text, Drupal 8 has made it easier to build accessibility into your publishing workflow. However, content creators still need to be able to write effective alt text. Below I’ve listed a handful of things to consider when writing alt text for your content.

    • Be as descriptive and accurate as possible. Provide context. Especially if your image is serving a specific function, people who don’t see the image should have the same understanding as if they had.
    • If you’re sharing a chart or other data visualization, include that data in the alt text so people have all of the important information.
    • Avoid using “image of,” “picture of,” or something similar. It’s already assumed that the alt text is referencing an image, and you are losing precious character space (most screen readers cut off alt text at around 125 characters). The caveat to this is if you are describing a work of art, like a painting or illustration.
    • No spammy keyword stuffing. Alt text does help with SEO, but that’s not it’s primary purpose, so don’t abuse it. Find that happy medium between including all of the vital information and also including maybe one or two of those keywords you’re trying to target.
    Example of good alt text: “Red car in the sky.”
    Example of better alt text: “Illustration of red car with flames shooting out of the back, flying over line of cars on sunny roadway.”3. Establish a hierarchy.

    Accessibility is more than just making everything on a page available as text. It also affects the way you structure your content, and how you guide your users through a page. When drafting content, put the most important information first. Group similar content, and clearly separate different topics with headings. You want to make sure your ideas are organized in a logical way to improve scannability and encourage better understanding amongst your readers.

    4. Use headings, lists, sections, and other structural elements to support your content hierarchy.

    Users should be able to quickly assess what information is on a page and how it is organized. Using headings, subheadings and other structural elements helps establish hierarchy and makes web pages easily understandable by both the human eye and a screen reader. Also, when possible, opt for using lists over tables. Tables are ultimately more difficult for screen reader users to navigate.

    If you’re curious to see how structured your content is, scan the URL using WAVE, an accessibility tool that allows you to see an outline of the structural elements on any web page. Using WAVE can help you better visualize how someone who is using assistive technologies might be viewing your page.

    5. Write a descriptive title for every page.

    This one is pretty straight forward. Users should be able to quickly assess the purpose of each page. Screen readers announce the page title when they load a web page, so writing a descriptive title helps those users make more informed page selections.

    Page titles impact:

    • Users with low vision who need to be able to easily distinguish between pages
    • Users with cognitive disabilities, limited short-term memory, and reading disabilities.
    6. Be intentional with your link text.

    Write link text that makes each link’s purpose clear to the user. Links should provide info on where you will end up or what will happen if you click on that link. If someone is using a screen reader to tab through 3 links on a page that all read “click here,” that doesn’t really help them figure out what each link’s purpose is and ultimately decide which link they should click on.

    Additional tips:

    • Any contextual information should directly precede links.
    • Don’t use urls as link text; they aren’t informative. A
    • void writing long paragraphs with multiple links. If you have multiple links to share on one topic, it’s better to write a short piece of text followed by a list of bulleted links.

    EX: Use "Learn more about our new Federated Search application" not "Learn more".

    7. Avoid using images of text in place of actual text.

    The exact guideline set forth by W3 here is “Make it easier for users to see and hear content including separating foreground from background.” 

    There are many reasons why this is a good practice that reach beyond accessibility implications. Using actual text helps with SEO, allows for on-page search ability for users, and creates the ability to highlight for copy/pasting. There are some exceptions that can be made if the image is essential to include (like a logo). Providing alt text also may be a solution for certain use cases.

    8. Avoid idioms, jargon, abbreviations, and other nonliteral words.

    The guideline set forth by W3 is to “make text content readable and understandable.” Accessibility aside, this is important for us marketers In the Drupal-world, because it’s really easy to include a plethora of jargon that your client audience might not be familiar with. So be accessible AND client-friendly, and if you have to use jargon or abbreviations, make sure you provide a definition of the word, link to the definition, or include an explanation of any abbreviations on first reference.

    Think about it this way: if you are writing in terms people aren’t familiar with, how will they know to search for them? Plain language = better SEO.

    9. Create clear content for your audience’s reading level.

    For most Americans, the average reading level is a lower secondary education level. Even if you are marketing to a group of savvy individuals who are capable of understanding pretty complicated material, the truth is, most people are pressed for time and might become stressed if they have to read super complicated marketing materials. This is also important to keep in mind for people with cognitive disabilities, or reading disabilities, like dyslexia.

    I know what you’re thinking, “but I am selling a complicated service.” If you need to include technical or complicated material to get your point across, then provide supplemental content such as an infographic or illustration, or a bulleted list of key points.

    There are a number of tools online that you can use to determine the readability of your content, and WebAIM has a really great resource for guidelines on writing clearly.

    10. Clearly label form input elements.

    If you are in content marketing, chances are you have built a form or two in your time. No matter whether you’re creating those in Drupal or an external tool like Hubspot, you want to make sure you are labeling form fields clearly so that the user can understand how to complete the form. For example, expected data formats (such as day, month, year) are helpful. Also, required fields should be clearly marked. This is important for accessibility, but also then you as a marketer end up with better data.

    Helpful Resources

    Here are a few guides I've found useful in the quest to publish accessible content:

    Accessibility Tools People
    Categories: Drupal

    Lullabot: Introducing Support & Maintenance at Lullabot

    17 May 2019 - 11:33am

    In our booth during DrupalCon Seattle this year, we had the pleasure of speaking with people in the Drupal community about our new Support & Maintenance offering. The response we heard most often was, “Doesn’t Lullabot already do support and maintenance?” The short answer is yes.

    Categories: Drupal

    Hook 42: Drupaldelphia: The Jawn That Never Disappoints

    17 May 2019 - 6:49am
    Drupaldelphia: The Jawn That Never Disappoints Lindsey Gemmill Fri, 05/17/2019 - 13:49
    Categories: Drupal

    myDropWizard.com: Experimental Composer repository with CKEditor plugins

    17 May 2019 - 6:49am

    In my experience, a big part of making a Drupal 8 site usable for content editors is customizing the WYSIWYG, which usually includes adding a couple additional CKEditor plugins.

    Of course, you can simply download the plugins into the 'libraries' folder, and that's fine. But these days, it's becoming best practice to pull in all of your site's dependencies using Composer.

    Adding 'package' repositories to your composer.json for the CKEditor plugins (the current best practice) works fine - but only for your individual site.

    It doesn't work so well if you want to install:

    • A Drupal "Feature" (like with the Features module) that configures the WYSIWYG, including adding some CKEditor plugins, or
    • A Drupal distribution (like Panopoly or Lightning)

    In those cases, you can't depend on what the individual site may have in its top-level composer.json, and asking the user to manually copy-paste a bunch of 'package' repositories in there may create enough confusion or problems that potential users will just give up.

    Well, I've got an possible solution to this problem: an experimental Composer repository which includes CKEditor plugins for use on a Drupal site.

    It works better for Feature modules and distributions, but can also make life easier for individual sites too.

    Read more to find out how it works and how to use it!

    Categories: Drupal

    ThinkShout: The Problems In Tech Go Deeper Than ‘Hacking’

    17 May 2019 - 5:00am

    Earlier this week, The Cut ran a piece about a “Tinder Hacker” who created a fake profile with his roommate’s photos, then hooked a piece of code up to the Tinder API and did some very simple string substitutions so that men who messaged “her”–after “she” swiped right on them–were tricked into actually talking to other men who did the same. In brief, he put strangers in contact with each other under false pretenses, rerouted and surveilled their communications without consent, and proceeded to use this as a bragging point on dates and in interviews.

    One might take exception to a number of elements of this story, but let’s start with its terminology. “Hacking” is a word whose meaning has broadened beyond all practical use, but in no sense did “Sean”, the pseudonymous subject of the story, “hack Tinder.” He relied on someone else’s reverse engineering to write some buggy code that ran against its API. That’s all.

    The article itself seems confused about whether the Tinder API, or Application Program Interface, only exists to allow homebrew apps on Windows Phone. But an API is just a set of commands made available by a server, like the Tinder mothership, to accept instructions from client apps, like the many copies of the Tinder app that run on all kinds of phones. Almost all the apps on your phone are clients that work this way, and APIs are ubiquitous. Even the Drupal and Wordpress sites we build each have their own versions.

    The code described in the article fits less within the definition of a hack than that of a bot. It would live on a server, persist as a service, wait for triggers–like incoming messages–and then respond to them according to certain rules. Some bots are used for automated customer service; some are used for art projects; some are used for jokes. Many, many, many bots are used for spam or other malicious purposes.

    The ethics of bot development are not always simple, but they’re not new territory either. That’s the second and most glaring exception to be taken here: Sean’s assertion that his bot was at the “gray hat” level of malice in terms of its exploitation of code. Bot creator and Portland local Darius Kazemi wrote a thoughtful piece about considering and refining the possibility space of joke bots toward kindness in 2015. That in turn references fellow creator Leonard Richardson’s seminal 2013 post “Bots Should Punch Up”, which contains a telling bit with regard to the color of that hat:

    “Hackers and comedians and artists are always attracted to the grey areas. But your bot is an extension of your will, and if you're a white guy like me, most of the grey areas are not grey in your favor.”

    Perhaps it’s assuming too much to conclude that Sean, a San Francisco programmer whose race is not mentioned in the article, is a white guy. Perhaps not. Technology as a field in the US is overwhelmingly full of white men, offering most of the benefits of the biggest wealth creation engine in history to the people who were already granted our society’s highest levels of privilege. That privilege, and power, means that thoughtless choices have more potential to do harm: by default, they’re punching down.

    But even if that weren’t the case, as an educated and socialized human adult, it shouldn’t have been hard to see that writing a service solely to entice, deceive, manipulate and mock people in a vulnerable space like a dating app might have consequences. That is, unless you’ve spent a career being rewarded for ignoring consequences, because you work in tech. That’s the third exception to be taken. For pulling a prank like this, many people would be fired or sued. Instead, Sean got a better job.

    I can admit that this story struck me on a personal level. Back before I had to quit Twitter, I used to write bots using their API myself. One of them, which I created in 2014, worked on a similar principle to the Tinder bot: it would receive a person’s message, put it in holding, and send them back a random held message from someone else in response. The juxtapositions were surreal, delightful, and often rewarding. And everyone involved was informed, consenting, and able to make use of built-in safety tools to report bad actors.

    I’m not an ethicist or a researcher by training, but I knew to consider those aspects of my work because I have an interest in the history of the internet. According to the article, Sean does too–I’m willing to bet he and I read the same books about phone phreaks, blue boxes and Captain Crunch.

    The phreakers he admires, by the way, were indeed “punching up” with their pranks–using low-rent tools to get one back at Bell, an exploitative tech monopoly that would eventually be broken up. Hey, there’s an idea.

    People have made infamously bad choices like Sean’s before, and one might expect creators here in the future to work at avoiding their repetition. But instead, his story reflects the broader attitude of a tech sector that is not just ahistorical, but willfully naive and ignorant of the lessons of its past. (If you only read one thing linked in this whole piece, make it that last one. Go ahead, I’ll wait.)

    The things I value about working at ThinkShout stand in opposition to all of that. My colleagues here are technical experts, but they’re also widely read, deeply informed, and always working to expand our collective view of the world in inclusive and considerate ways. That’s why we take pride in supporting progressive organizations like the Campaign Legal Center and ChangeLab Solutions. That’s why we focus on accessibility for all users as a core concern and increasing equity in our own job pipeline. That’s why we’re fine with being located far outside the insular centers of big tech culture, where it seems like people would rather try to land on the Moon than make change on the ground.

    Even if the article in The Cut highlights the deep problems in the technology sphere that engulfs us all, there are certainly worse things on the internet than a man getting his kicks by trolling a bunch of other men. But there are better things too. If you’d prefer to join us on that side, please get in touch! We’re hiring, and we’d be glad to hear about how your hobby project brought a little kindness and empathy to the world.

    Categories: Drupal

    Duo Consulting: A Better Way to Search in Drupal

    16 May 2019 - 1:04pm

    One of the best things about Drupal’s open-source ecosystem is that it empowers you to be open-minded. Given the vast array of solutions and modules available, users can customize their site to their whims. Alternatively, if you think up and code something new, your contributions can be shared online with other users. With all of the customization available, Drupal is a conducive platform for outside-the-box thinking.

    Decoupling is a recent example of this philosophy. Where a standard Drupal website would feature a Drupal-powered front and backend, decoupling opens the door for a variety of possibilities. A decoupled site can utilize different platforms and technologies for both the front and backend. For example, a decoupled site could utilize Drupal’s backend CMS while running a React-powered frontend. Such is Drupal’s flexibility that it can power scores of different, user-facing channels from a single backend, including other sites, native apps, Internet of Things (IoT), and more.

    This decoupled or “headless” concept has more applications than just for site design, though. The search function of a website, for one, can benefit from components that utilize this headless approach – and not a moment too soon. As Google has begun to sunset its Google Search Appliance offering, there is now a need for an open and flexible search tool with enterprise-level capabilities.

    At this year’s Midwest Drupal Camp, the team from Palantir demonstrated that a decoupled approach to site search was viable. This solution, federated search, allows for indexing and searching across multiple sites. For organizations with a large web portfolio across different platforms, this open federated search solution can fill the gap left by Google.

    Understanding why federated search for Drupal is important requires an understanding of how regular site search functions operate. At the core, the search feature is built from three different components: the source, index and results. The source simply refers to all of the searchable content on a given site, from blogs to landing pages. The index is a compilation of metadata that makes the content form the source easier to parse. At Duo, we often use Apache Solr, a platform-agnostic, open source solution for indexing, as it provides speed, power and its own server capabilities. Finally, the results refers to the front-end experience that compiles and delivers the search results to the user.

    The above setup will work fine for most simple websites, but larger organizations often require a more robust solution. With federated search, users can query across multiple sites across different platforms without placing much strain on Drupal, since Apache Solr is handling generating the index and providing results. This is accomplished through some tweaking of the basic site search formula.

    Part of what makes this search so powerful is that it takes advantage of Drupal’s backend without relying on its frontend. For that, Apache Solr’s dedicated servers empower this new search solution by shouldering the burden of indexing and providing the results. Before it can work, though, some configuration is needed. Based on this configuration, Apache Solr can encompass searches across different sites – including sites that aren’t built with Drupal. Creating this custom solution, in conjunction with the Search API and Search API Solr modules, will ensure that the different data types being indexed will be standardized.  

    As for the results section, the best approach is a decoupled one. Building out the front-end component in the React JavaScript library allows for robust searches without slowing down the rest of the site. By using Drupal’s CMS, Apache Solr and React’s power in coordination, any organization can create a search feature that quickly indexes vast ranges of data and delivers it in an easily digestible manner. For a deeper dive, Palantir has made their demo of federated search available.

    This powerful and streamlined take on site search has a variety of applications. Before releasing the solution, Palantir originally developed federated search for the University of Michigan, as each department ran their own sites on different platforms. Federated search now allows users to seamlessly search for information across the entire school’s network, regardless of the technology used to deliver the content. Beyond university ecosystems, federated search also presents an opportunity for eCommerce. Using this solution, products from different vendors can be consolidated into a simple search.

    Thanks to Drupal being open source, organizations can utilize federated search and any other contributed solution at any time. This level of openness is what makes Duo such champions of the Drupal platform. At Duo, we’re committed to exploring new features like this and helping each of our partners think outside the box. If you’re ready to start rethinking your website or sites, we’re just a click away.

    Categories: Drupal

    Srijan Technologies: Drupal and Accessibility: Does the Community Stand by What it Preaches?

    16 May 2019 - 4:46am

    “..an inclusive community, we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities.”

    Categories: Drupal

    Agiledrop.com Blog: Interview with Tim Lehnen: When you're trying to make a mark in the digital space, Drupal is your best choice

    16 May 2019 - 1:42am

    We're very happy we got to speak with Tim Lehnen, the interim Executive Director of the Drupal Association. Tim is honored to be serving the Drupal community for the past 5 years and is looking forward to how Drupal will evolve alongside digital innovations.

    READ MORE
    Categories: Drupal

    Morpht: Drupal 8 Configuration - Part 5: Module developers and the API

    15 May 2019 - 7:14pm
    Background

    We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

    While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

    This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

    This article will focus specifically on how developers can manage, declare, and debug configuration in their custom modules.

    Configuration Schema

    Configuration schema describes the type of configuration a module introduces into the system. Schema definitions are used for things like translating configuration and its values, for typecasting configuration values into their correct data types, and for migrating configuration between systems. Having configuration in the system is not as helpful without metadata that describes what the configuration is. Configuration schemas define the configuration items.

    Any module that introduces any configuration into the system MUST define the schema for the configuration the module introduces.

    Configuration schema definitions are declared in [MODULE ROOT]/config/schema/[MODULE NAME].schema.yml, where [MODULE NAME] is the machine name of the module. Schema definitions may define one or multiple configuration objects. Let's look at the configuration schema for the Restrict IP module for an example. This module defines a single configuration object, restrict_ip.settings:

    restrict_ip.settings:
      type: config_object
      label: 'Restrict IP settings'
      mapping:
        enable:
          type: boolean
          label: 'Enable module'
        mail_address:
          type: string
          label: 'Contact mail address to show to blocked users'
        dblog:
          type: boolean
          label: 'Log blocked access attempts'
        allow_role_bypass:
          type: boolean
          label: 'Allow IP blocking to be bypassed by roles'
        bypass_action:
          type: string
          label: 'Action to perform for blocked users when bypassing by role is enabled'
        white_black_list:
          type: integer
          label: 'Whether to use a path whitelist, blacklist, or check all pages'
        country_white_black_list:
          type: integer
          label: 'Whether to use a whitelist, blacklist, or neither for countries'
        country_list:
          type: string
          label: 'A colon separated list of countries that should be white/black listed'

    The above schema defines the config object restrict_ip.settings which is of type config_object (defined in core.data_types.schema.yml).

    When this module is enabled, and the configuration is exported, the filename of the configuration will be restrict_ip.settings.yml. This object has the keys enable, mail_address, dblog etc. The schema tells what type of value is to be stored for each of these keys, as well as the label of each key. Note that this label is automatically provided to Drupal for translation.

    The values can be retrieved from the restrict_ip.settings object as follows:

    $enable_module = \Drupal::config('restrict_ip.settings')->get('enable');
    $mail_address = \Drupal::config('restrict_ip.settings')->get('mail_address');
    $log = \Drupal::config('restrict_ip.settings')->get('dblog');

    Note that modules defining custom fields, widgets, and/or formatters must define the schema for those plugins. See this page to understand how the schema definitions for these various plugins should be defined.

    Default configuration values

    If configuration needs to have default values, the default values can be defined in [MODULE ROOT]/config/install/[CONFIG KEY].yml where [CONFIG KEY] is the configuration object name. Each item of configuration defined in the module schema requires its own YML file to set defaults. In the case of the Restrict IP module, there is only one config key, restrict_ip.settings, so there can only be one file to define the default configuration, restrict_ip/config/install/restrict_ip.settings.yml. This file will then list the keys of the configuration object, and the default values. In the case of the Restrict IP module, the default values look like this:

    enable: false
    mail_address: ''
    dblog: false
    allow_role_bypass: false
    bypass_action: 'provide_link_login_page'
    white_black_list: 0
    country_white_black_list: 0
    country_list: ''
     

    As can be seen, each of the mapped keys of the restrict_ip.settings config_object in the schema definition are added to this file, with the default values provided for each key. If a key does not have a default value, it can be left out of this file. When the module is enabled, these are the values that will be imported into active configuration as defaults.

    Debugging Configuration

    When developing a module, it is important to ensure that the configuration schema accurately describes the configuration used in the module. Configuration can be inspected using the Configuration Inspector module. After enabling your custom module, visit the reports page for the Configuration Inspector at /admin/reports/config-inspector, and it will list any errors in configuration.

    The Configuration Inspector module errors in configuration schema definitions

    Clicking on 'List' for items with errors will give more details as to the error.

    The 'enable' key has an error in schema. The stored value is a boolean, but the configuration definition defines a string

    Using the Configuration Inspector module, you can find where you have errors in your configuration schema definitions. Cleaning up these errors will correctly integrate your module with the Configuration API. In the above screenshot, then type of data in the active schema is a boolean, yet the configuration schema defines it as a string. The solution is to change the schema definition to be a boolean.

    Summary

    In this final article of this series on the Drupal 8 Configuration API, we looked at configuration schema, how developers can define this schema in their modules and provide defaults, as well as how to debug configuration schema errors. Hopefully this series will give you a fuller understanding of what the Configuration API is, how it can be managed, and how you can use it effectively in your Drupal projects. Happy Drupaling!

    Categories: Drupal

    Promet Source: Digital Accessibility and the Common Good

    15 May 2019 - 12:54pm
      “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   Today marks the 8th annual Global Accessibility Awareness Day.
    Categories: Drupal

    Pages