1

The upgrade from 4.6.10 to 4.6.16 ran and pronounced itself successful, but after re-enabling the modules The site reports an error which shows via Drush as:

WD menu: CRM_Core_Exception: Invalid Filter in CRM_Core_BAO_CustomGroup::validateSubTypeByEntity() (line [error] 647 of MYSITE/public_html/sites/all/modules/civicrm/CRM/Core/BAO/CustomGroup.php).

Running cron or clearing cache does nothing to help.

I did a compare of the backup files to those in the modules/civicrm direcotry and found one new file (Civi.php) and few other differences

diff /drupalbackups/civicrm4.6.pre16/civicrm-version.php /public_html/sites/all/modules/civicrm/civicrm-version.php 3c3

< return array( 'version' => '4.6.10',

return array( 'version' => '4.6.16', 5c5

< 'revision' => '3a0725b2d0' );

            'revision' => 'dcf53fa10e' );

Only in /public_html/sites/all/modules/civicrm: Civi.php diff /drupalbackups/civicrm4.6.pre16/composer.json /public_html/sites/all/modules/civicrm/composer.json 4a5 .... QUITE A FEW CHANGES IN THIS FILE diff /drupalbackups/civicrm4.6.pre16/composer.lock /public_html/sites/all/modules/civicrm/composer.lock 7c7,8 .... QUITE A FEW CHANGES IN THIS FILE

Only in /drupalbackups/civicrm4.6.pre16: .htaccess (I placed that to control against timeouts)

3 Answers 3

2

This is a JIRA ticket here which references a patch that others have said has fixed things. I just tried cherrypicking the changes over and then run drush cc but still seeing same errors.

clearly relates in my case to a contact_sub_type that looks like it had its name changed (in contact_type I am seeing label = Funder. and name=Funder_ but in custom_group it is just referred to as Funder)

I did try changing the contact_type name from Funder_ to Funder but no joy

EDIT: actually i think renaming did succeed, as i then reversed the patch out, for the sake of something else to try, but same error on drush cc - and then on a whim visited civicrm/upgrade, and while that page told me "Your database has already been upgraded to CiviCRM 4.6.16.0" it did the job, and the resolved alerts flooded on to the phone etc.

Hope that gives you some clues.

Also, in case it has any relevance, the sub-type that caused the problem had "CiviEngage - Funder" in the description, so wondering if the misnamed type came as part of that? Maybe worth checking.

10
  • No joy for me, or not much. I tried the patch (or really replaced CustomGroup.php with raw.githubusercontent.com/JKingsnorth/civicrm-core/CRM-18504/… ) and with just civicrm enabled, things seemed to work. As soon as I enabled any other related modules, the entire site was back on error. To fix I had to disable civicrm entirely.
    – TimETown
    May 7, 2016 at 1:24
  • Tried editing civicrm_custom_group.extends_entity_column_value value that seemed wrong, which in my case was Orchestra_MemberMusician instead of Orchestra_Member. Did not fix it with or without the patch.
    – TimETown
    May 7, 2016 at 1:27
  • Rolled back the patch and even after the edited value in the civicrm_custom_group table, site immediately errors out.
    – TimETown
    May 7, 2016 at 1:30
  • I have found another site which hit similar problems
    – petednz - fuzion
    May 7, 2016 at 4:05
  • what i see in DB is that contact_type has name = Media_Outlet and label of Media Outlet - and in custom_group it is Media_Outlet
    – petednz - fuzion
    May 7, 2016 at 4:05
1

The patches in Jira did not fix the problem for me, I was upgrading from 4.6.16 to 4.6.20.

I was able to fix this problem by changing the CustomGroup.php file to output the $subType and $subType the error is about in the error output and then setting those values to to NULL in the custom_group table's extends_entity_column_value column for each error.

0

The patch described on JIRA ticket CRM-18504 resolved the problem for me on 4.7.7

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.