It sure would be nice to explore the use of OG,
but EntityReference is required.

I installed 7.x-1.0-beta5 at my online website
and I enabled it,
but the first time I had clicked 'Clear all caches',
(on page.. admin/config/development/performance)
the site displayed only blank pages. Site-Dead.

I deleted the online folder ..../site/all/modules/entityreference
and the site came back to life.

I installed 7.x-1.x-dev - 2012-Feb-27.

I did NOT enable it and on the 'Modules' page,
'EntityReference' did not have a check-mark in front of it.

When I click 'Clear all caches', the site dies.


I actually wish all development on D7 would cease,
and D8 would be where all the creative energy and time was devoted
since that is where the leading edge of the Drupal dream resides.


All the best:

- Chris

#58 entityreference-1459540-58-workaround-fatal-error-try2.patch679 bytesmvc
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es). View
#47 entityreference-1459540-47-workaround-fatal-error.patch866 bytesmvc
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es). View
#40 entityreference-api_call_from_hook_field_schema-1459540-40.patch841 bytesMatthew Davidson
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es). View
#13 explicity_include_module.1459540.patch481 bytesjamesharv
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


haydeniv’s picture

Status: Active » Postponed (maintainer needs more info)

I just did a clean install of D7 with Organic Groups and Entity Reference 7.x-1.0-beta5 without any trouble. I think there is something unique to your install that is causing the trouble. Can you provide a list of the current contrib modules you have installed and the version of Drupal core you are using?

Also based on your comment about D7 development it would seem that you do not understand the relationship between Drupal's contrib modules and core. The major versions of Drupal that are released, D6, D7, D8 are what are considered core Drupal. There has always been 2 stable versions of Drupal core released at a time. Currently there are Drupal 6 and Drupal 7. When a new version of Drupal core is released, the older version is discontinued. So when D8 comes out, D6 will be discontinued.

Now there is Drupal Contrib (which Entity Reference, OG, Views, Panels all belong to) that follows the release of Drupal core. You will find that most of the power of Drupal lies with the contrib modules. Most contrib modules do not develop for the bleeding edge of Drupal (D8) because until D8 is released it is subject to change without notice.

With that in mind, D7 is exactly the place for contrib development to be because it is where stable development can occur without concern of being deprecated. We are still at least another year away before D8 is released and when it does, all of this effort done in contrib will be ported to a D8 version and new features will continue to be developed for D8 and all of it's goodness. Lastly, a large number of new Drupal core features were first developed in contrib as a proving ground and then migrated into Drupal core.

Hope this helps to clarify things a little.

Christopher James Francis Rodgers’s picture

Version: 7.x-1.x-dev » 7.x-1.0-beta5
Priority: Normal » Critical
Status: Needs work » Postponed (maintainer needs more info)

Haden IV:

Thank you for your response. I have been playing with D7 as a user
since D7a6, and the disposable site I created to test module compatibility
is the one with the EntityReference problem at

un: test
pw: test

Role: Administrator.

Check it out at your leisure.


Yes I know about the 2 version cycle of Drupal cores.

I have been waiting since July 2009 to simply create a D7 site
with instructional videos; and I refuse to go back to D6.

A simple case of frustration born of impotency.

In conclusion, I should have left my commentary out of my original post

jonathan_hunt’s picture

I have had a similar experience (using EntityReference 7.x-1.0-beta4). Soon after enabling EntityReference and adding an EntityReference field to a node and adding a sample node, I clear caches and immediately my entire site is unusable. Loading the original node gives.

Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/mysite/drupal-7.12/includes/ on line 284 and defined in /home/mysite/drupal-7.12/includes/database/ on line 1300

and trying drush status gives

Drush command terminated abnormally due to an unrecoverable error.                                                                                                          [error]
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS , revision.uid AS revision_uid
node base
INNER JOIN node_revision revis' at line 1: SELECT base.*, revision.*, revision.timestamp AS revision_timestamp, base. AS , revision.uid AS revision_uid
{node} base
INNER JOIN {node_revision} revision ON revision.vid = base.vid
WHERE  (base.nid IN  (:db_condition_placeholder_0)) ; Array
    [:db_condition_placeholder_0] => 295
 in DrupalDefaultEntityController->load() (line 196 of /home/mysite/drupal-7.12/includes/

Edit: fyi, I have modules such as Entity 7.x-1.0-rc1 and Media 7.x-1.0-rc3 installed.

Christopher James Francis Rodgers’s picture

D7 Site death with EntityReference as prime suspect

History - ControlPanel - SimpleScripts - Drupal 7.

I installed many contrib modules.
I would enable a few modules/ sub-modules at a time.
I changed various configurations settings for some.

At one point, I enabled another set of contrib modules/ sub-modules,
but upon clicking "Clear all caches" the site displayed blank white pages only.

Mozilla Firefox: view "Page source": The page source code is completely blank.

I could not remember the exact modules/ sub-modules than I had just "enable"-d,
but I went to my BlueHost CPanel file manager
and deleted the following module folders.

- og
- simple_access
- date
- entity
- commerce
- views bulk operations
- content access
- rules
- entityreference

The site came back to life.

I reinstalled each of the above, and for each one I would
- "Clear all caches" [root]/admin/config/development/performance
- Visit [root]/updates.php,
- Run cron.

When I reinstalled entityreference, however,
and clicked "Clear all caches", the site died.

I deleted the online folder entityreference again.


When I reinstall entityreference 7.x-1.0-beta5, and I go to the 'Modules' page,
I see that 'entity reference' does NOT have a check-mark in the check-box for 'Enable'.

I run cron: "Cron ran successfully."

I navigate to [root]/admin/config/development/performance
and I click "Clear all caches", and the site dies.

I deleted the online folder "entityreference" again,
and the site comes to life again.

Attempt with Entity Reference7.x-1.x-dev (2012-Feb-27): site death.


This time I will try running update.php before clicking "Clear all caches".

I visited [root]/update.php. The 'Drupal database update' page displays
"No pending updates."

I clicked the "Administration pages" link, and the site died.

Presently Installed | Enabled / Disabled Modules

Drupal core 7.12

Enabled modules
Address Field 7.x-1.0-beta2
Chaos tool suite (ctools) 7.x-1.0-rc1
Content Access 7.x-1.2-beta1
DHTML Menu 7.x-1.x-dev (2011-Nov-09)
Entity API 7.x-1.0-rc1
File entity (fieldable files) 7.x-2.0-unstable3
Media 7.x-2.0-unstable3
Media: YouTube 7.x-1.0-beta2
Module Filter 7.x-1.6
Rules 7.x-2.0
Views 7.x-3.3
Wysiwyg 7.x-2.1

Zen 7.x-3.1

Disabled modules
Admin 7.x-2.x-dev (2011-Sep-29)
Admin Tools 7.x-1.0
Administration menu 7.x-3.0-rc1
Advanced help 7.x-1.0
Apache Solr Search Integration 7.x-1.0-beta16
Backup and Migrate 7.x-2.2
Context 7.x-3.0-beta2
Custom breadcrumbs 7.x-1.0-alpha1
Date 7.x-2.2
Drupal Commerce 7.x-1.2
External Links 7.x-1.12
Features 7.x-1.0-beta6
Flag 7.x-2.0-beta6
Global Redirect 7.x-1.4
Google Analytics 7.x-1.2
Guestbook 7.x-2.x-dev (2012-Feb-18)
Heartbeat 7.x-1.0
Image Resize Filter 7.x-1.13
Insert 7.x-1.1
Libraries API 7.x-1.0
Memcache API and Integration 7.x-1.0
Meta tags 7.x-1.0-alpha4
Migrate 7.x-2.2
Mollom 7.x-2.0-beta2
Includes: Mollom
Organic groups 7.x-2.0-alpha1
Page Title 7.x-2.5
Panels 7.x-3.0
Pathauto 7.x-1.0
Quick Tabs 7.x-3.3
reCAPTCHA 7.x-1.7
Simple Access 7.x-2.0-beta1
Simplenews 7.x-1.0-beta2
Styles 7.x-2.0-alpha8
Superfish 7.x-1.8
Token 7.x-1.0-rc1
User Relationships 7.x-1.0-alpha4
Views Bulk Operations (VBO) 7.x-3.0-rc1
Views Slideshow 7.x-3.0
Webform 7.x-3.16
Workbench 7.x-1.1
XML sitemap 7.x-2.0-rc1
Zenophile 7.x-1.1

Christopher James Francis Rodgers’s picture

Another problem; another clue

Typically after deleting the entityreference folder online,
and navigating immediately to [root]/admin/reports/updates
many of the modules in the list display "No available releases found"
as seen on this page capture...

I cleared all caches four times, but that did not help.

I ran cron three times in a row, and on the third time it notified me of an available update.

I navigated to Page [root]/admin/reports/updates again,
and everything seems back to normal.

haydeniv’s picture

For those experiencing the white screen of death please see: for how to turn error reporting on and post your error here.

Damien Tournoud’s picture

Category: bug » support
Priority: Critical » Normal

The issue with beta4 has been fixed in beta5, and I don't see any clue in here that points in the same direction. Until we get more information there is nothing actionable in this issue.

Christopher James Francis Rodgers’s picture


I add to /public_html/[d7-root]/index.php...

ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE); that the total file is now...


ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

 * @file
 * The PHP page that serves all page requests on a Drupal installation.
 * The routines here dispatch control to the appropriate handler, which then
 * prints the appropriate page.
 * All Drupal code is released under the GNU General Public License.
 * See COPYRIGHT.txt and LICENSE.txt.

 * Root directory of Drupal installation.
define('DRUPAL_ROOT', getcwd());

require_once DRUPAL_ROOT . '/includes/';

Switch from Zen sub-theme to Bartik...and the Admin theme is "Default"

Just to see whether my choice of Zen as theme was the issue... (though it turned out Not to resolve the problem...)

Install entityreference

I install entityreference 7.x-1.0-beta5 using page [d7-root]/admin/reports/updates/install

After installation, I choose link "Enable newly added modules".

I note that entityreference does Not have a 'Enabled' check-mark.

I also visit pages: <front>, Appearance, admin/reports/status, etc. without any problem.

I go to [d7-root]/admin/config/development/performance and click "Clear all caches".

I get a WSOD as expected; but now displaying the error...

Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /home1/greatgr2/public_html/test/sites/all/modules/entityreference/entityreference.install on line 44

The new error was reported in /public_html/[d7-root]/error_log as

[09-Mar-2012 20:18:21] PHP Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /home1/greatgr2/public_html/test/sites/all/modules/entityreference/entityreference.install on line 44

I delete online folder entityreference, and refresh the WSOD page; and the site lives again.


Inform me as to any other report/ log file you would like to see and I will do my best to provide it.

Feel free to logon the my site using "test" as the username and as the password. User 'test' has role 'Administrator'.

Or if you desire any additional information that I can provide as user-1, or as webhost-account admin, let me know.

Otherwise, simply recommend to me any course of action that will reveal to you the cause of this 'replicable error'.

anavarre’s picture

Version: 7.x-1.0-beta5 » 7.x-1.0-rc1
[09-Mar-2012 20:18:21] PHP Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /home1/greatgr2/public_html/test/sites/all/modules/entityreference/entityreference.install on line 44

I delete online folder entityreference, and refresh the WSOD page; and the site lives again.

I can confirm that as well with RC1 but I also had to run first to get the site back.

choster’s picture

I am encountering the same error:

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

In my case, I am trying to sync my staging server database with my local development environment. The module is installed on the staging server; it installed without any issues and seems to be working fine, with an entity reference field pointing to a certain content type added to two other content types.

I clear caches, mysqldump and bzip2 the db, copy it to my local environment, then import the db. Usually, I then run drush cc all, but this fails with the above error. Attempting to browse any page on the site also generates this error, even after I manually truncate the cache tables and run cron. The sole exception is update.php, which fails with a 500 error.

I confess, I have no idea why entityreference.install should be loading in the first place, since the module is already installed and functioning on the staging server and is present in identical form on the local server (location relative to Drupal as well as version, 7.x-1.x-dev). There are no custom widgets or templates in use.

anavarre’s picture

Status: Postponed (maintainer needs more info) » Active

Putting back as active as it seems to me with several other people reporting the issue there might be something actionable here.

jamesharv’s picture

Category: support » bug

I too am seeing:
Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /sites/all/modules/contrib/entityreference/entityreference.install on line 44

For me, according to a debug_backtrace() it was being triggered by a call to features_rebuild() which was rebuilding content type from a feature which included an entityreference field.

It only seems to happen once, when I notice it (usually during a drush cc all, but also during a drush cron), and then it does not reoccur for a while.

It strikes me that the simple solution is to ensure that the entityreference.module file is included in the entityreference.install file before the call to entityreference_get_behavior_handlers() using a call to module_load_include('module', 'entityreference'). This ultimately does a require_once on the entityreference.module file so it shouldn't cause any problems, and it does resolve my issue.

I will submit a patch that does this shortly.

jamesharv’s picture

Status: Active » Needs review
481 bytes
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es). View

Patch related to previous comment attached.

Status: Needs review » Needs work

The last submitted patch, explicity_include_module.1459540.patch, failed testing.

John Lawter’s picture

Version: 7.x-1.x-dev » 7.x-1.0-rc1
Status: Needs review » Needs work

I am also having this issue. If I add the entity reference module, leave it disabled, and run cron, OR if I don't run cron and enable the entity reference module instead, I get the error:

Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /home1/greatgr2/public_html/test/sites/all/modules/entityreference/entityreference.install on line 44

I tried applying the patch in comment #13 (yes, I know it didn't pass, but curiosity got the better of me), it gets past that error, but then I get a Connection Rest error, killing the site.

I should add this I was having this problem using entityreference 7.x-1.0-rc1 after upgrading from entity-7.x-1.0-rc1 to entity-7.x-1.0-rc2. I completely removed/uninstalled both Entity (Entity API) and Entity Reference, then reinstalled entity-7.x-1.0-rc1 and entityreference 7.x-1.0-rc1 and I waxs then able to enable both modules without error or connection resets.

Dave Reid’s picture

Version: 7.x-1.0-rc1 » 7.x-1.x-dev
Dave Reid’s picture

Status: Needs work » Needs review
murrayw’s picture

Version: 7.x-1.0-rc1 » 7.x-1.x-dev
Status: Needs work » Needs review

I was having the issues described in this post when running drush make rebuilds as well as enabling and disabling modules. #13 has fixed the issue for me.

Damien Tournoud’s picture

Status: Needs review » Needs work

I'm not ready to accept this patch, not without half a ton of comment explaining why this is necessary, and a link to an open issue in core describing how the Field API can possibly call field-level hooks on disabled modules.

andrewperry’s picture

Version: 7.x-1.0-beta5 » 7.x-1.x-dev
Priority: Critical » Normal
Status: Postponed (maintainer needs more info) » Needs work

I had the same error message after disabling a feature using entityreference and the above one line patch fixed it.

mrfelton’s picture

Also got hit by this after disabling a feature and all 'orphaned' modules. Patch in #13 is a workaround.

Damien Tournoud’s picture

Project: Entity reference » Features

I'm guessing it's a Features bug. Maybe Features doesn't comply with dependencies when allowing you to disable a feature?

Damien Tournoud’s picture

Component: Code » User interface

Also guessing it's likely a UI bug.

Damien Tournoud’s picture

Title: Drupal 7 - EntityReference module crashes site using either 7.x-1.0-beta5, or 7.x-1.x-dev (2012-Feb-27). » People seems to be able to disable a Field module which still has fields, and core seems to call field hooks on disabled modules

Trying to make the actual issue clearer.

hefox’s picture

lotta comments up there, scanned them but may have missed some; can anyone clarify the exact steps reproducing the problem? Or at least indicate what "field module" and "field hooks" mean in this context XD

Some questions
* Features cannot guess all needed dependency for a given feature so may be missing some dependency that feature depends on; is entity reference dependency being added as a dependency to the feature that rebuild is being called for? (This isn't a bug, it's just not possible to always figure out dependencies).
* There's some bugs with disabled node type with how features is using hook_node_info so that node types aren't appearing as disabled when feature defining it is removed; is this effecting it?
* Is this a core bug with how core is handling disabled fields, or a features bug for features trying to do stuff with a field that should be disabled?

Btw, part of features rebuild is enabling any new dependencies, so that may be related.

somatics’s picture

I don't think this is a Features bug. I don't have Features installed.

However, like #4, I have Entity References installed, and I am getting a flood of the following errors, and it's grinding my site to a halt:

Line 44 
Call to undefined function entityreference_get_behavior_handlers()

I do have the same modules enabled that he does, other than DHTML Menu 7.x-1.x-dev, but there were no such errors at all until just last week I installed Entity References.

murrayw’s picture

I was getting the problem and the patch fixed it for me. However, I believe that I "may" have found a possible cause for my situation. For me, the problem was appearing when running a script to rebuild a site via a make file. During the process I deleted the contents of /contrib and then "drush cc all; drush make ...". This was, in hindsight, a very silly thing to do! I shouldn't be clearing the caches after the deletion. I removed the cache clear and I don't get the error. I can now rebuild without using the patch. This worked for rc1 and rc3.

Does this ring any bells for anyone? I see a number of the descriptions above are concerned with clearing caches and deleted/missing folders. This could be the combination which causes the issue. All I can suggest is that you make sure the entityreference project is on disk before you clear caches.

BTW. I'm a bit freaked out that the patch manages to do anything at all given this suggestion. Maybe the code has been cached or something???

Christopher James Francis Rodgers’s picture

I am happy to have initiated such a lively discussion of my original issue,
and as a note aside I would like to say that
I find it interesting that no-one had simply noted to me that
as I recently figured out...

Entity Reference is not in fact required for OG.

I had known OG requires "Entity", but since there is no "Entity" module,
I will now continue on my way under the assumption
that "Entity API" is what I need.

I hope I am not wrong again.

Oh well. You know how Drupal is for non-developers.

A bloody ongoing nightmare.

..or that must just be for me
since D. Buytaert mandated User-friendliness as priority one years ago,
it must just be my Alzheimers.

I think I'll reinvent the space shuttle as a relaxing hobby
in between my fits of frustration with Drupal.

Peace out.

- Chris

Christopher James Francis Rodgers’s picture


As I am totally free,
free to choose,
I choose instead of crying out,
I choose to laugh.

And Drupal had me in stitches;
often if not always.

mgifford’s picture

Patch #13 worked well for me.

hefox’s picture

Sounds like this is not a features issue from some of the comments; can someone put it into whichever module it is?

jrsinclair’s picture

Status: Needs work » Reviewed & tested by the community

Patch #13 worked well for me also. Many thanks to @jamesharv. Changing issue status as this seems to be working for several people.

hefox’s picture

Project: Features » Entity reference
Damien Tournoud’s picture

Status: Reviewed & tested by the community » Closed (won't fix)

If nobody wants to find the source of this bug, I'm marking this as won't fix. As already stated multiple times, this is *not* an Entity Reference issue. The patch in #13 just hides the bug under the carpet.

nedjo’s picture

To begin to debug, we'd need a backtrace or equivalent from an instance of the error message. Anyone able to provide this?

A simple way to get a backtrace:

Install and enable Devel module.
Edit entityreference.install, inserting the following within the function entityreference_field_schema():

  $backtrace = debug_backtrace();

Copy the result into a text file and attach it to this issue.

quicksketch’s picture

Status: Closed (won't fix) » Needs review

If nobody wants to find the source of this bug, I'm marking this as won't fix. As already stated multiple times, this is *not* an Entity Reference issue. The patch in #13 just hides the bug under the carpet.

I would say this is definitely a bug in Entity Reference, but it's convoluted to reproduce. In order to have this problem you have to have an Entity Reference field *already on your site* before the Entity Reference module is enabled. This situation is hard to get into because Field module doesn't let you disable Entity Reference while you have any entity reference data on your site. However as other people have pointed out, if you've exported a content type or field of the "entityreference" type, this problem comes up fairly easily because the field is created by Features, despite Entity Reference being disabled.

Looking at a stack trace, here's what seems to happen.

- On cache clears (or when installing modules), the schema cache is cleared.
- When Field SQL Storage module generates its schema in field_sql_storage_schema(), it calls hook_schema() directly in all field modules (including disabled ones).
- If Entity Reference module is disabled but there is a field of type "entityreference" on the site, Entity Reference attempts to call entityreference_get_behavior_handlers(), but the function isn't found because entityreference.module isn't included.

I would say this problem is similar to why you should always manually include the .module file in update hooks, because the update hooks get run whether or not the module is enabled. This is a similar problem, where Field module is calling the hook_schema() implementation of Entity Reference whether or not the module is enabled. Field module goes to some lengths to prevent the situation from happening, but when working with Features (or modules that create entityreference fields programmatically such as OG or Node Gallery), this situation can and does occur.

Anyway, all to say, +1 for #13. I don't think it's a hack, this kind of include is extremely common in hook_update_N(). Really it would be preferable if Entity Reference didn't use any API functions from the .module at all so the hook_schema was more robust, but from the maintenance point of view reusing the function in the .module file makes sense to me.

Here's a stack trace from drush en entityreference:

Fatal error: Call to undefined function entityreference_get_behavior_handlers() in docroot/sites/all/modules/contrib/entityreference/entityreference.install on line 44

Call Stack:
    0.0005     701144   1. {main}() drush/drush.php:0
    0.0193    4797712   2. drush_main() drush/drush.php:14
    0.0847   11125848   3. _drush_bootstrap_and_dispatch() drush/drush.php:59
    0.2862   39578824   4. drush_dispatch() drush/drush.php:90
    0.3198   39595544   5. call_user_func_array() drush/includes/
    0.3198   39595880   6. drush_command() drush/includes/
    0.3227   39814416   7. _drush_invoke_hooks() drush/includes/
    0.9231   45366976   8. call_user_func_array() drush/includes/
    0.9231   45367312   9. drush_pm_enable() drush/includes/
    0.9236   45367992  10. drush_module_enable() drush/commands/pm/
    0.9236   45367992  11. module_enable() drush/commands/core/drupal/
    1.3436   48289936  12. drupal_get_schema() docroot/includes/
    1.3436   48289936  13. drupal_get_complete_schema() docroot/includes/
    1.3683   51031944  14. module_invoke() docroot/includes/
    1.3683   51032304  15. call_user_func_array() docroot/includes/
    1.3683   51032552  16. field_sql_storage_schema() docroot/includes/
    1.3686   51033504  17. field_read_fields() docroot/modules/field/modules/field_sql_storage/field_sql_storage.install:16
    1.3850   52230040  18. module_invoke() docroot/modules/field/
    1.3850   52232152  19. call_user_func_array() docroot/includes/
    1.3850   52232488  20. entityreference_field_schema() docroot/includes/
quicksketch’s picture

I take back my suggestion in #37. I'm not sure the patch in #13 is going to solve the problem for anyone (it didn't for me) because I just get an undefined class error instead. So the problem is real as I said above, but I'm not sure #13 would do much to help it.

zhangtaihao’s picture

This could also happen if the bootstrap cache is not up-to-date, i.e. entityreference.module is not actually loaded when the field schema is being built, even if the system table says it is.

Matthew Davidson’s picture

841 bytes
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es). View

Another way to reproduce this behaviour, as I discovered this morning, is to delete the entityreference module and bootstrap Drupal before restoring it. The system disables the module, and Field module is in no position to do anything about it.

I would say this is a fairly likely scenario, and expecting the average site builder to know that the solution is to manually flip the appropriate 0 to a 1 in the system table and truncate a couple of cache tables is probably asking too much.

Can anybody more knowledgeable than myself predict what horrible side-effects the attached patch might have? It's still more a workaround than a real solution (which I think may lie with core), but from my position of great ignorance I can't see it leading to ill effects that outlast the next cache_clear_all().

ghalenir’s picture

diwant’s picture

I got this error, here's how I got it (I think):

Features said I had orphaned dependencies, do I want to disable? I said sure, and that gave me the fatal error about the behavior handler. Debugging showed it was coming from the field module still running it's stuff on a field I had that was supplied by entity reference (which was disabled in the orphaned dependencies step?).

So yea, looks like it's Fields. How do we tag it as such?

askibinski’s picture

I also got this error in the same scenario as #42 described.

Damien Tournoud’s picture

So, we do have two issues:

(1) The field module can call field hooks on disabled modules. We do have an architecture in place to disable fields when their module disappears, but it doesn't seem to work in all cases, a runtime check is probably required; We need a core issue opened for that.
(2) The issue described by Nate in #37, which is specific to Entity Reference. In that particular case, the module is actually enabled, but not yet fully loaded.

Damien Tournoud’s picture

Status: Needs review » Active

Active because we don't have any patch fixing the actual issue here. #40 is a workaround for the core bug.

signalScott’s picture

I also get this error after installing the dev versions of both Entity API and Entity Reference.

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

I tried applying the patch in #40 but I still get the same error on line 44. It seems the patch isn't taking, probably because of caching. However, this error seems to prevent me from clearing the cache.

Both Entity API and Entity Reference were installed and enabled before I attempted the upgrade to the dev versions. I tried reverting back to the original versions (Entity API 7.x-1.0-rc3, Entity Reference 7.x-1.0) but I'm still stuck with this error. Any ideas?

mvc’s picture

Status: Active » Needs review
866 bytes
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es). View

@damien tournoud: yes, there's a drupal core problem in here somewhere, but in light of the large number of people running into this problem (as shown by the comments here and on duplicate issues) i respectfully submit that it's reasonable for this module to add a quick sanity check to avoid a fatal error that would be very difficult for a drupal beginner to work around themselves. here's a patch that simply calls function_exists().

dagomar’s picture

That patch works for me. I don't have time to look into the issue, but I thought I'd let u know.

zhangtaihao’s picture

Just an idea: what about logging a warning/error line to watchdog if the function doesn't exist, given that is anomalous behavior?

-Mania-’s picture

The #47 patch works for me as well, thanks! A really nasty bug this one as it halts the whole website and can't access any of the pages.

The Slave&#039;s Dream’s picture

Um, I'm getting this and I'm a complete newbie - only finally got my site up and running pretty much after 3 days solid. The idea of a patch seems pretty horrendous to me (although it is 2am...) Do you think it would be easier for me to just re-install everything? I haven't put anything on my site yet :(

-Mania-’s picture

@The Slave's Dream: Re-installing will likely not help you with this bug. You can also apply the patch manually, it's just a couple of lines of code you need to change.

acb’s picture

I can confirm this is still a bug... and the (very welcome) workaround in #47 has unintended consequences.

The patch above causes broken/missing handlers in views; (in my case when a profile2 profile-entity is referencing a node entity).

So far ignoring the broken handler doesn't break anything. HOWEVER it does prohibit you from adding those fields with broken handlers to a view.

Here's to hoping for a fix soonish!

Valera Tumash’s picture

The patch in #47 has helped for me as well

rpsu’s picture

Status: Needs review » Reviewed & tested by the community

Patch #47 solved the issue. Moving status to RTBC.

Damien Tournoud’s picture

Status: Reviewed & tested by the community » Needs work

Given how widespread this is, I'm ready to accept a run-time check here. But we should simply check if the entity reference module is enabled, and do that at the very top of entityreference_field_schema() and just returns if it is not. We also need a core bug opened for the core issue (the Field module calling hooks on disabled modules...), and referenced in the patch.

pandaeskimo’s picture

We tested #1459540-47: People seems to be able to disable a Field module which still has fields, and core seems to call field hooks on disabled modules and it seems to solve our issue as well.

Our issue was clearing the cache on several environments would cause a failure and we couldn't access the site. For those sites, removing entityreference (deleting the folder), clearing the cache, and re-adding the files seemed to fix it as well. For some odd reason, this only happened on some of our dev sites, not our production site.


mvc’s picture

679 bytes
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es). View

@Damien Tournoud: I'm actually not convinced that the problem is related to calling hooks on disabled modules. Several of the problem reports mention upgrading from a stable version of this module to a dev version and it's possible that entityreference_field_schema() is being called when the function entityreference_get_behavior_handlers() isn't available for some reason, for example while update.php is being run and Drupal isn't fully bootstrapped.

I'm not currently able to reproduce this bug so I'm not able to debug this much further, but I'm attaching a patch which attempts to work around the problem as you suggested by checking if the module's enabled in case it helps someone. Once we figure out which of these two things is going on, a core issue can be opened. I dug around in the issue queue but can't find anything that seems relevant and which hasn't already been fixed.

If anyone currently having this problem can try this approach instead of my patch in #47, that would be great.

mvc’s picture

Status: Needs work » Needs review
wunderman4’s picture

Assigned: Unassigned » wunderman4

Hello Everyone,

I would like to start with I am complete noob, I know just enough to get myself in trouble and I have had an amazing time doing just that :)

So I have ran into this exact issue with the website reading:

"Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /home/content/10/10308310/html/profiles/commerce_kickstart/modules/contrib/entityreference/entityreference.install on line 44"

After looking around on here for a little while I realized I have no idea how to patch and I do not have any business trying to unless this issue gets really bad. In the meantime I believe that I may have found a solution... Well... Idk if it really is...

What I did was follow the above path, but instead of deleting the entire "entityreference" folder I only deleted "entiyreference.install"

This brought the site back to life, I then proceeded to go into the modules and turn entity reference back on.

Now the site is running, the module is on and seems to be functioning (but again I dont know how to actually test it)

I am not sure if running "cashe clearing ram humblog" stuff will break it again.

With a little direction I will be glad to try out other things also.

P.S. I got myself into this mess by clicking Admin> structure>Features>??? I ended up on a page that wanted to know if I wanted to turn off a bunch of stuff at once to optimize I clicked all and saved...

Hope this helps,

alanzanotto’s picture

Had the problem of my site breaking. "Fatal error: Call to undefined function entityreference_get_behavior_handlers() in ...entityreference/entityreference.install on line 44"

This solution worked for me.....



MANUAL FIX (Thank you balaclark)

How to manually fix this problem for an already-installed module
Posted by balaclark on August 23, 2012 at 10:20am
Go to your database and open the "field_config" table.
Replace all entries that have the field types you want to remove to have type "text" and module "text"
Now you can uninstall your module, the custom field tables will be automatically removed.
As you uninstall your module you will probably see some some error messages thrown by the text module, you can safely ignore these.


I just wanted to be able to upgrade my site from 7.18 to 7.22 Not uninstall the module.
My steps were as follows.

1. Disable all modules that I could to try and disable Entity Reference.

2. I was left with one that says "Required by: Drupal (Field type(s) in use - see Field list)".

3. So based on balaclark comment I went to my database "field_config" table and found all of the entries that had "entityreference" as their "type" and "module" column....I changed both of them to say "text".

4. Upgraded my site (Im on godaddy, so I used their upgrading wizard).

5. Re enabled Entity Reference Modules (And supporting modules).

6. Went back into my database and changed the entries in step 3 from "text" back to "entityreference".

7. Re enabled all my other modules.

This solution got my site upgraded to 7.22 and I'll probably have to do the same steps for future upgrades.

I hope this helps somebody else with the same issue.

j0rd’s picture

Same problem as this, which I believe is a duplicate of this issue
#1919472: Error: Call to undefined function entityreference_get_behavior_handlers() in entityreference.install, line 44

Applied the patch in the issue above to resolve the issue.

For me, this happened by mistakenly moving entityreference module from contrib instead of entityreference_prepopulate, then running some drush commands, which most likely caused entityreference to get disabled in system's table. Moving the folder back, caused the problem described in #1919472 and is fixed by including the appropriate file with the require.

With that said, checking to see if the module is enabled, which most likely also work.

mvc’s picture

@j0rd: when moving modules around, try running afterwards to make sure drupal knows where to find the files.

Soundvessel’s picture

Had the same issue after a git pull and db restore to a local environment. I tried wunderman4's method of deleting the .install file but is just replaced it with another error.

My solution was to run, copy htaccess (since a lot of people gitnone it) and under /admin/config/media/file-system make sure the private the tmp directory paths were setup correctly. Finally a cache dump and I was back in business! :)

Soundvessel’s picture

So I had to home the same site again to a second local environment (laptop vs desktop) but with the same XAMPP/Git setup etc. This time copying the htaccess file first I had no errors or issues. Might it be just that these people are missing the proper htaccess settings so Drupal can find the modules etc again?

MO’s picture

I was getting:

"Fatal error: Call to undefined function entityreference_get_behavior_handlers() in on line 44"

Patches in #58 and #47 both worked for me. I also ran Registry Rebuild, which failed/showed the error prior to patching and succeded after patching (both patches same behavior).

I'm going with #47 workaround for now.


manuelBS’s picture

Thanks for this patch, works great for me!

jsidigital’s picture

Tried to apply Patches #58 and #47 but they give me errors.
Apparently they are coded for PHP 5.3+ and i am running PHP 5.2.17

Can anyone tell me what the code would be for PHP 5.2.17 ?

Problem is the backslash towards the end of the code. What will happen if i simply do not add that part? And if it needs it, what would be the PHP 5.2.17 version of that to not get an error?

Can someone please help here? Need to apply this patch to get my site back live but i dont have PHP 5.3

Also, do you run registry rebuild after you enable the entityreference module? Or do you simply add the module folder via ftp, not enable it and run registry rebuild?


tfmedia’s picture

Issue summary: View changes

#58 and #47 worked for me.

@jsidigital - did you apply the patches to the dev version?

alberto56’s picture

Related issue: #1836106: Fatal error: Call to undefined function entityreference_get_behavior_handlers() in entityreference_schema(), a patch proposed there loads the module file before calling entityreference_get_behavior_handlers() in the install file.

banoodle’s picture

#13 worked for me - thank you thank you thank you!!!!