Problem on upgrading Drupal 7 core to Drupal 7 Commons distribution

By suthagar on 30 Oct 2014 at 12:31 UTC

Hi Team,
I want to upgrade my existing site from Drupal 7 core to Drupal 7 commons distribution,
I have followed some steps http://chocolatelilyweb.ca/upgrading-to-a-drupal-distribution.

While enabling some commons module (commons media) I am getting following error.
Fatal error: Call to undefined function commons_entity_integration_info() in profiles/commons/modules/commons/commons_media/commons_media.module on line 67.

Please suggest right way to upgrade Drupal 7 core to Drupal 7 Commons distribution

Comments

That sounds like a lot of

John_B commented 30 October 2014 at 17:07

That sounds like a lot of work! I would have just added the Commons features you need.

To debug the first thing is to check where the function should be defined. I think commons.api.php. You can check by searching all the files in commons for the string 'function commons_entity_integration_info()'. Then check that the file is present. This is usually the problem. Even if the file is present you could copy it again, in case was somehow corrupted when you loaded it onto the server.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

The commons_entity

suthagar commented 31 October 2014 at 09:52

Thanks Jhon,

The commons_entity_integration_info function is available in commons.profile file (profiles/commons/commons.profile).

If I redeclare the same commons_entity_integration_info function in another place means, its saying the function is already exist.

I have switched the commons profile using profile switcher module from standard profile.

If a function exists in a

John_B commented 31 October 2014 at 10:41

If a function exists in a file which should be in the file path, and is either not being loaded or not being loaded until too late, sometimes this is because the files are not registered in the database. In this case this tool https://www.drupal.org/project/registry_rebuild gives an alternative to sorting it out manually.

Also watch out for a stale opcode cache if you are using an opcode cache such as APC or php >= 5.5

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Hi John,

suthagar commented 3 November 2014 at 11:04

Hi John,
I tried registry rebuild and changing the module weight also,
I am getting the error "FieldException: Cannot change an existing field's type. in field_update_field() (line 234 of field.crud.inc)"

The site has multiple content types with multiple fileds and i am getting conflict in features also.

I am not sure where this is

John_B commented 3 November 2014 at 15:02

I am not sure where this is going. Do you mean that after the registry rebuild, the original problem cleared up and there was a new problem? Or do you mean that the old problem is still there and that there are two new problems?

Personally I would take a step back and consider implementing the functionality you want without using Commons. Keeping a Drupal profile up to date is a bit of pain because you depend on its maintainer, though I daresay Commons is one of the best supported.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

John, When I started updating

suthagar commented 4 November 2014 at 06:50

John, When I started updating to Commons profile, I did the registry rebuild. Its works fine before & after switching to commons profile but after enabling commons module registry rebuild not executed successfully, I got the fatal error that I reported in first.

Now changed the modules weight and profile settings in database through backend and I enabled all commons releated modules through drush. Now I am getting error "FieldException: Cannot change an existing field's type. in field_update_field() (line 234 of field.crud.inc)".

Even after disabling all custom features module also I am getting same error.

You need to work out which

John_B commented 4 November 2014 at 07:23

You need to work out which field has a type which needs to be change. Watchdog (ie. Reports > Latest Log Messages) may have some details, as suggested in post #14 here. Then you need to work out how to manually change the field type, as stated here.

Before you do that, you need to be aware the probably one module created the field in question and another module is trying to change it, so you may have a conflict where the same field name is being used in one way by one module and another way by another. Thus the first step is to get the name of the field which is causing the problem. The second step is to identify the module(s) which create and use that field (perhaps by searching for the field name in the code base). Then if there is more than one module using the same field name, either disable the module which is trying to update the field, or work out a plan of action. Once there is only one module using the field name, if you still have a problem, look at changing it manually, as suggested above.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors