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

TwoD’s picture

I'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.