Planet Drupal

It typically occurs when you click on a website and become disinterested in utilizing it because there are no language preferences. In addition, you will be more interested in browsing the website if you can easily navigate its user interface and select your preferred language, regardless of where you live. 

According to some reports: Multilingual websites can reach 75% more internet users and improve user experience, as 60% of global consumers prefer browsing in their native language. Businesses with such websites see a 70% average increase in conversion rates. That’s why it is preferred that you must create a multilingual website to help with website traffic and your business strategy.

How?

The Drop Times conducted an in-depth analysis of Drupal users across the world's largest cities, focusing on locations with populations over one million. Using LinkedIn data, this study identifies key urban centers with significant Drupal communities, highlighting 81 cities with more than 500 "Drupal People." This analysis aims to support local community growth and enhance global Drupal engagement. Discover the cities where Drupal is thriving and learn how to get involved in organizing and promoting local events.

The Drop Times aims to enhance and track the global growth of the Drupal community. By utilizing LinkedIn's public search capabilities, we can estimate the geographical spread of Drupal users. Despite certain limitations, this method provides a practical approach to gauge community growth and plan targeted events. Learn how we navigate data challenges and leverage LinkedIn for meaningful insights.

Drupal's migration system allows the use of a number of different plugins to perform source, processing, and destination functions. 

Process plugins are responsible for copying and sometimes manipulating data into the destination. There are a number of different process plugins that allow you to get data in different ways and and apply it to your destination fields.

Both the core Migrate module and the excellent Migrate Plus module contain a number of different process plugins that you can use to process your data in different ways.

Out of the box, the default process plugin is the get plugin, which can be used like this in your migration scripts.

destination_field: plugin: get source: source_field

This is often shortened to the following, which has exactly the same functionality.

destination_field: source_field

Most of the time you will want to avoid creating custom plugins, but sometimes your migration requirements will necessitate their use. You might find that your source data is very messy and needs to be cleaned up before importing it into the site. Process plugins are a really good way of doing this, but it is essential that you write tests to cover every situation that you might encounter. 

In this article we will look at two custom migrate process plugins that are built in different ways and how to test them. This will dive into some concepts around Drupal plugin management, dependency injection, as well as unit testing and data providers with PHPUnit.

First, let's look at the migration script that we will be using in this article. All of the source code for this migration example is available on GitHub.

Read more

PHPCamp 2024 in Pune offers an immersive experience where PHP developers of all levels can enhance their skills, expand their knowledge, and connect with a vibrant community. Attendees will engage in hands-on workshops, explore the latest trends, and network with industry leaders in a collaborative and inclusive environment. This event is a unique opportunity for developers to be part of a groundbreaking gathering that fosters innovation and professional growth.

Discover DrupalX with Jay Callicott on Medium, a toolkit tailored for enterprise website development. Learn how DrupalX integrates Bootstrap 5 and Storybook to empower developers to effortlessly create scalable, visually stunning websites.

Wordpress (Gutenberg) page editor in Drupal Zé Fri, 06/07/2024 - 08:34 Wordpress (Gutenberg) page editor in Drupal

WP's default Gutenberg editor is an intuitive, yet highly flexible page editor that exists as an independent open-source project, and has meanwhile matured and become popular, with integration into Drupal as well.

Learn how to streamline your web application's user experience by running batch processes through AJAX requests. This approach prevents page redirection and keeps users on the current interface, enhancing usability and performance. The guide covers key techniques including setting up AJAX calls, handling server responses, and ensuring smooth operation without disrupting user interactions. Discover best practices for error handling, progress updates, and optimizing batch processing for a seamless and efficient workflow.

Here's what I've been working on for my LocalGov Drupal contributions this week. Thanks to Big Blue Door for sponsoring the time to work on these.

The journey of testing methodologies underscores the importance of ensuring code reliability and functionality, especially in the complex landscape of Drupal development.

Monday was a U.S. holiday, which meant I was able to go full-steam ahead on the storage MR for Experience Builder (XB) that I started the prior week. On Tuesday, I continued that work, and spun off a second MR that allows changing the source type and source value … for which I shared a 2.5-minute screencast in #experience-builder late on Tuesday.

In it, you’ll see a hacky-as-hell UI. It’s currently named TwoTerribleTextAreasWidget to convey in no uncertain terms that this is throwaway code :D Its purpose: help stand up infrastructure and get the back-end pieces in place to power the UI (see last week’s screenshot), which is currently using hardcoded data.

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

The video is the first step in visualizing all the pieces of Alex “effulgentsia”’s data model proposal in #3440578. In a nutshell, you can see that for each placed component, this video proves:

• it is possible to exactly match Single Directory Components (SDC) props against Drupal field types (to be precise: props inside those fields)
• while allowing those values to be:
  • either dynamic: reuse of structured data that already exists on the entity (XB aims to embrace that strength of Drupal, not to diminish it)
  • or static: fixed values stored in JSON-in-the-database as described in #3440578 1
• crucially, we can automatically surface only sensible choices, and present the choices in an order that encourages best practices, using only schema matching2 (SDCs use JSON schema, whereas the Drupal entity/field system uses Typed Data + validation constraints)

I was relieved to see that effulgentsia indicated this indeed matches his vision :)

Just those two source types (dynamic and static) are insufficient, which is why Felix has been hard at work to bring us a working PoC of adapters too, which are able to

1. adapt data into a shape that Drupal does not provide a field type for (for example: the type: string, format: time)
2. combine multiple data sources (any combination of static and dynamic) into a single shape (for example: combine an image + Image Style inputs and to adapt them into an image that uses that style

Adapters were merged on Friday!

That was more technical than previous weeks. The more technical readers might, if they squint again just like last week for the UI, be able to see how Lauri “lauriii”, effulgentsia and I see the different pieces connect. I know that many of you are longing for detailed architectural diagrams. They do not exist today. We had to first prove what we envisioned was feasible. There’s a bit more proving to be done first, but then such documentation & diagrams will be my top priority.

Before sharing that video on Tuesday, I met with Cristina “ckrina”, Jared “jponch”, Mateu “e0ipso” and Mike “mherchel”, about design tokens, which is another crucial part of XB. e0ipso had already been working on a PoC for bringing design tokens to SDC, whereas ckrina felt it was important to start defining which design tokens should exist. We ended up concluding unanimously that building a few concrete components and making them use design tokens would help define that — so ckrina, jponch and mherchel are tackling that next.

The meeting was recorded and shared and sparked a lively discussion, where Pierre “pdureau” chimed in with interesting UI Suite-based opinions

It’s great to see this work in motion, because both the exploratory “how should it work from a design POV?” and the concrete SDC support work are necessary, and both will inform the direction of #3444424: [META] Configuration management: define needed config entity types.

On Wednesday, #3450586: [META] Early phase back-end work coordination and #3450592: [META] Early phase front-end work coordination were created, to start making it possible for any Drupal contributor to 1) see what’s happening, 2) find issues to contribute to. (The list of available issues is sparse at this early stage, because there barely is a codebase, and not all architectural puzzle pieces exist yet.)

Later that day, I rode my bicycle over to meet with 4 people of the Dropsolid team. They’re very eager to contribute to XB (their CEO, Dominique “domidc” almost didn’t let me leave the DrupalCon venue when it was closing, that’s how enthusiastic they are :D), and they bring a unique perspective: they focus on “mid-market” and have hundreds (thousand?) of sites using Layout Builder. Thanks to to that, they intimately know some of Layout Builder’s architectural choices that XB should avoid. On the code contribution side, I was able to point them to the 2 meta issues above that had been created only hours prior. On the UX/product side of XB, they’re coordinating with lauriii next, so expect to hear more in a future update.

Perhaps the best place to contribute to XB today is actually in SDC! Kyle “ctrlADel” Einecker discovered an SDC bug during DrupalCon Portland (#3446933) that definitely will block XB. e0ipso worked on a fix and penyaskito RTBC‘d it on Thursday. This also connects with #3446083 and #3446722 which focuses on defining different ways of composing components out of existing SDCs for XB to support.

Also on Wednesday, Lee “larowlan” helped the UI transition from miragejs to msw.

To round the week out, Ben “bnjmnm” finished his epic battle with the CI gods on Friday and won!: he got Cypress working on XB’s GitLab CI pipeline. Both Ben and Jesse were raving about the excellent DX that Cypress has compared to other (end-to-end) testing frameworks for JS. With the CI pieces in place, we’re ending this week on a strong note: future UI work will be able to move faster thanks to Cypress, and Cypress-on-CI!

Thanks to Lauri for reviewing this!

1. To generate field widgets for these, we conjure instances of those field types out of thin air! ↩︎

2. Schema matching basically is a fancy word for shape matching. ↩︎

• Drupal
• Acquia
• Experience Builder

At DrupalCon Portland 2024, members of the Drupal Community Working Group were pleased to announce the winner of the 2024 Aaron Winborn Award, Mike Anello (ultimike.)

About Mike Anello

Mike Anello winner of the Aaron Winborn Award 2024

Mike has been an integral part of the Drupal Community for nearly 20 years. His leadership is evident through his long-term involvement with the Community Working Group and its Conflict Resolution Team, as well as his role as the lead organizer of Florida Drupal Camp. As a co-founder and educator at DrupalEasy, he continues to mentor and inspire numerous community members, helping to lower barriers to entry. Mike consistently shares his expertise as a presenter and facilitator at many Drupal events. His contributions inspire many, both directly and indirectly, throughout our community.

Heartfelt Nominations

Each year many individuals are nominated for the award. But this year, one nomination seemed to sum the rest up with a simple, “You damned well know why Mike Anello deserves this award more than anyone else. Seriously.”  

Other nominations were less direct but full of grace and patience, much like Mike’s contribution to Drupal over the years. Here are a few others:

“Mike is a model community member who has had an exponential impact on the success of our community. I can't think of anyone more deserving of this award.”

“I believe hundreds of folks have been impacted positively by Mike over their career.”

“Without Mike Anello, I don't know if I would have been as enthralled with Drupal as I became. I still remember the first time I met Mike at DrupalCamp Atlanta in 2013. He inspired me to do more than work with Drupal; he inspired me to join the Drupal community. His work with DrupalEasy continues to build an education pipeline that brings in new community members and levels those who may already be involved so that they can grow their careers.”

The CWG has contacted all nominees to let them know of their nomination and shared some details about what their nominators wrote about them, thanking them for their continued work in the community. 

About the Aaron Winborn Award

The 2024 Aaron Winborn Award

The award is named after a long-time Drupal contributor who lost his battle with ALS in 2015. This award recognizes an individual who, like Aaron, demonstrates personal integrity, kindness, and an above-and-beyond commitment to the Drupal project and community.

Previous winners of the award are  Cathy Theys, Gabór Hojtsy, Nikki Stevens, Kevin Thull, Leslie Glynn, Baddý Breidert, AmyJune Hineline, Angie Byron, and Randy Fay. Current CWG Conflict Resolution Team members, along with previous winners, selected the winner based on nominations submitted by Drupal community members.

Nominations for next year's award will open in early 2025.

File attachments:  ma-24-awa.jpeg awa2024-award.png

Recently, Dries Buytaert announced the Drupal Starshot leadership team. Lullabot's Cristina Chumillas will be the UX lead. In this role, Cristina will "define the design and user experience vision" for the product.

Although my blog has been quiet, a lot has happened with the Drupal Starshot project since its announcement a month ago. We provided an update in the first Drupal Starshot virtual meeting, which is available as a recording.

Today, I am excited to introduce the newly formed Drupal Starshot leadership team.

Meet the leadership team Product Lead: Dries Buytaert

I will continue to lead the Drupal Starshot project, focusing on defining the product vision and strategy and building the leadership team. In the past few weeks, I have cleared other responsibilities to dedicate a significant amount of time to Drupal Starshot and Drupal Core.

Technical Lead: Tim Plunkett (Acquia)

Tim will oversee technical decisions and facilitate contributions from the community. His role includes building a team of Drupal Starshot Committers, coordinating with Drupal Core Committers, and ensuring that Drupal Starshot remains stable, secure, and easy to upgrade. With 7 years of engineering leadership experience, Tim will help drive technical excellence. Acquia is providing Tim the opportunity to work full-time on the Drupal Starshot project.

User Experience Lead: Cristina Chumillas (Lullabot)

Cristina will define the design and user experience vision for Drupal Starshot. She will engage with contributors to initiate research activities and share the latest UI/UX best practices, ensuring a user-centric approach. She has been leading UX-related Drupal Core initiatives for over 7 years. Lullabot, Cristina's employer, has generously offered her the opportunity to work on Drupal Starshot full-time.

Product Owner: Pamela Barone (Technocrat)

Pam will help ensure alignment and progress among contributors, including defining and prioritizing work. She brings strong communication and organizational skills, having led Drupal projects for more than 12 years.

Contribution Coordinator: Gábor Hojtsy (Acquia)

Gábor will focus on making it easier for individuals and organizations to contribute to Drupal Starshot. With extensive experience in Open Source contribution and community engagement, Gábor will help communicate progress, collaborate with the Drupal Association, and much more. Acquia will provide Gábor with the opportunity to work full-time on the Drupal Starshot project.

Starshot Council (Advisory Board)

To support the leadership team, we are establishing the Starshot Council, an advisory board that will include:

1. Three end-users (site builders)
2. Three Certified Drupal Partners
3. Two Drupal Core Committers (one framework manager and one release manager)
4. Three Drupal Association board members, one from each of the following Board Working Groups: Innovation, Marketing, and Fundraising
5. Two staff members from the Drupal Association

The council will meet monthly to ensure the leadership team remains aligned with the broader community and strategic goals. The Drupal Association is leading the effort to gather candidates, and the members of the Starshot Council will be announced in the coming weeks.

More opportunities to get involved

There are many opportunities for others to get involved as committers, designers, developers, content creators, and more.

We have specific tasks that need to be completed, such as finishing Project Browser, Recipes and Automatic Updates. To help people get involved with this work, we have set up several interactive Zoom calls. We'll update you on our progress and give you practical advice on where and how you can contribute.

Beyond the tasks we know need to be completed, there are still many details to define. Our next step is to identify these. My first priority was to establish the leadership team. With that in place, we can focus on product definition and clarifying the unknowns. We'll brief you on our initial ideas and next steps in our next Starshot session this Friday.

Conclusion

The Drupal Starshot project is off to an exciting start with this exceptional leadership team. I am grateful to these talented individuals for stepping up to drive this important project. Their combined expertise and dedication will drive excitement and improvements for the Drupal platform, ultimately benefiting our entire community. Stay tuned for updates as we continue to make strides in this ambitious initiative.

Monday was a U.S. holiday, which meant I was able to go full-steam ahead on the storage MR for Experience Builder (XB) that I started the prior week. On Tuesday, I continued that work, and spun off a second MR that allows changing the source type and source value … for which I shared a 2.5-minute screencast in #experience-builder late on Tuesday.

In it, you’ll see a hacky-as-hell UI. It’s currently named TwoTerribleTextAreasWidget to convey in no uncertain terms that this is throwaway code :D Its purpose: help stand up infrastructure and get the back-end pieces in place to power the UI (see last week’s screenshot), which is currently using hardcoded data.

The video is the first step in visualizing all the pieces of Alex “effulgentsia”’s data model proposal in #3440578. In a nutshell, you can see that for each placed component, this video proves:

• it is possible to exactly match Single Directory Components (SDC) props against Drupal field types (to be precise: props inside those fields)
• while allowing those values to be:
  • either dynamic: reuse of structured data that already exists on the entity (XB aims to embrace that strength of Drupal, not to diminish it)
  • or static: fixed values stored in JSON-in-the-database as described in #3440578 1
• crucially, we can automatically surface only sensible choices, and present the choices in an order that encourages best practices, using only schema matching2 (SDCs use JSON schema, whereas the Drupal entity/field system uses Typed Data + validation constraints)

I was relieved to see that effulgentsia indicated this indeed matches his vision :)

Just those two source types (dynamic and static) are insufficient, which is why Felix has been hard at work to bring us a working PoC of adapters too, which are able to

1. adapt data into a shape that Drupal does not provide a field type for (for example: the type: string, format: time)
2. combine multiple data sources (any combination of static and dynamic) into a single shape (for example: combine an image + Image Style inputs and to adapt them into an image that uses that style

Adapters were merged on Friday!

That was more technical than previous weeks. The more technical readers might, if they squint again just like last week for the UI, be able to see how Lauri “lauriii”, effulgentsia and I see the different pieces connect. I know that many of you are longing for detailed architectural diagrams. They do not exist today. We had to first prove what we envisioned was feasible. There’s a bit more proving to be done first, but then such documentation & diagrams will be my top priority.

Before sharing that video on Tuesday, I met with Cristina “ckrina”, Jared “jponch”, Mateu “e0ipso” and Mike “mherchel”, about design tokens, which is another crucial part of XB. e0ipso had already been working on a PoC for bringing design tokens to SDC, whereas ckrina felt it was important to start defining which design tokens should exist. We ended up concluding unanimously that building a few concrete components and making them use design tokens would help define that — so ckrina, jponch and mherchel are tackling that next.

The meeting was recorded and shared and sparked a lively discussion, where Pierre “pdureau” chimed in with interesting UI Suite-based opinions

It’s great to see this work in motion, because both the exploratory “how should it work from a design POV?” and the concrete SDC support work are necessary, and both will inform the direction of #3444424: [META] Configuration management: define needed config entity types.

On Wednesday, #3450586: [META] Early phase back-end work coordination and #3450592: [META] Early phase front-end work coordination were created, to start making it possible for any Drupal contributor to 1) see what’s happening, 2) find issues to contribute to. (The list of available issues is sparse at this early stage, because there barely is a codebase, and not all architectural puzzle pieces exist yet.)

Later that day, I rode my bicycle over to meet with 4 people of the Dropsolid team. They’re very eager to contribute to XB (their CEO, Dominique “domidc” almost didn’t let me leave the DrupalCon venue when it was closing, that’s how enthusiastic they are :D), and they bring a unique perspective: they focus on “mid-market” and have hundreds (thousand?) of sites using Layout Builder. Thanks to to that, they intimately know some of Layout Builder’s architectural choices that XB should avoid. On the code contribution side, I was able to point them to the 2 meta issues above that had been created only hours prior. On the UX/product side of XB, they’re coordinating with lauriii next, so expect to hear more in a future update.

Perhaps the best place to contribute to XB today is actually in SDC! Kyle “ctrlADel” Einecker discovered an SDC bug during DrupalCon Portland (#3446933) that definitely will block XB. e0ipso worked on a fix and penyaskito RTBC‘d it on Thursday. This also connects with #3446083 and #3446722 which focuses on defining different ways of composing components out of existing SDCs for XB to support.

Also on Wednesday, Lee “larowlan” helped the UI transition from miragejs to msw.

To round the week out, Ben “bnjmnm” finished his epic battle with the CI gods on Friday and won!: he got Cypress working on XB’s GitLab CI pipeline. Both Ben and Jesse were raving about the excellent DX that Cypress has compared to other (end-to-end) testing frameworks for JS. With the CI pieces in place, we’re ending this week on a strong note: future UI work will be able to move faster thanks to Cypress, and Cypress-on-CI!

Thanks to Lauri for reviewing this!

1. To generate field widgets for these, we conjure instances of those field types out of thin air! ↩︎

2. Schema matching basically is a fancy word for shape matching. ↩︎

This blog has been re-posted and edited with permission from Wim Leer's blog

Explore Drupaljam 2024 with Drop Times, the media partner! Discover sponsorship opportunities and delve into an insightful keynote session on the future of open source. Secure your spot for June 12th now!

NEW DATE - MidCamp returns in 2025! Mark Your Calendar - It's Gonna Be May! 

With an earlier DrupalCon next year we’ve adjusted the MidCamp dates
so make plans to be in Chicago, and join us at the DePaul University Student Center, for May 20-22, 2025.

Here’s our tentative timeline:

• Today: You read this Save the Date 

• Fall 2024: Call for speakers will open 

• Late 2024: Call for speakers closes 

• Late Jan/Early Feb: Speakers & schedule is announced! 

• May 20-22, 2025: Meet us at MidCamp! 

We will be releasing more posts with venue details, hotel and travel options, fun social events, speaker announcements and more!

Help us Make MidCamp

MidCamp doesn't run on commit credits and coffee, it takes lots of dedicated volunteers and almost 6 months of work to make it happen. We need volunteers who can commit just an hour a week from November through May to help us make the magic happen.

Join the MidCamp Slack where we make announcements from time to time. We’re also on X (formerly Twitter) and Mastodon.

If you’re interested in helping further, reach out in the #midcamp-organizers channel. We'll find you a task and get you some Drupal credits.  

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

Although my blog has been quiet, a lot has happened with the Drupal Starshot project since its announcement a month ago. We provided an update in the first Drupal Starshot virtual meeting, which is available as a recording.

Today, I am excited to introduce the newly formed Drupal Starshot leadership team.

Meet the leadership team Product Lead: Dries Buytaert

I will continue to lead the Drupal Starshot project, focusing on defining the product vision and strategy and building the leadership team. In the past few weeks, I have cleared other responsibilities to dedicate a significant amount of time to Drupal Starshot and Drupal Core.

Technical Lead: Tim Plunkett (Acquia)

Tim will oversee technical decisions and facilitate contributions from the community. His role includes building a team of Drupal Starshot Committers, coordinating with Drupal Core Committers, and ensuring that Drupal Starshot remains stable, secure, and easy to upgrade. With 7 years of engineering leadership experience, Tim will help drive technical excellence. Acquia is providing Tim the opportunity to work full-time on the Drupal Starshot project.

User Experience Lead: Cristina Chumillas (Lullabot)

Cristina will define the design and user experience vision for Drupal Starshot. She will engage with contributors to initiate research activities and share the latest UI/UX best practices, ensuring a user-centric approach. She has been leading UX-related Drupal Core initiatives for over 7 years. Lullabot, Cristina's employer, has generously offered her the opportunity to work on Drupal Starshot full-time.

Product Owner: Pamela Barone (Technocrat)

Pam will help ensure alignment and progress among contributors, including defining and prioritizing work. She brings strong communication and organizational skills, having led Drupal projects for more than 12 years.

Contribution Coordinator: Gábor Hojtsy (Acquia)

Gábor will focus on making it easier for individuals and organizations to contribute to Drupal Starshot. With extensive experience in Open Source contribution and community engagement, Gábor will help communicate progress, collaborate with the Drupal Association, and much more. Acquia will provide Gábor with the opportunity to work full-time on the Drupal Starshot project.

Starshot Council (Advisory Board)

To support the leadership team, we are establishing the Starshot Council, an advisory board that will include:

1. Three end-users (site builders)
2. Three Certified Drupal Partners
3. Two Drupal Core Committers (one framework manager and one release manager)
4. Three Drupal Association board members, one from each of the following Board Working Groups: Innovation, Marketing, and Fundraising
5. Two staff members from the Drupal Association

The council will meet monthly to ensure the leadership team remains aligned with the broader community and strategic goals. The Drupal Association is leading the effort to gather candidates, and the members of the Starshot Council will be announced in the coming weeks.

More opportunities to get involved

There are many opportunities for others to get involved as committers, designers, developers, content creators, and more.

We have specific tasks that need to be completed, such as finishing Project Browser, Recipes and Automatic Updates. To help people get involved with this work, we have set up several interactive Zoom calls. We'll update you on our progress and give you practical advice on where and how you can contribute.

Beyond the tasks we know need to be completed, there are still many details to define. Our next step is to identify these. My first priority was to establish the leadership team. With that in place, we can focus on product definition and clarifying the unknowns. We'll brief you on our initial ideas and next steps in our next Starshot session this Friday.

Conclusion

The Drupal Starshot project is off to an exciting start with this exceptional leadership team. I am grateful to these talented individuals for stepping up to drive this important project. Their combined expertise and dedication will drive excitement and improvements for the Drupal platform, ultimately benefiting our entire community. Stay tuned for updates as we continue to make strides in this ambitious initiative.

The Drupal Pune team will volunteer at PHPCamp 2024 in Pune on June 8th. Don't miss the chance to participate in this collaborative event! Secure your tickets now.

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

Read more mauricio Wed, 06/05/2024 - 14:17