Basic instructions to upgrade Panopoly

Posted by PedroKTFC on January 16, 2014 at 1:23pm

I've been using Panopoly for a few months to develop a site in my spare time. I hadn't done any module upgrades since I installed it and decided it was about time I did, especially as there were a few security upgrades (I was at drupal core 7.22).

I naively started going through the modules using drush to update them but quickly broke my site (no panic, all nicely backed up, phew)! After a bit of googling, I came across this https://drupal.org/node/2067773 so I realised I should be rather more careful how I upgrade things.

I've managed to update drupal core to 7.26 via drush but now I don't know where to go. The implication of the thread above suggests I should wait for a new Panopoly distribution, is this correct? When I get an update of all the modules that need updating I notice a few points:

there are a few modules (Media, Entity API and Entity reference) that have security updates. Ideally I'd update them immediately but can I, how should I?
most of the Panopoly specific modules suggest updates to version 7.x-1.0, yet looking at the Panopoly project page there's still only the rc5 release available. Is v1.0 actually available?
what about other modules, how and when should they be upgraded (I've added several)?
the thread above suggests using make. I've never yet used make for any drupal updates. Are there any instructions for using make in this context?

A simple step-by-step set of instructions would be very useful (apologies if they already exist, but I couldn't find them).

Thanks for a great distro btw.

Comments

It's best practice NOT to manually update modules from a distro

Posted by dsnopek on January 16, 2014 at 1:58pm

Hi PedroKTFC!

With any Drupal distribution, it's best practice NOT to update any of the modules that come with the distribution - unless you really know what your doing. :-)

Distributions include a lot of modules that sometimes have very complex and specific inter-dependencies, so going updating version 1.1 to 1.2 (which maybe harmless on its own) could break something somewhere else. Also, they include patches which may be necessary to make certain features work. If you update the module without re-applying all the patches, thing could break. And, of course, a patch might not apply to the new version and need an update too!

So, it's usually easiest to wait for the new version of the distribution to come out and and update only to that.

Unfortunately, due to bugs in Drupal.org, we're unable to make a new Panopoly release right now:

https://drupal.org/node/2161415

The Panopoly 1.0 release was supposed to come out on December 22nd. Since then, we've actually fixed a bunch of bugs and updated some more modules for security releases (in Git) and are already ready to release Panopoly 1.1!

So, as soon as Drupal.org will let us, we'll make both of those releases. :-)

In the meantime, you could try building Panopoly yourself from Git! (Unforunately, the Drupal.org bugs also mean that the 7.x-1.x-dev release isn't updating either - don't use that, it's old!)

Here is how you'd do that from the command line (requires git and drush version 5.8 or higher):

git clone --branch 7.x-1.x http://git.drupal.org/project/panopoly.git
cd panopoly
./build.sh /var/www/panopoly

Of course, replace /var/www/panpoly with the directory that you'd like the new Panopoly distribution to be built. When asks, I recommend building in release mode.

This will give you the equivalent of what you would get after unpacking a Panopoly release from a .zip or .tar.gz file in the directory you specify.

I hope that helps!

Best regards,
David.

Drush up panopoly_core?

Posted by miromarchi on May 16, 2014 at 8:03am

dear dsnopek,
I understand that the good practice is to update the distribution and not the singular modules.
So, my question is what is the good practice to update the distribution?
Is it drush up panopoly_core?

Thanks
[update]: I've been unclear in my comment, so let me add something.
I had installed panopoly by inserting panopoly related lines in my profile makefile, as stated in doc page: Developing Distributions with Panopoly.
I.e.:

; The Panopoly Foundation
projects[panopoly_core][version] = 1.1
projects[panopoly_core][subdir] = panopoly .... and so on

My drupal core version is 7.24

So now I am trying to follow this procedure:
1. drush up drupal
2. drush up panopoly_core
3. drush make --no-core --working-copy sites/all/modules/panopoly/panopoly_core/panopoly_core.make
4. drush updatedb
5. drush up panopoly_admin
6. drush make --no-core --working-copy sites/all/modules/panopoly/panopoly_admin/panopoly_admin.make
7. drush updatedb
and so forth for all panopoly modules which bear a makefile.

Is this a kind of smart thing to do? Is there another way?
I can't just download the full panopoly package, cause I never installed it.
I'm testing this procedure, I'll update the results.

Update with a custom makefile

Posted by miromarchi on May 16, 2014 at 3:24pm

The procedure above ended in many failures. So I tried with more success to create a custom make file, to launch every singole panopoly module from that make file, in ordert to let panopoly modules to manage their priorities and dependencies.
My make file is called update_panopoly.make and looks like this:

core = 7.28
api = 2
projects[] = drupal

; this make file is used to update panopoly

; The Panopoly Foundation
projects[panopoly_core][subdir] = panopoly
projects[panopoly_images][subdir] = panopoly
projects[panopoly_theme][subdir] = panopoly
projects[panopoly_magic][subdir] = panopoly
projects[panopoly_widgets][subdir] = panopoly
projects[panopoly_admin][subdir] = panopoly
projects[panopoly_users][subdir] = panopoly

; The Panopoly Toolset
projects[panopoly_pages][subdir] = panopoly
projects[panopoly_wysiwyg][subdir] = panopoly
projects[panopoly_search][subdir] = panopoly

I launch the make file it via this command drush make --working-copy rbv_update_panopoly.make

Then I launch drush updb and the script executes all database updates required.

I do have some issues with kalatheme, but this is out of this problem I believe.

Can you tell me if this is a good practice?

If you're using your own .make, things are even easier! :-)

Posted by dsnopek on May 16, 2014 at 8:36pm

If you're using your own .make file for your own distribution, updating is even easier! All you have to do is change the version number of the panopoly_* modules. For example, if your .make file had this:

projects[panopoly_core][version] = 1.4
projects[panopoly_core][subdir] = panopoly

You just need to change that to:

projects[panopoly_core][version] = 1.5
projects[panopoly_core][subdir] = panopoly

And then re-run drush make which will pull in the new panopoly_core, but also (and super importantly!) all the dependencies at the right versions and with any necessary patches.

So, yes, I'd say that using a .make file is definitely best practice! In the next release notes I'll put some instructions for people using drush make as well.

Thanks so much for posting about the things you tried and the issues you had! I'm glad you've got it working and good luck fixing the remaining Kalatheme issues!

verify-makefile missing

Posted by malberts on January 16, 2014 at 2:54pm

@dsnopek
Sorry for hijacking this discussion, but I'm not quite sure where to ask this as it relates to the manual building process.

When I run build.sh I get the following error:

Building Panopoly distribution...
Verifying make...
The drush command 'verify-makefile' could not be found.  Run drush cache-clear drush to clear the commandfile cache if you have installed new extensions.
A Drupal installation directory could not be found

I'm running Drush 6.2 (from PEAR). I couldn't find any reference to that command in the GitHub repo. I'm also having trouble finding information about it in general.

Am I supposed to install something else or did I overlook something stupid?

Ah, sorry! verify-makefile comes from drupalorg_drush

Posted by dsnopek on January 16, 2014 at 3:18pm

Ah, sorry! 'verify-makefile' comes from drupalorg_drush - you'll need to install that as well:

https://drupal.org/project/drupalorg_drush

Further questions

Posted by PedroKTFC on January 16, 2014 at 2:59pm

Thanks David, very helpful. I'll give building from git a go myself, I should probably learn how to do it anyway. Of course I've now a further question!

I already use git for my work (hence being able to recover my work earlier) and I actually use it to push new versions from my development PC to my hosting provider. Given I have my own theme and additional modules in the same tree, is the build approach compatible with this?

Hope this makes sense!

Cool! When the build is finished...

Posted by dsnopek on January 16, 2014 at 3:21pm

Cool! When the build is finished, you'll have a directory that contains basically the same as what you would get from extracting a Panopoly release .zip or .tar.gz. Once you have that, it's still up to you to perform the upgrade! There's lots of ways to do it - it's basically the same as upgrading to a new Drupal release by hand:

http://drupalcode.org/project/drupal.git/blob/refs/heads/7.x:/UPGRADE.txt

I hope that helps!

Turns out I did overlook

Posted by malberts on January 16, 2014 at 3:02pm

Turns out I did overlook something.
To follow the manual building process above you need to install drupalorg_drush first:
https://drupal.org/node/1848294

Minor bug

Posted by PedroKTFC on January 16, 2014 at 11:23pm

I did what you said David, but as I had already upgraded drupal core to 7.26, I only copied the profiles folder and crossed my fingers. Initial findings are that it seems to have worked. The only thing though is that when I ran the update script I got the following error:

1 PENDING UPDATE (0 TO BE APPLIED, 1 SKIPPED)
panopoly_users module

7001 - Enable user_picture_field and copy from field_user_picture to users.picture.
This update will been skipped due to the following missing dependencies: fieldable_panel_panes_update_7107

I think I tracked this down to panopoly_users.install and line 17
'fieldable_panel_panes' => 7107,
an 's' seems to have been missed out:
'fieldable_panels' => 7107,
That seems to sort it.

Thanks so much for the bug

Posted by dsnopek on January 17, 2014 at 1:34pm

Thanks so much for the bug report! I've created an issue here:

https://drupal.org/node/2175729