I could not find any issue in the issue-queue about this. But I was at a Drush 9 session at Drupalcon Vienna and learned some problematic stuff.

Drush 8 only support 8.3 and earlier.

Its because Drupal 8.4 has upgraded Symfony to version 3. And Drush 8 is built with Symfony 2. Most seems to be working but it might fail soon. But I had some problem in my Aegir install and need to debug in further.

It is not certain that Drush 8 will be updated either. Because current development is going into Drush 9. And Drush 9 only support Drupal 8 (no 6 and 7). Rewrite with OO code and plugins needs upgrading to new YAML standard, etc.

Here is the Drush status page:

And here is a link to Drupalcon Vienna session:

Members fund testing for the Drupal project. Drupal Association Learn more


kristofferwiklund created an issue. See original summary.

memtkmcc’s picture

memtkmcc’s picture

It's possible to use latest Drush 8 release to support Drupal 8.4, but there is no guarantee it will work with future versions.

We obviously can't use Drush 9, because Aegir needs to support Drupal 7 (and even legacy Drupal 6), also because Aegir itself is based on Drupal 7.

We need to figure out how to use both Drush 8 and Drush 9 for hosted sites to support both Drupal 7 and Drupal 8.4+

More context can be found in this issue: #2874827: Drush 8.x doesn't install Drupal 8.4.x and Drush master doesn't install Drupal 8.3.x

kristofferwiklund’s picture

I have now tried the latest Provision och the rc4 of Drupal. But it will not work.

I get lots of this warnings:
Illegal string offset 'version' provision_drupal.drush.inc:592

And no Install profiles has been found in the platform. So you can not install any site on the platform.

kristofferwiklund’s picture

I have found the problem. (But not a solution)

In file: platform/provision_drupal.drush.inc
On row 564:
$files[$name]->info = Symfony\Component\Yaml\Yaml::parse($yaml_file);

This will collect the basic information from the yaml file. The problem here is that provision is using the platforms Symfony version and running the parse() on the yaml file.

In 8.4 it tries the same thing. But Symfony has now been updated to 3.2.0 and the parse() function is not working like that. So we get no information from the yaml file.

kristofferwiklund’s picture

Found this in the Symfony documentation (http://symfony.com/doc/current/components/yaml.html)

"Because it is currently possible to pass a filename to this method, you must validate the input first. Passing a filename is deprecated in Symfony 2.2, and was removed in Symfony 3.0."

And that is what we are doing.

I have attached a patch that solves this problem. Because if we do a file_get_contents our self, it works and it is backwards compatible so it works for Drupal 8.3-

But that does not solve this issue its just the consequence of the root problem.

Jon Pugh’s picture

We need to figure out how to use both Drush 8 and Drush 9 for hosted sites to support both Drupal 7 and Drupal 8.4+

The modern recommendation of how to use drush is to embed it in the site that uses it... Perhaps it's time to look into triggering provision-backend-invoke using the site-local drush if there is one?

  • Jon Pugh committed c48f4bf on 7.x-3.x
    Issue #2911855: Adding a README.md in the provision/platform/drupal...

  • Jon Pugh committed 513fd9f on 2911855-d84 authored by kristofferwiklund
    Issue #2911855 by kristofferwiklund: Drupal 8.4 support: Fix loading of...
  • Jon Pugh committed c48f4bf on 2911855-d84
    Issue #2911855: Adding a README.md in the provision/platform/drupal...
Jon Pugh’s picture

The patch looks good, I pushed it to branch 2911855-d84, and I think we should commit this immediately.

There clearly are other issues coming, but this is a good first step.

Jon Pugh’s picture

Status: Active » Reviewed & tested by the community

Successful verify of 8.4.0-rc2 ... installing site now...

Jon Pugh’s picture

Undefined variable: config install_8.inc:113

$config is defined in settings.php, so I'd say this is a big problem at the moment...

ergonlogic’s picture

Status: Reviewed & tested by the community » Needs work

The path in #6 is definitely a good start, but I think Adam and Jon are correct. We should explore how to dispatch to a site-local Drush 9 for Drupal 8.4+ sites. Unfortunately, this means relying on the platforms' Composer config including Drush 9 (which doesn't even have a stable release, at this point). This seems fragile.

In the medium- to long-term, I think we should start putting more effort into the AegirNG initiative, and de-couple our code from Drush, since this issue is likely to only worsen.

Jon Pugh’s picture

Well it installed anyway.

That doesn't necessarily mean everything else will work but it's a start?

Can I get a RTBC?

P.S. I also added a README.md text to that directory, explaining that these files are bootstrapped into Drupal.

Jon Pugh’s picture

I agree that this Needs Work, I was just changing status to deal with this small patch first.

Jon Pugh’s picture

Ok, I've got a proposal for a step 2 to resolve this, and it's something which I've been wanting to do for a long time:

Add a "command" property to hook_hosting_tasks(). Right now, we hard code the drush command to run for a task as 'provision-' . $task->task_type.

It results in some silly things like extra provision commands for

I've got code ready to push that does the following:

   // Run the actual command. Adding alias here to work around Drush API.
-  $output = provision_backend_invoke($alias, 'provision-' . $task->task_type, $task->args, $task->options, $mode);
+  $output = provision_backend_invoke($alias, $task->task_command, $task->args, $task->options, $mode);

task_command is derived from hook_hosting_tasks(). To allow existing tasks to use default behavior, (append "provision-" to the task_type) I used hook_hosting_tasks_alter() to inject "provision-" if "command" is absent.

Please review over at #2912492: Allow hook_hosting_tasks to specify "command"? Then we can consider changing provision_backend_invoke()

Jon Pugh’s picture

Is it possible to utilize the "drush launcher" Moshe developed? It looks like it might already be doing some of the work (finding and bootstrapping a site and it's drush)


helmo’s picture

I haven't been following Drush development closely but wasn't there a a movement to get a per site drush installation and only have the bare minimum at a global level?
By supporting that we could handle this.

I tried to reproduce this and can confirm that #6 gets rid of the warnings.

More discussion in IRC #aegir at 18:00 UTC ( in 20m)

Jon Pugh’s picture

hmm it says

aegir@aegir:~$ drush
The Drush launcher could not find a Drupal site to operate on. Please do *one* of the following:
  - Navigate to any where within your Drupal project and try again.
  - Add --root=/path/to/drupal so Drush knows where your site is located.
  - Add a site alias so Drush knows where your site is located.

But drush @hostmaster doesn't work.

aegir@aegir:~$ drush @hostmaster
The Drush launcher could not find a Drupal site to operate on. Please do *one* of the following:
  - Navigate to any where within your Drupal project and try again.
  - Add --root=/path/to/drupal so Drush knows where your site is located.
  - Add a site alias so Drush knows where your site is located.
Jon Pugh’s picture

Wait I might be confused, this drush launcher might only work with sites with drush local in them...?

Jon Pugh’s picture


if you dont have a site local drush, you cant use this shim; call drush directly.

I wonder if it could fall back to a globally installed drush. Is that crazy?

memtkmcc’s picture

Yes, drush launcher expects site/codebase-local Drush present. We have experimented with using Drush to launch Drush child process, while both are different versions (for some rather crazy attempts to create a more controlled jail-like-env), but it seems that drush launcher could be useful if it would allow us to use version 8 with hostmaster and version 9 in the site context only. The big question is, does it work in both directions? So drush 8 will reliably get response from drush 9 site-context? Not sure if it's even possible?

memtkmcc’s picture

Globally installed Drush should be still supported even in Drush 9, I think?

Jon Pugh’s picture

aegir@aegir:~$ drush --version    
 Drush Version   :  8.1.12 

aegir@aegir:~$ drush @d8 status --fields=drupal-version
 Drupal version   :  8.4.0-rc2 

aegir@aegir:~$ drush @d8 uli                            
aegir@aegir:~$ drush @d8 cr 
Cache rebuild complete.      
Jon Pugh’s picture

tasks success

Everything is fine.

All tasks run fine.

As long as we keep using drush 8 globally, we don't have to worry about this just yet.

If we can confirm that drush 8 will be stable and compatible with drupal 8.4, we have until 8.5 comes out to deal with this in a more robust way.

colan’s picture

This gives us roughly 6 months before things could break irreparably: Drupal core release cycle: major, minor, and patch releases

memtkmcc’s picture

6 months is definitely better than 2 weeks, but it's also much less than, say, 2 years :-)

greg.1.anderson’s picture

In the short term, you should continue using a global Drush 8 as you suggest. This is currently working in Drupal 8.4.x, and currently broken in Drupal 8.5.x. Ideally, we will fix that problem so that Drush 8 will continue to work under Drupal 8.5.x; however, at the moment, the status of Drush 8 on anything after the last 8.3.x release is "unsupported, happens to work on 8.4.x". It is unlikely that Drush 8 will continue to be fixed for use with future versions of Drupal 8. The last supported version will depend on the difficulty of the required fixes. Drush 8 will continue to be supported for a long time on Drupal 8.3.x, Drupal 7, and Drupal 6.

If you wish to use Drush 9, note that currently there are NO VALID TAGGED RELEASES for Drush 9. We will probably tag an unofficial 'vienna' release for the sprinters tomorrow. The first Drush 9 release under the new architecture will be the 9.0.0-beta5 release. You should not try to fix or otherwise make any changes to the 9.0.0-beta4 or earlier releases, as most of the code from these versions has been REMOVED on the master branch, and replaced with the new Symfony Console-based runtime.

It is an aspirational goal to once again support Drupal 7 on the Drush 9 codebase. However, given the current Drush task list, it is currently looking doubtful that this will actually happen, at least not unless someone from the community steps up to port the commands and make this happen.

greg.1.anderson’s picture

See also https://www.drupal.org/node/2906637 for more background.

memtkmcc’s picture

@greg.1.anderson -- This is indeed helpful, and I really appreciate that you guys are willing to help make Drush 8 compatible with core 8.5.x (the core doesn't seem to care too much any longer, sadly, but that is the cost of progress, I guess).

The problem we face is: what is next? We can't hold any realistic hope that things will still (even if not officially supported) work with core 8.6+, so we must act *now* like there is no Drush future for Aegir, even if things may still work in the next 6-12 months (I hope!)

Aegir still needs to support both Drupal 8 and 7, and even 6, so we need to find a new way to build Aegir backend, so it will still use Drush where possible, but will no longer depend on it.

It was a fascinating decade, but we all need to move forward to stay relevant.

Jon Pugh’s picture

Status: Needs work » Fixed

Considering the patch is committed, and drupal 8.4.0-rc2 installs just fine, I'm calling this issue fixed.

Deprecating Drush definitely needs its own issue.

Helmo: Maybe we should go ahead and release 3.12.1 with this fix now, before 8.4.0 comes out, since people are testing the rc2 right now?

kristofferwiklund’s picture

I done some extra tests today. And for us the everything work for creating/deleting/remote import sites.

But its is risky that we have Symfony code in provision/Symfony/Component/ClassLoader.

And the loading either Symfony 2 and Symfony 3 code after that dependent on the Drupal 8 site version.

helmo’s picture

+1 for a 3.12.1 patch release ... we'll track that in #2882434: [meta] 3.12 release (bugfix/patches)

  • helmo committed 898e78b on 7.x-3.x authored by Jon Pugh
    Issue #2911855: Adding a README.md in the provision/platform/drupal...
  • helmo committed 9db9935 on 7.x-3.x authored by kristofferwiklund
    Issue #2911855 by kristofferwiklund: Drupal 8.4 support: Fix loading of...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.