Aegir is a hosting system built in Drupal, for Drupal.

It lets you easily create new Drupal sites and create databases, filesystems, virtual hosts etc. for the sites. You can manage hundreds or thousands of sites using a simple Drupal based UI. As simple as you would manage a list of 100 blog posts, you can manage 100 Drupal websites.

Currently the latest released version of Aegir is: Aegir 3.

Aegir 3 relies on Drush 8, which means it can work with: Drupal 7; Drupal 8 and Drupal 9. But not Drupal 10. Oh.

I have need for it to work with Drupal 10. Specifically we have a large collection of Drupal sites, that currently Drupal 9, but ready and waiting to jump to Drupal 10. Yes, we've left it too late, we should have done this a long time ago, but we are where we are.

I've spent the day looking into various options, they are roughly:

• Move to BOA
• Get Aegir 3 to work with Drupal 10
• Move to Aegir 4
• Move to Aegir 5
• Move to something else

My terms of reference

I'm looking for a solution that changes as little as possible in the current stack. We've got a big, beefy server, and lots and lots of Drupal sites on it. The Drupal sites themselves run fine and we're after the management of them really. We don't need to scale out particularly, and if we do, we've got options on the hardware side vertically. We also don't need some fancy multi-datacenter approach, and ideally keep with our Nginx, Varnish and Apache sandwich.

I do want to manage things in the old school way, but I need a few, select, non-technical users to be able to manage the sites in a friendly UI like Aegir's hosting system.

Lots of the new hotness out there are essentially orchestrating Kubernetes, and that's great, but I don't actually want 100 containers all running PHP which is how I understand all of these systems would essentially function.

I used to be an Aegir maintainer, and I have a deep knowledge of how Aegir works and even helped write some of the inter-process communications stuff in Drush 8. 

Move to BOA

The first option is one that has shown to be working, and requires a custom fork of Drush 8, some core patches and using BOA. BOA is quite an aggressive fork of Aegir, and I'm not sure I want all the changes and whatnot that comes with it. I think I have to discount it, because the last time I looked there would simply be too much change on the nginx side of things at least, and it was doing all kinds of things I don't simply understand and thus won't be able to reason about.

The main inspiration I take from BOA is that they've got it working! Well, they've got something working. It looks like they've essentially forked Drush 8, applied some Drupal core and Aegir patches. This makes it so that Aegir can still use it's aliases, code and talk to Drupal 10 sites. How they've been able to do this is very impressive indeed. I feel like it's just a matter of time before it breaks though, surely Drupal 10 is going to change something in it's lifecycle and cause issues. I don't quite see how this can work with Drush commands in contrib modules. For example, during deployments on our sites we revert features, but that's a features module provided Drush command, which won't be callable from Drush 8 in Drupal 10.

Get Aegir 3 to work with Drupal 10

This I feel is the least effort option. Find some way to get standard Aegir 3 to communicate with Drupal 10. Now, Drush 8 can't directly bootstrap a Drupal 10 site. Aegir 3 uses Drush 8 to be both the backend storage for all the data about the sites to host, and to bootstrap the sites it manages.

This worked really well in the Drupal 5/6/7 days, and just about coped with Drupal 8/9, but hasn't for Drupal 10. Think of it this way, what if instead of hosting a Drupal site, it was a Wordpress site? Aegir simply wouldn't be able to neatly bootstrap into a Drupal site and do it's stuff. It's the same with Drupal 10.

How much stuff does it really do though? I'm not 100% sure. I know that it gets the currently installed packages for example, but what else does it do. It looks to me like it often hands off a Drush subprocess do the heavy lifting. Maybe we can hand off to another subprocess, one that runs a site-local Drush 12+ instance, passing in all the options it needs to bootstrap and run the actual commands on the site.

Please, if this is a completely crazy way to go, someone please comment and let me know!

Move to Aegir 4

So there is a 4.x branch of Aegir, and apparently it can work with Drupal 10 sites. It does this by replicating the aliases to YAML files and then running a global Drush 11, which can then bootstrap the Drupal sites. Apparently it also has replaced some of the Drush invocations with standard process invocations. I guess it had to do this because the Drush to Drush process communication stuff was in Drush 8 and got removed.

It seems like Aegir 4 also brought in a lot of other changes too, and that's not particularly something I want or need. Also, it's never been officially released/tested by the community etc.

Move to Aegir 5

This got announced in a few blog posts a while back, and I've not heard anything since. It's possible that it's there and ready to go, but as far as I understand it, it's a whole change to how the sites would be managed and hosted, and while an import from Aegir 3 is on the roadmap, it seems like it would import the sites into something completely different, not some simple vhosts and a DB server.

Also, even if it does exist, it'll have had minimal testing and eyes on it.

Move to something else

I think this is my preferred long-term option. These sites don't really need Drupal. They could actually be static sites plugged into a central content repository. That would drastically simplify lots and lots of things. Or we keep the Drupal sites, but move them to Kubernetes and using something like Amazee's Lagoon to host them etc. This would be very cool, but probably quite expensive in terms of having enough resources to host all the containers.

One for the long term future I think.

Get Aegir 3 to work with Drupal 10

I might give this a go in that I think what I can do is this:

1. Get Aegir running normally.
2. Install a Drupal 9 site.
3. Get a single Aegir task running that doesn't bootstrap the Drupal 9 site with Drush 8. I'm thinking something like getting the one-time login link. This has data flowing in both directions, and I think, Drush 8 trying to bootstrap Drupal to the run the provision command. Getting this working would involve calling a site local Drush based on the data from the alias, but not actually using the alias.
4. If that works, put something into settings.php that throws an exception if Drush 8 is detected, and then try to get everything else working for my use-cases.
5. Then try and set up a Drupal 10 site.

I'd love to know your thoughts on this. Do you have an old Aegir running sites, and you don't know what to do with it? Or do you think I'm crazy and want to offer me a better way to go, use the comments below, please!

Updates/notes

So looking at the provision commands, the actual provision command to say, get the one-time login link bootstraps the Drupal site. So that would need to change that command so that it no-longer bootstrapped Drupal at all, but instead changed to be a pure Drush command. Then it could load the data from the alias etc.
I'm tempted to go ahead and get a dev instance of Aegir running and the add a new Drush command, that doesn't bootstrap Drupal, but does attempt to grab data from an alias and see what I can do. That possibly an even simpler proof of concept, as it's an entirely new Drush command, but one I then know could be called by provision's task runner instead of the current one.

The requirement is to cache content for as long as possible, but update promptly when content changes are made in Drupal. 

Note that in this setup I’m using Acquia Edge powered by Cloudflare, but the strategy would be similar for Acquia Edge powered by Akamai.

The objective is to bootstrap Drupal as infrequently as possible, by relying on the Varnish and CDN layers, but always to serve fresh content: Cache pages in Varnish for a long time, but provide a method (Purge) to invalidate Varnish when a content change is made in Drupal. At the CDN layer, the goal is to make sure the current version of a page is delivered to the browser, by checking Varnish frequently to see if a new version is available. This check is a lightweight call to Varnish. If Varnish does not have a new version, the CDN-cached version is delivered.

Drupal Modules:

An increasingly common setup is to use Drupal as the CMS / backend of an application with a frontend Node.js application: Drupal holds the content and manages certain things like search indexing and integration with certain third-party tools (DAM, for example), and the Node application creates the presentation layer. An assumption in this post is that the Node.js application is making JSON:API requests to the Drupal application via the Drupal core JSON:API module’s functionality.

With this setup, it’s critically important to plan a cache strategy, to avoid making excessive requests to the backend and potentially sacrificing performance. Here are some considerations.

Objective: For the best results in terms of performance and utilization, both the Drupal backend and the Node.js frontend should have a cache strategy in place. 

We all know such an effective and common way of demonstrating content as a slideshow. Similarly, visual content was shown even before the invention of computers on ancient mechanical devices that used slides. This is where the name comes from.
But, sometimes, a simple carousel of pictures is boring. Today, the Drupal web development agency tells you how to add slideshows using Drupal views effectively and creatively.

Authored by: Nadiia Nykolaichuk.

Libraries are known as one of the most traditional ways of helping people get valuable knowledge. Most people imagine a library as a quiet building with long shelves, filled with the scent of well-worn books and the quiet rustle of turning pages. It’s a true intellectual haven, and librarians are its guardians.

Drupal's contribution recognition system is a key part of the way we recognize and incentivize contribution in the Drupal project. It's a system that needs constant care and feeding, both to ensure that we're recognizing the many kinds of contributions people and organizations are making, and to ensure that the system itself is proportional and fair for the effort being put in.

Event Sponsorship credit

We're about to introduce a new way for organizations to improve their marketplace rank. Drupal.org/community/events has allowed organizers to feature their sponsors since the beginning. Now, those sponsors listed will automatically receive contribution credit as well. To start, this will be a fixed amount for small events and a larger one for DrupalCon, but in the future, in collaboration with event organizers, we'd like it to scale to each sponsor's level of support.

We hope this will encourage companies to do the important work of financially supporting the grass roots events that help our community thrive. (And reward those who already do!). 

Reducing redundancy

We're also making a small tweak to the system this week related to how we recognize Contributor Roles. Contributor Roles are community submitted, and represent all of the many ways contribution happens in our community. However, we want to avoid double counting credit for certain types of roles. For example, issue credit is a fundamental pillar of our contribution recognition system, and some of our community roles such as 'Project Contributor' are also organically receiving credit from issues. 

We will no longer be granting marketplace rank to organizations sponsoring roles that are already represented in other ways, and we'll update the contributor role descriptions to reflect when this restriction applies. 

We expect this change to help level the playing field between some organizations who've made extensive use of the role system, and others who have kept a laser focus on contribution and innovation directly in issues.

Drupal is a cutting-edge open-source content management system that has won global acclaim as a web development tool. Every Drupal development company across the globe and business organization relying on Drupal proclaims that the CMS is unmatchable in terms of web development. If you have also heard a lot about the magic of Drupal and wonder what makes it so phenomenal, this blog is for you. It elucidates 4 reasons why Drupal is a worthwhile investment for web development. 

You are probably interested in setting up a workign environment for Drupal-based projects or maybe you have new members in your development team, so the configuration of the correct development environment is a fundamental part of the process of working with Drupal, you are right. By reading this how-to guide, you will implement a complete and ready-to-go Drupal working environment ready for versions 8, 9, and 10 of our favorite CMS/framework. Do you want to start?…

Picture from Unsplash, user Mathyas Kurmann, @mathyaskurmann.

This content has been constructed as a …

In Part 2 of our exploration of Symfony components in Drupal, we focus on the event dispatcher.

The event dispatcher is a tool that enables the application to communicate across objects by subscribing to and listening for events. It achieves this by creating a directory for various event types, and the corresponding registered listeners for each event type. When a specific type of event occurs, the code that has registered a listener for that event is invoked. If you're familiar with the Mediator and Observer design patterns you might recognize similarities here.