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.

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?

Drupal 10: Not Just Another Upgrade, But a Revolution in Web Development bhavinhjoshi Tue, 06/04/2024 - 10:42

Ever had to scratch your head, ferreting out the secret weapon behind those mammoth success stories of the digital world? Well, ponder no more, you've just stumbled upon the world of Drupal 10!

As the latest prodigy of the Drupal family, Drupal 10 isn't just a facelift but a tool that champions uncharted territories. With an arsenal of new features, it's here to empower developers - both seasoned and novice ones.

Let's picture this through an everyday scenario. You're a site developer catering to a global audience. Earlier, you'd have to have multiple versions of the site to cater to various languages. Drupal 10 simplifies this with its built-in multilingual feature. You can now translate and localise your website without bothersome plugins.

Consider another common tussle developers face - keeping up with the digital world's insatiable appetite for interactive and responsive designs. With Drupal 10's layout builder, you can create and customize layouts per content type, per node, or even per user role.

Even SEO, the lifeline of online visibility, gets a boost with Drupal's 10 in-built meta tag and path auto modules. Now you can ensure your site stays in the limelight with less effort and more smart work.

Yet the standout trait of Drupal 10, one that deserves a tip of the hat, is the ease of upgrade. Remember the hair-pulling days of upgrading from Drupal 7 to 8? Those days are in the rear view mirror as Drupal 10 ensures a seamless upgrade, promising the preservation of custom themes and modules.

In conclusion, Drupal 10 is not just a new version, but a pivotal shift in web development that caters to today's fast-paced, ever-evolving digital landscape. It's about time we embrace it!

Drupal 10 Drupal Planet

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

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.

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.

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

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.

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

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.