Fatal error: Call to undefined function entityreference_get_behavior_handlers() in C:\xampp\htdocs\recruiter\profiles\recruiter\modules\entityreference\entityreference.install on line 44

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kscheirer’s picture

Priority: Critical » Normal

Can you give some more information to reproduce this bug?

greggles’s picture

Status: Active » Postponed (maintainer needs more info)

I agree with downgrading the priority until there's a clear set of steps to repeat the bug (as kscheirer did in #1).

Also updating the status.

Damien Tournoud’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)
MichaelCole’s picture

Status: Closed (duplicate) » Active

Hi, I got this error when moving a site from d7.1x to d7.19 on pantheon - specifically when using Drush. The site would show a maintenance mode screen.

The bug marked duplicate didn't address the issue, and the patch didn't apply.

To fix, I added this line to the top of entityreference.install:

require_once "entityreference.module";

A call stack:
quickstart@qs10:~/websites/nvbarcle.dev$ drush cc all

Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /home/quickstart/websites/nvbarcle.dev/sites/all/modules/entityreference/entityreference.install on line 44

Call Stack:
0.0004 707712 1. {main}() /home/quickstart/drush/drush.php:0
0.0230 5140824 2. drush_main() /home/quickstart/drush/drush.php:14
0.1696 15852136 3. _drush_bootstrap_and_dispatch() /home/quickstart/drush/drush.php:59
0.2274 15859360 4. drush_bootstrap_to_phase() /home/quickstart/drush/drush.php:79
0.2274 15859360 5. drush_bootstrap_max() /home/quickstart/drush/includes/bootstrap.inc:291
0.4431 42284120 6. drush_bootstrap() /home/quickstart/drush/includes/bootstrap.inc:345
0.4446 42286760 7. _drush_bootstrap_drupal_login() /home/quickstart/drush/includes/bootstrap.inc:185
0.4449 42287056 8. drush_drupal_login() /home/quickstart/drush/includes/bootstrap.inc:949
0.4449 42287056 9. user_load() /home/quickstart/drush/includes/drupal.inc:138
0.4449 42287880 10. user_load_multiple() /home/quickstart/websites/nvbarcle.dev/modules/user/user.module:366
0.4449 42288016 11. entity_load() /home/quickstart/websites/nvbarcle.dev/modules/user/user.module:291
0.4449 42288016 12. entity_get_controller() /home/quickstart/websites/nvbarcle.dev/includes/common.inc:7729
0.4449 42288928 13. entity_get_info() /home/quickstart/websites/nvbarcle.dev/includes/common.inc:7760
0.4486 42494328 14. drupal_schema_fields_sql() /home/quickstart/websites/nvbarcle.dev/includes/common.inc:7592
0.4486 42494408 15. drupal_get_schema() /home/quickstart/websites/nvbarcle.dev/includes/common.inc:6981
0.4492 42496304 16. DrupalCacheArray->offsetExists() /home/quickstart/websites/nvbarcle.dev/includes/bootstrap.inc:0
0.4492 42496304 17. DrupalCacheArray->offsetGet() /home/quickstart/websites/nvbarcle.dev/includes/bootstrap.inc:345
0.4492 42496304 18. SchemaCache->resolveCacheMiss() /home/quickstart/websites/nvbarcle.dev/includes/bootstrap.inc:356
0.4492 42496304 19. drupal_get_complete_schema() /home/quickstart/websites/nvbarcle.dev/includes/bootstrap.inc:2946
0.4699 46234936 20. module_invoke() /home/quickstart/websites/nvbarcle.dev/includes/bootstrap.inc:2992
0.4699 46235488 21. call_user_func_array() /home/quickstart/websites/nvbarcle.dev/includes/module.inc:833
0.4699 46235856 22. field_sql_storage_schema() /home/quickstart/websites/nvbarcle.dev/includes/module.inc:0
0.4732 46656448 23. field_read_fields() /home/quickstart/websites/nvbarcle.dev/modules/field/modules/field_sql_storage/field_sql_storage.install:16
0.5131 47160456 24. module_invoke() /home/quickstart/websites/nvbarcle.dev/modules/field/field.crud.inc:373
0.5133 47163336 25. call_user_func_array() /home/quickstart/websites/nvbarcle.dev/includes/module.inc:833
0.5133 47163824 26. entityreference_field_schema() /home/quickstart/websites/nvbarcle.dev/includes/module.inc:0

Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Call to undefined function entityreference_get_behavior_handlers() in /home/quickstart/websites/nvbarcle.dev/sites/all/modules/entityreference/entityreference.install, line 44
Drush was not able to start (bootstrap) Drupal. [error]
Hint: This error can only occur once the database connection has already been successfully initiated, therefore this error generally points to a site configuration issue, and not a problem connecting to the database.

Drush was attempting to connect to:
Drupal version : 7.19
Site URI : http://default
Database driver : mysql
Database hostname : localhost
Database username : nvbarcle_dev
Database name : nvbarcle_dev
Database : Connected
Default theme : nvbar
Administration theme: seven
PHP configuration : /etc/php5/cli/php.ini
Drush version : 5.7
Drush configuration:
Drupal root : /home/quickstart/websites/nvbarcle.dev
Site path : sites/default
Modules path : sites/all/modules
Themes path : sites/all/themes
File directory path: sites/default/files
Private file directory path: sites/default/private
temp : tmp
%paths : Array

MichaelCole’s picture

Version: 7.x-1.x-dev » 7.x-1.0

For whatever reason, all contrib modules were disabled in the database (inc EntityReference)

Something is attempting to use entityreference when it's disabled. It's a database error for my site so I have to back and fix something else.

matiaslezin’s picture

#4 did the job.

kscheirer’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
Issue tags: +Novice

Awesome, want to create a simple patch that does that? It should go against 1.x-dev.

RobLoach’s picture

Status: Active » Needs review
FileSize
625 bytes
Damien Tournoud’s picture

Status: Needs review » Closed (duplicate)
jhodgdon’s picture

Status: Closed (duplicate) » Reviewed & tested by the community

I do not think this issue is a duplicate of that other one.

I got this problem today after trying to create a development copy of a running site on my test server using Backup and Migrate.

The database was successfully migrated, but the site didn't come up.

I checked the {system} table and entityreference module's status was 1 (enabled), and yet this error occurred and I couldn't visit any pages on my site.

Applying the patch in #8 fixed the problem.

Since this error can apparently come up without having entityreference being disabled, would you consider adding this patch to the module? The patch should not hurt anything, and it does seem that the error can be triggered even though the module is enabled. Granted, it was after a Backup and Migrate restore to migrate a site to a different host, but as it's a simple fix and it did fix the problem... please? :)

Firelf’s picture

Thank you for the patch. If anyone needs to know, I encountered this error whilst restoring a development backup onto the production site using Backup and Migrate. I too got the patch in #8 to work. If more details are needed, just holler.

ianthomas_uk’s picture

I'm working on an install profile which includes some dummy content. I also encountered this bug, and #8 fixed the problem for me too. It looks low risk and now has three community reviews, please can it be committed?

welly’s picture

Fourth confirmation this patch fixes the problem!

alberto56’s picture

Issue summary: View changes

Thanks for the patch. Two notes though:

(1) using require_once is not recommended usually. See here and here.

(2) although the patch fixes the problem, It seems to be a temporary solution. I think the module file should be loaded if we are in the .install file, no? This might be a symptom of an underlying problem, maybe #1459540: People seems to be able to disable a Field module which still has fields, and core seems to call field hooks on disabled modules?

alberto56’s picture

Status: Reviewed & tested by the community » Closed (duplicate)

The patches posted at #1459540: People seems to be able to disable a Field module which still has fields, and core seems to call field hooks on disabled modules seem more thought-out than this one, see comments 47 and 58. I'd argue in favor of marking this issue as a duplicate, unless someone can demonstrate why it is better to explicitly load the module file instead of just ignoring the function call if the module does not exist.

ianthomas_uk’s picture

Status: Closed (duplicate) » Needs work

#14.1 Good point about require_once, I think we should be using drupal_load(), or possibly module_load_include().

#14.2 There are some cases where the .module will not be loaded before a .install. To quote the drupal_load() change request, "The function [is] used to manually load .module or module-related include files when these [are] not loaded automatically, for example to load a disabled module's .module file during uninstallation."

#15 Please be cautious closing issues, as it makes them a lot less visible. I don't see why the patches on the other issue are better thought out. In my example (creating dummy content in an install profile) I expect the patches on #1459540 would mean that instead of the fatal error I'd get incorrect or missing content, which could be considered worse. #8 means my code still runs as intended and creates the required content.

Setting to needs work, as I think we need a patch similar to #8 but not using require_once.

cs_shadow’s picture

Status: Needs work » Needs review
FileSize
613 bytes

Attaching patch that uses drupal_load() instead of require_once.

alberto56’s picture

Status: Needs review » Needs work

The last submitted patch, 17: entityreference-1836106-17.patch, failed testing.

cs_shadow’s picture

Status: Needs work » Needs review
FileSize
614 bytes

Missed the semicolon in last patch.

loudmu’s picture

#20 worked for me

pimok3000’s picture

using the patch at #20 simply changes the error into:
PHP Fatal error: Call to undefined function ctools_include() in /mysite/sites/all/modules/entityreference/entityreference.module on line 173

Fatal error: Call to undefined function ctools_include() in mysite/sites/all/modules/entityreference/entityreference.module on line 173
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Call to undefined function ctools_include() in
/mysite/sites/all/modules/entityreference/entityreference.module, line 173

if i take away the line require_once "entityreference.module"; from entityreference.install the error on line 44 reappears.

stuzog’s picture

I'm having the same problem on a Drupal7 Commerce Kickstart-based site that was updated using drush and now shows this error without any access to any pages. I suspect that there are modules not enabled that should be, as previously suggested. Drush has the identical problem, so I can't clear caches etc. I even tried registry_rebuild -- no change.

kscheirer’s picture

You can always clear caches by connecting to the database directly and truncating all tables that start with "cache".

greggles’s picture

I'm not sure the exact reason why, but I also ran into this issue and #20 fixed it for me.

My scenario was similar to jhodgdon in #10: migrated the site and then in the new location I got this error (though I used drush sql-dump and then loaded the db backup directly).

Jaypan’s picture

20 worked for me as well. Same situation as others - backup and migrate restore caused the error.

Jaypan’s picture

Status: Needs review » Reviewed & tested by the community
treksler’s picture

#20 works for me as well

mrconnerton’s picture

#20 worked for me as well

jroberts’s picture

#20 worked for me.

alberto56’s picture

Title: Fatal error: Call to undefined function entityreference_get_behavior_handlers() » Fatal error: Call to undefined function entityreference_get_behavior_handlers() in entityreference_schema()
Status: Reviewed & tested by the community » Needs work

According the the hook_schema API page, hook_schema cannot always rely on the module file being loaded or hooks being known. We are explicitly loading the module file in this patch but the module's ctools dependency still seems to not be known, as can attest comment #22, above.

The patch herein only works on systems which already have ctools enabled before entityreference_schema() is called. If ctools is not enabled on such systems, then the error at #22 occurs. I am setting this to needs to work accordingly.

If you site does not have ctools enabled, then entityreference_schema() is called before entityreference's dependencies (including ctools) are loaded, so even if we explicitly load entityreference.module, the function being called, entityreference_get_behavior_handlers(), in turn calls _entityreference_get_behavior_handler(), which itself calls ctools_include(). At this point the fatal error occurs.

One solution might be to make sure ctools is enabled before running this code in the hook_schema(); however module_enable(array('ctools')) would require cache clearing to be active, which itself would call entityreference_schema() again, resulting in an infinite loop.

medienverbinder’s picture

#20 worked for me as well.

Situation:

For troubleshooting I switched off all non-core modules with drush. (not the best solution, I know ;-) ).
When I tried to enable the disabled modules again, the following error message appears:

PHP Fatal error:  Call to undefined function entityreference_get_behavior_handlers() in /var/www/htdocs/drupal/sites/all/modules/entityreference/entityreference.install on line 44

Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /var/www/htdocs/drupal/sites/all/modules/entityreference/entityreference.install on line 44
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Call to undefined function entityreference_get_behavior_handlers() in /var/www/htdocs/drupal/sites/all/modules/entityreference/entityreference.install, line 44

Drush was not able to start (bootstrap) Drupal. [error]

Hint: This error can only occur once the database connection has already been successfully initiated, therefore this error generally points to a site configuration issue, and not a problem connecting to the database.
DamienMcKenna’s picture

Just to mention it, the patch in #20 saved the day for us when a production deployment was failing because of this bug. I suggest committing the patch so the bug at least has a temporary fix, and then bikeshed on whether the module's internal logic should be changed.

budda’s picture

The patch #20 fixed my problem after cloning the production site locally to work on it.

kwerey’s picture

I ran into this error restoring from a Backup & Migrate backup - Entity Reference was enabled in the system table, but I was getting a fatal error visiting any page except the homepage.

Truncating cache_bootstrap fixed the problem for me, but I'm glad to know there's work happening on a patch.

I feel like the cause of this must be a little different to the issue about disabling field modules without deleting the fields. The only modules on my site that require it Commerce Coupons, which were enabled and have all their dependencies in order - is it more a load order problem?

I'm interested in why that function call is being made: the error occurred on any page load whether or not Commerce products were being rendered.

bdupls’s picture

I tried #20 and the error changed to
Fatal error: Cannot redeclare class EntityReference_BehaviorHandler_Broken in /home/xxx/public_html/profiles/commons/modules/contrib/entityreference/plugins/behavior/abstract.inc on line 214
These 2 links seem to refer to the same error.https://www.drupal.org/node/2425825
Running update doesn't update the entity_translation module
The following updates returned messages
entity_translation module
Update #7006

wiifm’s picture

Status: Needs work » Reviewed & tested by the community

Agree with @DamienMcKenna here, this 1 line patch rescued our broken deployment, here is the error message produced:

Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /mnt/www/html/sitename/docroot/profiles/profilename/modules/contrib/entityreference/entityreference.install on line 44
Drush command terminated abnormally due to an unrecoverable error.

After applying the patch, the issue went away. I really don't see what the issue with committing this is, the issue has been open for a long time, and people are still experiencing the (critical) problem.

juampynr’s picture

Found this error after downloading the development environment's database to my local environment. Patch #20 fixed it.

DamienMcKenna’s picture

stevo70’s picture

Patch #20! Highly appreciated.

ronaldmulero’s picture

Path #20 for the win! Thanks.

AdamPS’s picture

#20 is good.

As @torstenzenk points out, the patch doesn't solve things for everyone. However it has helped a lot of people now. As far as I can see, it has not actually made it worse for anyone. Plus it's only a single line. Seems good to commit.

deetergp’s picture

I was getting this same error and the changes in #20 worked for me as well. Let's get it in!

deetergp’s picture

Actually… #20 does not apply anymore. I updated and am re-submitting it.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 44: entityreference-1836106-44.patch, failed testing.

AdamPS’s picture

Status: Needs work » Needs review

#44 seems like the exact same patch as before but with the wrong patch format

Xano’s picture

Status: Needs review » Reviewed & tested by the community

This is the same patch as #20. I re-uploaded it so the maintainer will not have to search the entire issue.

I confirmed the validity of this fix with @catch on IRC. I can also confirm this patch works, so setting the issue to RTBC again.

Xano’s picture

FileSize
614 bytes

And now with the patch!

Devin Carlson’s picture

Status: Reviewed & tested by the community » Fixed

Tested #20 and committed to Entity Reference 7.x-1.x.

kscheirer’s picture

There's still the problem of folks not having ctools available later on in the function call. Probably needs another module_load_include, or just return.

Status: Fixed » Closed (fixed)

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

kscheirer’s picture

Status: Closed (fixed) » Needs work

Not completely fixed, see #31. Also #51, #42, #22.

howards’s picture

The code in patches previous to this comment was put in place in ef2075e

While others have noted the issues are not completely fixed, patches up through *-48.patch will not apply as the code has been committed.

joelpittet’s picture

Ran into this, this project could really use a stable release. upgrading to dev helped resolve this.

AdamPS’s picture

Status: Needs work » Fixed

@kscheirer Please can you raise a new issue for the outstanding problems? In my experience, once an issue has been fixed, even if not fixed completely for everyone, reopening it just leaves everyone confused.

The issue as it stands describes a particular scenario and symptoms. The issue has now been fixed for many users.

The problems that remain will presumably have a different scenario "if you upgrade from version blah to blah without ctools already installed", symptoms "error message blah" and workaround "manually install ctools". It will need a different patch (as per #54). The "version fixed" might even end up being different.

Status: Fixed » Closed (fixed)

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

hkirsman’s picture

Applied the bach and now getting Fatal error: Call to undefined function ctools_include() in /Users/hannes/Sites/vap/sites/all/modules/entityreference/entityreference.module on line 173

hkirsman’s picture

This is the patch that fixes #58. Should we create another issue? I've built on my custom git branch but should work. Well, at leat you see what i did. :)

AdamPS’s picture

@hkirsman Yes I suggest you raise another issue if you would like the patch to be committed - a patch file on an already fixed issue is not likely to noticed by the maintainers. If you are happy to leave your patch here as "FYI other readers", then it's fine.

tjcvd’s picture

@hkirsman I applied your patch and got the following error now:
Fatal error: Call to undefined function facetapi_get_realm_info() in /home/sarelres/public_html/tvd_sarel/sites/all/modules/contrib/search_api/contrib/search_api_facetapi/search_api_facetapi.module on line 15

Jaypan’s picture

That's a problem with the facetapi module, not this one. It looks like the patch solved that problem, and now you're dealing with a different one.