Drupal (core)

Our normally scheduled call to chat about all things Drupal and nonprofits will happen TODAY, Thursday, February 17 at 1pm ET / 10am PT. (Convert to your local time zone.) We don't have anything on the agenda at the moment, so we're looking to enjoy ... [More] an informal chat about anything at the intersection of Drupal and nonprofits. Got something specific on your mind? Feel free to share ahead of time in our collaborative Google doc: https://nten.org/drupal/notes! All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call. This free call is sponsored by NTEN.org and open to everyone. Join the call: https://us02web.zoom.us/j/81817469653 Meeting ID: 818 1746 9653 Passcode: 551681 One tap mobile: +16699006833,,81817469653# US (San Jose) +13462487799,,81817469653# US (Houston) Dial by your location: +1 669 900 6833 US (San Jose) +1 346 248 7799 US (Houston) +1 253 215 8782 US (Tacoma) +1 929 205 6099 US (New York) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) Find your local number: https://us02web.zoom.us/u/kpV1o65N Follow along on Google Docs: https://nten.org/drupal/notes Follow along on Twitter: #npdrupal View notes of previous months' calls. [Less]

2 years ago Drupal JSON:API support was released in Core, this was a huge milestone. The focus on JSON:API is what is enabling Drupal to become a project beyond PHP, and is enabling more JavaScript components, Decoupled Drupal applications and ... [More] easier integrations with 3rd parties and tools and applications. It’s time to look ahead to the challenges Drupal faces and how JSON:API will have to grow to keep Drupal ahead in the game. Facilitating JS components and Decoupled architectures. But also paving the way for Drupal to slot into any composable architecture. Help shape the future of Drupal's JSON:API I joined the Drupal JSON:API team last summer to help move it forward faster. Since then quite a few bugs have been fixed, new PHP API's through hooks and events have been added and a lot of inconsistencies have been fixed. Today we ask for your help. Are you using JSON:API to build decoupled applications or integrate Drupal in your organization's IT landscape? Consider filling out our survey. The results of the survey will be used as the basis of the Drupal JSON:API roadmap for next year. Developing what the community and Drupal needs to stay relevant. Take 5 minutes to fill out our survey Filling in the survey takes about 5 minutes helps us out tremendously. The survey will be open for 3 weeks, closing on the 1st of march. Start the survey The results of this survey will not be sold or shared with 3rd parties. The results will be analysed and published publicly without any identifiable reference to individual submissions. Thank you! Björn Brala, Mateu Aguiló Bosch, Gabe Sullice and Wim Leers Special thanks to Laim Hockley, Stuart Clark, Joe Shindelar and Baddy Sonja for their help creating this survey and SWIS for sponsoring Björn Brala's time and surveymonkey account. [Less]

My last post about letting a robot update your website was based on some of the questions I got presenting the talk "Less human interaction, more security?" last year at Drupalcon North America. The talk is showing how we can discover and deploy ... [More] updates to our Drupal websites automatically, using tools like violinist.io and Gitlab CI. In addition to the feedback about automation being scary, the most asked question I get is around database updates. What about database updates? How do we handle them? How can they be done correct automatically? In this blog post I will outline my approach, why I use this approach, and why you might consider doing the same. The problem I use violinist.io to update all of my PHP projects (both at work and personal, including this blog). So let's say I receive an automated pull request from violinist.io with an update to Drupal core. Maybe this update has this piece of new code in it: /** * Clear caches due to behavior change in DefaultPluginManager. */ function system_update_8201() { // Empty update to cause a cache rebuild. } As we can see, this database update is actually empty, and only exists to make sure the cache is being cleared. Would this be OK to deploy automatically? For sure, no problem at all. Let's look at something different. Let's say I receive an automated pull request containing this update: /** * Notes on update for multilingual sites. */ function layout_builder_restrictions_update_8210() { $moduleHandler = \Drupal::service('module_handler'); if ($moduleHandler->moduleExists('locale')) { $message = t("Please note: since your site uses the Locale module, you will likely need to manually resave each Layout Builder Restriction entity configuration, due to new code that makes Layout Builder Restrictions' configuration multilingual compatible. For more information, see Layout Builder Restrictions version 2.6 release notes."); \Drupal::logger('layout_builder_restrictions')->warning($message); return $message; } } This database update is taken from a contributed module, and serves as an example of an update hook that would literally require human interaction. It says that you will likely need to resave and re-export your configuration. So trying to apply that database update automatically would most likely work great, but our configuration will now possibly be wrong since the automated update only contain changes to composer files. So the problem is that deploying database updates introduces unknown side effects. They might be harmless, they might not. Another problem is that it's hard to even know if an update contains a database update. A diff of a typical dependency update would probably only show something like this: }, { "name": "drupal/core", - "version": "9.3.2", + "version": "9.3.3", "source": { "type": "git", "url": "https://github.com/drupal/core.git", - "reference": "6c9ba6b6314550e7efb8f5f4e2a40f54cfd6aee1" + "reference": "a9bd68be9a4e39724ea555f8040114759a8faf7f" }, "dist": { "type": "zip", - "url": "https://api.github.com/repos/drupal/core/zipball/6c9ba6b6314550e7efb8f5f4e2a40f54cfd6aee1", - "reference": "6c9ba6b6314550e7efb8f5f4e2a40f54cfd6aee1", + "url": "https://api.github.com/repos/drupal/core/zipball/a9bd68be9a4e39724ea555f8040114759a8faf7f", + "reference": "a9bd68be9a4e39724ea555f8040114759a8faf7f", "shasum": "" }, "require": { Can you tell from that diff if there was a database update or not just by looking at it? The toolbox So the question then is: How do we identify these database updates and determine if we can apply them safely and automatically? The answer for me is: we don't. Instead we just always assume the worst, and err on the side of caution. So let's instead look at how we can identify a pending database update in the first place. When detected, we want to avoid the update being deployed automatically. To do that, I am going to use a technique we can combine with detecting another potentially disruptive trait of dependency updates: Changed files. This is not quite as common as database updates, and hopefully you mostly see this from either Drupal core or from a distribution you are using. Sometimes an upgrade can change some of your project files, for example robots.txt or .gitignore. In most cases these changes are useful and something you want to commit to your codebase. But just like database updates, we have no reliable way of determining what is useful and what is disruptive without human interaction. Which is why I am an advocate for failing a test suite when the working tree is not clean after running integration tests. This will then take care of the case of avoiding deploying an update that changes other files than composer.json / composer.lock. Now let's see how it can help us with database updates. The characterisation testing approach Enter site schema. A site schema is a big list of the "current" schema of your production website. The idea of a site schema borrows from a testing paradigm called characterisation testing, (or golden-master testing, snapshot testing and probably other names). It contains a list of all the currently applied hook_update_N updates, in addition to all the currently applied post updates. The site schema package is a drush command that makes it possible to produce a file for the site that represents your current working state. This in turn makes it possible to commit a file containing this state. Which in turn makes it easy to see which automated updates contain database updates. All we have to do is dump the site schema as part of our tests, and it would produce a diff in the committed site schema file, failing the tests, showing the dependency update contains a database update. Then when we want to deploy a dependency update that includes a database update, we also would have to commit an update to our site schema file. It's a way of manually approving the unknown side effect. So that sums up the why and how. We have looked at why applying database updates automatically on automated dependency updates can be harmful. We have touched on why it's hard to know whether a given database update can be harmful or not. Finally, we have looked at one way of detecting database updates, so we can avoid deploying these unknown results automatically. I also hope this has inspired some ideas on how you can do similar things in your own projects so you can have more automation in both dependency updates and deployment. If you need more inspiration, the next blog post will include examples of actual implementations of this in CI workflows. What I can say personally is that using this approach has greatly improved my confidence in deploying automated dependency updates that I am continuously getting from violinist.io. Are you still not convinced about automating boring maintenance tasks? Still think it sounds scary? Please let me know in the comments ✌️ I guess all that remains now is to finish off with an animated gif called "scary"! [Less]

With DrupalCon North America coming up in two months, now is the time to make arrangements for your stay in beautiful Portland, Oregon! When you’re booking your hotel, we ask you to book through the official DrupalCon Hotel Portal. When the Drupal ... [More] Association signed contracts for our forthcoming conferences in 2019, we contractually guaranteed a minimum amount of rooms sold. This means that if the room blocks do not meet a certain amount of room-nights sold, we are financially responsible for the difference. Because of lesser expected attendance (as a result of COVID), it’s not guaranteed we will meet these contractual minimums. By booking through the DrupalCon Hotel Portal, you can help us avoid paying the difference, which will enable more funding for Drupal infrastructure such as the Gitlab migration and Drupal.org improvements. In addition to helping out the Drupal Association, booking through the portal means Guaranteed lowest prices for these hotels. In fact, if you find a lower price anywhere else, screenshot it and send it over to us (along with a link). You stay in the hotel filled with other Drupal friends from around the world, filled with lively conversations in the hallways and lobbies. You’re physically closer to the convention center! Thank you for reading, and we’re looking forward to seeing you in Portland this April! [Less]

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one ... [More] of them! Today, there is a Critical security release for Drupal core to fix a Input Validation vulnerability. You can learn more in the security advisory: Drupal core - Critical - Cross-Site Scripting - SA-CORE-2021-002 Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ. If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-) Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org). [Less]

Project:  Drupal core Date:  2022-February-16 Security risk:  Moderately critical 12∕25 AC:None/A:User/CI:Some/II:None/E:Theoretical/TD:Default Vulnerability:  Information disclosure Description:  The Quick Edit module does not properly check ... [More] entity access in some circumstances. This could result in users with the "access in-place editing" permission viewing some content they are are not authorized to access. Sites are only affected if the QuickEdit module (which comes with the Standard profile) is installed. This advisory is not covered by Drupal Steward. Solution:  Install the latest version: If you are using Drupal 9.3, update to Drupal 9.3.6. If you are using Drupal 9.2, update to Drupal 9.2.13. All versions of Drupal 9 prior to 9.2.x are end-of-life and do not receive security coverage. Note that Drupal 8 has reached its end of life. Drupal 7 core does not include the QuickEdit module and therefore is not affected. Uninstalling the QuickEdit module will also mitigate the vulnerability. Site owners may wish to consider this option as the QuickEdit module will be removed from core in Drupal 10. Reported By:  Samuel Mortenson Fixed By:  Théodore Biadala xjm of the Drupal Security Team Alex Bronstein of the Drupal Security Team Adam G-H Drew Webber of the Drupal Security Team Wim Leers Ted Bowman Dave Long Derek Wright Lee Rowlands of the Drupal Security Team Samuel Mortenson Joseph Zhao [Less]

Project:  Drupal core Date:  2022-February-16 Security risk:  Moderately critical 14∕25 AC:Basic/A:None/CI:Some/II:Some/E:Theoretical/TD:Uncommon Vulnerability:  Improper input validation Description:  Drupal core's form API has a vulnerability ... [More] where certain contributed or custom modules' forms may be vulnerable to improper input validation. This could allow an attacker to inject disallowed values or overwrite data. Affected forms are uncommon, but in certain cases an attacker could alter critical or sensitive data. Also see Quick Edit - Moderately critical - Access bypass - SA-CONTRIB-2022-025 which addresses the same vulnerability for the contributed module. This advisory is not covered by Drupal Steward. Solution:  Install the latest version: If you are using Drupal 9.3, update to Drupal 9.3.6. If you are using Drupal 9.2, update to Drupal 9.2.13. If you are using Drupal 7, update to Drupal 7.88. All versions of Drupal 9 prior to 9.2.x are end-of-life and do not receive security coverage. Note that Drupal 8 has reached its end of life. Reported By:  Fabian Iwand Fixed By:  xjm of the Drupal Security Team Lee Rowlands of the Drupal Security Team Ben Dougherty of the Drupal Security Team Drew Webber of the Drupal Security Team Jen Lampton Nate Lampton Fabian Franz Alex Bronstein of the Drupal Security Team [Less]

It's that time again! Like the list of Drupal modules for 2021, we have made our list of top Drupal modules for 2022. This year's picks include migration power tools to help you prepare for Drupal 7's upcoming end of life, modules to improve ... [More] accessibility, and user experience, and modules to boost your website security and SEO. Some of our favourite modules are Drupal mainstays, while others are lesser-known. They range from very simple to rather elaborate, but they're all worth considering as you plan your next project. So now, let's check our list of top Drupal modules for 2022. This Year's List Migrate Plus Migrate Tools Location Migration Editoria11y Accessibility Checker View Password Entity Save and Add Another Scheduler Schema.org Metatag Search 404 Password policy Two-factor Authentication 💁‍♀️Need help with your Drupal project? Get in touch! Migrate Plus The Migrate Plus module is a pretty standard tool for migrating to Drupal 9. It allows migration plugins to be implemented as configuration entities, eliminating the need for server access to make adjustments. These configuration entities can be grouped and managed using GUI and command-line tools (such as those provided by Migrate Tools below). Grouping lets developers and administrators store common configurations in a single file and reuse them across multiple migrations and makes it easier to organize and manage complex projects with multiple migration types. Migrate Plus also provides a catalogue of migration plugins: Match source data to existing Drupal 8 or Drupal 9 entities Generate entities from source data Merge multiple source arrays into one array Set value matching rules to skip rows String transliteration to remove language decorations and accents such as in file names Migrate source data directly into SQL table Manage source URLs and fetchers to support file- and stream-based content Data fetching and parsing Other migration processes and tasks Submodules provide detailed, documented examples for implementing Drupal migrations. Migrate Tools The Migrate Tools module provides a variety of drush commands for managing and executing migrations, including imports and rollbacks, messages, and status reports. A user interface is also included for several of its drush commands and running migrations defined as configuration entities (see Migrate Plus above). Location Migration The Location Migration module migrates data from the CCK and entity fields previously enabled in Drupal 7 by the Location module and its submodules. Data including street addresses, phone numbers, email addresses, web addresses, and geocodes are mapped to the appropriate Drupal 8 or Drupal 9 field types: Street addresses to Address module fields Geocodes to Geolocation module fields Web addresses to the core link field Phone and fax numbers to core telephone fields As of this writing, the Location module statistics page shows over 32,000 sites still using the Location module. Migrating all those sites would mean a LOT of developer hours spent mapping the same fields from Drupal 7 to Drupal 9 over and over again. This module saves those hours and creates a standardized migration path for Location data on Drupal sites. 📖D9 migration: agency or in-house? Download our free eBook and see your best options Editoria11y Accessibility Checker There are several contributed modules available to help improve Drupal site accessibility. The Editoria11y Accessibility Checker got our attention for its easy integration into a content workflow and editor-friendly features. Editoria11y runs automatically, so editors do not have to remember to use it consciously. When a Node, View, Page Layout, or other entity is saved, Editoria11y scans the result for issues and flags potential errors. This method catches errors in the context of rendered pages rather than only at the field level. For example, a heading structure that appears correct in the node WYSIWYG can result in a messy document outline when added to the other page pieces; analyzing the rendered page makes it easier to discover and fix these conflicts. Flagged issues are limited to things editors can quickly fix themselves, like alt tags, link text, and heading structure. The interface uses icons to visually highlight where problems are found, and helper text clearly explains why this might be a problem and what a better solution would be. Users can toggle between highlighted issues, visual markup icons, and a clean document view. View Password The View Password module is one of those simple little things that makes a big difference. It provides the familiar "eye" icon on password fields, allowing the user to click and see their password as they've entered it. This may not suit specific systems, like those protecting sensitive financial and health information. In most cases, though, it's a helpful feature and is especially appreciated by mobile users prone to typos. Entity Save and Add Another The Entity Save and Add Another module addresses minor, almost invisible annoyances that can drag on the editor user experience. When saving their entity, rather than going back to the main listing screen for that type, the user can stay put and go straight into creating another entity of the same type. The module supports Node, Taxonomy, Block, and Menu entities. This is a lesser-used module, so you'll want to test your use cases thoroughly. Scheduler Scheduler has been around for a long time and does one thing: it schedules node publishing and unpublishing. The module integrates with Rules and Devel Generate and provides drush commands and date tokens. On Drupal 8 and 9, it integrates with the core Content Moderation module via the Scheduler Content Moderation Integration sub-module. Auditing and removing outdated content is critical for user experience and SEO. The Scheduler module allows editors to make this an ongoing part of their routine instead of a messy and time-consuming project. For more content auditing, check out our blog post on what you can learn from Marie Kondo about running a content audit. Schema.org Metatag In last year's Drupal Modules our Team Loves, 2021 Edition, we highlighted the Metatag module for its benefits in controlling how content is presented on social media. We're building on that idea in this year's list with the Schema.org Metatag module. If you aren't familiar with Schema.org, it provides a widely adopted set of standardized properties that help define your content's structure. That structure can be read by compatible systems like search engines, portals, mapping tools, social media platforms, and various other apps and tools. Adding this externally standardized structure to your site makes content more readily shareable and easier for users to find and can give your SEO a major boost. The Schema.org Metatag module provides tools to generate JSON LD code for your page headers. This code extracts associated data from your content with the correct Schema.org properties; these associations are configurable with tokens and managed by the Metatag module. In addition, this module supports mapping against an extensive list of common Schema.org data properties. Search 404 The 404 page can be a dead end, or it can be a helpful guide. The Search 404 module analyzes the bad URL for keywords and returns relevant internal search results. Users who click outdated or broken links from other sites and search indices receive helpful suggestions instead of being presented with the equivalent of a shrug and a "sorry." Generic 404 pages are an enormous missed opportunity to retain visitors and provide them with what they need. Thoughtful design and messaging and smart modules like Search 404 change the 404 page from a frustrating error message into a helpful resource. Password policy Unsurprisingly, the Password Policy module allows you to set a custom password policy for your site users. It allows for typical constraints, including length, alphanumeric rules, special characters, and recently used passwords. The module also provides password expiration and update requirements and forces users or roles to change their passwords on their next login. Senior Drupal Developer Kevin Porras provides Drupal security recommendations (including password policy) and a downloadable security checklist in Our Guide to Securing a Drupal Installation. Two-factor Authentication The Two-factor Authentication (TFA) module provides another security mainstay. Most people know that passwords are far too easy to crack or match against data breaches. Moreover, strong password practices might be impractical for the average user. Adding TFA helps protect against unauthorized access via automated cracking and simple password theft. The module provides an interface for integrating Drupal with a number of standard TFA tools, including temporary passwords, SMS and email codes, and third-party services. What Are Your Favourite Modules? So, that was our list. What about yours? What contrib modules are must-haves for your projects and migrations in 2022? Drop them in the comments and tell us how they make your projects better! Need Drupal training for your team? Check our upcoming courses, or contact us for custom training! + more awesome articles by Evolving Web [Less]

The Drupal Community Working Group (CWG) is holding open office hours on Thursday, March 3 1700-1800 UTC. This live online gathering will provide all members of the Drupal community with the opportunity to ask questions, hear about current efforts ... [More] , and find out how to get involved. The CWG is composed of both the Community Health Team (CHT) and the Conflict Resolution Team (CRT) . Members from both teams will be participating and be available for questions. The CHT develops and presents proactive ways to help educate the members of the Drupal community in community health related matters. It organizes and provides workshops, resources for Drupal event organizers and tools for community members. The CHT is always interested in hearing ideas about resources and ways it can serve the community. The CRT provides mediation and communication services for community members. Through our processes, we work with community members who are in disagreement to find common ground and tools for working through similar issues in the future. The CRT is eager to hear input from the community.  We want to hear from you. If you'd like to submit a question anonymously for office hours, please use this form. Otherwise, you are welcome to ask questions when you join us on March 3. The meeting will be held via Zoom; the link will be available in the Drupal Community's Slack workspace's #events channel prior to the starting time.  We value your privacy; the meeting will not be recorded.   [Less]

As a Drupal developer, you will often want to inspect variables in your modules or themes to view the actual values. PHP has default functions such as var_dump() and print_r() that will print all the information but it’s not very intuitive nor ... [More] printed in an easy to understand way. In most cases, it prints too much information and it can be time-consuming to find the variable you actually want by filtering through all the arrays and methods. Using Devel and the Devel Kint Extras modules, you can print variables in a more user-friendly way. This tutorial will walk through how to set up these modules so you can print variables in PHP and Twig using Kint. [Less]