Series Overview & ToC | Previous Article | Next Article - coming June 13th Now that we have covered how to prepare for a migration, let’s put that knowledge into practice. In this article we introduce the example project: a Drupal 7 site that we will be migrating to Drupal 10. After providing an overview of project setup, we will perform an audit of the Drupal 7 site and draft a migration plan to Drupal 10. ### Example repository The repository is available on Github. We will be using DDEV to set up local development environments for Drupal 7 and 10. Refer to DDEV’s official documentation for installation instructions. If you choose to use a different development environment, adjust the commands accordingly. To get the Drupal 7 site up and running, execute the following commands: bash git clone https://github.com/tag1consulting/d7_to_d10_migration.git d7_to_d10_migration cd d7_to_d10_migration/drupal7 ddev start ddev import-db -f ../assets/drupal7_db.sql.gz ddev import-files --source ../assets/drupal7_files.tar.gz ddev restart ddev launch ddev drush uli This will clone the repository into a folder named d7_to_d10_migration. Inside, you will find a drupal7 folder with the code for a Drupal 7 installation including contrib modules. The commands also import an already populated database and user uploaded...

Authored by Nadiia Nykolaichuk and Bryan Sharpe.

The Drupal Association now maintains a GitLab CI Template that can be used for all Drupal contrib projects. It's an excellent way to quickly take advantage of Drupal.org's CI system and ensure your project is following code standards and best practices. And using it has the bonus of giving you a sweet green checkmark on your project page!

We recently added this template to the Same Page Preview module. After doing so, our JavaScript linting was failing. This wasn't surprising since we hadn't yet committed a standard ESLint or Prettier configuration to the codebase. I took a shot at trying to resolve these linting issues, initially turning to the ESLint Drupal Contrib plugin. This allowed me to get ESLint up and running quickly and run linting with only within the context of this module. I resolved all of the linting issues, pushed my work up to GitLab, and started thinking about how I'd reward myself for a job well done.

Disaster Strikes

And as you might expect, the CI build still failed. 🤦‍♂️

At this point I took a step back. First off, I needed to determine what differed between my ESLint process and the one that was being executed by the Drupal Gitlab CI Template. Secondly, beyond just getting the CI job to pass, I wanted to define the linting use cases I was trying to solve for. I decided to focus on the following:

1. Determining how to run the exact same ESLint command that the GitLab CI Template was running, using the same configuration as Drupal Core.
2. Developing an ESLint configuration that could be run within the standalone module codebase (with or without an existing instance of Drupal) but matching Drupal Core and GitLab CI's configuration as closely as possible.

Using the Drupal Core ESLint Configuration

Here we literally want to use the same ESLint binary and config used by Drupal Core. Since this is what Drupal's GitLab CI Template is doing, this is also an opportunity to match the CI linting configuration as closely as possible.

The CI job is running the following command:

And prior to that command, symlinks are also created for some relevant configuration files:

This means that we'll need to run eslint using Core's 'passing' configuration (which itself extends the 'jquery' configuration.)

To match that, I created an eslint:core script in the module's package.json:

I was surprised to find that even after running this command locally, the CI job was still failing. It turned out that ESLint wasn't using Core's Prettier config in this case, resulting in a different set of formatting rules being applied. Copying core/.prettierrc.json into the module's root directory resolved this issue.

Copying Drupal Core's prettier config wholesale isn't great. The approaches to referencing and extending a prettier config are clunky, but possible. A more ideal solution would be to have Drupal's prettier config as a package that could be referenced by both core and contrib modules.

Using a Standalone ESLint Configuration

Ideally it would also be possible to run this linting outside of the context of a full Drupal instance. This could help speed up things like pre-commit hooks, some CI tasks, and also make quick linting checks easier to run. With the lessons from using Drupal Core's ESLint configuration fresh in mind, I took another shot at using the eslint-plugin-drupal-contrib plugin.

First, I installed it in the module as a dev dependency:

Next, I created a file .eslintrc.contrib.json in the module's root directory:

This will result in eslint using the same configuration as Drupal Core's 'passing' configuration, but without needing to reference Core's configuration files. Finally, you can run this by adding the following eslint script in the module's package.json:

You might be surprised to see the --no-eslintrc flag above. That prevents ESLint from looking for any other configuration files in the directory tree. Without it, ESLint will find the Drupal Core configuration files if this happens to be run from within a Drupal project. This will result in ESLint attempting to resolve plugins using Drupal Core's node_modules directory, which may or may not exist.

Also note that ESLint 8.x uses the --no-eslintrc flag, while the ESLint 9.x equivalent is --no-config-lookup. Drupal core is currently on ESLint 8.x, which is the previous major release.

Happy Linting

I ran into a few more hiccups than I expected along the way, but now feel confident that I can have consistent linting results between my local environment and the Drupal.org CI system in all of the JavaScript code I write for contrib modules. Hopefully this can help you do the same.

Resources

• Drupal GitLab CI Template
• ESLint
• Prettier
• ESLint Drupal Contrib plugin
• Checking custom JavaScript with ESLint - an alternative approach that can be run from the conext of /core.

A few weeks ago at DrupalCon Portland, I announced Drupal Starshot, a project to create the new default download of Drupal. Built on Drupal Core, Drupal Starshot will include popular features from the contributed project ecosystem. It focuses on delivering a great user experience right out of the box. Drupal Starshot builds on recent initiatives like Recipes, Project Browser, and Automatic Updates to elevate Drupal to new heights.

The response has been incredible! Hundreds of people have pledged their support on the Drupal Starshot page, and many more have asked how to get involved. Over the past few weeks, we have been planning and preparing, so I'm excited to share some next steps!

We're launching a series of sessions to get everyone up to speed and involved. These will be held as interactive Zoom calls, and the recordings will be shared publicly for everyone to watch at their convenience.

The main goal of these Zoom sessions is to help you get involved in each area. We'll cover details not included in my keynote, update you on our progress, and give you practical advice on where and how you can contribute.

We've scheduled six sessions, and we invite everyone to attend. The first one will be on this Friday on participation, funding, and governance! You can find the latest schedule online at https://www.drupal.org/starshot#sessions and the core calendar in the sidebar of the Drupal core news page.

We look forward to seeing you there and working together to make Drupal Starshot a success!
 

We do not usually make use of private composer repos. The reason is simple, all our private code lives inside a single repo.

But sometimes, we need to re-use a project for multiple sites, and we still want to keep the code private. In those cases, a private composer repo makes sense.

To celebrate Pride Month 2024, the Drupal Association is sharing information to uplift international organizations that support the LGBTQ+ community and donating our proceeds of themed apparel from the Drupal Swag Shop to those organizations. Pride Month is celebrated in June each year to acknowledge the anniversary of the Stonewall Uprising (1969), which was a tipping point for the gay liberation movement and spurred the growth of LGBTQ+ support. The movement has since spread across the globe. Read more on the history of Pride Month.

The Drupal Association is guided by the values of open source, which have a strong history of inclusivity. Our focus is human-centric. We believe that the way forward is with collective responsibility, accountability, and care. As stated in the Open Web Manifesto, the open web thrives on inclusion: Everyone in the world, regardless of background, identity, wealth, or status, has a home on the open web. Inclusivity is one of Drupal’s core principles, making an open web possible. At the core of our beliefs is that every individual, regardless of sexual orientation, gender identity, or expression, has a place here and deserves to be supported.

This year, the Drupal Association will celebrate LGBTQ+ organizations from around the world who work in different sectors: jobs and training, legal advocacy, refugee support, and youth mental health. We invite you to learn more about each organization that we highlight. Then, we ask you, the Drupal Community, to vote for which organization will receive the proceeds from Drupal Pride swag raised during Pride Month in the Drupal Swag Shop.

Here are the organizations we will be celebrating during each week of the month:

• Week 1: Micro Rainbow International Foundation is an organization that works globally to help LGBTQ+ people achieve their full potential in life and have equal access to employment, training, education, financial services, healthcare, housing, places of faith, and public places and services.

• Week 2: Human Dignity Trust defends the human rights of LGBTQ+ people globally to challenge laws that persecute people on the basis of their sexual orientation and/or gender identity.

• Week 3: Rainbow Railroad supports refugees, helping at-risk LGBTQ+ people get to safety worldwide. They’ve helped over 13,000 LGBTQ+ individuals find safety through emergency relocation, crisis response, cash assistance, and more.

• Week 4: The Trevor Project provides resources for international LGBTQ+ youth, including a 24/7 helpline and a safe and secure social networking site for LGBTQ+ youth and their allies.

Follow the Drupal Association on Linkedin and X/Twitter as we celebrate each organization this month! 

You can shop now and throughout the month of June in the Drupal Swag Shop for Drupal Pride gear! At the end of the month, 100% of the Drupal Association’s profits from the sales of the Drupal Pride gear will be donated to the LGBTQ+ organization that receives the most votes. Shop now and spread the word with the community! 

When you’re ready, we invite you to vote for the organization for which you want to receive the donation.

We want to hear your Drupal Pride stories!

In addition to celebrating LGBTQ+ organizations worldwide, we want to hear the Drupal community’s stories! What does Drupal Pride mean to you? We want to hear why Pride is important to you. We invite you to share your story with us to be featured on the Drupal Association social media channels celebrating Pride Month 2024! 

We are looking for videos that are less than 30 seconds long, short quotes, or photos that we can share on social media to amplify your messages. To share your story, you can either upload it to this Google Drive folder or email it directly to christina@association.drupal.org. We look forward to seeing your submissions and celebrating Pride together!

 Today we are talking about Urban Institute, What they do, and How they use Drupal with guest Josh Miller. We’ll also cover Access Unpublished as our module of the week.

For show notes visit: www.talkingDrupal.com/453

• Tell us how you got started with Drupal
• What does Urban Institute do
• What do you do at Urban Institute
  • Number of people on dev team
  • Number of sites
• How does Urban Institute use Drupal
• Are you using a custom upstream
• How many sites on Drupal 7
• Are you doing Page builders
• What kind of front end tools do you use
• What is the preferred local development tool
• Why did Urban Institute choose Drupal
• What is the hardest part of using Drupal at a large non profit
• What is the most interesting interactive experience you have built for Urban Institute

• Urban Institute
  • https://www.urban.org/
  • https://datacatalog.urban.org
  • https://upward-mobility.urban.org/
• Josh's new custom home
• Urban Institute at DrupalCon 2023
• DKAN
• Drupal GovCon
• Post-recording
  • https://www.palantir.net/blog/open-all-bringing-collaborative-editing-drupal-node
  • https://www.palantir.net/edittogether
  • https://www.drupal.org/project/yjs

Josh Miller - joshmiller

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Randy Fay - rfay

• Martin Anderson-Clutz - mandclu.com mandclu
• Brief description:
  • Have you ever wanted to get feedback on unpublished content from people who aren’t users on your Drupal site? There’s a module for that.
• Module name/project name:
  • Access Unpublished
• Brief history
  • How old: created in Feb 2011 by aberg, though recent releases are by Christian Fritsch (chr.fritsch) of Thunder
  • Versions available: 8.x-1.5
• Maintainership
  • Security coverage
  • Test coverage
  • Number of open issues: 58 open issues, 17 of which are bugs against the current branch
• Usage stats:
  • 8,638 sites
• Module features and usage
  • Once installed, this module adds a new element to your unpublished entity forms, for generating links with a special hash value. When generating the link, you can choose how long the hash value can be used for access.
  • Within that form section, you can copy the access URL for any of your generated tokens, and then paste into an email or some kind of direct message.
  • You will need to set a permission for users to access content using the special access URLs, so if you want anyone with the URL to be allowed access, you’ll need to assign that permission to the Anonymous user role
  • The access lifetime can be anything from 1 day to unlimited (never expires), and you can set the default value in the settings form. That form also allows you to set the URL parameter that will be used for access, gives you options to modify the HTTP headers on the unpublished page, and has a check box you can use to delete all expired tokens.
  • Expired tokens will be deleted on cron run, and when you delete an entity any related tokens are also removed.
  • This use case of allowing review of unpublished content for people who aren’t users in the Drupal site is a request I hear on a regular (if infrequent) basis, so I’ve personally found this module really useful.
• Necessary Patch: https://www.drupal.org/project/access_unpublished/issues/3421309
• Not to be confused with https://www.drupal.org/project/preview_link
  • Preview link is missing the ability to set length of access.