Fatal error: Call to undefined function user_access() in /var/www/drupal-6.10/includes/menu.inc on line 449
MountainX - May 5, 2009 - 20:36
I'm getting this error message while trying to transfer a Drupal site from 6.9 to a site running 6.10.
I have gone through all the steps such as importing the MySQL database and setting the database permissions.
The message displays when I browse to my site (example.com).
The only hits that come up for this message on Google are in Russian.
When I try to run http://example.com/update.php, I get redirected to this URL (http://example.com/update.php?op=info) and I only see a blank page in the browser.
A few things to check:
A few things to check:
- the user module file is under modules/user/user.module and hasn't been moved
- there are no duplicate copies of user.module in any other location accessible to drupal
- user module is enabled in the "system" table in the database (status =1) and it has the correct path (modules/user/user.module).
- your cache settings in admin/settings/performance are not too aggressive for the modules that you are using
Also check your php memory_limit (http://drupal.org/node/207036). It may be too low for your installed modules in that server, which may cause blank pages. A core-only installation needs at least 16M.
Thank you! - the user module
Thank you!
- the user module file is under modules/user/user.module and hasn't been moved
Yes, it is there.
I have a multisite install. There is a site running correctly on the new server, so that also verifies that all the required modules exist.
- there are no duplicate copies of user.module in any other location accessible to drupal
Verified. There are none
- user module is enabled in the "system" table in the database (status =1) and it has the correct path (modules/user/user.module).
I do not know how to verify this. I suspect this might be the problem. How do I display and modify values in this table?
- your cache settings in admin/settings/performance are not too aggressive for the modules that you are using.
Not sure about this... I'll ask later if the above issue turns out not to be it.
My php memory limit is 32M.
I may have found my
I may have found my problem....
When I set up the first (OLD) site, I paid someone to install drupal for me. (On my new site, I did it myself. Now I am trying to transfer the data from the old site to the new one.
Just now I was comparing the two sites and I found on the OLD site that the joker who installed Drupal for me put a drupal-6.9 folder inside the modules folder like this:
/var/www/drupal/modules/drupal-6.9
(this contains all the drupal installation files, including all core modules, etc. What a mess!)
I renamed this folder to /var/www/drupal/modules/drupal-6.9-deleteme and then my OLD site immediately started displaying this same error message ("Call to undefined function user_access"). So I renamed it back to "/var/www/drupal/modules/drupal-6.9" and the old site started working again.
So my database at my old site is apparently screwed up... and that's probably why it won't work on my new site. Any ideas for fixing this?
Probably one site or the
Probably one site or the other got the wrong path for the user module (and maybe for other modules) from the duplicate copy. There are five required Drupal modules which are not allowed to be moved (system, node, user, filter, block) and that causes confusion.
Move that drupal-6.9 directory out of Drupal or try to make it completely unreadable (for example permissions 000). Then try running update php and also try browsing to admin/build/modules and let it load (if it can load, it will update the module paths).
If this doesn't work, you will need to take a look at the databases of the two sites.
- Using phpmyadmin, go to the "system" table of the site
- Search in the column which has the paths to find any paths containing "modules/drupal-6.9/modules/something" and change these paths to "modules/something".
- Also check that the 5 unmovable required modules (system, node, user, filter, block) have status=1.
- Repeat for the other site.
By the way, the problem of misplaced copies of the whole Drupal upload is not uncommon. It takes only a mouse slip in the FTP window.
Thanks again for the tips. I
Thanks again for the tips.
I tried your suggestion to make the extra copy of Drupal unreadable and then run update.php. That didn't work. Update.php will not run. Browsing to admin/build/modules didn't work either.
Any time I make the extra copy of Drupal unreadable, all sites on this multi-site install stop working with this error:
Fatal error: Call to undefined function user_access() in /var/www/drupal/includes/menu.inc on line 449
So my next step is to go into the "system" table of the site. Does Drupal include phpmyadmin? If not, is there another way to update entries in the system table? Thanks.
No. phpmyadmin is a different
No. phpmyadmin is a different php program, a tool which most people use to work with their MySQL databases (http://www.phpmyadmin.net). There are other similar tools. Drupal just uses a database, it doesn't let you work directly with it.
What kind of hosting do you have? Don't they provide some panel or some database tool?
You could also take a database backup, open it with a good text editor and search for those wrong "drupal-6.9" paths.
I host at Linode.com. I do
I host at Linode.com. I do not think there are any database front end tools. But I can access mysql directly and run sql commands. (See my other question about the syntax for the update statement.) Thanks
SQL update statement
Maybe I can just use a sql update statement like this:
use my_database
update system
set XXX = 'modules/'
where XXX = 'modules/drupal-6.9/modules/'
What is the column name that holds the path to the modules (where I have written XXX above)?
Yes, you could. The field
Yes, you could. The field name is "filename". If you fix the paths of the 5 required modules I believe that the admin/build/modules page will fix the rest. The correct values are:
modules/system/system.module
modules/user/user.module
modules/node/node.module
modules/filter/filter.module
modules/block/block.module
Also make sure that their "status" field is set to 1.
Thanks. Our messages crossed.
Thanks. Our messages crossed. :)
I will try your suggestion.
one step of progress, but still need SQL help
I found out the column name is "filename".
Unfortunately, it doesn't hold just the path such as "modules/drupal-6.9/modules/", it holds the fully qualified filename such as "modules/drupal-6.9/modules/aggregator/aggregator.module"
So I need a query that will replace entries like "modules/drupal-6.9/modules/aggregator/aggregator.module" with the fixed path like this "modules/aggregator/aggregator.module".
I have never written SQL that would alter only part of the value in a field. How would that be done?
BTW, this is definitely a problem. Here's the list of modules with incorrect entries in the system table:
|
| modules/drupal-6.9/modules/aggregator/aggregator.module |
| modules/drupal-6.9/modules/block/block.module |
| modules/drupal-6.9/modules/blogapi/blogapi.module |
| modules/drupal-6.9/modules/book/book.module |
| modules/drupal-6.9/modules/color/color.module |
| modules/drupal-6.9/modules/comment/comment.module |
| modules/drupal-6.9/modules/contact/contact.module |
| modules/drupal-6.9/modules/dblog/dblog.module |
| modules/drupal-6.9/modules/filter/filter.module |
| modules/drupal-6.9/modules/forum/forum.module |
| modules/drupal-6.9/modules/help/help.module |
| modules/drupal-6.9/modules/locale/locale.module |
| modules/drupal-6.9/modules/menu/menu.module |
| modules/drupal-6.9/modules/node/node.module |
| modules/drupal-6.9/modules/openid/openid.module |
| modules/drupal-6.9/modules/path/path.module |
| modules/drupal-6.9/modules/php/php.module |
| modules/drupal-6.9/modules/ping/ping.module |
| modules/drupal-6.9/modules/poll/poll.module |
| modules/drupal-6.9/modules/profile/profile.module |
| modules/drupal-6.9/modules/search/search.module |
| modules/drupal-6.9/modules/statistics/statistics.module |
| modules/drupal-6.9/modules/syslog/syslog.module |
| modules/drupal-6.9/modules/system/system.module |
| modules/drupal-6.9/modules/taxonomy/taxonomy.module |
| modules/drupal-6.9/modules/throttle/throttle.module |
| modules/drupal-6.9/modules/tracker/tracker.module |
| modules/drupal-6.9/modules/translation/translation.module |
| modules/drupal-6.9/modules/trigger/trigger.module |
| modules/drupal-6.9/modules/update/update.module |
| modules/drupal-6.9/modules/upload/upload.module |
| modules/drupal-6.9/modules/user/user.module |
Hmm... MySQL regular
Hmm... MySQL regular expressions are too much fun. I would try with a text editor on a database dump file, searching and replacing "drupal-6.9/modules/" with nothing.
first I'm trying your other suggestion
OK, I like the idea of a text editor on the mysql dump file. I will try that next if needed.
But first I'm trying your other suggestion of fixing the five core modules. I did these 5 statements:
mysql> update system set filename = 'modules/user/user.module' where filename = 'modules/drupal-6.9/modules/user/user.module';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update system set filename = 'modules/system/system.module' where filename = 'modules/drupal-6.9/modules/system/system.module';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update system set filename = 'modules/node/node.module' where filename = 'modules/drupal-6.9/modules/node/node.module';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update system set filename = 'modules/filter/filter.module' where filename = 'modules/drupal-6.9/modules/filter/filter.module';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update system set filename = 'modules/block/block.module' where filename = 'modules/drupal-6.9/modules/block/block.module';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Now I can access update.php. I'm running it, and it is at step 3 (run updates). But it seems to be stuck at "starting updates" and the progress bar doesn't seem to be moving....
partial success
update.php never seemed to finish. But running a select on the system table shows that all the module filenames were fixed:
| modules/aggregator/aggregator.module |
| modules/block/block.module |
| modules/blog/blog.module |
| modules/blogapi/blogapi.module |
| modules/book/book.module |
| modules/color/color.module |
| modules/comment/comment.module |
| modules/contact/contact.module |
| modules/dblog/dblog.module |
| modules/filter/filter.module |
| modules/forum/forum.module |
| modules/help/help.module |
| modules/imce/imce.module |
| modules/locale/locale.module |
| modules/menu/menu.module |
| modules/node/node.module |
| modules/node_import/node_import.module |
| modules/openid/openid.module |
| modules/path/path.module |
| modules/php/php.module |
| modules/ping/ping.module |
| modules/poll/poll.module |
| modules/profile/profile.module |
| modules/search/search.module |
| modules/smtp/smtp.module |
| modules/statistics/statistics.module |
| modules/syslog/syslog.module |
| modules/system/system.module |
| modules/taxonomy/taxonomy.module |
| modules/throttle/throttle.module |
| modules/tracker/tracker.module |
| modules/translation/translation.module |
| modules/trigger/trigger.module |
| modules/update/update.module |
| modules/upload/upload.module |
| modules/user/user.module
The site home page comes up now. But when I try to access the admin area, I get this error:
Fatal error: require_once() [function.require]: Failed opening required 'modules/drupal-6.9/modules/system/system.admin.inc' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/drupal-6.10/includes/menu.inc on line 346
Is the drupal-6.9 directory
Is the drupal-6.9 directory inaccessible now? Is your php memory_limit big enough?
Is the drupal-6.9 directory
Is the drupal-6.9 directory inaccessible now?
Yes, it's gone.
Is your php memory_limit big enough?
Yes, 32M.
You may need to do that text
You may need to do that text search after all. Maybe it is in some cache.
no success
> You may need to do that text search after all. Maybe it is in some cache.
I did this step 100% on the old site (just to avoid the differences between Drupal 6.9 and 6.10 that I have to deal with when moving to the new site).
I did the dump, text search/replace and import. After doing that, my site would not come up -- I just got a blank page. I tried several fixes and I didn't have success, so I imported the unchanged dump file again, and my site was back to normal.
The only thing I changed in the dump file was a global search on "modules/drupal-6.9/modules/" and a replace with "modules/".
Maybe there is some stuff under modules/drupal-6.9/ that is needed...
You could also try to
You could also try to truncate all the cache_... tables before taking the backup, or searching further for the "drupal-6.9" string alone.
Can update.php run in the new site if you don't make the changes?
Still no luck
I repeated the whole process again and I generated a new db dump after disabling all 3rd party modules.
I did the search/replace and it replaced 945 instances of "modules/drupal-6.9/modules/" with "modules/".
After that, the only place "drupal-6.9" remained in the db was in two strings like this:
"download_link\";s:54:\"http://ftp.drupal.org/files/projects/drupal-6.9.tar.gz\"
Those seem OK for now, so I left them alone.
update.php will not run in the new site without making changes. When I import the table dump with no changes, I'm back to the original problem: Fatal error: Call to undefined function user_access().
How did you disable access to
How did you disable access to that drupal-6.9 directory? Is it possible that drupal can still read the filenames in it, although it can't read the files?
On the new site I do not have
On the new site I do not have that drupal-6.9 directory at all (and never did). So when I have run tests on the new site, that would not be the problem.
However, on the old site, I now realize that I didn't follow your instructions well enough. I simply renamed the directory to drupal-6.9-deleteme and I did not make it inaccessible.
So I will repeat the steps and try everything again.
Thanks for your help.
how to get notified when comments are made on a thread?
BTW, is there a way to get notified (via email) when new comments are posted here?
No, I just visit my
No, I just visit my /user/{id}/track page.
Block Cache
Fyi, I only get errors like this when I have BlockCache enabled.
Discovered a new issue
I discovered a new problem on my new site by chance.
Initially I thought this was a separate issue. I posted about it here:
http://drupal.org/node/455466
But now I think that the other problem must be related to this one. I think I should solve that one first and then come back and try the data import again.
What I don't say in that other post is that I dropped the database I was attempting to import and I started totally fresh. I got rid of everything related to this transfer project and I was just going to make a brand new Drupal site. But even that didn't work, so now it is clear that not only do I have a problem at the old site (the drupal-6.9 directory inside the modules directory), I also have something preventing me from adding any more sites to the new server.
(The problem on the new site is probably a result of me trying to make the new server secure...)
Success!
I was able to import my entire database from my old Drupal site! I edited the table dump to remove all references to the bad module path, and after fixing my other problems (see the thread I mentioned above), I got this to work!!! :)
DTools
You may try to use WSOD from DTools module (http://www.drupal.org/project/dtools)
Try latest dev version and run in emergency mode (README.txt)
It will diagnose reason of the error and it will rebuild the whole system table.