When accessing the admin...settings page on a subdomain site, I get the following two errors:

warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/username/public_html/includes/common.inc on line 227.

warning: fsockopen(): unable to connect to sub.domain.com:80 in /home/username/public_html/includes/common.inc on line 227.

This is a result of a failure to resolve the subdomain at my host. (DNS is hosted elsewhere from the server.) This could be easily fixed by adding an "@" before
$request = drupal_http_request($GLOBALS['base_url'] . '/system/test');
in system.module.

I don't have an environment set up to create a patch at the moment, but the change is very minor.

Comments

Anonymous’s picture

(not verified) commented
Title: PHP Error when accessing settings page » Error handler ignores @ operator
Component: system.module » base system

I have determined the source of this problem. The fsockopen functions (which are causing the errors) in drupal_http_request are already prefixed with the @ operator... but it's not doing anything. Why? Because Drupal implements its own custom error handler in the error_handler function (inside common.inc).

To make the error_handler function respect the @ operator, this code can be added to the top of the function:

  // don't respond to the error if it was suppressed with a '@'
  if (error_reporting() == 0) {
    return;
  }

This code was borrowed from a comment made on php.net.

killes@www.drop.org’s picture

killes@www.drop.org commented

I do think we want to suppress this erros fully. You can chose to put the error sonly into the logs nd not on the screen. There is no patch. I think this is by design and will mark it as such shouldI not hear more about it (and not forget it).

Anonymous’s picture

(not verified) commented

I did a quick grep through the code and found that the @ operator was used in the following places:

bootstrap.inc - db_query (cache table)
bootstrap.inc - strpos
common.inc - fsockopen
common.inc - fsockopen
common.inc - iconv
common.inc - mb_convert_encoding
common.inc - recode_string
file.inc - mkdir
file.inc - chmod
theme.inc - getimagesize
locale.module - eval
node.module - db_query (history table)
user.module - getimagesize

I can understand how the site admin would want to see the error from the db_query statements... however, I do NOT feel that it is acceptable for the site admin to receive two error messages on every hit to the admin-settings page. (Even if they are not displayed to users, they still pollute the watchdog table. At least 4 errors are recorded for every change to the settings page.) Because we now have the setting to hide/show error messages, I believe we should revert the @ operator to its original use, which is hiding error messages entirely. Therefore, I propose we remove the @ operator from those function whose error messages we wish to retain and add the proposed lines to the error_handler function.

Anonymous’s picture

(not verified) commented

Hmm, my earlier comment should have had a "not" in the first sentence.

deekayen’s picture

deekayen commented

Gerhard, you said you were going to mark this as "by design", then you made it active. I'm hoping that was just an accident and changing it for you.