Tag1 Consulting: Enhancing Drupal's Layout Builder: Introducing Layout Builder Plus

Drupal’s Layout Builder feature has established a critical content creation and display framework in the four years since its integration into Core. Replacing older, more complex tools like Panels and Display Suite, this integration marked a significant shift towards a more user-friendly, native layout-building experience. Better yet, unlike other JavaScript-based content layout tools, LayoutBuilder retains support for Drupal’s more powerful features like views, accessibility, and multilingual, to name just a few. Despite its robustness, creating an excellent Layout Builder experience for your content editors typically requires several additional community modules. These modules add layout options, style customizations, granular permissions, content preview-ability, and, most importantly, fewer clicks to get the job done! You can see a list of Additional Modules for Layout Builder on Drupal.org. Knowing which ones to choose and how best to configure them is a challenge of its own. To help solve some of these friction-ridden experiences, Tag1 would like to formally introduce its new Layout Builder Plus Module, which dramatically helps improve Drupal’s content editor experience out of the box! ## Layout Builder Plus by Tag1 ![Animated image walking through various features of the Layout Builder Plus module. It...

Read more Mariano Wed, 02/28/2024 - 06:27

The Drop Times: DrupalCon Lille 2023: A Personal Account of Adventure, Learning, and Community

Dive into a firsthand narrative of navigating visa hurdles, volunteering, and embracing the high-energy environment of DrupalCon Lille 2023. Gain insights into the Drupal ecosystem, contribution day experiences, and memorable encounters with industry peers. Explore the unique intersection of professional growth, global networking, and European travel in this comprehensive recount.

Specbee: How to integrate SSO with Drupal using SAML

Show of hands for anyone thrilled about logging in to every website every single time? Anyone? Didn't think so. When businesses prioritize convenience, customers will follow. Single Sign-On (SSO) is one such convenient feature that leaves your customers feeling satisfied and less stressed. It is a huge time-saver, is more secure (reduces password breach attacks), and increases productivity. In fact, businesses adopting SSO have seen an increase in user adoption rate too. Do you want to learn about how you can integrate SSO with your Drupal website? Keep reading and dive into the details! What is SSO ? Single Sign-On (SSO) is a user authentication service that allows users to use one login credential for all the systems integrated with SSO. Or, if there already is an open session in the main application, just clicking a button will log you in. An example: We can consider Quora as an example, as the forum allows you to create a new account, log in with those credentials, and also use social media logins (Google and Facebook).                          Source: https://www.quora.com/ Types of SSO Protocols Like any other concept, there are many available protocols to achieve this. Some of the common protocols are: Lightweight Directory Access Protocol (LDAP) Kerberos Security Assertion Markup Language (SAML) OAuth 2 OpenID Connect Things to know before we start XML Certificate/Key Generation XML XML (eXtensible Markup Language) is a markup language similar to HTML. It has the ability to store and transport data. Example: <start> <first>Data1</first> <new>NewData</new> </start>Certificate/Key Generation Certificates and private keys play a major role in SAML-based SSO. Since they are used for security reasons, they validate incoming requests. To generate an OpenSSL certificate and private key, run the following command in the terminal: openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout private_key.key -out certificate.crtHow it Works In SAML SSO, we consider the application requesting login as a Service Provider (SP), and the application providing authentication information is the Identity Provider (IdP). Flow: When a user tries to log in to SP, the browser sends a request to the SP server. SP will generate a SAML request (which contains SAML data in XML format) and redirect to the configured IdP URL (in SP) for authentication. Then, the IdP will validate the SAML data from the request XML with the pre-configured data of SP(in IdP). Once validated, IdP will generate an XML formatted SAML response to the ACS URL from the SAML request of SP with the current email address (by default which can be overridden) value with other data for validation. Now, SP will validate the data of the SAML response and authenticate the user of the email address in the SAML response.                                                                   Source Here, both the SAML request and SAML Response will be encrypted and will be decrypted in the redirected application (SP/IdP). In most cases, Drupal is used as a service provider, but it can also be enhanced as an identity provider. We can have 3 different types of SAML Request(AuthNRequest): AuthNRequest <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN_809707f0030a5d00620c9d9df97f627afe9dcc24" Version="2.0" ProviderName="SP test" IssueInstant="2014-07-16T23:52:45Z" Destination="http://idp.example.com/SSOService.php" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs"> <saml:Issuer>http://sp.example.com/demo1/metadata.php</saml:Issuer> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/> <samlp:RequestedAuthnContext Comparison="exact"> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest> With Signature (HTTP-Redirect binding) bM441nuRIzAjKeMM8RhegMFjZ4L4xPBHhAfHYqgnYDQnSxC++Qn5IocWuzuBGz7JQmT9C57nxjxgbFIatiqUCQN17aYrLn/mWE09C5mJMYlcV68ibEkbR/JKUQ+2u/N+mSD4/C/QvFvuB6BcJaXaz0h7NwGhHROUte6MoGJKMPE= AuthNRequest with embedded signature (HTTP-POST binding) <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="pfx41d8ef22-e612-8c50-9960-1b16f15741b3" Version="2.0" ProviderName="SP test" IssueInstant="2014-07-16T23:52:45Z" Destination="http://idp.example.com/SSOService.php" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs"> <saml:Issuer>http://sp.example.com/demo1/metadata.php</saml:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#pfx41d8ef22-e612-8c50-9960-1b16f15741b3"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>yJN6cXUwQxTmMEsPesBP2NkqYFI=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>g5eM9yPnKsmmE/Kh2qS7nfK8HoF6yHrAdNQxh70kh8pRI4KaNbYNOL9sF8F57Yd+jO6iNga8nnbwhbATKGXIZOJJSugXGAMRyZsj/rqngwTJk5KmujbqouR1SLFsbo7Iuwze933EgefBbAE4JRI7V2aD9YgmB3socPqAi2Qf97E=</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQQFADBSMQswCQYDVQQGEwJ1czETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMT25lbG9naW4gSW5jMRcwFQYDVQQDDA5zcC5leGFtcGxlLmNvbTAeFw0xNDA3MTcwMDI5MjdaFw0xNTA3MTcwMDI5MjdaMFIxCzAJBgNVBAYTAnVzMRMwEQYDVQQIDApDYWxpZm9ybmlhMRUwEwYDVQQKDAxPbmVsb2dpbiBJbmMxFzAVBgNVBAMMDnNwLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7vU/6R/OBA6BKsZH4L2bIQ2cqBO7/aMfPjUPJPSn59d/f0aRqSC58YYrPuQODydUABiCknOn9yV0fEYm4bNvfjroTEd8bDlqo5oAXAUAI8XHPppJNz7pxbhZW0u35q45PJzGM9nCv9bglDQYJLby1ZUdHsSiDIpMbGgf/ZrxqawIDAQABo1AwTjAdBgNVHQ4EFgQU3s2NEpYx7wH6bq7xJFKa46jBDf4wHwYDVR0jBBgwFoAU3s2NEpYx7wH6bq7xJFKa46jBDf4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQCPsNO2FG+zmk5miXEswAs30E14rBJpe/64FBpM1rPzOleexvMgZlr0/smF3P5TWb7H8Fy5kEiByxMjaQmml/nQx6qgVVzdhaTANpIE1ywEzVJlhdvw4hmRuEKYqTaFMLez0sRL79LUeDxPWw7Mj9FkpRYT+kAGiFomHop1nErV6Q==</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/> <samlp:RequestedAuthnContext Comparison="exact"> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest>Reference: https://www.samltool.com/generic_sso_req.php We can have different types of SAML Response: SAML Response <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z" Destination="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"> <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status> <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version="2.0" IssueInstant="2014-07-17T01:01:48Z"> <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer> <saml:Subject> <saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData NotOnOrAfter="2024-01-18T06:21:48Z" Recipient="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2024-01-18T06:21:48Z"> <saml:AudienceRestriction> <saml:Audience>http://sp.example.com/demo1/metadata.php</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2024-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93"> <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response>The rest of the types can be referred in https://www.samltool.com/generic_sso_res.php. The request and response can be sent as both GET and POST methods. Available Modules for SSO In Drupal, we have a list of modules for Service Provider and Identity Provider. Here are some of the SP and IdP modules: SP Modules: SAML Service Provider SAML Authentication Onelogin Integration miniOrange SAML SP(Paid Version)  IdP Modules: Light SAML IDP SAML IdP miniOrange SAML IDP (Paid Version) Testing Tools: Even though the data is encrypted, we can debug the SAML request with the help of the following tools. SAML Tracer for Mozilla Firefox. SAML Chrome Panel for Google Chrome. How to integrate SSO in Drupal using SAML Configure SSO module in SP Here we have used the saml_sp module for gearing up Drupal as a Service Provider. Configure SP module Settings Create the certificate and private_key and place them in a Drupal-readable location. Install the module.composer require 'drupal/saml_sp:^4.2' Enable the module in the Extend section.  Go to the configuration of the module (/admin/config/people/saml_sp). Configure the SP settings Provide the entityID if you want to override the default https://sp.lndo.site/user. Here https://sp.lndo.site is the domain. Provide an assertion URL similar to https://sp.lndo.site/saml/consume. Provide other mandatory details. Make sure that if you are using Sign specify the correct algorithm and select the Assertion and Encryption type based on requirement(based on the requirement of IdP). Provide the certificate and private key file path.Based on the data provided, Metadata will be generated. This XML metadata will be used for configuring the SP data in IdP. Configure Identity Providers in SP 1. Under Identity Providers click on Add Service Provider.2. Add the data from the metadata file/url provided by IdP. In SAML SP we can use the Drupal Login module once the above are configured. Under the Login Menu, configure the process of SAML login. For example, if a user without an account in SP but with an account in IdP creates an account in SP with an authenticated role. Configure SSO module in IdP Here we have used the light_saml_idp module for gearing up Drupal as an Identity Provider. Configure IdP module Settings: 1. Create the certificate and private_key and place it in a Drupal readable location.2. Install the module.3. Enable the module in the Extend section. 4. Go to the configuration (/admin/config/people/light_saml_idp) Provide the entity_id. Provide the other necessary details. Make sure to provide the correct file path of the certificate and private_key. Once the data is provided metadata will be generated under the Metadata tab. This needs to be provided to SP to configure there. Add the Service Provider under the Service Provider, with the data from SP metadata. The SSO will work properly once these are configured successfully. Hurray! SSO is integrated successfully. If you are not able to use the SSO, use testing tools to verify what is causing the issue. Final Thoughts You just learned how to seamlessly integrate SSO with Drupal using SAML for a stress-free user experience! Considering the protocols, certificates, and complex SAML login flow we've explored, SSO plays a significant role in simplifying user authentication. For a seamless SSO journey and Drupal development expertise, look no further than Specbee - your trusted partner in crafting exceptional digital experiences.  

Chapter Three: Next-Drupal 2.0: Making a Good Thing Even Better

Remember Next-Drupal? It’s that thing we used to talk about incessantly but have been fairly quiet about in recent months. Not to worry – we haven’t lost interest. In fact, we’ve been working hard to make our Next.js-powered decoupled Drupal front-end product even better in Next-Drupal 2.0! For those of you who are not yet familiar, here is a good introduction to Next-Drupal. For those already acquainted, please read on. Making a Fast Front-End Even Faster The primary reason for the new release is that Next.js has recently released a new feature called App Router. App Router is a new model for building applications in React that allows users to render some React components on the server side, as opposed to on the user side only.

Talking Drupal: Talking Drupal #439 - Drupal 7 Long-Term Support

Today we are talking about Drupal 7 Long Term Support, common security tips, and support services you can use with guests Greg Knaddison, Aaron Frost, and Dave Welch . We’ll also cover Storybook as our module of the week.

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

Topics
  • Drupal 7 EoL
  • Drupal will not stop working
  • Security team perspective
  • Security concerns
  • Extened Community Support
  • Long Term support
  • HeroDevs
  • Never ending support (NES)
    • PHP
    • Hosting
    • Security
    • Contrib
  • Product advisor
  • Colorado Digital Service
Resources Guests

Greg Knaddison - morrisanimalfoundation.org greggles Aaron Frost - herodevs.com aaronfrost Dave Welch - herodevs.com dwelch2344

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Ivan Stegic - ten7.com ivanstegic

MOTW Correspondent

Mark Casias - markie

  • Module name/project name:
  • Brief description:
    • The storybook module makes it easier to create a connection between Drupal and Storybook. It adds some Twig functionality so you can write Stories in Twig as opposed to YML or JSON or React
  • Brief history
    • How old: Less than a year
    • Versions available: Alpha4 came out earlier this month
  • Maintainership
    • Actively maintained: Yes
    • Number of open issues: 6
    • Test coverage: no
  • Usage stats:
    • N/A: for development only
    • Maintainer(s):
    • Mateu Aguiló Bosch (e0ipso) from Lullabot.
    • Module features and usage
    • Twig based stories
    • Pulls in Sites theme and base css.
    • So needs some updates to the development.services.yml
    • Also means it is hard to publish a storybook.
    • No need for SDC (but works well with it)
    • Great instructions on the module page
    • Way easier than previous integrations including cl_server.
    • Not as opinionated as previous storybook integrations.

ComputerMinds.co.uk: Aegir 3 and Drupal 10: just about working

In my previous article I outlined that I really needed to get Drupal 10 sites running in Aegir 3. I had no time to wait around for other solutions, and I was going to try to decouple Aegir from running Drupal sites, so that it wouldn't be tied to Drupal versions.

Since writing that article and actually sitting down to do this work, I realised that it's quite an undertaking, and the approach outlined by Omega8cc in various github issues was worth a second look.

It works!

But it's wild. It comprises three main things:

  1. A custom/forked version of Drush 8.
  2. A custom/forked version of Provision 3.
  3. A custom/forked version of Drupal 10.
  4. (A sneaky fourth is that you absolutely do not want to have site-local Drush)

So...yeah...it's not going to be for the faint-hearted, but I'm going to detail out those three things a little, and how you might want to apply them to your situation.

Custom Drush 8

So the official Drush 8 doesn't support Drupal 10. But, it's actually not that much work to get this up and running, since Drush has pluggable 'engines' that load code based on the Drupal version that's detected when running commands.

Omega8cc has done a great job of doing the leg-work and providing a forked version of Drush, you can see the changes that have been made to support Drupal 10 here:
 

https://github.com/omega8cc/drush/compare/8.4.12...8-boa-micro

Although note, that there are some Aegir specific and non Drush 10 supporting changes in there too, so what I did was to make my own (private) fork of Drush and go through and apply the relevant changes to the files. If you don't know what the relevant changes are, then you probably are better off simply replacing your Drush with the Omega8cc fork, and it'll probably be fine.

Essentially this step is needed so that Drush sees the Drupal 10 codebase, and can interact with it correctly. It's likely that in Drupal 10's lifetime something will change, and Drush 8 will need some more work to be compatible with 10.3 and 10.4 etc.

If you were to run Drush 8 commands at this point, they'd start to bootstrap the site, but would fail with fatal errors. You need changes in Drupal 10 core too...

Custom Provision 3

Provision also makes use of Drush engines to load the correct code for the correct situation, so that if you ask Aegir to install a new site on a platform it'll load up the correct bit of code for the relevant Drupal version.

Again Omega8cc has done all the hard work here and provided the changes you need, but they are a bit harder to pick out of the repo. Try searching for files that contain '_10':

https://github.com/omega8cc/provision

And that should get you the files you need. I will note that unlike the Drush fork above, this really is a heavy fork. You are getting a lot more besides Drupal 10 support, if you can, I'd go for patching this into your existing Provision codebase.

I could add these to official provision 3 on Drupal.org, but without the other pieces they are useless and won't help you. Aegir 3 is essentially unmaintained, so while I've committed some PHP 8 fixes in the last few weeks, I'm not going to commit huge things like this.
I suppose we could have some code maintained in an issue fork or a patch.

This step is need so that Provision will call the correct bits of code at the right time, as far as I can see, these are largely the same as Drupal 9 versions of the engines.

Custom Drupal 10

Now for the big compromise.

The main problem here is that Drupal 10 uses Symfony 6, which has type hints on various interfaces and methods, and Drush 8 uses Symfony 2, which does not.

So, if you load one before the other, then as soon as PHP tries to load the second, it'll die because either the types are there, or they aren't.

This is a bit of a showstopper and there's no decent way to get it to work nicely. Instead, Omega8cc has discovered some band-aids you can slap on and while it'll work, it's brittle!

Omega8cc's fork of Provision automatically tries to apply some of these patches to Drupal 10 platforms, and gives you a nice way to add/remove them. But again, also has a lot of other opinionated changes (to provision), so if you want to know what to do to Drupal 10 core...keep reading:

We need to:

  1. Remove a bunch of typehints from Drupal core's logging mechanisms.
  2. Downgrade psr/log
  3. Patch symfony/console

 

Removing the typehints

Omega8cc have got a nice patch that does this:

https://raw.githubusercontent.com/omega8cc/boa/5.x-dev/aegir/patches/drupal-ten-aegir-01.patch

And you can apply that using composer patches if you want.

Note that if you have any classes that extend these patched classes, they'll need patching too, so if you have any custom or contrib loggers, you'll need to go sort those out.

Downgrading psr/log

Composer makes this one super easy:

composer require 'psr/log:1.1.4 as 3.0.0'

Will do what you want. It's the companion to the first step, those classes implement these interfaces, so they need to get downgraded too. This might need to get adjusted if Drupal 10 core requires psr/log 3.1.0 or something like that, but the principles should still work.

If your Drupal 10 codebase isn't managed by Composer...well...getta out here and get that sorted first.

Patching symfony/console

Drush 8 only uses part of this package, so we can get away with patching just a tiny bit of it. Essentially you want to remove the 'Input' directory within the package. If you have a build system you could delete the files as part of your build process. Omega8cc's approach is to make the directory essentially unreadable.

Either way the result is that when PHP tries to load some code that uses version 6 of Symfony\console\Input it'll fail to find the code in Drupal core, and instead fallback to the version that came with Drush 8. Luckily this code isn't used by Drupal core, but you'll need to check that your custom and contrib code doesn't use it either, or handles the case when it magically loads code from Symfony 2.

For me and my codebase this was fine. None of our custom or contrib code used the classes or interfaces, so all good.

That's it

For Drupal 10 support in Aegir, that should be it. You can run Aegir 3 in PHP 8.1 and Drupal 7 and Drupal 10 on the same box. Magic.

Make sure you don't have a site-local Drush in your composer require, otherwise, Drush 8 being the great tool that it is will find it, and pass execution over to it, but it's not the same Drush that Aegir has all it's claws/hooks in, so things will go badly quite quickly.

Gotchas

Probably many, we've not actually rolled this out into our production environment yet, but we're close.

The main thing I can think of is that Drupal 10 contrib modules are very much going to assume that there's a modern version of Drush running commands, and not Drush 8, so it's likely that they aren't going to provide Drush 8 commands. You might need to write your own shims that copy/paste large lumps of code, or call through the new style Drush commandfiles, but that means that Drush command hooks won't be working quite right etc.

So yeah, danger if you're doing anything interesting using Drush commands on your sites.

Oh, and I guess it's possible that this will all break hard in the Drupal 10 lifecycle. I mean, it probably won't because it'll always be a foundation of Symfony 6, but you never know, the Drop is always moving and all that.

Thanks to Omega8cc

This was all shown to be possible, and documented in code by the great team at Omega8cc, so thanks very much for the work they are doing. I have nothing against there heavy forks of Aegir, they just aren't for me, hence why I've tried to pull out just the bits you need into this post.

Future

I still think that Aegir 3 could be decoupled from hosting Drupal sites. So that it was hosting 'sites' and then one could have some well-defined way to interact with those sites via some command line tool depending on what they were. However, that's a big effort, and Aegir 3 is essentially unmaintained now, so that's not going to happen. 

A number of others in the #aegir Drupal.org Slack channel have mentioned other alternatives, such as Aegir 5, or getting Drush 12 running Provision commands and running everything with Drush 12 instead of Drush 8, or using some other tool as the outer runner.
I think they are all going to run into the same issues/have to deal with the same thing: abstracting the notion of the 'site'. Provision 3 takes a number of shortcuts to make it really easy to pass data around between itself and the site, and those shortcuts simply aren't possible in Modern Drupal.

However, in case there's someone out there with a big ol' budget, and a desire to keep Aegir 3 going, I think the 'decoupled' Aegir would look something like:

  • A provision where the places that it calls through to functions executed in the Drupal context abstracted out into some kind of site specific 'plugin'. Instead of trying to use the nice Drush functions for calling a 'inner' Drush command, instead the usual command line interface would be used and data simply encoded on stdin/stdout/stderr in a format not tightly coupled to Drush 8 or Drush 12/13 etc.
  • Provision calls into the Drupal site a lot and because it's never needed to be explicit about doing it, it's sometimes hard to spot where this is happening.
  • Some kind of shim package that can be composer required into sites hosted on Aegir that would provide some way for the Provision plugins to call into the Drupal site and get the response it needs. Maybe this would merely provide some Drush commands.

Good luck if anyone ever embarks on such a project! Or contact us if you want a shoulder to cry on to hire us for a project!

The Drop Times: Which CMS? Global City Website Trends Examined

Explore the trends of Content Management System (CMS) usage on official city websites with a comprehensive study spanning 466 cities worldwide. The research delves into the prevalence of open-source solutions, highlighting the dominance of WordPress, Drupal, and other platforms. The report categorizes findings based on city size, region, and EU membership, revealing intriguing patterns and insights. The study raises essential questions about the adoption of open-source systems in the public sector, shedding light on challenges and opportunities for promoting transparency and cost-efficiency in digital governance. Dive into the detailed analysis to understand the global dynamics of CMS choices in city administrations.