This happens when some script is including includes/unicode.inc, I have faced this problem on hierarchical_select_json page where all included files from form_state are getting included.
as both unicode.inc and unicode.entities.inc files are under the same directory, I think including unicode.entities.inc with just the file name could be all right, this solved my problem anyway.

steps required to reproduce the bug:
1- install drupal 6.20
2- install hierarchical_select
3- add some taxonomies and config hierarchical_select to be used for taxonomy selection
4- use the taxonomy created in previous step in a content type
5- in the node add form, select a taxonomy
6- you should see in inclusion error in the response json as:
Warning: include_once(/includes/unicode.entities.inc) [function.include-once]: failed to open stream: No such file or directory in Path\To\Drupal\includes\unicode.inc on line 340

Warning: include_once() [function.include]: Failed opening '/includes/unicode.entities.inc' for inclusion (include_path='.;C:\Program Files\Apache Group\Apache2\php;') in Path\To\Drupal\includes\unicode.inc on line 340

So the work around would be replacing line 340 of includes/unicode.inc:
include_once './includes/unicode.entities.inc';
with:
include_once 'unicode.entities.inc';

CommentFileSizeAuthor
#46 example.zip20.59 KBWolf_22
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Damien Tournoud’s picture

Project: Drupal core » Hierarchical Select
Version: 6.20 » 6.x-3.x-dev
Component: other » Code

The current line is ok. Something in your installation must be changing the current directory incorrectly.

Could someone from HS shed some light on this?

farshid’s picture

Status: Active » Closed (works as designed)

After some trace, echo, print_r, and finaly eclipse + xdebug, I found another problem is causing an error, which devel_watchdog function wants to log (here the decode_entities function from unicode.inc is called, and the include problem comes from here...)
The error was coming from session.inc line 70 the value of db_affected_rows() was -1 which means an error, I checked the session table and found the error is due to 2 records for user id 1, guess what, I have logged in twice, from chrome and FF, when I logged out from one browser the problem was solved, I don't know to laugh or cry :) / :(
Any way, sorry to take your time, this issue is closed for now... I think.

Bodo Maass’s picture

Project: Hierarchical Select » Drupal core
Version: 6.x-3.x-dev » 6.20
Component: Code » other
Status: Closed (works as designed) » Active

Suddenly got the same error after upgrading to Drupal 6.20, but I don't use Hierarchical Select, but a large number of other modules. So I'm more inclined to say this is a problem with core (or an interaction with some modules). Still investigating.

mjoyce’s picture

I don't think this should be closed.

It is preventing cron from running on my site, throwing an error into the apache httpd error logs like this:

[Tue Jan 25 14:23:21 2011] [error] [client 137.82.18.101] PHP Warning: include_once(): Failed opening './includes/unicode.entities.inc' for inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /path/to/drupal/includes/unicode.inc on line 340

The Drupal admin/reports message is "Cron run exceeded the time limit and was aborted." which isn't what happened.

Googling for that specific error message shows it occurring for many other sites as well.

Lars Toomre’s picture

For those that have experienced this bug, I am wondering if a common characteristic is that you all had the devel module installed and enabled? I have had a similar elusive bug with decode_entities inclusion. In my case, there turned out to be an issue of defining the path to drupal root in the devel module's hook_watchdog implementation.

This morning I posted sample code for a fix to the problem over in issue #752366: Fatal error: Call to undefined function decode_entities() in devel.module. That issue may help resolve those reported in this thread. Perhaps someone can roll a patch so others can test this elusive decode_entities bug issue? (I am unable to roll a patch currently.)

Cheers!

Bodo Maass’s picture

I'm not using the devel module, but maybe some other module is something similar. I'll have a look.

Bodo Maass’s picture

Ok, the problem for me was my failure to copy unicode.entities.inc into my production folder. I have my copy of drupal under version control and hadn't noticed that this file was new.
So from my point of view the issue is solved.

M_Z’s picture

+1 for "disabling devel module fixed my problem" (I saw the warning messages only for anonymous user on the bottom of some pages, e.g. user/register, user/login or contact - but other pages (e.g. Panels pages) work fine for anonymous user - no warning messages for logged in users - strange...)

-1 for http://drupal.org/node/752366#comment-4004466 didn't solve my problem

but many thanks @Lars Toomre and all the others!

arritjenof’s picture

To add a bit to the confusion:

In a multi-site install, 1 of three different sites was having this problem, resulting in cron never finishing etc..

After a detailed comparison of the problem-site agaist the two fine-working sites,
what appeared to have solved it, is setting the $base_url variable in settings.php..
It has been working fine without that setting before.. Anyway, i hope this helps.

chaugi’s picture

+1 devel module causes this error for me, when making order change save in nodequeue module

jdvc’s picture

#10 @chaugi
Wow, I would never have figured that out if you hadn't posted! Exact same issue I ran into. Disabled Devel, no more errors.

Lars Toomre’s picture

I am glad that we have now identified the devel module as the problem as I suggested in #5 above. Has anyone had a chance to roll a patch for the DRUPAL_ROOT issue needed in D6 version of the Devel module. In another thread, I posted the code I made for determining this value, but I do not think it has gotten into the module yet. Any help in rolling a patch would be welcome.

M_Z’s picture

@Lars Toomre:

Did you read my comments #8 (above) and http://drupal.org/node/752366#comment-4103436 ? Your suggested patch didn't work for me. I have to disable the devel module to get rid of this error.

Lars Toomre’s picture

M_Z:

I misunderstood what you had written since I had not put that substitute drupal_root code into a formal patch. I just saw that you overcame the problem by disabling the devel module. Sorry about that...

Cheers, Lars

fuzzy76’s picture

Subscribing. If current dir is includes it makes no sense to specify ./includes/utf8.entities.inc to include?

itserich’s picture

I started receiving the error after changing to CloudFlare servers... However, I have used Cloudflare in the past, without error, and just reenabled it so perhaps I did something during the interim also.

http://drupal.org/project/cloudflare

Disabling the Devel module resolved the errors.

jimahuja’s picture

devel module is causing this error on my project also... :(

M_Z’s picture

What about moving this issue to Devel module?
Is there one case, where disabling devel module didn't solve the problem?

Andy_Read’s picture

I was trying to do a drush update and getting this warning from many modules. Disabling the devel module has removed all of the warnings.

kirkage’s picture

Version: 6.20 » 6.22

I'm updating this slightly since I also receive this issue and do not use the devel module. This began after updating to Drupal 6.20 and persisted under the latest 6.22.

This appears to be a bug in Drupal includes/unicode.inc line 339 where it tries to include unicode.entities.inc but this file doesn't exist. I'll put the code at the bottom for a quick glance, but I'm not sure what a proper fix is since includes/unicode.entities.inc doesn't exist.

A work around that doesn't seem to have any ill effects is to create a blank unicode.entities.inc in the includes folder. This at least silences the error and doesn't require any code changes to Drupal core.

Function that is including the missing file is in includes/unicode.inc on line 336.

function decode_entities($text, $exclude = array()) {
  static $html_entities;
  if (!isset($html_entities)) {
    include_once './includes/unicode.entities.inc';
  }

  // Flip the exclude list so that we can do quick lookups later.
  $exclude = array_flip($exclude);

  // Use a regexp to select all entities in one pass, to avoid decoding
  // double-escaped entities twice. The PREG_REPLACE_EVAL modifier 'e' is
  // being used to allow for a callback (see
  // http://php.net/manual/en/reference.pcre.pattern.modifiers).
  return preg_replace('/&(#x?)?([A-Za-z0-9]+);/e', '_decode_entities("$1", "$2", "$0", $html_entities, $exclude)', $text);
}
Heine’s picture

Unicode.entities.inc is in both the zip and tar archives of the latest Drupal 6 release.

farshid’s picture

Hi everyone,

I think (in theory) using dot + slash (./) while including gives us a performance hit as PHP won't look up extra paths to find the file for inclusion, but just the current directory, (refer to: http://stackoverflow.com/questions/579374/what-does-the-dot-slash-do-to-...) hence what is happening here is that something, some module, code, ... is changing the current working directory of PHP and thus the include command using (./) fails.

So here is my point:
1- The problem is caused out side Drupal core. (nothing wrong in includes/unicode.inc)
2- We need to know if we should solve this problem in includes/unicode.inc or not as this is some place we may do this.
3- If our answer to above is NO, We need to find out the problem source and add it to drupal code advisory so that people (module / theme developers) avoid the mistake.

any ideas?

by the way if some one is facing this problem may be they could test the current directory using PHP "getcwd" http://php.net/manual/en/function.getcwd.php command, just echo this function output before the include command causing the problem at includes/unicode.inc and if it is not the same directory the above theory should be considered alright.

Anonymous’s picture

subscribing

I got this error throwed by devel module, I need Devel so I can't just 'deactivate the module'...
then the strange thing is the server path of the file unicode.entities.inc sayed 'missing' is present at the right place :-/

Anonymous’s picture

I got it ! in the errors throwed, there are ones about mysql fails, there is a "Got a packet bigger than 'max_allowed_packet'"
in fact this comes apparently when we try to devel debug anywhere (dpm for example) a too much big data for mysql entry in watchdog...for me this comes after I got more than 4 comments in a node I debugged with devel.
so in your mysql.ini, try to up your variable 'max_allowed_packet', then it solves the problem for me.
in fact there is no path error, it is just subsequent of a mysql error...

wweibel’s picture

i just recently encountered this same problem. mine was while attempting to access Table Wizard admin menus. i too also have the Devel module enabled. i am also receiving a message about "The site is currently not available due to technical problems". this would seem to be a problem with connecting to an external database.

when i disabled the Devel module, the inclusion error did go away, however, like k303 above, i can not just 'deactivate the module'. it would appear, hopefully, that if an error occurs during a database connection that Devel is generating an error and is attempting the inclusion itself, not through drupal core.

when the connection issue was resolved - everything worked accordingly.

also, in reference to 'max_allowed_packet' - yes just up the amount allowed in your mysql config. but also, this error caused a node of id = 0 to be inserted into additional tables; not node, but any table that you may be updating/inserting into with a reference to the "created" node, ie. via hook_insert, or hook_update.

Dimm’s picture

Assigned: Unassigned » Dimm

Warning: include_once() [function.include]: Failed opening './includes/unicode.entities.inc' for inclusion (include_path='.:/usr/share/pear:/usr/share/php') file /home/uxxxx/domains/site.com/includes/unicode.inc line 339.
Warning: include_once(./includes/unicode.entities.inc) [function.include-once]: failed to open stream: No such file or directory file /home/uxxxx/domains/site.com/includes/unicode.inc line 339.

Is variant (unicode.inc line 339 ):?

  //  include_once './includes/unicode.entities.inc';
      include_once '/home/uxxxx/domains/site.com'.'/includes/unicode.entities.inc';
//OR
      include_once $_SERVER['DOCUMENT_ROOT'].'/includes/unicode.entities.inc';

It is Ok for me.

HolgiB’s picture

I am facing the same issue, sind updating from 6.19 to 6.22. I disabled already the Devel module and changed the max_allowed_packet in my.cnf from 1 to 2MB. But still the same error.

Anonymous’s picture

@HolgiB
it should comes from somewhere else if if you disabled devel and if you don't have mysql error 'max_allowed_packet'
mine was throwing error when it was at 8M, it worked when I set it to 16M...big queries for tracing deep objects may be greedy...

ha5bro’s picture

+1 for disabling Devel. Unfortunately it's not really a solution if you need Devel.

HolgiB’s picture

Well I am still facing this issue. I tried:

* Increase max_allowed_packet im my.cnf to 16 MB and later 32MB, some of the error messages are gone
* Disabled devel
* Removed devel
* Re-installed devel

But especially in panels I am getting a ton of these:

# warning: include_once(./includes/unicode.entities.inc): failed to open stream: Permission denied in /web/aibd.org.my/includes/unicode.inc on line 339.
# warning: include_once(): Failed opening './includes/unicode.entities.inc' for inclusion (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in /web/aibd.org.my/includes/unicode.inc on line 339.
# warning: include_once(./includes/unicode.entities.inc): failed to open stream: Permission denied in /web/aibd.org.my/includes/unicode.inc on line 339.
# warning: include_once(): Failed opening './includes

OliverColeman’s picture

Had the same problem: Drupal 6.22, Devel 6.x-1.26 enabled.

The problem only occurs for me when xhprof is enabled in the Devel settings, and the xhprof.output_dir setting in php.ini is set incorrectly (eg pointing to a non-existent directory). Can other people reproduce this behaviour?

HolgiB’s picture

I managed to fix this issue now. First thing I had to do was to chang to the absolute path to unicode.entities.inc, as mentioned in the OP. That solved the problem in some places, but not all.

When I checked the permissions of the file:

#:> ls -lisa unicode.*
402704574  8 -rw------- 1 root www  5496 2011-08-31 21:50 unicode.entities.inc
402737544 20 -rw-r--r-- 1 6226 www 17648 2011-12-14 09:35 unicode.inc

it turned out that the permissions are indeed not sufficient. Why this works on some places of the site and other not, I have not explanation. However, when I added R for the group and other, the error was completely gone.

I also have no idea, why the permission of only this file are wrong!

hmach’s picture

If You're using cck take a look how You call it's values.
Cck fields are (in most cases) called like this $node->field_cck_field[0]['value'] - if You forget that [0]['value'] it will case that kind of error. Yes, spent too many hours before finding that out.

Regards.

nzcodarnoc’s picture

My workaround:

The problem went away if I ran cron as the Anonymous user with devel disabled.

(For Drupal 6.20)

ShaneOnABike’s picture

I tried disabling Devel but that didn't seem to make a difference I'm still getting these errors :/

reformatt’s picture

in my case #7 was right. I forget to notice the new files when overwritting my folder with the new drupal core update. Thus I had to look for those additional files and add them to my repository.

Thanks again

IRuslan’s picture

The problem only occurs for me when xhprof is enabled in the Devel settings, and the xhprof.output_dir setting in php.ini is set incorrectly (eg pointing to a non-existent directory). Can other people reproduce this behaviour?

I have the same problem. It appears only if xhprof logging enabled.

robin_b’s picture

I had the same problem when I created a custom module for testing purposes (with Devel).

I had a MENU_CALLBACK pointing to a function. That function printed some text, but I forgot the return() function at the end. That caused the error.

This caused the error:


  $items['some_page'] = array(
    'page callback' => 'custom_function_from_menu_callback',
    ...
    'type' => MENU_CALLBACK
  );

function custom_function_from_menu_callback(){
    print("some text");
}

This removed the error:

function custom_function_from_menu_callback(){
    print("some text");
    return("");
}

Note: an empty return doesn't work. It has to be a return with some data in it.

John Franklin’s picture

I experienced this once when memcached died. Restarting memcached fixed it. One more thing to add to the checklist.

ShooterMG’s picture

I was receiving this error all of a sudden, like many others. Turns out the cause for me was in the Devel settings. I had "Display query log" checked, but I didn't have "Collect query info checked". Checking/Unchecking them both fixed it for me.

kenorb’s picture

If any of you are using CacheRouter or Devel module, probably that's the reason.
Follow-up: #1758956: Warning: Failed Opening './Includes/Unicode.Entities.Inc' For Inclusion In Unicode.Inc On Line 339
(backtrace included)

kenorb’s picture

function devel_watchdog($log_entry) {
...
    'message' => decode_entities(strtr($log_entry['message'], (array)$log_entry['variables'])),

When there is any error (like cache engine error as above), then this happen.
But I'm not sure if it's boot or shutdown case.

Cameron Tod’s picture

I fixed this in my contributed module (pathinfo). In my case, it was because the working directory had been changed to / in my shutdown function. Apache can do weird things with the working directory in shutdown functions.

This was my approach:

/**
 * Implements hook_init().
 */
function pathinfo_init() {
  // A hack to get around a limitation with register_shutdown_function, where
  // the cwd can change during shutdown.
  define('PATHINFO_DRUPAL_ROOT', getcwd());
  if (user_access('view pathinfo') && !devel_silent() && variable_get('pathinfo_footer_display', TRUE)) {
    drupal_add_css(drupal_get_path('module', 'pathinfo') . '/pathinfo.css');
    register_shutdown_function('pathinfo_shutdown');
  }
}

/**
 * Shutdown callback.
 */
function pathinfo_shutdown() {
  // Make sure that the working directory does not change during the request.
  // @see pathinfo_init()
  chdir(PATHINFO_DRUPAL_ROOT);
  // Try not to break non html pages.
  if (pathinfo_html_page()) {
    print pathinfo_served_by(pathinfo_get_info());
  }
}

Cameron Tod’s picture

Actually, while looking at something else, I found that this is the same approach D7 uses in core:

// In index.php
define('DRUPAL_ROOT', getcwd());
function _drupal_shutdown_function() {
  $callbacks = &drupal_register_shutdown_function();

  // Set the CWD to DRUPAL_ROOT as it is not guaranteed to be the same as it
  // was in the normal context of execution.
  chdir(DRUPAL_ROOT);

  // snip
}

http://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/_drup...

Wolf_22’s picture

Was there ever a conclusive and concise explanation for this issue? It seems like nobody really knows due to the many explanations that have been proposed on here.

I'm having a similar issue that I created a ticket for a few days ago for the Sheetnode module. Whenever I try to export a spreadsheet, it blows up with the following error:

An error occurred. /projects/foobar/?q=batch&id=31&op=do { "status": true, "percentage": 100, "message": "Exported 1 out of 1 sheets.\x3cbr/\x3eProcessed sheet \x3cem\x3eSheet1\x3c/em\x3e." }
Warning: include_once(./includes/unicode.entities.inc) [function.include-once]: failed to open stream: No such file or directory in C:\www\projects\foobar\includes\unicode.inc on line 339

Warning: include_once() [function.include]: Failed opening './includes/unicode.entities.inc' for inclusion (include_path='.;C:\php\pear') in C:\www\projects\foobar\includes\unicode.inc on line 339

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:7:\"warning\";s:8:\"%message\";s:102:\"mysqli_query() [function.mysqli-query]: MySQL server has gone away\";s:5:\"%file\";s:53:\"C:\\www\\projects\\foobar\\includes\\database.mysqli.inc\";s:5:\"%line\";i:114;}', 3, '', 'http://localhost/projects/foobar/?q=batch&id=31&op=do', 'http://localhost/projects/foobar/?q=batch&op=start&id=31', '127.0.0.1', 1354290343) in C:\www\projects\foobar\includes\database.mysqli.inc on line 134

Warning: include_once(modules/dblog/dblog.admin.inc) [function.include-once]: failed to open stream: No such file or directory in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 367

Warning: include_once() [function.include]: Failed opening 'modules/dblog/dblog.admin.inc' for inclusion (include_path='.;C:\php\pear') in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 367

Fatal error: Call to undefined function dblog_overview() in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 375

If something isn't escaped correctly, it would easily cause a nosedive like this... The thing is that I've been trying as hard as I can to backtrace all this and every single trick I try always brings me back to something related to "decode_entities()". This is so frustrating...

Wolf_22’s picture

FileSize
20.59 KB

Accidentally attached to the wrong thread... (Someone feel free to remove that if you can--I meant to attach that to a similar thread as this one.)

ExTexan’s picture

I can't explain why, but #26 worked for me - changed line 339 in entities.inc to...

include_once $_SERVER['DOCUMENT_ROOT'].'/includes/unicode.entities.inc';

Thanks @Dimm. Hope this helps others.

codeyourdream’s picture

I also run into this issue on Drupal 6.28 with Devel module enabled (6.x-1.27). As my investigation shows the problem occurs when Devel module is configured to "Store executed queries" ('devel_store_queries' variable name) but not to "Collect query info" ('dev_query' variable).

The reason is that Drupal checks if 'dev_query' is 1 in _db_query() function and, if not, does not populate global $queries array with executed query. However, Devel in devel_store_queries() function checks if 'devel_store_queries' is 1 and, if so, tries to iterate through the same global $queries variable, which is NULL.

This provokes E_WARNING during shutdown phase, Drupal calls error_handler which, in turn, invokes 'watchdog' hook. devel_watchdog calls decode_entities() that tries to include './includes/unicode.entities.inc' file but fails, because we are running during shutdown phase and the current working directory is '/'.

kenorb’s picture

@codeyourdream:
Your problem is related to Devel, this issue is related only to Drupal.
Please follow these issues:
#362555: Invalid argument supplied for foreach() in devel.module on line 763.
#752366: Fatal error: Call to undefined function decode_entities() in devel.module

rares’s picture

#26 solves this for me too. However, the problem is not in Drupal core, since throughout Drupal core (and the includes folder), includes are done using "./includes/filename.inc" without any issues. The issue here is that decode_entities is called by devel before the Drupal root folder is added to the include path. How that is possible, I do not know.

I propose moving this to devel, since after turning off devel, the errors disappear. Also, issues like the ones mentioned in #49 suggest devel has issues with calling decode_entities before the full bootstrap.

joelstein’s picture

For what it's worth, I was having the exact issue as originally posted (seeing the "unicode.entities.inc" error), and it was caused by what @codeyourdream reported in #28. I fixed my Devel configuration, and now it works! Seems like this should be repaired in Devel, but for anyone else stumbling in here, FYI.

ironsizide’s picture

I imagine I'm not posting this in the entirely correct place, but $43 and #44 provided me with the clues to solve my version of this problem. I've been to heck and back with this issue. I would get the error message in this issue (with unicode.inc) IF I disabled the REST server module that gave me my initial error, in the same style. If I made the DOCUMENT_ROOT change indicated in #26, I could correct the problem in the REST server... then in the unicode.inc include... and then in the next module with an include_once or require_once statement. As long as I made the change to explicitly use the document root syntax I could fix the problem in each module, but the error would cascade to the next module. Not a good fix.

My problems started with this issue when I installed a new SSL cert for the domain this Drupal install runs under. I changed nothing else in the code. The errors only showed up when calling the site through the services URL. If you went to the Drupal site in a web browser - no problems.

I added the following code to the module_load_include function in includes/module.inc:
echo "name:".$name."module:".$module.", CWD: ".getcwd()."\n";
in order to find where the current working directory was being changed from the expected Drupal to anything else. Sure enough, the REST server was showing a change from the Drupal root to the root root (/), and every include there after was barfing as a result. The true root cause is probably something in the services module (I am using Services v2), but putting this code:
define('DRUPAL_ROOT', getcwd());
in index.php as described in #44 and then putting this code:
chdir(DRUPAL_ROOT);
into the rest_server_autoload_info function in rest_server.module lie so:

function rest_server_autoload_info() {
  chdir(DRUPAL_ROOT);
  module_load_include('inc', 'rest_server');
  return _rest_server_autoload_info();
}

fixed the problem for me. Nothing else after the REST server seems to be changing the directory on me.

I hope this can help someone else with the same style of problem.

philsward’s picture

Began happening after updating to PHP 5.4

Devel is NOT installed so no fix as of yet, but there are a handful of modules out of date...

Update: Turns out Nodewords basic meta tags might be the culprit...