Closed (fixed)
Project:
Panopoly
Version:
7.x-1.0-rc5
Component:
Install
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
17 Aug 2013 at 09:52 UTC
Updated:
23 Dec 2013 at 06:02 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
c13l0 commentedI updated drupal core with drush on a local site and haven't found any new issues (yet).
Comment #2
dsnopekI've also used Panopoly 1.0-rc5 with Drupal 7.23 without problems. Panopoly doesn't patch core and the changes in Drupal 7.23 shouldn't have an effect on Panopoly.
If anyone interested in writing a patch, this is the file to change:
http://drupalcode.org/project/panopoly.git/blob/refs/heads/7.x-1.x:/drup...
Comment #3
mrfelton commentedSame here - We are using 7.23 with Panopoly in the latest Open Academy codebase. Here is the patch.
Comment #4
kbell commentedHowever, on Pantheon we have to do these updates manually because the upstream repo doesn't have 7.23 as it's dependency, so the sooner we get this update in the better. I personally love to have these updates happen in 10 minutes instead of an hour. Plus I just feel more secure in the Pantheon infrastructure knowing it's coming from the upstream repos in Git instead of being a manual update.
So, pretty please?
Thanks!
-Kelly
Comment #5
kbell commentedPS - one of my developer partners used the patch to update one of our sites already, but he forgot to write that he's reviewed it so we can push it through the process. I've asked him to comment asap, for the RBTC.
-Kelly
Comment #6
timani commentedThis patch looks clean and should be safe to commit to get the upgrade to core pushed out.
Comment #7
dsnopekI've used Panopoly plenty on Drupal 7.23, so I'm going to RTBC this.
Comment #8
liza commenteddittoing the RTBC. definitely needed this. thanks!
Comment #9
mrfelton commentedComment #10
lsolesen commentedUpdate to Drupal 7.24.
It seems a little odd to need to have to change the Drupal version in four different files though?
Comment #11
lsolesen commentedHere is a patch which makes use of include instead of having to update a drupal core update in four places?
Comment #12
dsnopekThanks for the patch!
Unfortunately, the Drupal.org packager doesn't support make files with
includes[]. All the extra file are actually to work around limitations in the Drupal.org packager. :-/ I've been working on a phing-based build system to make life easier for distribution maintainers, but, yeah, ideally we'd be able to fix the packager itself!Comment #13
dsnopekCommitted in 61c7e54!
Comment #14
lsolesen commentedCommerce kickstart uses the method i suggested
Comment #15
dsnopek@lsolesen: Ah, sorry! I honestly didn't even look at your second patch, I just saw your comment about
includes[]and wrote it off. :-/ Sorry about that!It's Simplytest.me that uses the build-*.make file, not Drupal.org and I just tested Commerce Kickstart 2.9 on Simplytest.me and it works fine.
Follow-up committed in baa7ae1.
Once again, sorry about that!
Comment #16
boabjohn commentedHi guys,
Sorry for kicking in here with what is probably a bit clueless query, but I'm quite new to the workflow for both Pantheon and Drupal Profiles. I've got skin in both of these camps now with a real project on the build.
Then when D7.24 came out I suddenly realised I was not sure what is best practice...
- In the Pantheon world we have the standard Panopoly profile installed
- Pantheon is entirely based on Pressflow...the standard Panopoly profile available through d.o is based on vanilla Drupal (no?)
- I've asked Pantheon support for some guidance on how to get the new Pressflow 7.24 version installed and they have said:
- They also point out that an update notice will appear in my control panel when the new Panopoly is available, but there is no ETA for that.
So...
it's a bit of an outside request perhaps, but for people like me with a tendency towards OCD when it comes to security updates, would it be possible to post up an expected release date for *both* the Drupal and Pressflow versions of Panopoly?
And, what is the recommended practice for handling individual module updates? I have been updating some of the modules that come along with Panopoly...if I run a *profile level* release, won't that overwrite my interim updates and patches? I may have chosen to run with a dev version of a module where Panopoly profile is only packaging the recommended release...
Any clues most appreciated.
Kind regards,
JB
Comment #17
lsolesen commentedThe team behind Panopoly is working hard on the release right now http://www.systemseed.com/blog/getting-panopoly-10-and-beyond. You can help speed up, when the next release can be tagged by help test out patches for https://drupal.org/project/issues/search/panopoly?text=&assigned=&submit...
Comment #18
dsnopek@boabjohn: We're aiming to release Panopoly 1.0 shortly before Christmas. @lsolesen is right! If you want to help us get there on time, please test and/or review patches that are part of the sprint! It would be much appreciated. :-)
I'm not sure where the Pressflow version of Panopoly comes from. @populist: Is this something you know about?
Also, I don't know much about Pantheon, but I have to believe that it's possible to update Drupal without waiting for us... If you have Git access to the full site installation, can't you just copy Drupal 7.24 over it?
I hope that helps!
Comment #19
mrfelton commentedThe version of Panopoly that runs on Pantheon comes from https://github.com/populist/panopoly-drops-7. Once we release 1.0, we will push the update out to the panopoly-drops-7 repo on github, which will have the result of pushing the update out to Pantheon since that repository is configured as the upstream for the Panopoly distro on Pantheon. The only difference between the Pantheon build and a standard build is the Drupal core which for Pantheon comes from https://github.com/pantheon-systems/drops-7
To understand better how this works, have a read through of http://helpdesk.getpantheon.com/customer/portal/articles/1150064-running...
Comment #20
boabjohn commentedThanks guys for the replies and clarifications.
We have the Pantheon security update already in place now, so that's good.
I'm really not sure why we need to keep updating Panopoly as a distribution profile though since we update the component contrib modules at various points (ie, at any time we feel it's a good idea) so we're already "out of sync" with the Panopoly profile. Why would we update the profile? Only advantage I see is to gain access to the 3-4 custom modules that Panopoly directly develops. Have I got that right or am I missing some secret sauce that makes the profile more important than I'm suggesting?
Thanks indeed,
JB
Comment #21
dsnopekIf you're fine with what Panopoly does already and have no problem maintaining it yourself - you could stay with the current version of the Panopoly profile if you want!
However, sometimes updating contrib modules will require updates to the code in the Panopoly modules. Also, we try our best to only do updates that won't break anything and upgrade correctly (although, we can make mistakes too). Once we get into the cycle of doing releases more often, you wouldn't necessarily have to do any updates for modules that come from Panopoly, because we'll do them. Sometimes too, Panopoly depends on patches to modules in order to work, so you have to be careful what you update manually.
Anyway, it's up to you!
Comment #22
mrfelton commentedAs a general rule of thumb you should avoid upgrading individual modules from a distribution, and instead only update the distribution as a whole when new releases for the distribution are released.
A distribution is a carefully selected set of specific versions of modules with specific patches applied that are known or required in order to 'play well' together.
By upgrading just a single module from a distribution without upgrading the distribution itself, you risk breaking things that have been developed for the distribution that may require specific versions of specific code.
You are of course free to upgrade individual components if you need to, but make sure that you know what you are doing beforehand, be sure you know what new code the new version of a module introduces or what code that it removes. Be sure that have applied the same patches against the module that were applied by Panopoly if those patches have not already been committed to the module upstream.
Comment #24
boabjohn commentedHi guys,
I am truly sorry for pestering the queue here, but I'm keen not to bork our site through sheer ignorance.
So:
Could you please let us know if it's safe to proceed with an upgrade to all Panopoly modules listed in the Admin>Modules>Update list?
Thanks hugely!
JB
Comment #25
boabjohn commentedreopening: I once again forgot to use this field for the comment instead of the tempting field at the bottom of the issue thread!
Comment #26
lsolesen commentedA new release of panopoly is coming soon. All the subprojects have already been tagged. See #2161415: Create Panopoly 7.x-1.x release
Comment #27
dsnopek@boabjohn: You can't simply update the Panopoly modules - that probably won't work. Each of the modules comes with a .make file which adds dependencies and patches to those dependencies. If you want to update each of the Panopoly modules manually, you'll have to also run each of the .make files with Drush. The easier solution would be waiting for the 1.0 release of Panopoly (like @lsolesen mentions) and upgrading to that. Once that's out, it *should* just be a matter of clicking a button on Pantheon. However, if you made some manual changes to the distribution that may mess things up.
Comment #28
mrfelton commentedAlso relevant to this discussion is #2128959: Replace default "update" module behavior with something that makes sense for distributions. Would be good to get that in so that people don't get confused by this in the future.
Comment #29
boabjohn commentedAhhh dearie me.
Thanks to you fellas for taking the time to help explain this. Lured by the promise of the newly available goodies, I had already gone forward with a manual update of all the Panopoly sub-modules using the Drupal Admin>Module UI.
It's possible I could roll back to a previous database, but I've done a fair bit of Views/field/panels work too...would not want to lose that, but such is life.
Do you have any recommendations?
When the full profile release is available, should I just try a one-click over-write?
At the moment the site seems to be working...
Sorry to be a pain...as I say the workflow around using a profile (and Pantheon) is pretty alien for someone like me who has been building it all from scratch.
Good luck with your new release. And if you have any guidance for me, much appreciated.
Kind regards,
JB
Comment #30
dsnopekYou could finish the manual upgrade by also running the .make files from all the Panopoly modules? I'm not sure how this will affect your ability to do the Pantheon one-button upgrade later, though.