Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Having a corrected 'Available updates' report is great, but people who depend on drush for updates still have broken data. Let's fix that!
It appears that we can do something like:
/**
* Implements hook_drush_engine_ENGINE_TYPE().
*/
function mydropwizard_drush_engine_update_status() {
return array(
'mydropwizard' => array(
'description' => 'Check available updates with mydropwizard.module.',
'drupal dependencies' => array('mydropwizard'),
'class' => 'myDropWizard\Drush\StatusInfoDrupal6',
),
);
}
And then use 'drush ups --update-backend=mydropwizard' to use our (yet to exist) myDropWizard\Drush\StatusInfoDrupal6 class to call to our service.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | mydropwizard-drush-2681403-3.patch | 34.26 KB | dsnopek |
Comments
Comment #2
dsnopekHere's a patch that works for 'drush up --update-backend=mydrowizard' and 'drush ups --update-backend=mydropwizard'.
It doesn't have any effect on 'drush dl', though. :-/
Need to figure out if there's a way to fix that!
Comment #3
dsnopekThis version includes a release_info engine to support 'drush dl'. This is way less clean than the 'update_status' engine, because this engine really was never meant to be swapped out and is tightly coupled to
Drush\UpdateService\Project, which meant that I had to fork the whole thing and modify it. :-/ This should probably be improved upstream in Drush itself, but this whole module is a big fork job anyway, so I think this is probably fine.It also sets mydropwizard as the default update_status engine, so you no longer need to specify it on the command-line.
Comment #5
dsnopekThis has been working for me in my testing all day, even for the new Prepopulate 2.3 release (which is only in the mydropwizard data - it's not from Drupal.org). So, committed!
Comment #6
mariagwyn CreditAttribution: mariagwyn commentedJust a quick note that the project page specifies using Drush 7, but I seem to be getting results from Drush8 as well.
Comment #7
dsnopekYeah, I was struggling with how to word that on the project page.
I want to let people know that Drush 7 works because it supports PHP 5.3, which is the oldest reasonable PHP that makes sense to still run, and Drupal 6 sites tend to run older versions of PHP -- whereas Drush 8 needs PHP 5.4.5+. I worry if people see Drush 8, they'll just write this off as something that won't work for them.
I've added the word "at least" to the project page, which will hopefully make it clear that Drush 8 works too. Suggestions welcome to make it clearer if you have any!
Comment #8
moshe weitzman CreditAttribution: moshe weitzman at Acquia commentedI'm available to chat or phone about whether Drush itself can work better you.
Comment #9
dsnopek@moshe: Thanks! Unfortunately, I have a million other things to do for the D6 LTS right now, and wouldn't be able to really focus on helping the drush team with this for a week or two.
In the meantime, I can put a few comments here...
The way update_status engines work and are swapable is great! I have no complaints there. :-) However, release_info engines are a whole other story. Here's some things that would make them easier to extend:
ReleaseInfo::andProject::) - some kind of dependency injection (maybe specifying the Project class name in the engine config?) would possible have allowed us to inherit from those classes, rather than having to copy-paste and modify them.Those are really the main things! Thanks again!
Comment #10
mariagwyn CreditAttribution: mariagwyn commentedJust FYI: a drush8 update just worked on a D6 site, beginning to end. It is more fragile, I need to look in to other errors, but at base, it works.
Comment #11
dsnopek@mariagwyn: Awesome, thanks for testing! If there were any errors (even if it worked in the end), could you open a new issue with them? Thanks!