This patch added UUID functionality to Ctools: #2155825: Add UUID generation functionality to CTools

If UUID isn't enabled, it will define some of the same functions. Unfortunately, if CTools is installed first, it won't see UUID and define the functions. Then when UUID is installed (during the same request during install) it will try to redefine those functions and we get this error:

PHP Fatal error:  Cannot redeclare _uuid_generate_com() (previously declared in /home/travis/build/lsolesen/drupal/profiles/panopoly/modules/contrib/ctools/includes/uuid.inc:19) in /home/travis/build/lsolesen/drupal/profiles/panopoly/modules/contrib/uuid/uuid.inc on line 158

Options:

  1. Simply re-order the dependencies in panopoly.info - Works in testing. However, if that's the solution, it will also have to be made in all distributions based on Panopoly too!
  2. Change panopoly_core_install_load_profile() to make sure that 'uuid' always comes before 'ctools' - This would continue to work with an distributions based on Panopoly without making any changes to it's .info file. But I haven't been able to get it to work yet...
  3. Remove 'uuid' from Panopoly.info altogether - We don't actually need this for anything and there is now a UUID API in Ctools. Then distributions based on Panopoly that wanted to continue using it could, but it'd be there problem since Panopoly would no longer support it.

What do you think?

Comments

caschbre’s picture

Isn't this more of an issue with CTools and UUID modules? I'm assuming that this could happen regardless of Panopoly.

dsnopek’s picture

Issue summary: View changes

Added an option to just drop 'uuid' altogether.

dsnopek’s picture

Issue summary: View changes
caschbre’s picture

I like option #3. Panopoly isn't making use of UUID so let's not try to spend time making it work since it isn't Panopoly specific.

dsnopek’s picture

@caschbre: Yeah, this would be a problem with any install profile that attempted to install both 'ctools' and 'uuid'. But it's also our problem because we're trying to do that. :-)

I've been churning on #2 for a while (like an hour and a half) and the only way to make it work, is to override the 'install_profile_modules' task as well. It unfortunately does an asort() on the modules before installing them! This would require existing distributions based on Panopoly to add something to their .profile, which makes it worse than #1.

I'm leaning towards committing a solution based on #1 and then creating an issue for #3, ie. just plain removing the 'uuid' module from the install profile. Users can still install it later if they want to.

dsnopek’s picture

Status: Active » Fixed

Committed a fix using approach #1:

http://drupalcode.org/project/panopoly.git/commitdiff/5be08ff4435dbf4ca8...

And created an issue to remove the 'uuid' dependency altogether:

#2186443: Remove 'uuid' dependency from panopoly.info

(I'm all for removing it, but I'd like to hear other peoples opinions first - primarily @populist who added it in the first place!)

japerry’s picture

Also to make ctools a bit more robust, I'm adding if statements around the functions in the uuid.inc file. That should fix this problem.

dsnopek’s picture

Title: Installing 'ctools' (1.4) before 'uuid' during Panopoly install causes fatal error » Revert: Installing 'ctools' (1.4) before 'uuid' during Panopoly install causes fatal error
Status: Fixed » Active

@japerry: Awesome, thanks!

To anyone else following along, this is the commit: http://drupalcode.org/project/ctools.git/commitdiff/f16fce929bc0dec36797...

This should fix the problem entirely. :-) Let's revert the Panopoly change as it makes the panopoly.info cleaner.

dsnopek’s picture

Status: Active » Fixed

Updated to the CTools revision with the fix and reverted the patch from this issue:

http://drupalcode.org/project/panopoly.git/commitdiff/9a3456eb6c8df53874...

caschbre’s picture

Just so I know where we're at.... we've effectively patched to ctools 1.4 and panels 3.4 on the dev release?

The reason I ask is I'm attempt to make some other patches but noticed that most of the feature modules are shown as overridden.

dsnopek’s picture

Yes, in the -dev Panopoly we're on the latest Git versions of CTools and Panels, which will become those releases on Wednesday. We probably won't release a new Panopoly on Wednesday, because we'll need to do more testing, but it'd be great to do sooner rather than later. If this has caused all the Features to be overridden, then I guess we'll need to deal with that before we can release!

caschbre’s picture

Yeah, just trying to figure out if I should make new exports of each feature module now or wait until the official ctools/panel releases.

dsnopek’s picture

I think now is probably best! If it turns out the problem should be best fixed in CTools or Panels, then we can help to make that happen before release which would be awesome. :-)

liza’s picture

due to the new Panopoly and those changes in Ctools & Panels, I lost a day of rebuilding my site. i opened a META discussion #2190579: [META] We have no best practices for updating to new Panopoly releases about why code updates for Panopoly have to re-assessed. the problems with CTools & Panels; along with these patches #2188597: Provide feature module updates for ctools / panels upgrade merit a new release of Panopoly --and maybe a new way of thinking how to package those updates/releases.

caschbre’s picture

@liza... why are you applying patches we haven't committed to the recommended release yet? These are patches we're working on in preparation for the yet-to-be-released versions of ctools and panels.

Status: Fixed » Closed (fixed)

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