1

In the Recent log messages I get this message repeated many times:

Warning: array_flip(): Can only flip STRING and INTEGER values! i DrupalDefaultEntityController->cacheGet() (rad 388 av C:\wamp\www\includes\entity.inc).

I assume that the problem lies within one of the modules I have installed, but after spending the whole day trying to narrow down which module is causing the problem, without luck, I post this question. I have read other answers that relates to the same log message, but they did not help me.

Anyone that can explain how to get more info out of that warning?

3
  • 1
    There's only one way, really: debugging. Ideally use an IDE and XDebug, you'll be able to see the full backtrace that way. Otherwise just add print; die; statements throughout the code until you narrow it down
    – Clive
    Commented Jan 4, 2018 at 13:50
  • If it helps any for me this error is usually due to doing an entity_load() and not passing the ID as an array
    – Leigh
    Commented Jan 4, 2018 at 15:07
  • Clive, I haven't used Xdebug but I will try to get it to work in my environment (WAMP and Atom). My problem is that the warning can originate from any of about 30 modules, so I need to pin down the faulty module before I can print and die.
    – TBJ
    Commented Jan 4, 2018 at 15:59

4 Answers 4

1

Best way is probably to use a debugguer like xdebug and watch the callstack in your IDE before your warning.

If you cannot, use debug_print_backtrace() or debug_backtrace(), locate your warning and you will see all the calls before it happens.

Here is an exemple you have to adapt (or not) : set_error_handler()

5
  • OK, I will follow your advice on Xdebug (struggling to get it to work with Atom and WAMP though). Thanks.
    – TBJ
    Commented Jan 4, 2018 at 15:53
  • 1
    Use PHPStorm, 0 config.
    – Kevin
    Commented Jan 4, 2018 at 17:21
  • Oulalahakabu; I finally succeded in using Xdebug with Atom and with the help of the answer from erier (to use drush watchdog-show --tail) I could pin down this warning to belong to the Field Collection module. Upvote and right answer. Now I only have to figure out what is wrong in Field Collection....
    – TBJ
    Commented Jan 5, 2018 at 10:44
  • Have you found the callstack in your IDE ? Commented Jan 5, 2018 at 10:58
  • Yes, I did. It's awesome.
    – TBJ
    Commented Jan 8, 2018 at 7:44
1

We always prefer to use drush and view the watchdog from the command line using:

drush watchdog-show --tail

watchdog-show gives the latest log messages.

--tail gives you a 'live look' at any log messages.

3
  • Wow, thanks that worked immediately and was very handy. Thanks a lot! That visualizes quite well on which page the warning is generated.
    – TBJ
    Commented Jan 5, 2018 at 7:06
  • Again... with your tip on using drush in combination with the answer from Oulalahakabu I could pin down the module. It is the Field Collection module that causes this warning. Thanks again and upvote.
    – TBJ
    Commented Jan 5, 2018 at 10:46
  • Awesome, glad it helped, @TBJ!
    – erier
    Commented Jan 5, 2018 at 19:19
0

I haven't used Xdebug but I will try to get it to work in my environment (WAMP and Atom). My problem is that the warning can originate from any of about 30 modules, so I need to pin down the faulty module before I can print and die

Another approach is like so:

  1. Disable ALL 30 modules
  2. Re-enable each of those 30 modules, 1 at a time.
  3. Try to recreate the issue each time you re-enabled 1 of those modules.
  4. At some point the issue will come back ... the last module you re-enabled is the module you were looking for ...
  5. To ensure there are no other (extra) modules that cause the issue, temporary disable that module again, and continue with the remaining modules. When you're done, re-enable the module discovered in step 4.
5
  • Yes, you are right. But I thought of this solution as a last resort. I will try to get Xdebug to work with Atom first, since it can come in handy som other time as well. Thanks for your answer all the same.
    – TBJ
    Commented Jan 5, 2018 at 7:08
  • @TBJ any other updates? Did you get it sorted out? Commented Feb 8, 2018 at 13:20
  • Pierre Vriens: No, I am up to my neck in work, so meanwhile I just keep an eye on the log messages. I did succeed in integrating Xdebug with Atom though, and I am pretty sure it's the Field Collection module that is the cause of the messages. I will post an issue with them... thakns for cheking in!
    – TBJ
    Commented Feb 9, 2018 at 14:37
  • @TBJ merci for the feedback. If you ever find the time, maybe try to replace that field collection entirely with the paragraphs module (if you succeed, the msg might disappear also ...). PS: "integrating xdebug with Atom", sounds interesting (any links to suggest to get started with that?). Commented Feb 9, 2018 at 14:48
  • Pierre Vriens: I posted a question on StackOverflow and ended up answering my own question. If you use WAMP it could help to get the settings right. Begin by downloading the php-debug package for Atom. here is the link for the question: stackoverflow.com/questions/48109871/…
    – TBJ
    Commented Feb 9, 2018 at 15:47
0

Latest patch for adding backtrace to errors in core: https://www.drupal.org/project/drupal/issues/1158322#comment-12405373

This is a must for any Drupal install; very handy.

2
  • I made a dry run of the patch and got lots of fail messages. Also it sounds a bit scary to patch the core. But thanks anyway. I can see that it sould have been useful.
    – TBJ
    Commented Jan 5, 2018 at 10:16
  • @TBJ ‘patch -p1 ...’ or ‘patch -p0 ...’ is what to try if a lot of warnings get thrown; did you go against 7.56? Be sure to search the issue queue in field collections for your exact issue and comment or create a new issue.
    – mikeytown2
    Commented Jan 5, 2018 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.