Fatal error opening required theme.inc in content.module

I think both issues are the same. So marking this one as a dup of #615760: Enabling views crashes whole site - only plain text error message (smoking ruin)

AFAICT, CCK code is correct. The file should be there (it is included in the package), and it should be accesible with that statement (Drupal executes from the Drupal root, and ./sites/all/modules/cck/theme/theme.inc is relative from there), unless something odd is happening in your system. Maybe the file is not there (caused while upgrading from an earlier version? ), or maybe another module has changed the current working directory, or maybe it is a filesystem issue, permissions?

@vacilando: looking at that issue, moved to the Views queue, you'll see how merlinofchaos also states it's not a problem with the module, but something else. He says, it's user error. I also add that it could be caused by another software component, or even hardware related. Please, read my second paragraph in #1.

I'm switching the issue to "fixed" so that it is more visible in the queue, but still nothing to do with CCK itself, otherwise it would be failing to everyone else, which is not the case. The require_once invocation is correct. So the problem may come from something else.

- Check the file is there.
- Check file permissions.

If that's seems correct, then it could be that another module has changed the current working directory of the process. We (and any other code in Drupal) assume the current working directory is the same directory where Drupal itself is installed, aka Drupal root. So we should be able to use relative paths that work everywhere.

Line 177 in content.module is part of content_theme() function. This is implementation of hook_theme() in content module. This function is invoked when Drupal rebuilds the Theme registry. To check if the current working directory is still Drupal root, you could do this:

 function content_theme() {
   $path = drupal_get_path('module', 'content') .'/theme';
+  drupal_set_message(t('Current working directory at content_theme() is: @cwd', array('@cwd' => getcwd())));
+  drupal_set_message(t('The real path of file @file is @path', array('@file' => "./$path/theme.inc", '@path' => realpath("./$path/theme.inc"))));
+  if (!file_exists("./$path/theme.inc")) {
+    drupal_set_message(t('File not found. @path', array('@path' => realpath("./$path/theme.inc"))));
+  }
+  elseif (!is_readable("./$path/theme.inc")) {
+    drupal_set_message(t('File is not readable. @path', array('@path' => realpath("./$path/theme.inc"))));
+  }
   require_once "./$path/theme.inc";

The quickest way I know of to force a Theme registry rebuild is from the icon menu in Administration menu.

First thing would be to try the code I posted in #4. That should reveal if the cwd has been changed, and where it has been set.

Another thing would be to look at the Drupal logs and find these errors. Are all related to the same URL? Can you see a pattern here?

Another thing: scan the code of all module in your site for code that may alter the current working directory. Function chdir()?

Another thing: if you know how to reproduce the error, then start a debug session to find out where the cwd is being changed. This could be done adding drupal_set_message(__FILE__ .' - '. __LINE__ .' - '. getcwd()) here and there.

The same problem.
When cache is cleared, memcache trying to execute theme() function on shutdown:

9	2.5519	9357860	memcache_admin_shutdown( )	../memcache_admin.module:0
10	2.5523	9357860	theme( 'item_list', array () )	../memcache_admin.module:238

On Apache, current dir is changed on shutdown and it's not pointing to Drupal directory (it's by design).
Possible solutions:
- this theme() function should be removed
- this function shouldn't be called on shutdown
- directory should be changed back to Drupal root, but it doesn't make sense to theme something on shutdown

Subscribed.

Same thing here. >_<

I've detected a few days ago the same error after installing memcache and enable statistics at the bottom of each page.
I have Drupal 6.16 and Memcache Admin 6.x-1.4 installed.
Add the following condition to theme registry:

if (function_exists('theme_get_registry') && theme_get_registry()) {
        foreach ($_memcache_statistics as $stat => $value) {
          $stats[] = "<strong>$stat:</strong> ". theme('item_list', $value);
        }
        if (!empty($stats)) {
          $output = theme('item_list', $stats);

          // this makes sure all of the HTML is within the <body> even though this <script> is outside it
          print '<div id="memcache-devel"><h2>'. t('Memcache statistics'). '</h2>'. $output. '</div>';
        }
}

I've experienced the same issue here, disabling 'show memcache statistics at the bottom of each page' at admin/settings/memcache fixed the issue for me.

++

The same problem again. This time my website is broken and is not loading.
Why you theme anything on shutdown?

Same issue. Subscribe.

Ok, I've now spent HOURS trying to put my site back together after this error. No matter what I do, turning on CCK now gives me the error and whitescreen.

I do not see a memcache admin table in my database. I have deleted the module code, removed the reference to it in my system table, removed the info from my settings.php file and I am still unable to turn CCK on.

Where else has this module modified my installation?

Argh!!

Nevermind, I'm going to restore from 2 nights ago backup. This is just insane.

Here's the fix that iestevao posted but written as a simple guard.

http://bitbucket.org/dalejung/hookdrupal/changeset/416545384c68

Here's dalejung's change as a patch file.

Subscribed

I don't think we should be calling theme_get_registry() from our stats shutdown function. So if the theme function ain't there, we get the heck out and just don't show stats.

The patch in #22 doesn't work, as the theme_get_registry() function should always available by this point; we also need to ensure the registry is not empty to avoid the error, which the patch in #20 does - in D6, theme_get_registry() is just a static cache function, it doesn't invoke any hooks.

Devel uses the same approach in its shutdown handler: http://drupalcode.org/viewvc/drupal/contributions/modules/devel/devel.mo...

Marking #20 as RTBC for D6. Is this also an issue in D7? theme_get_registry() is more complicated there and I'm not sure the same fix is viable.

subscribe.

It seems I have (almost) the same error with the latest 6.x-1.x-dev (and 1.6):
require_once(./sites/default/modules/contrib/date/date/date.theme) [function.require-once]: failed to open stream: No such file or directory in file xxxx/sites/default/modules/contrib/date/date/date.module on line 260.

It stops when i disable memcache_admin. I wonder why there arent more people reporting the same issue?

Same problem here. Annoying as heck. I'll try the patch in #22 and see if that fixes it.

[Edit: Patch in #22 didn't fix the problem... but disabling memcache_admin did. Go figure. This seems to happen only when I clear all the caches via admin_menu, or when my cron script hits the cron.php file.]

[Edit 2: (thanks to longwave's suggestion below) Patch in #20 fixes the problem.]

@geerlingguy: the patch in #22 doesn't work, try #20 instead.

Subscribing, thanks.

I confirmed that a similar patch is in the devel module, and applied it locally:
http://drupal.org/cvs?commit=438212

However in further testing, I realized that the stats were _never_ showing up, so I backed the patch back out:
http://drupal.org/cvs?commit=438216

There appears to be another unrelated issue in which the theme is getting broken, not introduced by this patch (it happens with or without this patch being applied.)

@Jeremy: your commit didn't work because the logic test is backwards. The attached patch reverses this and fixes the problem.

The easiest way to test this is with both CCK and Memcache installed on a site, disable the statistics at /admin/settings/memcache, save changes, enable the statistics and save changes again. Without the patch, a require_once error is logged to the watchdog, but with the patch in place the error does not occur.

This error started showing up on our site after installing memcache. I can confirm that the patch in #29 resolves the issue for our scenario.

I can also confirm that I started getting this error as soon as memcache was installed. The patch in #29 was applied and the error is now gone.

Committed this to 6.x, moving to 7.x in case it's also needed there.

Committed to 7.x.