Drupal, the renowned content management platform, is a result of collective efforts by developers and contributors worldwide.

But have you ever considered how you can contribute to its evolution? Let's unpack the benefits of contributing, explore avenues to contribute and decipher tools that ease the process.

The Benefits of Contributing

Contributing to Drupal is a symbiotic process, where every effort you put in reaps multiple rewards:

1. Skill Enhancement: Whether you choose to contribute code, help with testing, design or translations, each contribution is an opportunity to sharpen your skills. 

2. Networking: Engage with the global Drupal community at meetups, workshops, and forums. These platforms present a potent opportunity to connect with fellow developers, learn about Drupal trends, and imbibe best practices.

3. Impact: Every contribution counts. Whether it's contributing code, reporting bugs, suggesting enhancements, or sharing expertise and insights in the community, each contribution plays a pivotal role. These collective contributions help in creating a more robust, user-friendly, and advanced platform. Thus, every contribution, regardless of its size or nature, holds immense value as it brings about change and propels Drupal forward in its ongoing evolution.

Contribute to Drupal: The How-To Guide

There's a multitude of ways to contribute to Drupal. Here's a few:

1. Code Development: If you're proficient in PHP, consider developing for Drupal core or contributing modules. 

2. Testing: Quality assurance plays a crucial role in Drupal development. Test new features or updates, and report bugs. 

3. Documentation: A clear, comprehensive documentation bolsters user experience and uptake.

4. Community Support: Help others on Drupal forums or organise Drupal events. 

Tools That Make Drupal Contribution Easy

Several tools can support your journey as a Drupal contributor:

1. Drupal.org: A treasure trove of resources, Drupal.org is your starting point.

2. 'Simply Test Me': This tool lets you test patches or projects before submission. 

3. Drupal CI: This integrated tool helps test your code's compatibility with different environments. 

4. Dreditor: This browser extension streamlines code review and submission. It aids in identifying errors within the code, ensuring your contributions are more sturdy and resilient.

5. Slack: Join the Drupal Slack workspace for ongoing discussions and mentorship. 

In conclusion, contributing to Drupal is not just about giving back to the community but also about enhancing your skills, creating influential networks, and leaving a lasting impact. Remember, every contribution matters, no matter how small. 

So, wear your Drupal contributor hat and let’s keep the wheel of innovation turning. Together, we can shape the future of this robust platform. Every step we take, every effort we make, brings Drupal a step closer to the epitome of perfection. 

It’s a journey, and everyone’s invited. After all, the best way to predict the future is to create it. Let's create the Drupal we want, together!

In the constantly evolving digital world, the ability to efficiently manage multiple websites has become a necessity for businesses of all sizes. 

Thankfully, Drupal, an open-source content management system, has made this simpler with its multi-site configuration feature. 

This functionality makes it easier to handle numerous websites from a single Drupal installation, saving time, effort, and resources. But how do we configure this feature in Drupal? 

This blog post explores the ways to achieve multi-site configurations in Drupal in thorough detail.

Understanding Drupal Multi-Site Configurations

Before we go deeper, let's understand what Drupal multi-site configuration means. Simply put, it allows you to run multiple websites from one codebase. Each website can have its own content, settings, enabled modules, and themes, while sharing the core code, contributed modules, and themes. This arrangement benefits website managers who manage multiple sites, as they can apply updates to all at once.

How to Set Up Multi-Site Configurations

1. Creating Sub-Directories
   The first step is to create sub-directories for each site in the 'sites' directory. This is where individual settings for each site reside. The directory name would typically be your site's URL. For instance, if your site's URL is 'example.com', the directory name would be 'sites/example.com'.
2. Setting Up the Database
   Each site requires its own database. During Drupal installation, you need to set up a new database for each site. Remember to collate each database in 'utf8mb4_general_ci' to avoid any characters failing to write to the database.
3. Configuring Settings.php
   For each site, you will need a settings.php file. This file contains critical information about your site such as base URL, database credentials, and more. You can find a default.settings.php file in the 'default' directory. Copy this file into your new site directory and rename it to 'settings.php'. Update the necessary details like the database name, username, and password.
4. Configuring the Web Server
   Next, you need to configure your web server to point to the correct site directory. For Apache servers, you would use the .htaccess file, while nginx servers use the nginx.conf file.
5. Installing Drupal
   Finally, install Drupal for each site by navigating to your site's URL in a web browser. Follow the installation prompts, and in no time, your website will be up and running.

The Importance of Multi-Site Configurations

With multi-site configurations, you can centralise your web management tasks, reducing the need for redundant tasks. You can apply core updates, security patches, and other changes across all your sites with a single stroke. This translates into reduced effort, time, and risk of errors.

Further, this simplifies your hosting environment as you're using a single codebase, making it easier to manage your server resources and optimise for performance.

Pitfalls to Avoid

Despite its numerous benefits, multi-site configurations are not without their challenges. Remember, changes made are site-wide; an update beneficial to one site might disrupt another. Thus, always carry out extensive testing before deploying changes. Additionally, ensure to maintain regular backups to quickly restore any problematic updates.

Conclusion

Mastering Drupal's multi-site configurations can become an asset in your digital arsenal. It not only optimises resources but also streamlines your web management process. However, it requires strategic planning and careful execution to exploit its full potential.

Recently, we worked on performance improvements for a complex enterprise-scale Drupal system. Performance bottlenecks can appear in many different parts of such systems. Many possible performance improvements merit their respective discussion - each with a high level of detail. In this blog post, we want to share what we have learned from a more distant perspective. For some improvements, the Drupal ecosystem already offers well-working solutions in core and the contribution space. Some other changes sound easy on paper, but the implementation requires much effort. That is why we need to zoom out more to make good decisions on the software architecture level. Here are some of the noteworthy changes and decisions we made.

1.5 week prior, Lee “larowlan” + Jesse fixed a bug in the undo/redo functionality and added the first unit test (#3452895), and added it to CI (where it now runs immediately, no need to wait for composer to run JS unit tests!) Except … the unit tests didn’t actually run — oops! Rectifying that revealed a whole range of new Cypress challenges, which Ben “bnjmnm” worked tirelessly to solve this during the entire 5th week, and it was merged on Wednesday of this week :)

Anybody who has contributed to the drupal.org GitLab CI templates knows how painful this can be!

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!

As alluded to in last week’s update, I’m shifting my focus to coordinating.

That, together with quite a few people being out or preparing for webinars or Drupal Dev Days Burgas means this is an unusually short update — also because I left on vacation on Friday the 21st of June.

Before going on vacation, I wanted to ensure work could continue in my absence because we need to get to the point where Lauri’s vision is accessible in both UX wireframe form (Lauri’s working on that with Acquia UX) and technical diagram form (up to me to get that going). So, since last week:

1. Lauri created #3454094: Milestone 0.1.0: Experience Builder Demo. I created #3455753: Milestone 0.2.0: Experience Builder-rendered nodes. Anything that is not necessary for either of those two should not be worked on at this time. They together form “the early phase” — the milestone 0.1.0 has a hard DrupalCon Barcelona 2024 deadline in September, the 0.2.0 does not have a similar firm date.
2. As much of 0.2.0 as possible should already be in 0.1.0, which means ideally the back end is ahead of the front end. That’s what #3450586: [META] Early phase back-end work coordination and #3450592: [META] Early phase front-end work coordination. are for. I did a big update to have the next ~10 or so back-end things to build spelled out in detail in concrete issues, with vaguer descriptions for the things that are further out and subject to change anyway.
3. Initial diagram of the data model as currently partially implemented and the direction we’ve been going in … followed by a significant expansion of detail. You can see the diagrams on GitLab, in the docs/diagrams directory.
4. The JSON-based data storage model is influenced significantly by some of the product requirements, and what those are and their exact purpose has not been very clear. To fix that, I created [later phase] [META] 7. Content type templates — aka “default layouts” — affects the tree+props data model (which updates the data model diagram!) — and Lauri recorded a video with his thinking around this, in which he walks through two diagrams: one for data sources + design system, one that breaks down a concrete content type.
5. A lot of discussion happened between Lauri, catch and I on [META] Configuration management: define needed config entity types, which needs a lot more clarity before all config entity types can be implemented.

One pretty cool issue landed this week that drives home that second item : #3455898: Connect client & server, with zero changes to client (UI): rough working endpoints that mimic the UI’s mocks — thanks to that, the PoC UI is now optionally populated by the first article node, unless you enable development mode (see ui/README.md), then it uses dummy data not served by Drupal. A small but hacky change but an important pragmatic step in the right direction :) And it unblocks Jesse on next steps on the UI!

Try it yourself locally if you like, but there’s not much you can do yet.
Install the 0.x branch — the “Experience Builder PoC” toolbar item takes you there!

Weeks 7 and 8 will be special editions: I will have been completely absent during week 7 (plus, it’ll be Drupal Dev Days!), and present only for the last day of week 8. I’ll catch up what happened and do a write-up both for myself as well as all of you!

Thanks to Lauri for reviewing this!

• Drupal
• Acquia
• Experience Builder

• The UI starts being powered by the server side.

We still keep improving the ecosystem readiness and tooling with each new major Drupal core version. Drupal 11 is to be released in a few weeks on the week of July 29 (so probably the first days of August) and already almost half of the top 200 modules are ready. But we need to keep thinking ahead.

The Project Update Bot (originally built by Ted Bowman at Acquia and since then very actively owned and improved by Björn Brala at SWIS) posted into more than 7600 project issue queues on Drupal.org with merge request suggestions to improve and in many cases solve compatibility with the upcoming major version. 

The bot is a clever combination of Upgrade Status and drupal-rector with some custom decision logic. So humans can also run those tools! But what if we automate it even more? What if we help pre-empt forwards incompatible code getting into modules in the first place? 

Authored by Nadiia Nykolaichuk.

Drupal is ceaselessly evolving, with the best Drupal minds nurturing brilliant ideas and implementing them in the new releases. Six months ago, Drupal 10.2 rolled out with a set of exciting enhancements. Now it’s time to celebrate that Drupal 10.3 has been officially released on June 20.

Here's what I've been working on for my Drupal contributions this week. Thanks to Code Enigma for sponsoring the time to work on these.

Over the past few weeks I've been sharing handy ways to set up Drupal for easier Drupal core development. Here's a bash script for installing Drupal and allowing you to choose what profile you want.

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.