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_profile
entities yet.