You need this patch: https://github.com/omega8cc/hosting/commit/1fe13f2b3d567e01f2cd7cf7d3924...
Hello, I am happy to see you joining the effort to keep Aegir 3 alive.
We at omega8.cc have demonstrated last year that it’s perfectly possible to support Drupal 10 and beyond with surprisingly little effort and just a few tweaks to both Drush 8 and Aegir.
Since our efforts are not limited to making it possible to host Drupal 10 and beyond, we have already forked Aegir to add many new features which required some controversial modifications, including switching the admin interface to Backdrop CMS before D7 dies for good.
We also don’t support Ubuntu nor Apache, not even Debian after we have switched our BOA stack to Devuan, so it further limits our ability to support standalone Aegir 3 as it stands now.
That’s why having you onboard may be useful for those thinking about keeping their Aegir servers close to the project origins.
Anyone else will be able to easily migrate to BOA based Aegir 3 fork already supporting Drupal 10 and soon also Drupal 11. I will post about it separately.
Welcome to the team and hope others will welcome you too.
This has been fixed in BOA and we need to commit the fix back. While not recommended, it’s still useful for users trying to fix issues they can’t fix with system nor local Drush.
The patches looked promising, but they don't fix the problem in our tests (see the first run in the attached log), plus they break compatibility with PHP 7 (see the second run in the attached log) required by older sites and Aegir itself, since it's not yet fully PHP 8.1 compatible until we commit upstream some BOA patches. I'm thus bringing this issue back to Aegir 3 branch, which is currently our focus here.
Hey @porchlight, we are currently preparing to backport our patches to all relevant parts of Aegir and will also post a how-to to list requirements and changes normally automated in BOA but requiring some simple manual work for standalone Aegir. New issues will be opened to track this process.
TL;DR BOA supports Drupal 10 while running slightly modified Drush 8. We don’t need newer Drush versions and we shouldn’t.
Longer version follows.
Aegir 3 can work only with Drush 8 because it’s the only still supported Drush version which can be reliably used as standalone Drush.
All post-8 Drush versions up to 11 could theoretically be used as standalone (on command line but not with Aegir) if their dependencies matched the managed Drupal site code, which in practice happens rarely and thus should be used as site-local only.
Composer doesn’t care about possible versions conflicts between Drush and Drupal and you could get pretty different versions of the same Drush release installed depending on when you have installed it. This makes using them as standalone a completely unpredictable mess.
That’s why Drush 12 has been officially announced as the first version which can’t be used as standalone at all — no matter how hard you would try.
The only question was therefore: can we make the old good Drush 8 able to avoid conflicts despite aggressive deprecation coming with Drupal 10?
It seemed impossible initially, so we at Omega8.cc launched a complete rewrite of our BOA stack to make it use Aegir 3 without Drush — at least without the way it was always used, based on bootstrapping Drupal directly, with the intention to use it as a bridge with our own backend code, not affected by any Drush and Drupal compatibility issues.
It turned into serious rabbit hole and we have realized we couldn’t make it a mature enough project before Drupal 9 EOL, which in turn got us back in the dirty hacking and trying to make things work, removing obstacles as we go through tedious and frustrating debugging and testing cycles.
We didn’t believe it was possible, really, but we just wanted to give it a try before taking the risk of switching horses completely and without option to go back.
Guess what.. it worked! We are planning to release it tonight and upgrade all hosted Aegir systems later this night. More details are coming once we have more free time.
Take a look: https://github.com/omega8cc/boa/issues/1678#issuecomment-1778803057
Well, the news about Aegir 3 death were greatly exaggerated. Here’s visual proof: https://github.com/omega8cc/boa/issues/1678#issuecomment-1778803057
Aegir 3.x actually supports both PHP 8.1/8.2 and latest Drupal 9.x but not in this main/current upstream version but in the BOA fork, so we are working on backporting all accumulated fixes/patches.
Do we have any reference for the changes committed to Provision 4 and Provision 5 branches?
I have looked in the patches for a few months back and both look like heavily experimental sandboxes without any issues referenced, so they almost look like private repository not intended to be used by the community?
My questions arise since we plan to backport many accumulated patches from our BOA fork to bring the Provision 3 up to speed to fully support both PHP 8.1/8.2 and Drupal 9 and then we considered creating separate branch for the work being done on the Drupal 10 support, which is quite separate effort and can't be continued in the 3.x branch, while changes in 4.x and 5.x look pretty drastic without any documentation to figure out either backward compatibility or at least compatibility matrix -- like supported Drupal core, PHP and Drush versions.
I have already noticed many patches there similar to our attempts to overcome the limits of 3.x branch, so making this work more transparent could certainly help in avoiding reinventing the wheel.
This module works with any redis server version, we are using it with latest 7.x for a long time already.