Drupal News

This is all about Drupal

  • Drupal Planet

    Droptica: Paragraph View Mode – Review of a Module for Drupal

    15 hours 51 minutes ago

    Creating components using the Paragraphs module offers incredible flexibility in building pages based on Drupal. One of the common restrictions is the issue of reusing the same paragraphs in very similar components. If the only thing that limits you is the set and layout of fields, the Paragraph View Mode module will help you.

    The very first lines of the module's code were created as a dedicated module for one of the projects we implemented. I quickly noticed, however, how such a functionality could be useful in the whole Paragraphs module ecosystem. Currently, the module has a stable 1.4 version and is covered by the Security Advisory Policy.

    Dates 

    The first version of the module was released in July 2019. Since then, I have been actively following the list of issues, implementing patches and new functionalities. The last patches were introduced to the developer version in July 2020.

    Module's popularity

    According to the statistical data published on the module's page: https://www.drupal.org/project/paragraph_view_mode, it is currently used by about 450 websites, which translates into approximately 10 uses per week.

    Module's creators

    The first draft of the module was created in order to address the needs of a current project. After its initial release on the drupal.org website, I introduced some additional improvements and new functionalities. The community also helped, e.g. with making the module compatible with Drupal 9.
    Currently, I am the only person who worked directly on the module's code. The module itself is supervised by two maintainers who respond to all issues as quickly as possible.

    What is the module used for? 

    Paragraph View Mode is a sub-module for the Paragraphs module. Its advantages will be appreciated by both, developers and people responsible for editing content on a website. It may be necessary when:

    • you are building a website from many components, and some of them are very similar, e.g. they use a similar set of fields;
    • you want to minimise the number of components with regards to the administration;
    • you think about streamlining the frontend part;
    • you want to ensure better organisation of templates with regards to the UI and directly within the code;
    • you want to avoid using many complex field-based modifiers, e.g. lists.

    As you can see, this module can offer several useful functions, and all this goes hand in hand with the simplicity of this solution in accordance with the so-called "Drupal Way".

    Unboxing

    You can download the module from the https://www.drupal.org/project/paragraph_view_mode webpage or via composer:

    composer require drupal/paragraph_view_mode


    After the installation, go to editing the selected paragraph type, the default path is usually:
     
    [your_domain]/admin/structure/paragraphs_type/[your_paragraph_bundle]
     
    In the "Paragraph View Mode" drop-down section, select the option “Enable Paragraph view mode field on this paragraph type" and then save the form.

    The module will automatically create a "Paragraph view mode" field with a configuration widget (available in the manage form display tab).
     
    The widget's configuration consists of two fields. The first field is the selection of available display modes. The module automatically receives a list of only those that are unblocked on the current paragraph type, while you can decide which of them you want to display on the list of options in the form.

    The second field is used to define the default value of the field in the absence of its value (e.g. for a newly created paragraph).

    With the module configured in this way, you can dynamically switch the display modes directly in the page adding/editing form.

    Plans for the future

    The basic functionality of the module is already completed, and it is hard to come up with new functionalities. Recently, however, I created a new issue https://www.drupal.org/project/paragraph_view_mode/issues/3150153, in which I plan (with a little help from the community) to develop the functionality of linking the field value with the display mode of the form and its dynamic substitution. I also intend to continue supporting Drupal 9 and future versions.

    Summary

    The Paragraph View Mode module, despite its low complexity, offers a lot regarding the efficiency, convenience and – above all – flexibility of the editors' work. In addition, it allows the Drupal developers or the person responsible for the website to reduce the amount of work needed to organise and maintain the components on the website, thus reducing the overall cost of maintaining the website.

    Nextide Blog: Innovating Healthcare with Drupal

    1 day 3 hours ago

    Innovation within Canadian healthcare continues to provide better care experiences for those using the system.  As the population ages and strains our facilities to care for those nearing their end-of-life, hospitals are looking at technological solutions to ease the burden on emergency rooms and give people access to accurate and timely healthcare.   Nextide partnered with uCarenet, a Toronto-based e-health company, to create an innovative health and wellness application to monitor the condition of palliative care patients for a major Canadian hospital.

     

    Vardot: DrupalCon 2020: Going Global

    1 day 17 hours ago

    DrupalEasy: DrupalEasy Podcast 234 - Jess Snyder (Drupal Nonprofits), Kaleem Clarkson (Drupal Event Organizers)

    2 days 11 hours ago

    Direct .mp3 file download.

    Jess Snyder joins Mike Anello to talk about how Drupal and nonprofit organizations - topics include the unique needs of nonprofits, the challenges they have with Drupal 8+, and how nonprofit folks organize and support each other. Also, Kaleem Clarkson returns to the podcast to provide an update on the Drupal Event Organizers Group.

    URLs mentioned DrupalEasy News Subscribe

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

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

    Drupal blog: The first ever virtual DrupalCon

    3 days 6 hours ago

    This blog has been re-posted and edited with permission from Dries Buytaert's blog.

    I remember the first gathering of Drupal contributors back in 2005. At the time, there were less than 50 people in attendance. In the 15 years since that first gathering, DrupalCon has become the heartbeat of the Drupal community. With each new DrupalCon, we introduce new people to our community, demonstrate the best that Drupal has to offer, and reconnect with our Drupal family.

    Next week's DrupalCon Global is going to be no different.

    Because of COVID-19, it is the first DrupalCon that will be 100% virtual. But as much as we may miss seeing each other in person, the switch to virtual has opened opportunities to bring in speakers and attendees who never would have been able to attend otherwise.

    There are a few moments I'm particularly excited about:

    • Mitchell Baker, CEO of the Mozilla, is joining us to talk about the future of the Open Web, and the importance of Open Source software.
    • Jacqueline Gibson, Digital Equity Advocate and Software Engineer from Microsoft, will be talking about Digital Inequity for the Black community – a topic I believe is deeply important for our community and the world.
    • Leaders of current Drupal strategic initiatives will be presenting their progress and their calls for action to keep Drupal the leading CMS on the web.
    • And of course, I'll be giving my plenary presentation to celebrate the community's accomplishment in releasing Drupal 9, and to talk about Drupal's future.

    Beyond the sessions, I look forward to the human element of the conference. The side conversations and reunions with old friends make attending DrupalCon so much more powerful than simply watching the recordings after the fact. I hope to see you at DrupalCon Global next week!

    Chapter Three: Import files from Google Drive, Dropbox, OneDrive and other services into Drupal

    3 days 6 hours ago

    External Media module for Drupal 8 and 9 is a successor of the File Chooser Field module that was bulit for Drupal 7. The same functionality was implemented for Wordpress too. The module provides custom form element.

    The new form element would allow you to add external services such as Google Drive, Dropbox, Box, OneDrive, AWS, Unsplash, Instagram, Pixabay, Pexels and other services, in addition to regular file choose field. 

    Event Organizers: Events Organizers at DrupalCon Global

    3 days 8 hours ago

    DrupalCon Global is right around the corner and as usual, the Event Organizers will be everywhere! This year we've had a booth generously sponsored by the Drupal Association, so we'll have a place right in Hopin where you can come find us, chat about events, and even win some direct consulting time to help plan your next event! Whether you’re an event organizer, interested in starting an event in your area, or just want to flag one of us down, here’s where to look.

    Nonprofit Drupal posts: Join the DrupalCon Nonprofit Summit Tues., July 14th

    3 days 10 hours ago

    DrupalCon Global starts on Tuesday, July 14th, 2020, 2-4pm ET/11am-1pm PT. Because everything is online, every summit, session and event within DrupalCon is available under one ticket.

    If you haven't registered yet, you still can at https://events.drupal.org/node/31305

    We've kept the original theme for the Nonprofit Summit - The Lifecycle of a Drupal Website, because when we see our websites as dynamic, evolving communications tools, we make the most out of them. 

    Although the pivot to a virtual event has been hard, it’s given us the opportunity to feature speakers who were not originally planning to attend in-person DrupalCon MN. Many of us are juggling massive changes in our work and personal lives, along with fear and anxiety. We are grateful to our fantastic slate of speakers for taking time to share their experiences and knowledge with this community! 

    A full day in front of a screen would be exhausting. So we've taken our original schedule and pared it down to two hours of focused, lesson-packed programming, along with space for participants to ask questions.

    One of the most valuable aspects of summits is the ability to get to know and network with others that share this fairly niche interest of “nonprofit Drupal”. We will approximate that experience by weaving in ways for us to network with one another via chat, a shared notes doc, and an opt-in directory of people.

    Here's the full schedule. We hope to see you there!

    Nonprofit Summit Sponsors

    Immense thanks to our sponsors, Aten Design Group and Message Agency, for their continued, unwavering support of our Nonprofit Summit, in spite of the difficult pivot to a virtual event, and extremely challenging times for everyone involved. 

    Nonprofit Summit Co-organizers
    • Molly Byrnes, mbyrnes on D.o, @mabfire on Twitter

    • Johanna Bates, DevCollaborative, hanpersand on D.o, @hanabel on Twitter

    • Clayton Dewey, DevCollaborative, cedewey on D.o, @claybolto on Twitter

    DrupalCon Global Nonprofit Summit Agenda

    The summit runs 2-4pm EDT / 11am-1pm PDT. Start and end times are approximate. All times listed in UTC.

    • 18:00-18:10 - Welcome 

      • Summit organizers, & introduction to sponsors Aten & Message Agency

    • 18:10-18:35 - The Lifecycle of a Drupal Site Panel 

      • Dan Thiede (Clean Energy Resource Teams)

      • Corey Brown (CLINIC Legal)

      • Paige Eaton (Facing History)

      • Moderated by Lynn Winter (Manage Digital)

    • 18:35-18:50 - Panel Q&A

    • 18:50-18:55 Break

    • 18:55-19:05 - 12 Tips for Nonprofits Converting to Drupal Lightning Talk

      • Monica Flores (Lullabot)

    • 19:05-19:15 - Drupal 8 & 9 Module Compatibility Lightning Talk

      • Cecelia Sullivan (Race Forward)

    • 19:15-19:25 - Lightning Talks Q&A

    • 19:25-19:35 - Requirements-gathering for the Mukurtu Drupal Distribution Lightning Talk

      • Elliot Bannister (Standing Rock Sioux Tribe)

    • 19:35-19:45 - Integrating Drupal with Mighty Networks - A Lightning Case Study 

      • Joe Turgeon (The Whether)

    • 19:45-20:00 - Q&A and Wrap-up

    Nonprofit Summit Page: https://events.drupal.org/global2020/program/summit/nonprofit 

    Mobomo: How to Choose the Right Drupal Theme

    3 days 12 hours ago

    When you first sit down to create your Drupal website, you have plenty of decisions to make. What are your first blog posts going to be? What kinds of marketing materials do you need to help your website convert? What is your SEO strategy to boost your SERP position? These are all important, and we highly recommend that you consider each point before you launch your first website.

    But those are details. The most significant decision you’re going to make is what theme you’ll use. Think of your theme as the building block of your website. It’s how users are going to perceive your site, interpret your content, and engage with your products or services. You want a beautiful, interactive, intuitive, and easy-to-browse website that pushes customers to think, engage, and consume your rich creatives.

    Here’s the problem: there are thousands of Drupal themes. When you first look through the avalanche of bright colors, minimal panes, and unique content configurations, it can be dizzying. How do you pick a theme with that certain something that sets you apart? 

    Here are some criteria to help you sift through the tsunami of designs on the market.

    How Important is Your Drupal Theme, Really?

    At some point, you need to pull the trigger. But how soon should you go with your gut instinct? After all, is picking the “perfect” theme really that important? In today’s hyper-redundant theme ecosystem, it’s easy to think that website design is a secondary factor in your website build process. Many websites today have eerily similar themes, and you may be looking to copy-paste that minimalist, white-space-heavy style that your competitors probably use.

    Don’t make the mistake of minimizing the importance of the theme. Your competitors may use cookie-cutter themes, but you shouldn’t. Here’s why:

    • 38% of people will flat out refuse to engage with a website if its looks aren’t appealing to them.
    • 88% of people won’t return to your website ever again after a single bad experience.
    • 75% of customers make a judgment call on your brand’s credibility based on your website design.
    • Given 15 minutes to read content, people would rather view something beautifully designed than something plain-looking.
    • 94% of negative feedback regarding your website will be design related.

    In other words, your customers are going to judge the efficacy of your brand based on your website’s design. Remember the phrase, “first impressions are everything.” Well, 94% of first impressions are based on design—you want something stunning. Obviously, design is still a highly personal experience. Some people like quirky and weird, some like minimal and smooth, and others like aggressive and animation heavy. It depends on your end user and who you are as a brand.

    So how do you go about picking the right one? After all, there’s a lot at stake. Your theme is going to be the first thing customers see when they click on your website. Here are the three core components of website themes you should consider before you make your choice.

    1. Your Brand’s Identity

    We all know that branding is a big deal. 89% of marketers say that branding is their top goal, and branding is the first thing that 89% of investors look at when deciding whether or not to open their wallets. So, when it comes to your design, brand should be front-of-mind. Who is your company? What does it stand for? And, most all, what does it look like?

    Your Drupal theme is a powerful branding tool. Every single component of your website is an opportunity for branding. We could get overly complicated diving into website branding, but we’ll stick with the simple stuff. Let’s talk about color. Seems simple enough, right? Check this out:

    • Color alone improves brand recognition by 80%.
    • 93% of people focus on your brand’s color when buying products.
    • When people make subconscious decisions about your product, 90% of that decision is related to color.

    Ok! So color is obviously important. But what about all the other “stuff” on your website? Does the position of content boxes, navigation menu, and blog posts really matter? You bet! Consistent brand representation across content boosts bottom-line profits by 33% on average. And 80% of people think content is what drives them to really engage and build loyalty with brands.

    In a nutshell, think about branding when you look at themes. 90% of users expect you to have consistent branding across all channels. If you can’t find a theme that screams, “you,” that’s ok! If you can’t find one, build one.

    2. Performance

    The theme you choose will have a direct impact on your website’s performance. Unnecessary components, visual clutter, and poor frontend coding can all increase load times and disrupt website accessibility. Obviously, some of your performance capabilities happen on the backend (e.g., caching, DB Query optimization, MySQL settings, etc.) But your theme still has a sizable effect on how your website performs.

    Overly large CSS files, redundant coding for modules, blank spaces, and other issues can all increase time-to-load, create visual issues, and create stop-points for your users. To be clear, performance is a significant component in both lead generation and retention:

    • A 100-millisecond delay drops conversions by 7%.
    • Increasing the number of page elements from 400 to 6,000 drops conversion rates by 95%.
    • 79% of shoppers that encounter a website with poor performance will never return.

    Always test out themes for performance. The aesthetic qualities of a website are important, but performance is a necessity.

    3. UX

    We like to call UX the “hidden performance.” It’s how your users will engage with and consume content throughout your website. The theme you pick will dictate a significant portion of your UX. Before you choose a theme, build out your information architecture strategy, create mockups for UI (or at least find UI examples that you enjoy), and plot out your broad content strategy. Then, choose a theme that compliments your strategy and information architecture.

    Here’s the most important thing: always evolve your UX. Consider applying agile to your theme building and choosing practices. Even after you select the right theme, constantly make improvements to your UI/UX to breed consistency and customer-centricity. You can purchase a pre-made theme on the Drupal marketplace, but you still need to customize the theme to fit your brand and conform to your UX framework. You don’t want to choose a cookie-cutter theme on the marketplace and fail to maximize its value. Not only will your website look nearly identical to thousands of other Drupal sites, but you also won’t truly build an experience-driven website. Give your customers home-cooked steak and potatoes—not a microwaved frozen dinner.

    Are You Looking for the Perfect Drupal Theme?

    If you want a theme that’s hyper-branded, built for performance, and created using brand-specific information architecture, you won’t find it on a pre-built theme website. You need to create it. At Mobomo, we help public and private entities create breathtaking Drupal themes specifically for their brand and their users. Let’s build your brand something amazing.

    Contact us to learn more.

    The post How to Choose the Right Drupal Theme appeared first on .

    Dries Buytaert: The first ever virtual DrupalCon

    3 days 13 hours ago

    I remember the first gathering of Drupal contributors back in 2005. At the time, there were less than 50 people in attendance. In the 15 years since that first gathering, DrupalCon has become the heartbeat of the Drupal community. With each new DrupalCon, we introduce new people to our community, demonstrate the best that Drupal has to offer, and reconnect with our Drupal family.

    Next week's DrupalCon Global is going to be no different.

    Because of COVID-19, it is the first DrupalCon that will be 100% virtual. But as much as we may miss seeing each other in person, the switch to virtual has opened opportunities to bring in speakers and attendees who never would have been able to attend otherwise.

    There are a few moments I'm particularly excited about:

    • Mitchell Baker, CEO and Chair of the Mozilla Foundation, is joining us to talk about the future of the Open Web, and the importance of Open Source software.
    • Jacqueline Gibson, Digital Equity Advocate and Software Engineer from Microsoft, will be talking about Digital Inequity for the Black community – a topic I believe is deeply important for our community and the world.
    • Leaders of current Drupal strategic initiatives will be presenting their progress and their calls for action to keep Drupal the leading CMS on the web.
    • And of course, I'll be giving my keynote presentation to celebrate the community's accomplishment in releasing Drupal 9, and to talk about Drupal's future.

    Beyond the sessions, I look forward to the human element of the conference. The side conversations and reunions with old friends make attending DrupalCon so much more powerful than simply watching the recordings after the fact. I hope to see you at DrupalCon Global next week!

    Drupal In the News: Drupal Association Launches Drupal Steward Program To Increase Protection For Site Owners

    4 days 15 hours ago

    The Drupal Steward Program enhances the security of Drupal Sites by protecting sites from exploits even before they are able to patch, and supports the sustainability of the Drupal Security Team and Drupal Association.

    PORTLAND, Ore. July 7, 2020—The Drupal Association is announcing the launch of the Drupal Steward security program, together with founding partners Acquia and Pantheon, two of the largest hosting platforms for Drupal, and major contributors to the project. This is a paid service offered to further enhance the sites built on Drupal. A portion of the proceeds from both the founding partners and the community tier are used to support the Drupal Security Team and Drupal Association.

    The Drupal Steward program answers the most pressing concern that keeps CIOs/CTOs up at night - "How do I protect my sites from the next unknown vulnerability?" In today's world, a Public Service Announcement of a critical vulnerability means disruption to existing engineering roadmaps, overtime hours, and all-hands on deck waiting for a patch release so that it can be deployed before bad actors reverse engineer the vulnerability.

    Drupal Steward addresses this issue by putting in place a network-level mitigation strategy that prevents many of these kinds of highly critical vulnerabilities from being exploited, even before the patch has been applied. While there may be some rare vulnerabilities that cannot be mitigated with this technique - most of the highly critical vulnerabilities in Drupal's past would have been mitigated with this method.

    "I am proud that we can advance Drupal's commitment to enterprise-grade security," said Heather Rocker, Executive Director of the Drupal Association. "The Drupal Steward program and its security protections should give the world the confidence to build the next generation of digital experiences on open source technology."

    Drupal sites hosted with the Drupal Steward Founding Partners Acquia and Pantheon will be directly protected by those partners. For sites not hosted by the Drupal Steward founding partners, Drupal site owners will be able to subscribe to the Community tier of the Drupal Steward program directly through the Drupal Association at an affordable cost, with discounts provided to clients of Drupal Association supporting partners with a record of contribution to the project in the form of time, talent, or treasure.

    Learn more about Drupal Steward

    For complete details about the Drupal Steward program, including how to sign up - please visit https://www.drupal.org/security-team/steward

    Powered by a global community

    Drupal is a true open source project, leveraging the expertise of tens of thousands of developers around the world. Drupal has a proven track record for strong security practices, with a strong belief that the transparency of open source leads to more secure software.

    About Drupal and the Drupal Association

    Drupal is the open source content management software used by millions of people and organizations around the world, made possible by a community of 100,000-plus contributors and enabling more than 1.3 million users on Drupal.org. The Drupal Association is the non-profit organization dedicated to accelerating the Drupal software project, fostering the community, and supporting its growth.

    ###

    For more information contact secwg-partnerships@association.drupal.org 

    Amazee Labs: Join us at DrupalCon Global

    4 days 15 hours ago
    <img src="https://www.amazeelabs.com/sites/default/files/styles/leading_image/public/images/current-affairs/AL-Going-to-DrupalCon-Global-Blogs.jpg?h=994a2424&amp;itok=j5e9gWaA" width="1120" height="630" alt="Join us at DrupalCon Global " title="Join us at DrupalCon Global " class="image-style-leading-image" /> DrupalCon Global 2020 is just a few days away, and we’re excitedly prepping up for what’s sure to be a virtual event like nothing the community has seen before. To say the least, it’s been a strange few months for everyone on the planet, but we at Amazee Labs think nothing exemplifies the resilient and persistent spirit of the open-source community like the innovative skills and organizational determination it took to bring DrupalCon Global 2020 and all its global attendees together.

    Agaric Collective: Drupal migrations reference: List of properties per content entity

    4 days 21 hours ago

    In a previous article we explained the syntax used to write Drupal migrations. When migrating into content entities, these define several properties that can be included in the process section to populate their values. For example, when importing nodes you can specify the title, publication status, creation date, etc. In the case of users, you can set the username, password, timezone, etc. Finding out which properties are available for an entity might require some Drupal development knowledge. To make the process easier, in today’s article we are presenting a reference of properties available in content entities provided by Drupal core and some contributed modules.

    For each entity we will present: the module that provides it, the class that defines it, and the available properties. For each property we will list its name, field type, a description, and a note if the field allows unlimited values (i.e. it has an unlimited cardinality). The list of properties available for a content entity depend on many factors. For example, if the entity is revisionable (e.g. revision_default), translatable (e.g. langcode), or both (e.g. revision_translation_affected). The modules that are enabled on the site can also affect the available properties. For instance, if the “Workspaces” module is installed, it will add a workspace property to many content entities. This reference assumes that Drupal was installed using the standard installation profile and all modules that provide content entities are enabled.

    It is worth noting that entity properties are divided in two categories: base field definitions and field storage configurations. Base field configurations will always be available for the entity. On the other hand, the presence of field storage configurations will depend on various factors. For one, they can only be added to fieldable entities. Attaching the fields to the entity can be done manually by the user, by a module, or by an installation profile. Again, this reference assumes that Drupal was installed using the standard installation profile. Among other things, it adds a user_picture image field to the user entity and body, comment, field_image, and field_tags fields to the node entity. For entities that can have multiple bundles, not all properties provided by the field storage configurations will be available in all bundles. For example, with the standard installation profile all content types will have a body field associated with it, but only the article content type has the field_image, and field_tags fields. If subfields are available for the field type, you can migrate into them.

    Content (Node) entity

    Module: Node (Drupal Core)
    Class: Drupal\node\Entity\Node
    Related article: Writing your first Drupal migration

    List of base field definitions:

    1. nid: (integer) The node ID.
    2. uuid: (uuid) The node UUID.
    3. vid: (integer) Revision ID.
    4. langcode: (language) Language code (e.g. en).
    5. type: (entity_reference to node_type) Content type machine name.
    6. revision_timestamp: (created) The time that the current revision was created.
    7. revision_uid: (entity_reference to user) The user ID of the author of the current revision.
    8. revision_log: (string_long) Briefly describe the changes you have made.
    9. status: (boolean) Node published when set to TRUE.
    10. uid: (entity_reference to user) The user ID of the content author.
    11. title: (string) Title.
    12. created: (created) The time that the node was created.
    13. changed: (changed) The time that the node was last edited.
    14. promote: (boolean) Node promoted to front page when set to TRUE.
    15. sticky: (boolean) Node sticky at top of lists when set to TRUE.
    16. default_langcode: (boolean) A flag indicating whether this is the default translation.
    17. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    18. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
    19. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.

    List of field storage configurations:

    1. body: text_with_summary field.
    2. comment: comment field.
    3. field_image: image field.
    4. field_tags: entity_reference field.
    User entity

    Module: User (Drupal Core)
    Class: Drupal\user\Entity\User
    Related articles: Migrating users into Drupal - Part 1 and Migrating users into Drupal - Part 2

    List of base field definitions:

    1. uid: (integer) The user ID.
    2. uuid: (uuid) The user UUID.
    3. langcode: (language) The user language code.
    4. preferred_langcode: (language) The user's preferred language code for receiving emails and viewing the site.
    5. preferred_admin_langcode: (language) The user's preferred language code for viewing administration pages.
    6. name: (string) The name of this user.
    7. pass: (password) The password of this user (hashed).
    8. mail: (email) The email of this user.
    9. timezone: (string) The timezone of this user.
    10. status: (boolean) Whether the user is active or blocked.
    11. created: (created) The time that the user was created.
    12. changed: (changed) The time that the user was last edited.
    13. access: (timestamp) The time that the user last accessed the site.
    14. login: (timestamp) The time that the user last logged in.
    15. init: (email) The email address used for initial account creation.
    16. roles: (entity_reference to user_role) The roles the user has. Allows unlimited values.
    17. default_langcode: (boolean) A flag indicating whether this is the default translation.

    List of field storage configurations:

    1. user_picture: image field.
    Taxonomy term entity

    Module: Taxonomy (Drupal Core)
    Class: Drupal\taxonomy\Entity\Term
    Related article: Migrating taxonomy terms and multivalue fields into Drupal

    List of base field definitions:

    1. tid: (integer) The term ID.
    2. uuid: (uuid) The term UUID.
    3. revision_id: (integer) Revision ID.
    4. langcode: (language) The term language code.
    5. vid: (entity_reference to taxonomy_vocabulary) The vocabulary to which the term is assigned.
    6. revision_created: (created) The time that the current revision was created.
    7. revision_user: (entity_reference to user) The user ID of the author of the current revision.
    8. revision_log_message: (string_long) Briefly describe the changes you have made.
    9. status: (boolean) Published.
    10. name: (string) Name.
    11. description: (text_long) Description.
    12. weight: (integer) The weight of this term in relation to other terms.
    13. parent: (entity_reference to taxonomy_term) The parents of this term. Allows unlimited values.
    14. changed: (changed) The time that the term was last edited.
    15. default_langcode: (boolean) A flag indicating whether this is the default translation.
    16. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    17. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
    18. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
    File entity

    Module: File (Drupal Core)
    Class: Drupal\file\Entity\File
    Related articles: Migrating files and images into Drupal, Migrating images using the image_import plugin, and Migrating images using the image_import plugin

    List of base field definitions:

    1. fid: (integer) The file ID.
    2. uuid: (uuid) The file UUID.
    3. langcode: (language) The file language code.
    4. uid: (entity_reference to user) The user ID of the file.
    5. filename: (string) Name of the file with no path components.
    6. uri: (file_uri) The URI to access the file (either local or remote).
    7. filemime: (string) The file's MIME type.
    8. filesize: (integer) The size of the file in bytes.
    9. status: (boolean) The status of the file, temporary (FALSE) and permanent (TRUE).
    10. created: (created) The timestamp that the file was created.
    11. changed: (changed) The timestamp that the file was last changed.
    Media entity

    Module: Media (Drupal Core)
    Class: Drupal\media\Entity\Media

    List of base field definitions:

    1. mid: (integer) The media ID.
    2. uuid: (uuid) The media UUID.
    3. vid: (integer) Revision ID.
    4. langcode: (language) Language code (e.g. en).
    5. bundle: (entity_reference to media_type) Media type.
    6. revision_created: (created) The time that the current revision was created.
    7. revision_user: (entity_reference to user) The user ID of the author of the current revision.
    8. revision_log_message: (string_long) Briefly describe the changes you have made.
    9. status: (boolean) Published.
    10. uid: (entity_reference to user) The user ID of the author.
    11. name: (string) Name.
    12. thumbnail: (image) The thumbnail of the media item.
    13. created: (created) The time the media item was created.
    14. changed: (changed) The time the media item was last edited.
    15. default_langcode: (boolean) A flag indicating whether this is the default translation.
    16. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    17. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
    18. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.

    List of field storage configurations:

    1. field_media_audio_file: file field.
    2. field_media_document: file field.
    3. field_media_image: image field.
    4. field_media_oembed_video: string field.
    5. field_media_video_file: file field.
    Comment entity

    Module: Comment (Drupal Core)
    Class: Drupal\comment\Entity\Comment

    List of base field definitions:

    1. cid: (integer) The comment ID.
    2. uuid: (uuid) The comment UUID.
    3. langcode: (language) The comment language code.
    4. comment_type: (entity_reference to comment_type) The comment type.
    5. status: (boolean) Published.
    6. uid: (entity_reference to user) The user ID of the comment author.
    7. pid: (entity_reference to comment) The parent comment ID if this is a reply to a comment.
    8. entity_id: (entity_reference to node) The ID of the entity of which this comment is a reply.
    9. subject: (string) Subject.
    10. name: (string) The comment author's name.
    11. mail: (email) The comment author's email address.
    12. homepage: (uri) The comment author's home page address.
    13. hostname: (string) The comment author's hostname.
    14. created: (created) The time that the comment was created.
    15. changed: (changed) The time that the comment was last edited.
    16. thread: (string) The alphadecimal representation of the comment's place in a thread, consisting of a base 36 string prefixed by an integer indicating its length.
    17. entity_type: (string) The entity type to which this comment is attached.
    18. field_name: (string) The field name through which this comment was added.
    19. default_langcode: (boolean) A flag indicating whether this is the default translation.

    List of field storage configurations:

    1. comment_body: text_long field.
    Aggregator feed entity

    Module: Aggregator (Drupal Core)
    Class: Drupal\aggregator\Entity\Feed

    List of base field definitions:

    1. fid: (integer) The ID of the aggregator feed.
    2. uuid: (uuid) The aggregator feed UUID.
    3. langcode: (language) The feed language code.
    4. title: (string) The name of the feed (or the name of the website providing the feed).
    5. url: (uri) The fully-qualified URL of the feed.
    6. refresh: (list_integer) The length of time between feed updates. Requires a correctly configured cron maintenance task.
    7. checked: (timestamp) Last time feed was checked for new items, as Unix timestamp.
    8. queued: (timestamp) Time when this feed was queued for refresh, 0 if not queued.
    9. link: (uri) The link of the feed.
    10. description: (string_long) The parent website's description that comes from the element in the feed.
    11. image: (uri) An image representing the feed.
    12. hash: (string) Calculated hash of the feed data, used for validating cache.
    13. etag: (string) Entity tag HTTP response header, used for validating cache.
    14. modified: (timestamp) When the feed was last modified, as a Unix timestamp.
    Aggregator feed item entity

    Module: Aggregator (Drupal Core)
    Class: Drupal\aggregator\Entity\Item

    List of base field definitions:

    1. iid: (integer) The ID of the feed item.
    2. langcode: (language) The feed item language code.
    3. fid: (entity_reference to aggregator_feed) The aggregator feed entity associated with this item.
    4. title: (string) The title of the feed item.
    5. link: (uri) The link of the feed item.
    6. author: (string) The author of the feed item.
    7. description: (string_long) The body of the feed item.
    8. timestamp: (created) Posted date of the feed item, as a Unix timestamp.
    9. guid: (string_long) Unique identifier for the feed item.
    Custom block entity

    Module: Custom Block (Drupal Core)
    Class: Drupal\block_content\Entity\BlockContent

    List of base field definitions:

    1. id: (integer) The custom block ID.
    2. uuid: (uuid) The custom block UUID.
    3. revision_id: (integer) The revision ID.
    4. langcode: (language) The custom block language code.
    5. type: (entity_reference to block_content_type) The block type.
    6. revision_created: (created) The time that the current revision was created.
    7. revision_user: (entity_reference to user) The user ID of the author of the current revision.
    8. revision_log: (string_long) The log entry explaining the changes in this revision.
    9. status: (boolean) Published.
    10. info: (string) A brief description of your block.
    11. changed: (changed) The time that the custom block was last edited.
    12. reusable: (boolean) A boolean indicating whether this block is reusable.
    13. default_langcode: (boolean) A flag indicating whether this is the default translation.
    14. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    15. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
    16. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.

    List of field storage configurations:

    1. body: text_with_summary field.
    Contact message entity

    Module: Contact (Drupal Core)
    Class: Drupal\contact\Entity\Message

    List of base field definitions:

    1. uuid: (uuid) The message UUID.
    2. langcode: (language) The message language code.
    3. contact_form: (entity_reference to contact_form) The ID of the associated form.
    4. name: (string) The name of the person that is sending the contact message.
    5. mail: (email) The email of the person that is sending the contact message.
    6. subject: (string) Subject.
    7. message: (string_long) Message.
    8. copy: (boolean) Whether to send a copy of the message to the sender.
    9. recipient: (entity_reference to user) The ID of the recipient user for personal contact messages.
    Content moderation state entity

    Module: Content Moderation (Drupal Core)
    Class: Drupal\content_moderation\Entity\ContentModerationState

    List of base field definitions:

    1. id: (integer) ID.
    2. uuid: (uuid) UUID.
    3. revision_id: (integer) Revision ID.
    4. langcode: (language) Language.
    5. uid: (entity_reference to user) The username of the entity creator.
    6. workflow: (entity_reference to workflow) The workflow the moderation state is in.
    7. moderation_state: (string) The moderation state of the referenced content.
    8. content_entity_type_id: (string) The ID of the content entity type this moderation state is for.
    9. content_entity_id: (integer) The ID of the content entity this moderation state is for.
    10. content_entity_revision_id: (integer) The revision ID of the content entity this moderation state is for.
    11. default_langcode: (boolean) A flag indicating whether this is the default translation.
    12. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    13. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
    URL alias entity

    Module: Path alias (Drupal Core)
    Class: Drupal\path_alias\Entity\PathAlias

    List of base field definitions:

    1. id: (integer) ID.
    2. uuid: (uuid) UUID.
    3. revision_id: (integer) Revision ID.
    4. langcode: (language) Language.
    5. path: (string) The path that this alias belongs to.
    6. alias: (string) An alias used with this path.
    7. status: (boolean) Published.
    8. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    9. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
    Shortcut link entity

    Module: Shortcut (Drupal Core)
    Class: Drupal\shortcut\Entity\Shortcut

    List of base field definitions:

    1. id: (integer) The ID of the shortcut.
    2. uuid: (uuid) The UUID of the shortcut.
    3. langcode: (language) The language code of the shortcut.
    4. shortcut_set: (entity_reference to shortcut_set) The bundle of the shortcut.
    5. title: (string) The name of the shortcut.
    6. weight: (integer) Weight among shortcuts in the same shortcut set.
    7. link: (link) The location this shortcut points to.
    8. default_langcode: (boolean) A flag indicating whether this is the default translation.
    Workspace entity

    Module: Workspaces (Drupal Core)
    Class: Drupal\workspaces\Entity\Workspace

    List of base field definitions:

    1. id: (string) The workspace ID.
    2. uuid: (uuid) UUID.
    3. revision_id: (integer) Revision ID.
    4. uid: (entity_reference to user) The workspace owner.
    5. label: (string) The workspace name.
    6. parent: (entity_reference to workspace) The parent workspace.
    7. changed: (changed) The time that the workspace was last edited.
    8. created: (created) The time that the workspace was created.
    9. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    Custom menu link entity

    Module: Custom Menu Links (Drupal Core)
    Class: Drupal\menu_link_content\Entity\MenuLinkContent

    List of base field definitions:

    1. id: (integer) The entity ID for this menu link content entity.
    2. uuid: (uuid) The content menu link UUID.
    3. revision_id: (integer) Revision ID.
    4. langcode: (language) The menu link language code.
    5. bundle: (string) The content menu link bundle.
    6. revision_created: (created) The time that the current revision was created.
    7. revision_user: (entity_reference to user) The user ID of the author of the current revision.
    8. revision_log_message: (string_long) Briefly describe the changes you have made.
    9. enabled: (boolean) A flag for whether the link should be enabled in menus or hidden.
    10. title: (string) The text to be used for this link in the menu.
    11. description: (string) Shown when hovering over the menu link.
    12. menu_name: (string) The menu name. All links with the same menu name (such as "tools") are part of the same menu.
    13. link: (link) The location this menu link points to.
    14. external: (boolean) A flag to indicate if the link points to a full URL starting with a protocol, like http:// (1 = external, 0 = internal).
    15. rediscover: (boolean) Indicates whether the menu link should be rediscovered.
    16. weight: (integer) Link weight among links in the same menu at the same depth. In the menu, the links with high weight will sink and links with a low weight will be positioned nearer the top.
    17. expanded: (boolean) If selected and this menu link has children, the menu will always appear expanded. This option may be overridden for the entire menu tree when placing a menu block.
    18. parent: (string) The ID of the parent menu link plugin, or empty string when at the top level of the hierarchy.
    19. changed: (changed) The time that the menu link was last edited.
    20. default_langcode: (boolean) A flag indicating whether this is the default translation.
    21. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    22. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
    23. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
    Paragraph entity

    Module: Paragraphs module
    Class: Drupal\paragraphs\Entity\Paragraph
    Related article: Introduction to paragraphs migrations in Drupal

    List of base field definitions:

    1. id: (integer) ID.
    2. uuid: (uuid) UUID.
    3. revision_id: (integer) Revision ID.
    4. langcode: (language) The paragraphs entity language code.
    5. type: (entity_reference to paragraphs_type) Paragraph type.
    6. status: (boolean) Published.
    7. created: (created) The time that the Paragraph was created.
    8. parent_id: (string) The ID of the parent entity of which this entity is referenced.
    9. parent_type: (string) The entity parent type to which this entity is referenced.
    10. parent_field_name: (string) The entity parent field name to which this entity is referenced.
    11. behavior_settings: (string_long) The behavior plugin settings
    12. default_langcode: (boolean) A flag indicating whether this is the default translation.
    13. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    14. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
    15. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.

    List of field storage configurations:

    1. field_reusable_paragraph: entity_reference field.
    Paragraphs library item entity

    Module: Paragraphs Library (part of paragraphs module)
    Class: Drupal\paragraphs_library\Entity\LibraryItem

    List of base field definitions:

    1. id: (integer) ID.
    2. uuid: (uuid) UUID.
    3. revision_id: (integer) Revision ID.
    4. langcode: (language) Language.
    5. revision_created: (created) The time that the current revision was created.
    6. revision_uid: (entity_reference to user) The user ID of the author of the current revision.
    7. revision_log: (string_long) Briefly describe the changes you have made.
    8. status: (boolean) Published.
    9. label: (string) Label.
    10. paragraphs: (entity_reference_revisions) Paragraphs.
    11. created: (created) The time that the library item was created.
    12. changed: (changed) The time that the library item was last edited.
    13. uid: (entity_reference to user) The user ID of the library item author.
    14. default_langcode: (boolean) A flag indicating whether this is the default translation.
    15. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    16. revision_translation_affected: (boolean) Indicates if the last edit of a translation belongs to current revision.
    17. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
    Profile entity

    Module: Profile module
    Class: Drupal\profile\Entity\Profile

    List of base field definitions:

    1. profile_id: (integer) ID.
    2. uuid: (uuid) UUID.
    3. revision_id: (integer) Revision ID.
    4. type: (entity_reference to profile_type) Profile type.
    5. revision_created: (created) The time that the current revision was created.
    6. revision_user: (entity_reference to user) The user ID of the author of the current revision.
    7. revision_log_message: (string_long) Briefly describe the changes you have made.
    8. status: (boolean) Whether the profile is active.
    9. uid: (entity_reference to user) The user that owns this profile.
    10. is_default: (boolean) Whether this is the default profile.
    11. data: (map) A serialized array of additional data.
    12. created: (created) The time when the profile was created.
    13. changed: (changed) The time when the profile was last edited.
    14. revision_default: (boolean) A flag indicating whether this was a default revision when it was saved.
    15. workspace: (entity_reference to workspace) Indicates the workspace that this revision belongs to.
    Available properties for other content entities

    This reference includes all core content entities and some provided by contributed modules. The next article will include a reference for Drupal Commerce content entities. That being said, it would be impractical to cover all contributed modules. To get a list of yourself for other content entities, load the entity_type.manager service and call its getFieldStorageDefinitions() method passing the machine name of the entity as a parameter. Although this reference only covers content entities, the same process can be used for configuration entities.

    What did you learn in today’s article? Did you know that there were so many entity properties in Drupal core? Were you aware that the list of available properties depend on factors like if the entity is fieldable, translatable, and revisionable? Did you know how to find properties for content entities from contributed modules? Please share your answers in the comments. Also, we would be grateful if you shared this article with your friends and colleagues.

    Read more and discuss at agaric.coop.

    OSTraining: How to Use the Recaptcha Module in Drupal 8

    4 days 22 hours ago

    The reCAPTCHA module for Drupal 8 integrates the reCAPTCHA service provided by Google with your Drupal site. This service provides additional protection by detecting if the user accessing your site is a real person or a robot. 

    Keep reading to learn how to use this module!

    PreviousNext: Testing Twig templates and custom JavaScript with Jest

    5 days 3 hours ago

    Jest is the defacto standard for testing in modern JavaScript but we've traditionally not been able to leverage it for testing in Drupal.

    But with twig-testing-library, we can now test our twig templates and any dynamic behaviours added by Javascript using Jest.

    In this article we will go through the process of adding Jest based testing to an existing accordion component.

    by lee.rowlands / 9 July 2020 Installation

    Firstly we need to install twig-testing-library and jest

    npm i --save-dev twig-testing-library jest

    And we're also going to add additional dom-based Jest asserts using jest-dom

    npm i --save-dev @testing-library/jest-dom

    Now we need to configure Jest by telling it how to find our tests as well as configuring transpiling.

    In this project, we've got all of our components in folders in a /packages sub directory.

    So we create a jest.config.js file in the root with the following contents:

    // For a detailed explanation regarding each configuration property, visit: // https://jestjs.io/docs/en/configuration.html module.exports = { clearMocks: true, // Clear mocks on each test. testMatch: ['/packages/**/src/__tests__/**.test.js'], // How to find our tests. transform: { '^.+\\.js?$': `/jest-preprocess.js`, // Babel transforms. }, setupFilesAfterEnv: [`/setup-test-env.js`], // Additional setup. };

    For transpiling we're just using babel-jest and then chaining with our projects presets. The contents of jest-preprocess.js is as follows:

    const babelOptions = { presets: ['@babel/preset-env'], }; module.exports = require('babel-jest').createTransformer(babelOptions);

    As we're going to also use the Jest dom extension for additional Dom based assertions, our setup-test-environment takes care of that as well as some globals that Drupal JS expects to exist. The contents of our setup-test-env.js file is as follows:

    import '@testing-library/jest-dom/extend-expect'; global.Drupal = { behaviors: {}, }; Writing our first test

    Now we have the plumbing done, let's create our first test

    As per the pattern above, these need to live in a __tests__ folder inside the src folder of our components

    So let's create a test for the accordion component, by creating packages/accordion/src/__tests__/accordion.test.js

    Let's start with a basic test that the accordion should render and match a snapshot. This will pickup when there are changes in the markup and also verify that the template is valid.

    Here's the markup in the twig template

    <div class="accordion js-accordion"> {% block button %} <button class="button button--primary accordion__toggle">{{ title | default('Open Me') }}button> {% endblock %} <div class="accordion__content"> {% block content %} <h1>Accordion Contenth1> <p>This content is hidden inside the accordion body until it is disclosed by clicking the accordion toggle.p> {% endblock %} div> div>

    So let's render that with twig-testing-library and assert some things in packages/accordion/src/__tests__/accordion.test.js

    import { render } from 'twig-testing-library'; describe('Accordion functionality', () => { it('Should render', async () => { expect.assertions(2); const { container } = await render( './packages/accordion/src/accordion.twig', { title: 'Accordion', open: false, }, ); expect(container).toMatchSnapshot(); expect(container.querySelectorAll('.accordion__toggle')).toHaveLength(1); }); }); Running the tests

    So let's run our first test by adding a jest command to our package.json under "scripts"

    "jest": "jest --runInBand"

    Now we run with

    npm run jest > jest --runInBand PASS packages/accordion/src/__tests__/accordion.test.js Accordion functionality ✓ Should render (43 ms) Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total Snapshots: 1 passed, 1 total Time: 4.62 s, estimated 6 s Ran all test suites. Testing dynamic behaviour

    Now we know our template renders, and we're seeing some expected output, let's test that we can expand and collapse our accordion.

    Our accordion JS does the following:

    • On click of the accordion title, expands the element by adding accordion--open class and sets the aria-expanded attribute
    • On click again, closes the accordion by removing the class and attribute

    So let's write a test for that - by adding this to our existing test:

    it('Should expand and collapse', async () => { expect.assertions(4); const { container, getByText } = await render( './packages/accordion/src/accordion.twig', { title: 'Open accordion', }, ); const accordionElement = container.querySelector( '.accordion:not(.processed)', ); const accordion = new Accordion(accordionElement); accordion.init(); const accordionToggle = getByText('Open accordion'); fireEvent.click(accordionToggle); expect(accordionElement).toHaveClass('accordion--open'); expect(accordionToggle).toHaveAttribute('aria-expanded', 'true'); fireEvent.click(accordionToggle); expect(accordionElement).not.toHaveClass('accordion--open'); expect(accordionToggle).toHaveAttribute('aria-expanded', 'false'); });

    Now let's run that

    npm run jest packages/accordion/src/__tests__/accordion.test.es6.js Accordion functionality ✓ Should render (29 ms) ✓ Should expand and collapse (20 ms) Test Suites: 1 passed, 1 total Tests: 2 passed, 2 total Snapshots: 1 passed, 1 total Time: 5.031 s, estimated 6 s Ran all test suites.

    Neat! We now have some test coverage for our accordion component

    Next steps

    So the neat thing about Jest is, it can collect code-coverage, let's run that

    npm run jest -- --coverage packages/accordion/src/__tests__/accordion.test.es6.js Accordion functionality ✓ Should render (28 ms) ✓ Should expand and collapse (13 ms) -------------------|---------|----------|---------|---------|-------------------- File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s -------------------|---------|----------|---------|---------|-------------------- All files | 29.55 | 11.27 | 24.14 | 30 | accordion/src | 100 | 85.71 | 100 | 100 | accordion.es6.js | 100 | 85.71 | 100 | 100 | 53 base/src | 11.43 | 3.13 | 4.35 | 11.65 | utils.es6.js | 11.43 | 3.13 | 4.35 | 11.65 | 14,28,41-48,58-357 -------------------|---------|----------|---------|---------|-------------------- Test Suites: 1 passed, 1 total Tests: 2 passed, 2 total Snapshots: 1 passed, 1 total Time: 2.813 s, estimated 5 s Ran all test suites.

    Pretty nice hey?

    What's happening behind the scenes

    If you've worked on a React project before, you've probably encountered Dom testing library and React testing library. Twig testing library aims to provide the same developer ergonomics as both of these libraries. If you've familiar with either of those, you should find Twig testing library's API's comparable.

    Under the hood it's using Twig.js for Twig based rendering in JavaScript and Jest uses jsdom for browser JavaScript APIs.

    A longer introduction

    I did a session on using this for a Drupal South virtual meetup, here's the recording of it.

    Get involved

    If you'd like to get involved, come say hi on github.

    Tagged Front End Development, Testing, Jest, JavaScript

    Lullabot: Alternatives to Upgrading from Drupal 7 to Drupal 9

    5 days 8 hours ago

    Drupal 9 was recently released, Drupal 8 will reach end-of-life November 2021, and Drupal 7’s life will expire in November 2022 (the date was extended due to COVID-19). With a window of a little under a year and a half to upgrade from 7 to 9, it's time to make a plan, or pursue other options if that timeline isn't viable. But what other options are there?

    Mobomo: How Drupal manages Accessibility

    5 days 9 hours ago

    Businesses and governments build websites for one reason: to provide value to their users. But what if your website was incapable of reaching millions of your users? 25% of Americans live with disabilities. For some of them, the simple act of navigating websites, digesting information, and understanding your content is difficult. Yet, despite brands increasing spending on web design and digital marketing, less than 10% of websites actually follow accessibility standards. Businesses are spending significant money to capture an audience, yet they’re not ensuring that their audience can engage with their website.

    It’s a problem—a big one.

    You don’t want to exclude customers. It’s bad for business, and it’s bad for your brand. Better yet, accessibility features help improve your SEO, reduce your website complexity, and increase your ability to connect with your loyal audience. But accessibility standards aren’t always baked into the architecture of websites.

    Luckily, there are some content management systems (CMS) that let you create hyper-accessible websites without even trying. Drupal comes equipped with a variety of accessibility features — each of which helps make your website more accessible for your customers.

    Understanding the Importance of Website Accessibility

    Creating an accessible website may sound vague, but there’s already a worldwide standard you can follow. The Web Content Accessibility Guidelines (WCAG) — which is maintained by The World Wide Web Consortium — is the global standard for web accessibility used by companies, governments, and merchants across the world.

    Sure! Following the WCAG standard helps you reach a wider audience. But it also keeps you out of legal hot water. Not only has the ADA made it abundantly clear that compliance requires website accessibility. A United States District Court in Florida ruled that WCAG standards are the de facto standards of web accessibility. And there are already cases of businesses getting sued for failing to adhere to them.

    • The DOJ sues H&R Block over its website’s accessibility.
    • WinnDixie.com was sued for accessibility, and the judge required them to update their website.
    • The National Museum of Crime and Punishment was required to update its website accessibility.

    The list goes on. Adhering to WCAG web accessibility standards helps protect your brand against litigation. But, more importantly, it opens doors to millions of customers who need accessibility to navigate and engage with your amazing content.

    One-third of individuals over the age of 65 have hearing loss. Around 15% of Americans struggle with vision loss. And millions have issues with mobility. The CDC lists six forms of disability:

    • Mobility (difficulty walking or climbing)
    • Cognition (difficult remembering, making decisions, or concentrating)
    • Hearing (difficulty hearing)
    • Vision (difficulty seeing)
    • Independent living (difficulty doing basic errands)
    • Self-care (difficulty bathing, dressing, or taking care of yourself)

    Web accessibility touches all of those types of disabilities. For those with trouble seeing, screen readers help them comprehend websites. But, screen readers strip away the CSS layer. Your core content has to be accessible for them to be able to comprehend it. Those with mobility issues may need to use keyboard shortcuts to help them navigate your website. Hearing-impaired individuals may require subtitles and captions. Those with cognitive issues may need your website to be built with focusable elements and good contrasting.

    There are many disabilities. WCAG creates a unified guideline that helps government entities and businesses build websites that are hyper-accessible to people with a wide range of these disabilities.

    Drupal is WCAG-compliant

    WCAG is vast. A great starting point is the Accessibility Principles document. But, creating an accessible website doesn’t have to be a time-consuming and expensive process. Drupal has an entire team dedicated to ensuring that their platform is WCAG compliant. In fact, Drupal is both WCAG 2.0 compliant and Authoring Tool Accessibility Guidelines (ATAG 2.0) compliant. The latter deals with the tools developers use to build websites. So, Drupal has accessibility compliance on both ends.

    What Accessibility Features Does Drupal Have?

    Drupal’s accessibility compliance comes in two forms:

    1. Drupal has built-in compliance features that are native to every install (7+).
    2. Drupal supports and enables the community to develop accessibility modules.
    Drupal’s Built-in Compliance Features

    Drupal 7+ comes native with semantic markup. To keep things simple, semantic markup helps clarify the context of content. At Mobomo, we employ some of the best designers and website developers on the planet. So, we could make bad HTML markup nearly invisible to the average user with rich CSS and superb visuals. But when people use screen readers or other assistive technology, that CSS goes out-of-the-window. They’re looking at the core HTML markup. And if it’s not semantic, they may have a difficult time navigating it. With Drupal, markup is automatically semantic — which breeds comprehension for translation engines, search engines, and screen readers.

    Drupal’s accessibility page also notes some core changes made to increase accessibility. These include things such as color contrasting. WCAG requires that color contrasting be at least 4.5:1 for normal text and 7:1 for enhanced contrast. Drupal complies with those guidelines. Many other changes are on the developer side, such as drag and drop functions and automated navigation buttons.

    Of course, Drupal also provides developer handbooks, theming guides, and instructional PDFs for developers. Some of the accessibility is done on the developer’s end, so it’s important to work with a developer who leverages accessibility during their design process.

    Drupal’s Support for the Accessibility Community

    In addition to following WCAG guidelines, Drupal supports community-driven modules that add additional accessibility support. Here are a few examples of Drupal modules that focus on accessibility:

    There are hundreds. The main thing to remember is that Drupal supports both back-end, front-end, and community-driven accessibility. And they’ve committed to continuously improving their accessibility capabilities over time. Drupal’s most recent update — the heavily anticipated Drupal 9 — carries on this tradition. Drupal has even announced that Drupal 10 will continue to expand upon accessibility.

    Do You Want to Build an Accessible Website

    Drupal is on the cutting-edge of CMS accessibility. But they can’t make you accessible alone. You need to build your website from the ground up to comply with accessibility. A good chunk of the responsibility is in the hands of your developer. Are you looking to build a robust, functional, beautiful, and accessible website? 

    Contact us. We’ll help you expand your reach.

    The post How Drupal manages Accessibility appeared first on .

    Tag1 Consulting: How Drupal can make true shared components a reality - part 1

    5 days 13 hours ago

    Front-end development workflows have seen considerable innovation in recent years, with technologies like React disseminating revolutionary concepts like declarative components in JSX and more efficient document object model (DOM) diffing through Virtual DOMs. Nonetheless, while this front-end development revolution has led to significant change in the developer experiences we see in the JavaScript landscape and to even more momentum in favor of decoupled Drupal architectures in the Drupal community, it seems that many traditional CMSs have remained behind the curve when it comes to enabling true shared component ecosystems through developer experiences that focus on facilitating shared development practices across back and front end. At DrupalCon Amsterdam 2019, Fabian Franz (Senior Technical Architect and Performance Lead at Tag1) delivered a session entitled "Components everywhere: Bridging the gap between back end and front end" that delved into his ideal vision for enabling such shared components in Drupal's own native rendering layer. Fabian joined Michael Meyers (Managing Director at Tag1), and me (Preston So, Editor in Chief at Tag1; Senior Director, Product Strategy at Oracle; and author of Decoupled Drupal in Practice) for a Tag1 Team Talks episode highlighting the progress other ecosystems have made in the face of this problem space...

    Read more preston Wed, 07/08/2020 - 05:59
    Checked
    7 hours 49 minutes ago
    Drupal.org - aggregated feeds in category Planet Drupal
    Subscribe to Drupal Planet feed
    Category
  • Dries

    The first ever virtual DrupalCon

    3 days 13 hours ago

    I remember the first gathering of Drupal contributors back in 2005. At the time, there were less than 50 people in attendance. In the 15 years since that first gathering, DrupalCon has become the heartbeat of the Drupal community. With each new DrupalCon, we introduce new people to our community, demonstrate the best that Drupal has to offer, and reconnect with our Drupal family.

    Next week's DrupalCon Global is going to be no different.

    Because of COVID-19, it is the first DrupalCon that will be 100% virtual. But as much as we may miss seeing each other in person, the switch to virtual has opened opportunities to bring in speakers and attendees who never would have been able to attend otherwise.

    There are a few moments I'm particularly excited about:

    • Mitchell Baker, CEO and Chair of the Mozilla Foundation, is joining us to talk about the future of the Open Web, and the importance of Open Source software.
    • Jacqueline Gibson, Digital Equity Advocate and Software Engineer from Microsoft, will be talking about Digital Inequity for the Black community – a topic I believe is deeply important for our community and the world.
    • Leaders of current Drupal strategic initiatives will be presenting their progress and their calls for action to keep Drupal the leading CMS on the web.
    • And of course, I'll be giving my keynote presentation to celebrate the community's accomplishment in releasing Drupal 9, and to talk about Drupal's future.

    Beyond the sessions, I look forward to the human element of the conference. The side conversations and reunions with old friends make attending DrupalCon so much more powerful than simply watching the recordings after the fact. I hope to see you at DrupalCon Global next week!

    Dries

    Caring for old software

    2 weeks 4 days ago

    Given the impact of COVID-19 on organizations' budgets, we extended Drupal 7's end-of-life date by one year. Drupal 7 will receive security updates until November 2022, instead of November 2021. For more information, see the official announcement.

    Extending the lifetime of Drupal 7 felt like the right thing to do. It's aligned with Drupal's goal to build software that is safe for everyone to use.

    I wish more software was well-maintained like Drupal is. We released Drupal 7 almost a decade ago and continue to care for it.

    We often recognize those who help innovate or introduce new features. But maintaining existing Open Source software also relies on the contributions of individuals and organizations. Today, I'd like us to praise those who maintain and improve Drupal 7. Thank you!

    Dries

    Mautic 3 released (and other important changes)

    3 weeks 6 days ago

    A year ago, Acquia acquired Mautic. Mautic is an Open Source marketing automation and campaign management platform.

    Some of you have been wondering: What has been going on since the acquisition?. It's high time for an update!

    Mautic 3 released

    Mautic 3 was released last night. It is the first major release in four years, and a big milestone!

    I'd like to extend a big thank you to everyone who contributed to Mautic 3. I'm also proud to say that Acquia was the largest contributor.

    For me personally, it was nice to see some long-term Drupal developers contribute to Mautic 3. When Acquia acquired Mautic, I hoped to see cross-pollination between Drupal and Mautic.

    A streamlined release model for Mautic 4

    The Mautic 3 release was mostly an "under the hood" release. The focus was on upgrading and modernizing Mautic's underlying frameworks (e.g. Symfony and other dependencies).

    We want Mautic 4 to offer some much-requested new features. In order to do so, Mautic is switching to a new innovation and release model. Instead of having to wait almost four years for a major release with new features, there will be four Mautic releases with new features each year.

    The Drupal community went through a similar transformation five years ago. The Drupal community now brings more value to its users in less time. Because of the faster innovation cycle, Drupal also has more active contributors than ever before.

    A quarterly release cycle creates a healthy heartbeat for an Open Source project. You can expect Mautic to deliver improvements more frequently and predictably moving forward.

    A streamlined governance model

    As a young Open Source project, Mautic was lacking clearly defined roles and responsibilities. For example, it was unclear to many (including me) how the Open Source project and Mautic, Inc., the for-profit company, best collaborated.

    With the acquisition by Acquia, the need for clear roles and responsibilities became even more called for.

    One of the first things Acquia did post-acquisition was to develop a new governance model in collaboration with the Mautic community.

    Mautic's new governance model defines different teams and working groups, how the community and Acquia collaborate, and more. With roles and responsibilities more clearly defined, we can go faster together.

    A new project lead

    I'm also excited to share that Ruth Cheesley is Mautic's new Project Lead.

    Ruth has been involved with Mautic for a long time, and prior to Mautic, was on Joomla!'s Community Leadership Team. She is also a member of Drupal's Community Working Group. Ruth works at Acquia. As she is part of my team, I've been working closely with Ruth for the past 6+ months and could not be more excited about her involvement and new role.

    Ruth has the full support of Acquia, Mautic's community leadership team, and DB Hurley, Mautic's founder and previous Project Lead. A big thank you to DB for his leadership and having guided Mautic thus far — getting an Open Source project off the ground and to this stage is no small feat.

    Conclusions

    With a new governance model, leadership structure, as well as a new release and innovation model for Mautic, we're set up well to accelerate and innovate for the long run.

    Dries
    Checked
    7 hours 49 minutes ago
    Subscribe to Dries feed
    Category