When both private message and message are enabled and a message (block) views created and assigned to user/* errors are thrown on visiting user/*....

Warning: array_flip() [function.array-flip.html]: Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 178 of /var/www/dev/recruiter/includes/entity.inc).
Recoverable fatal error: Object of class Message could not be converted to string in DatabaseStatementBase->execute() (line 2108 of /var/www/dev/recruiter/includes/database/database.inc).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ronald_istos’s picture

Came across this error myself. The problem pops up when you have the two modules activated because of a namespace collision that makes Drupal think that Private Message's entity load function is a hook to call when Message loads an entity as well :-)

Private message has an entity load function as

privatemsg_message_load

while Message has message_load.

This namespace affinity makes privatemsg_message_load fire whenever a Message entity loads with ensuing hilarity.

Now the problem is really Private Message's - one should avoid function names that can cause this problems. A larger issue is whether Drupal core should check these things - or maybe Coder.

Will post in Private Message with a short term patch - long term solution is to change the function name.

jbrown’s picture

Issue tags: +namespaces

tagging

davidcsonka’s picture

Did you ever post in the PrivateMsg issues queue? Can you list the issue link here so I can check on it?

berdyshev’s picture

Title: Private messages and messages not working well togather » Private messages and messages not working well together
Project: Message » Privatemsg
Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Active » Needs review
FileSize
3.06 KB

I have debbuged this problem and find the place where it fails.
Handler for views (message_handler_field_message_render) calls message_load() function in includes/views/message_handler_field_message_render.inc:75. This will call the attachLoad() method of the DrupalDefaultEntityController class. In this method there is such code (includes/entity.inc:332):

foreach (module_implements($this->entityInfo['load hook']) as $module) {
  call_user_func_array($module . '_' . $this->entityInfo['load hook'], $args);
}

where $this->entityInfo['load hook'] is equal to message_load. So, the privatemsg_message_load() function will be called.

As solution, privatemsg_message_load() function should be renamed to something like privatemsg_msg_load(). But this will cause changes in privatemsg's API and I don't sure if this is possible.
But I have attached patch which is applying this renaming to privatemsg module.

Status: Needs review » Needs work
berdyshev’s picture

Version: 7.x-2.x-dev » 7.x-1.2
Status: Needs work » Needs review
berdyshev’s picture

berdyshev’s picture

and here it's the patch for the latest dev version of the 2.x branch

berdyshev’s picture

Version: 7.x-1.2 » 7.x-2.x-dev

changed version

Status: Needs review » Needs work
berdyshev’s picture

renaming applied to the test files.

Status: Needs review » Needs work
Berdir’s picture

Status: Needs work » Needs review

This doesn't make sense. I see the problem, but things aren't abbreviated like that in Drupal and there is much more that is called privatemsg_message, like all of our hooks, the privatemsg_message entity and more.

There is a much simpler solution for this problem. Add a check to that function that looks if the argument is an object and if so, do nothing.

berdyshev’s picture

Oh, sorry, I was trying to fix this issue globally and missed this simple solution.

Patch attached.

Berdir’s picture

Status: Needs review » Needs work
+++ b/privatemsg.moduleundefined
@@ -1970,6 +1970,10 @@ function privatemsg_get_link($recipients, $account = array(), $subject = NULL) {
+  // if $pmid is object or array - do nothing (fixing conflict with message_load() function in message module)
+  if(is_array($pmid) || is_object($pmid)) {
+    return NULL;

Yeah, that's much more sane :)

Let's format that comment according to the guidelines (first character upper case, no longer than 80 characters, end with a "." and I'm happy to commit this change.

See http://drupal.org/node/1354#inline

berdyshev’s picture

Status: Needs work » Needs review
FileSize
587 bytes

Thanks for review. revised patch attached.

omar’s picture

Michsk’s picture

This does not fix it. The following error keeps appearing http://drupal.org/node/1659228

Michsk’s picture

Don't we also need something for privatemsg_message_load_multiple(). Since the Message module also uses message_load_multiple(array_keys($check_mids);.

Berdir’s picture

Status: Needs review » Fixed

No, there is no such hook. Commited the patch, fix looks valid to me. If you still experience this issue, please reopen with a detailed error report (backtrace).

Status: Fixed » Closed (fixed)

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

ajmartin’s picture

Will this patch be committed to version 7.x-1.3, or is the 2.x-dev stable enough for a production site?

Berdir’s picture

It has been commited to 7.x-1.x-dev. Fixed releases are never updated.

ajmartin’s picture

Great. Thanks for clarifying. I assume it will be part of 7.x-1.4 when that's released.

snehi’s picture

#16 works for me
Thanks for the patch :)

Anonymous’s picture

Thank you for this patch. #16 worked for me, too!

maximpodorov’s picture

@Berdir
Please make a new stable release (7.x-1.4) with this fix. We need it badly. :)

kalistos’s picture

Yes, please, make new stable release for 7.x-1.x.

A lot of people are faced with this problem #1851478-13: Object of class Message could not be converted to string in DatabaseStatementBase (Private Message integration)

Connoropolous’s picture

Thanks so much for this. #16 worked like a charm.

Anonymous’s picture

Issue summary: View changes

We ran into this problem as well with commerce sp paypal module since it relies on the message module. in the process of testing with 7.x-1.4 version of private message.

And to clarify: the problem is caused by private message inadvertently implementing the core hook_TYPE_load (see entity.inc around line 350). core entity supports 2 hooks:
- hook_entity_load
- hook_TYPE_load
and unfortunately the message module defines an entity of type "message"
Seems best practise is to never use _load as the end of a function name.