Fatal error: Call to undefined function decode_entities() in devel.module

I also just noticed this when I was working in Drupal 7 yesterday after I updated CVS.

fixed slightly differently.

Reopening this issue since the same problem exists in 6.x. And the same fix of using a "require_once" fixes the issue. However there is no "DRUPAL_ROOT" constant in D6, so the file would have to be included another way.

I just ran into this with a watchdog in a hook_boot. I don't care about dfb, so I just disabled it with the attached patch.

( ! ) Fatal error: Call to undefined function decode_entities() in /var/www/drupal7x/includes/common.inc on line 1552

error in D7 if you set the wrong xhprof path

I am getting the same error when trying to update my devel site

Fatal error: Call to undefined function decode_entities() in /Users/gwheatley/Sites/My Website/includes/common.inc on line 1552

Same error:
Fatal error: Call to undefined function decode_entities() in includes\common.inc on line 1552

This is not a core bug.

i don't care what kind of bug it is, looking for answer for over a day now. I have the same problem.

i don't care what kind of bug it is, looking for answer for over a day now.

@Branjawn: I'm tempted to write something like "you poor crybaby," but no, I wouldn't do that.

The first step towards a solution might be to agree about
— what Drupal version (D6 or D7) we're talking about,
— what path (URL) is producing the error message, and
— why you think this is related to the Devel module.

Until then you can be sure that nothing will happen...

Install the -dev version of Devel, enable its Backtrace error handler, and post the call stack that leads to the error. (We're actively working on the Backtrace error handler, that's why you should get the very latest version.)

#8: If this happens only "if you set the wrong xhprof path," then why don't you just set the right xhprof path? Are we talking about catching the admin error more gracefully?

Does greggles' patch in #7 help? Is it acceptable to just drop the messages as he does? Or should we instead pass them on without decoding the entities? I suspect we're mixing different issues here...

Lamenting does not bring us forward. Those who have the issue are expected to contribute substantially, not just "me too"...

I'm not convinced that #9+ are even related to Devel. Try disabling Devel and check whether the error persists. The title of this issue says "[...] in devel.module" — #8+ say "[...] in common.inc". It's the same error condition, but there's no indication that they might be related.

Cry baby, good one. Just frustrated with the never ending errors associated with Drupal. My response was in regard to Damien's "This is not a core bug."

Anyways, I didn't fix it... but I did a fresh install of Drupal, which meant losing a lot of data but as I know not very much about php or anything I was never going to solve this problem anyways.

@salvis,
OK. my issue is not related, opened a new #1011308: Call to undefined function decode_entities IN common.inc

Anyone who waste time to read #8 & #16, please accept my sincere apologies for my error above. Thanks :)

@Branjawn: Has reinstalling helped?

I'm sorry to hear you're "frustrated with the never ending errors associated with Drupal." Even if you're not well-versed with Drupal yet, you can still start accumulating a bag of tools and methods to provide better error reports, which have a better chance of getting useful responses and ultimately leading to fixes.

I assume you're using D7, right? We're getting very close to the release date, but technically, until then, you're using unreleased software. This means you're using software that is officially "not done yet" and that is provided to you so that you can help to test it before it's released. By downloading and installing unreleased versions you have implicitly accepted to become a tester who is willing to report and deal with errors in order to contribute to the project. IOW, you're at the bleeding edge. If this is outside of your comfort zone ("frustrated"), then you shouldn't be here and should have waited until D7 is released before installing it.

So, please reset your counter of "never ending errors" to zero when you install the released Drupal 7.1 in a few days!

Thanks to the backtrace in droplet's new post it's obvious (to those who can read these things) where thehis error is. If you still have theyour error, you can create your own backtrace by installing the latest -dev version of Devel, go to admin/config/development/devel#edit-devel-error-handler and select the Backtrace error handler. Then visit the page where you see the error (using user 1) and you should get a backtrace that you can post here. If it's a published site then you should disable Devel after that; it's not intended to be run permanently on production sites.

@droplet: Thanks for posting the new issue — I've responded over there.

Well, I removed the Devel module (make that all modules) and started from scratch. I have not yet installed the Devel module again. But, alas, no errors :)

To be really sure that there are no nasty surprises, wait for the 7.1 release and really start from scratch (i.e. empty your database). If you have a database that has lived through a number of pre-release versions, then it may be in an inconsistent state.

Upgrading from D6 to 7.1 is supposed to work, but not necessarily through alpha/beta/rc versions.

I just downloaded the latest release of the 6-dev version of this module and got this error again. I had patched a previous version and thought that this had gotten into the Drupal 6 version of the code base. To help others and to remind myself (if I need to patch things again), this error can be fixed (when DRUPAL_ROOT is undefined) by adding the following around line 444 of the devel module:

  if (!function_exists('decode_entities')) {
    $unicode = getcwd() . '/includes/unicode.inc';
    require_once $unicode;
  }

Insert this just before the '$watchdog = array(' line to ensure that decode_entities is available even before complete bootstrap is complete.

Does this fix make sense to add to the D6 version of the code?

Cheers!!

What is your version of Drupal core?

What path (URL) is producing the error message?

Have you thought about the various ways of installing Drupal. Will getcwd() work with all of them?

Hi Salvis,

Let me try to help with some limited details. I am running the most current release of D6 (6.20) on a Ubuntu server running Linux 10.4 and PHP 5.3x. For the particular website in question, I have the moist current snapshot of the 6-dev module installed together with both the FirePHP and chromephp debugging classes installed in /sites/all/libraries. I also have xhprof installed, but it was not directed to do any profiling.

The problem for me with this error is that there was no path (URL) directly showing me an error message nor was there an entry in the watchdog logs. The first time I solved it was very carefully looking at the logs produced by the TRACE module. At this point though I do not recall where exactly the watchdog hook was being called from.

The problem manifests itself whenever an unpatched version of the devel module is installed on my website. I will enter a new node together with an image (using imagecache and imagecahce_actions modules among others). The new node saves fine and the image is displayed. However, when I then switch to a page that uses a different size of that same newly created image, there is a missing image symbol in both the Firefox and Chrome browsers.

I was quite puzzled at first about what in the mess of complicated files could be causing the problem. However, a clue to the solution revealed itself by clicking on the show page source in the Chrome browser and then attempting to click further on the troublesome image link. (It was in the page source as expected.) What came up in the new browser window was a message stating that decode_entities was undefined on line 444 of the devel.module!! What a surprise... I would have thought that the jpg would have displayed itself instead (if it existed at that point [not sure at this point, exactly when the different sized image was produced]).

That error message led me to this thread and the realization that hook_watchdog can be called without a fully bootstrapped Drupal instance. What appears to be needed for the D6 version is definition of DRUPAL_ROOT. In looking at the D7 code code, I saw that getcwd() was called to define DRUPAL_ROOT at one stage of the boot process. Hence, I attempted to duplicate that logic in my case to overcome my problem. I have not considered whether this will work with the various ways of installing Drupal.

What does seem to be needed is a way to reference the current Drupal root directory without depending on any Drupal functions (that may or may not have been included at that point). This way it will be "safe" to call the watchdog like functions from early hooks like hook_boot.

Does this help?

Cheers!!

The Drupal community is great at sharing common problems and often solutions. I just noticed that mossy2100 posted the code for his function absolute_path_to_drupal(). I have not tested it but this might be something that should be included in the devel module for the early boot cases. The link to the code is http://drupal.org/node/67961#comment-3800534.

Salvis, using code like that referenced here should solve the potential case of drupal being called from a directory other than what was returned in my quick solution of using getcwd(). Your thoughts on adding a function like what mossy2100 shared to the devel module project?

Cheers!!

Thank you for the additional information. So we're back at D6. This is a pretty elusive issue, so we may have to fix what we can, even if it's D6 first.

Thanks for the pointer to absolute_path_to_drupal(), too. There's also drush_locate_root() in Drush, which is even more involved. We're treading on thin ice here.

I don't really know how to proceed...

moshe?

Reflecting a bit on the comments by salvis in #24, I am keenly aware that the devel module is attempting to provide debugging support throughout the various stages of webpage delivery process (including the Drupal bootstrap stage). Hence, I believe that this one "semi-official" module needs to diverge some from the standard Drupal way of depending upon other Drupal core code.

For me, this divergence means if there is any uncertainty about whether some portion of the Drupal boot process has been completed, this module should include a module-specific equivalent functionality that depends only the most "base" PHP code possible. Hence, while in completed boot mode in version D7, DRUPAL_ROOT (and proposed new DEVEL_DRUPAL_ROOT) constant can be well trusted; otherwise, these constants should be built from from basic PHP.

This probably also means that this module needs to vary some from the standard Drupal way of modifying first the dev or head version. Key development certainly should continue in the head area. However, if some new feature introduced in head cannot be replicated in basic PHP further down the supported version chain, there needs to be some form of feedback/correction. My thoughts on this subject are not fully evolved, but let me try to explain:

Say we introduce a dependency in head that constant XYZ exists. While the head version of the module may not need a helper subroutine to support that newly introduced constant or functionality, prior versions of the module might/do require a helper function. An example is a function that sets the equivalent of DRUPAL_ROOT.

This is the one module that I am aware of where modifications might need to introduced not to support the dev version, but to introduce equivalent functionality for earlier versions of Drupal and/or this module. Such a modification process will help the many Drupal 5.x and Drupal 6.x developers/maintainers that are starting to figure out how they might make the leap to Drupal 7. Thoughts??

Cheers!!

Hmm, if I understand you correctly, you're saying pretty much the same thing I said: let's try to fix this in 6.x-1.x-dev now.

The question is how do we find the includes directory for loading unicode.inc in D6, in the general case.

Good morning salvis,

You inquired about about a method to find Drupal root directory? This morning I have used both functions mentioned above as guides and created a function I have called devel_drupal_root(). This function uses only code available in both PHP4 and PHP5 to do its calculations so it should be fine to use anywhere in the Drupal boot process in any version of Drupal. (I have only tested with D6 using PHP 5.2.)

Here is what I added to the bottom of my local copy of the 6-dev devel.module file:

/**
 * Locates Drupal root directory from arbitrary one in directory tree.
 *
 * This function returns directory equivalent to constant DRUPAL_ROOT defined in
 * Drupal 7 and later; FALSE returned if no root directory found.  It is derived
 * from drush_locate_root() function and purposely uses only PHP4 functions so
 * that it can be used in both prior versions of Drupal and anywhere in the
 * Drupal bootstrap process.
 *
 * @return $drupal_root
 *   String representing Drupal root directory; FALSE if none found.
 */
function devel_drupal_root($start_path = NULL) {
  $drupal_root = FALSE;

  if (!empty($start_path) && !is_dir($start_path)) {
    return $drupal_root;
  }
  else {
    // We want to use PWD if available because getcwd() resolves symlinks, which
    // might shift us from beneath the Drupal root directory, making it
    // impossible to find.
    // Nota bene: $_SERVER['PWD'] is not set on windows and generates a Notice.
    $start_path = isset($_SERVER['PWD']) ? $_SERVER['PWD'] : '';
    if (empty($start_path)) {
      $start_path = getcwd();
    }
  }
  // Convert path if necessary to standard Unix format
  $start_path = str_replace('\\','/', $start_path);
  $start_path = preg_replace('/^\/cygdrive\/([A-Za-z])(.*)$/', '\1:\2', $start_path);

  // Check for symbolic links as well as real paths
  $max_directory_levels = 25;
  foreach (array(TRUE, FALSE) as $follow_symlinks) {
    $path = $start_path;
    if ($follow_symlinks && is_link($path)) {
      $path = realpath($path);
    }
    // Check if directory is a Drupal root, otherwise try to move up one level
    // Implemented with for statement instead of while to prevent infinite loops
    for ($i = 0; $i < $max_directory_levels; $i++) {
      if ($follow_symlinks && is_link($path)) {
        $path = realpath($path);
      }
      if (!empty($path) && is_dir($path) &&
        file_exists($path . '/includes/bootstrap.inc') &&
        file_exists($path . '/sites') &&
        file_exists($path . '/index.php')) {
        $drupal_root = $path;
        break 2;  // Break out of both while and foreach loops
      }
      // Try to determine next directory up tree
      $path = explode('/', $path);
      if (!empty($path)) {
        array_pop($path);
        $path = implode('/', $path);
      }
      else {
        $path = FALSE;
      }
    }
  }
  return $drupal_root;
}

I then modified the change noted above in #20 (around line 444) to be:

  if (!function_exists('decode_entities')) {
    $drupal_root = devel_drupal_root();
    $unicode = $drupal_root . '/includes/unicode.inc';
    require_once $unicode;
  }

This new code is working fine for me. Perhaps someone can roll a patch so that others can test this solution? I hope this helps the effort. Cheers!!

I am wondering if errors reported in #1028730: includes/unicode.inc line 340 fails to include unicode.entities.inc under some circumstances are tied into this drupal root definition issue as well.

Looking at the debug_backtrace() results for an unpatched version of this module, I am further wondering if any module that implements hook_watchdog has the potential to cause this missing decode_entities() problem. This is because the bootstrap process calls module_invoke_all() for the watchdog hook in some cases before the full bootstrap is complete. I however have no clue what other module(s) (besides devel) implements this particular hook. I am just noting this observation for further debugging clues.

#27 didn't solve my problem - see http://drupal.org/node/1028730#comment-4103428 for further details

Posted by codeyourdream on May 28, 2013 at 4:34am new
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 '/'.

http://drupal.org/node/1028730#comment-7466062

Devel & Cache Router related: #1758956: Warning: Failed Opening './Includes/Unicode.Entities.Inc' For Inclusion In Unicode.Inc On Line 339
Backtrace: http://drupal.org/files/Demo___CKEditor.pdf

I think #30 is fixed by #362555-25: Invalid argument supplied for foreach() in devel.module on line 763. in the -dev version.

Marked as duplicated of this: #1028730: includes/unicode.inc line 340 fails to include unicode.entities.inc under some circumstances

I'm seeing an error trying to unlink('/tmp/cache_lock') in #31. Unfortunately, the call to _drupal_error_handler() is clipped — it might be a good idea to check whether that path exists...

Closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.