Hey all,
I have been using panopoly for a few websites lately (one with rather complex functionality and quite some extra modules).
As we all know drush cannot update modules inside distributions the way it handles modules inside sites/all/modules
With drush dl this is not so bad (all though I think this drush should be able to do this somehow!)
However, with one project I have about 30 modules that extend panopoly.
It would be great if I can use drush up for those, instead of checking every module seperately and making a long command with specified modules each time I update.
So my quesion,
is there a way that makes drush ignore all modules in /profiles ?
If not, I read something about locking modules in drush so they won't update with drush up. Anyone tried this?
If this works, maybe it is an idea to explain this (including the full command for all the panopoly modules) in the update panopoly guide?
EDIT: or maybe include a bash script in the panopoly distro that runs the drush command so even new modules can be added and will be locked, that way the commands for a full update would be:
drush dl panopoly
drush make profiles/panopoly/drupal-org-core.make .(I SEE THIS IS NEW AS WELL)
drush updb
drush updb # yes, do it twice!
/profiles/panopoly/scripttolockmodules
drush up
This would prevent user error and make updating other modules a breeze...
I love the idea of distributions, but I hope we can find a way to make the update process as easy as possible (especially for small projects with small budgets :))
Thanks for you input!
Comments
What version of Panopoly are
What version of Panopoly are you running and do you have the Distribution Update Status Manager enabled? It "should" prevent modules defined in .make files from being updated. You'll want to test that locally first.
The way the distribution update status manager works is it reads the .make files for version #s and if the module matches that .make file, it registers that module as up-to-date. That should work with drush as well. So doing a drush up will look at the other modules not defined in .make files and update only those.
Now if you have a module in a .make file that doesn't match the .make file, it will be read as out-of-date and try to update that.
If you want to test what the drush command would do, try the following...
$ drush upc -n
That basically tells drush to update code (upc) but you pass -n to tell it no. Drush will read what modules need to be updated but not actually update them. You can verify that only your additional contribs appear.
-
@foggyperspectiv | foggyperspective.com (blog)
currently using 1.27
So this indeed seems to do something (THNX!)
I do see panopoly in the listed modules to be updated though,
drush up -n gives;
Panopoly (panopoly) 7.x-1.27 7.x-1.29 Update available
does that mean that it will update panopoly including all the modules that belong to panopoly in the profile folder (with the correct version)?
Because that would mean that drush now fully works with distro's!!
If it does does it check for what core version works with this version of panopoly?
In the past I have updated panopoly, then updated core and since core was brand new it didn't match the version from the make file.
I am sorry to sound so confused, but honestly I am a little confused about this, cannot really find any clear documentation..
Thanks again!
Unfortunately drush still
Unfortunately drush still doesn't update distros. The distro update status manager simply tries to keep admins from updating modules that are defined in .make files (by the distro). You'll still need to follow the upgrade instructions provided by panopoly.
But if you had other contrib modules you added on your own that needed update, I believe the method I mentioned above should work.
-
@foggyperspectiv | foggyperspective.com (blog)
Ok, so just to clarify, Do I
Ok, so just to clarify, Do I need to drush dl panopoly first?
So that drush doesn't try to update panopoly?
Or will it ignore it with drush up?
Check out the guide on
Check out the guide on upgrading panopoly (https://www.drupal.org/node/2272177). There is a section on using drush. You will use the $ drush dl panopoly followed by a few other drush commands.
If panopoly was the only thing showing when you did $ drush up -n then it sounds like all of your other non-panopoly defined modules are already up-to-date.
-
@foggyperspectiv | foggyperspective.com (blog)
Drush Update Status
Another drush command that will be very helpful is
drush ups
Drush update status checks the status of all modules on the site, and gives a list of those modules that have updates.
First I update Panopoly and let it update all of it's modules in the profiles directory. Then I run 'drush ups' to get the list of available updates. Then I compare that list to my contrib module list.
I usually keep contrib modules in a separate directory, so it's easy to compare the update list to a modules list in a file browser. Once I have a list of modules that need updating, I use 'drush up', and add the list of modules to be updated, like this:
drush up addtoany another_module_name and_another_module_name
Hope this helps.
@caschbre No, there were more
@caschbre
No, there were more modules showing, I just copied the line for panopoly.
I think the right way to update will be:
drush dl panopoly
drush make profiles/panopoly/drupal-org-core.make .
drush updb
drush updb # yes, do it twice!
drush up
I was just wondering what would happen if I did drush up before updating panopoly. Would that try to update panopoly or?!?
@wylbur
yea that is how I used to do it...
I was just looking for a way to not make a line like that and do this without checking what actually needs updates. But it seems there is a solution now :)
(I am still hoping for drush to eventually work completely with distri's)
Anyway, tnx guys!
Using distro_update, 'drush up' is actually safe :-)
Just to reiterate what @caschbre said in the first comment: if you have the 'distro_update' module enabled (which is enabled by default in recent Panopoly releases), then doing
drush upis actually safe -- it'll ignore all the module included by Panopoly and just update the ones you added.We probably will continue to recommend to people NOT to run 'drush up' because they could disable 'distro_update' or use a child distro based on Panopoly that doesn't use it, but this is a secret trick we can keep between ourselves. ;-)
Including a script to do the drush-based update of Panopoly is an interesting idea! Please open an issue about that:
https://www.drupal.org/node/add/project-issue/panopoly
Ah, cool thanks for the
Ah, cool thanks for the anwser, didn't know that distro update does this :)
Created a feature request in the tracker.
Coming back...
Hi guys,
Today I had some time so I thought I'd test this in a local vagrant environment. Turns out it is not safe to do a drush up, even with the distro manager!
I first updated panopoly as described in the guide and after that did a drush up...
I turns out this updated search_api from 1.5 to 1.6, which is a module only located in the panopoly profile folder.
I also updated to drush 8 (so maybe there is an issue there?!?)
Anyone who can enlighten me?