I was trying to add the BoWoB Chat module to my site. It doesn't work and the error log file in its directory contain multiple lines like the following ones:

Failed opening required 'sites/all/modules/og/og.field.inc' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/public_html/mysite.com/sites/all/modules/og/og.module on line 16

Lines 15 and 16 are the following ones.

// Load all Field module hooks for Organic groups.
require(drupal_get_path('module', 'og') . '/og.field.inc'); 

The file og.field.inc is in the same directory as sites/all/modules/og/og.module and its permissions are 644, so it is readable.

This one has me stumped. Do you have any suggestion?

  • Bugs in existing modules are off-topic, as per faq. – kiamlaluno Aug 23 '12 at 7:10
  • This should be using module_load_include() anyways – Chaulky Aug 25 '12 at 1:39

Your file at least needs to have 755.

With 644 it is readable, but is not executable so the file cannot be managed as a php file (executable).

  • and you got two up-votes on that??!! The file is included, and in no way executed. Which means that readable is enough – Mawg says reinstate Monica Dec 19 '11 at 10:56

I don't have an explanation for this, but have seen something similar before, not for OG though. For some reason I could not change permissions/open a file that I had uploaded via FTP. I ended up deleting the entire directory and putting a fresh tar up there.


You've probably checked, but is the owner/group of the file accessible for your webserver account? I.e. on Linux do a ls -l to see what the owner and group of the offending file is -- you can fix with, for example chown www-data:[your group] og.field.inc, depending on your setup.

Just be sure to match the other, working, files. Group/owner settings have bitten me before -- usually when doing stuff via root or sudo... Good luck!

  • I don't have shell access, but surely 644 is enough? Anyone can read it. – Mawg says reinstate Monica Dec 20 '11 at 2:11
  • 1
    If you don't have shell access, then the issue is probably not the file owner/groups as the files were likely put up via FTP... Or did someone else with shell access put them up. Another simple 'solution': have you tried putting the site in maintenance mode, then deleting the whole og directory and putting it back again? It's a long shot, but sometimes a server just needs a gentle slap! – Jim Kirkpatrick Dec 20 '11 at 12:15
  • +1 thanks. No, noone lese has acess. Delete & "put back"how? Just make a copy & copy t back? I woulld try uninstalling & renstalling, but with so many other modules dependant on OG and all of them would need to be reconfigured, I am reluctant. – Mawg says reinstate Monica Dec 22 '11 at 3:30
  • To be safe I'd: 1) put the site in maintenance mode, 2) Move the OG folder OUT of the modules folder, 3) Put a fresh copy of OG you downloaded from Drupal.org in its place, 4) Disable/enable the module, 5) Put the site back to normal, 6) Test --- Hopefully this approach will rule out the files themselves being an issue and leave you with Drupal-level things to check. Ensure the new folder and its contents are 644 or 755 though! Definitely try 755 if in doubt. – Jim Kirkpatrick Dec 23 '11 at 11:38
  • @Jim Kirkpatrick...maybe you mean chown www-data:[your-group] – ninjascorner Dec 26 '11 at 2:46

Looks like php is looking in the wrong directory, (include_path='.:/usr/lib/php:/usr/local/lib/php') probably isn't where the file lives.

  • sites/all/modules/og is a directory in the current directory, which is the web server document root. The current directory is the first directory in the include path. If that were the problem, then no module would be loaded, as Drupal uses include_once to load the module files. – kiamlaluno Aug 23 '12 at 7:09

Install registry_rebuild in Drush, and then run drush rr.

There are times in Drupal 7 when the registry gets hopelessly hosed and you need to rebuild the registry (a list of PHP classes and the files they go with). Sometimes, though, you can't do this regular cache-clear activity because some class is required when the system is trying to bootstrap.

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