The function named wysiwyg_profile_load coincides with the pattern that's used to generate entity load hooks within DrupalDefaultEntityController:attachLoad().
Let's assume for a moment that some module of mine declares an entity named profile whose load hook property happens to follow the general pattern of ENTITY_TYPE_load:
$entityInfo['load hook'] = 'profile_load';
This and the way load hooks are being determined in DrupalDefaultEntityController:attachLoad() would then accidentally call wysiwyg_profile_load.
// Call hook_TYPE_load(). The first argument for hook_TYPE_load() are
// always the queried entities, followed by additional arguments set in
// $this->hookLoadArguments.
$args = array_merge(array($queried_entities), $this->hookLoadArguments);
foreach (module_implements($this->entityInfo['load hook']) as $module) {
call_user_func_array($module . '_' . $this->entityInfo['load hook'], $args);
}
Renaming the function to e.g. wysiwyg_load_profile or wysiwyg_text_format_profile_load would fix this issue.
Comments
Comment #1
twodI'm not sure how to safetly change this since that is our autoloader function for the profile editing forms. Changing the menu paths in wysiwyg_menu and forcing a menu rebuild in an update hook should take care of it, but I haven't had time to test it.
We can't use the first name suggestion since it doesn't end in _load, but I suppose something like the second one should work.
Haven't checked how this relates to our
wysiwyg_profileentities yet.