0

How one can deal with warnings in Drupal? If the code is getting executed smoothly, then what's the purpose of these warnings? Is there any way to deal with drupal "warnings", "notices".

one example here is: I have written hook_uninstall

function hook_uninstall(){
   if (field_info_field('hide_field')) {
        field_cache_clear();
        field_delete_instance('hide_field');
        field_delete_field('hide_field');
    }
}

and this code is throwing warning:

Warning: Illegal string offset 'field_name' in field_delete_instance() (line 772 of modules/field/field.crud.inc).

Warning: Illegal string offset 'entity_type' in field_delete_instance() (line 773 of modules/field/field.crud.inc).

Warning: Illegal string offset 'bundle' in field_delete_instance() (line 774 of /modules/field/field.crud.inc).

Warning: Illegal string offset 'field_name' in field_delete_instance() (line 781 of modules/field/field.crud.inc).

Warning: Illegal string offset 'field_name' in image_field_delete_instance() (line 480 of /modules/image/image.module).

and there is no halt in the execution of the code. I'm very much curious about how drupal deals with exceptions, warnings, notices.

What does these warnings mean?

And can we contribute our module to drupal community if warnings or notices exits in module?

Can anyone share their piece of knowledge here?

1

The purpose of warnings are to warn you that something is wrong with the code you've executed. They are provided by PHP, not by Drupal (though Drupal can trigger them if required). Notices are similar, but considered less urgent. Warning/notices are not fatal, so don't halt the scripts' execution.

The way to "deal with" them is to simply fix the code, which might mean fixing your code, reporting a bug to a core/contrib issue queue, digging through a request to make sure that the value of variables being passed around are what they're expected/required to be, or something else.

Some people might tell you just to disable warnings/notices so that they're not bothering you visually, but as in all walks of life, hiding a problem instead of fixing it is a bad idea.

There isn't a catch-all answer to fixing every possible type of warning. You need to debug the site, find out exactly what and where the problem is, and apply your skills as a developer to fix them.

I don't know what the policy is for contributing modules that containing warnings/notices. I would hope that they are, at least in an initial review, rejected if they cause such things, but that might not be a practical expectation.

Regarding how Drupal deals with them: the answer is that it doesn't, really. You can switch on and off the display of error messages through the admin UI, but Drupal can't, and doesn't, have any interest in fixing these errors, or helping you any further to narrow down what's causing them. It's just a PHP app at the end of the day.

Incidentally, Drupal does implement its own PHP error handler (_drupal_error_handler_real()), so that it can log errors and exceptions in the watchdog, and/or to the screen.

  • 1
    "Some people might tell you just to disable warnings/notices" - wouldn't it be a good idea on production server, if he has separate dev and (or) stage instances? Of course I'd still advise regular log inspection. – Mołot Sep 8 '15 at 12:20
  • Yeah absolutely @Mołot, wasn't trying to get to deep into that here but you're right. Of course, in an ideal world, that's a redundant task - by the time the code gets to prod, there shouldn't be any errors in it ;) – Clive Sep 8 '15 at 12:29
0

Notices vs Warnings vs Errors

There are three main ways in which PHP will report problems: notices, warnings and errors.

Notices

These are the least important. According to the official PHP website, notices are generated when:

"the script encountered something that could indicate an error, but could also happen in the normal course of running a script."

Warnings

Warnings are more serious, but probably won't break your site. According to the official PHP website, warnings are:

"non-fatal errors. Execution of the script is not halted."

Errors

Errors are the most serious type of problem and may break your site. According to the official PHP website, warnings are:

"Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted."

Option 1: Disabling Error Reporing on Your Drupal Site

One the solution, and probably the one you'll take first, is to stop the errors from showing.

  • Go to Configuration > Logging and Errors.
  • You have three choices:
    • None will disable all error reporting.
    • Errors and warnings will display on the most serious problems.
    • All messages will display all problems and is probably only useful for developers. enter image description here

Option 2: Fix the Problem

Yes, yes, I know this is a controversial idea. Fixing a problem is definitely harder than hiding a problem.

Here are some suggestions to help you fix the problem. Please backup your site before trying any of these.

Make sure your Drupal site and all your modules and themes are up-to-date. Search Google and Drupal.org for anyone who has reported the same message. See if they have found a solution. Read the message itself for hints about the problem. For example, the problem in the image at the top of this tutorial is all/modules/calendar/includes/calendar_plugin_display_page.inc on line 47. This tells that the problem may well be with the Calendar module, because the error is coming from the Calendar module folder.

  • 1
    Re: option #2-- there are so many stray errors on Drupal sites from various contrib modules that it becomes impossible, from a practical sense, to "fix the problem". Developers want to produce web sites, not clean up contrib code. – user1359 Jul 27 '17 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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