Install: Call to undefined _user_password_dynamic_validation()

also with:
PHP 4.4.6
MySQL 4.1.22-standard
at:
/install.php?locale=en&profile=default&op=start&id=1

Reproducible error (4x); completely from scratch.
Checked file permissions; htaccess, etc.

If I pull line 710 in install.php out: _user_password_dynamic_validation()

Then after (during?) saving the site configuration I'll get:

Fatal error: Call to undefined function user_access() in /home/houseoff/public_html/includes/theme.inc on line 1637

Both these functions are defined in user.module so maybe it's not getting loaded in properly?

On the other hand, it's hard to believe few people are having a problem this major in an RC.

whole problem set still appears if I change the .php handler to PHP5.

Well, this could be some local problem on your server, or we would see lots of people complaining about it. I was unable to reproduce this so far.

I am facing the same error. However I hesitated in posting, thinking that it would be a nuisance to the developers as I was sure that everybody else is sure to face the same issue.

This is a fresh install. (I did not install any other Drupal 6 (alpha or beta etc) before this)

I also tried to supress that error ... It goes ahead and stops at
Fatal error: Call to undefined function user_access() in /home/houseoff/public_html/includes/theme.inc on line 1637

I request you to kindly look into this, as I just cannot proceed any further.

Some details of my hosting setup :

System Linux ----- 2.4.21-53.ELsmp #1 SMP Mon Dec 3 13:34:41 EST 2007 i686

PHP Version 4.4.4

Apache Version Apache/1.3.37 (Unix) mod_gzip/1.3.26.1a mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a

MySQL Client API version 4.1.22

Pl ask me if I should provide any other data.

Thanks in advance.

P.S. : I do not know if this is a useful piece of information but let me share it any way. I am trying to install Drupal 6 in a subdirectory.

Running PHP 5.x.

When installing normally or in a subdirectory, I can only replicate this error by physically removing the user.module file or the user directory, or by running chmod 600 user.module.

I suspect a file permissions issue, though it might be a PHP 4.4 issue of some sort.

I figured it out.

When you want to install Drupal in subdirectory, you are required to uncomment the following line in .htaccess file

# RewriteBase /drupal

and replace /drupal with /whatever_sub_directory.

You are required to do this before install starts. (This is
what I think)

Drupal 6 rc 1 got installed properly in subdirectory when I did this.

I do not know whether this is THE way to solve this or there are more appropriate instructions given somewhere to address this situation. (I found the instructions in comments in .htaccess file itself.)

Thanks

I was unable to reproduce this with a fresh installation of either D6 RC1 or D6 HEAD.

PHP 4.4.7
MySQL 4.1.22

EDIT: Cross-posted with velankar.
I forgot to mention that I installed both versions into a subdirectory. No changes were required to .htaccess for my installations to work properly.

I have also installed rc1 and HEAD in subdirectories without problems.

On other systems (mosso) I did need to uncomment the RewriteBase directive or I would get fatal errors like this even when I was installing into the root directory.

I think this is only a problem on a relatively small number of systems. If we can figure out what makes them this way then I guess we could warn people about it. Given that it is not common, I feel this should be downgraded.

For clarity, I am not required to edit .htaccess on Apache 1.3 (Mac OS 10.4) when installing in a subdirectory.

@velankar, what type of system are you installing on? This seems to be platform-specific.

I am a little surprised to see that this is not mentioned in INSTALL.txt. Reassigning as a documentation task.

Your question:
@velankar, what type of system are you installing on? This seems to be platform-specific.

here are some details of my hosting setup :

System Linux ----- 2.4.21-53.ELsmp #1 SMP Mon Dec 3 13:34:41 EST 2007 i686

PHP Version 4.4.4

Apache Version Apache/1.3.37 (Unix) mod_gzip/1.3.26.1a mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a

MySQL Client API version 4.1.22
========================================

Here are the instructions given in .htaccess file, that came with the Drupal 6 rc 1 gz file

# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal

=========================================
I followed the above istructions and install went fine.

during installation after removing drupal beta and removing the database for that.
Brand New installation in a sub directory.

This is the error
Fatal error: Call to undefined function: _user_password_dynamic_validation() in /home/xyz/public_html/drupal/install.php on line 710

I've tried modifying the .htaccess file. It didn't seem to do anything.

cPanel Build 16999
Theme x3
Apache version 1.3.37 (Unix)
PHP version 4.4.4
MySQL version 4.1.22-standard
Architecture i686
Operating system Linux
Shared Ip Address x.x.x.x
Path to sendmail /usr/sbin/sendmail
Path to PERL /usr/bin/perl
Kernel version 2.6.9-55.0.9.ELsmp

.HTACCESS

Do I also need to uncomment "virtualdocumentroot" ?

# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /

So, the commonality seems to be 4.4.4.
@agentrickard - what is your php version? can you test with 4.4.4?

@greggles - the OP listed PHP 4.4.7 (which happens to be the version I also tested on).

@greggles. No. I use PHP 5.1.6, and nearly crashed my Mac when I tried to switch.

I doubt this would be a PHP issue, the likely culprit is web server rules. Perhaps something in mod_rewrite?

COBALT appears to be on a shared host that may not allow .htaccess directives.

@COBALT, can you confirm?

Hi,

I've installed 6.0-rc1 with no problems the first time. this problem occurred when i tried to create another site with the same code base.

I have PHP Version 5.2.1.
Mysql 5.0.22
Apache 2.2.4
I'm running on windows XP SP2

This is what i did to get the problem (after having a working install of 6.0-rc1)
1. created a new folder in the sites directory i.e. localhost.newsite
2. created a new DB and user for second site
3. copied settings.php from default directory
4. edit my new settings.php with right DB credentials
5. edit httpd.conf file with alias to new website i.e. Alias /newsite "/www/webapps/drupal-6.0-rc1"
6. launch install.php script on my new site i.e. http://localhost/newsite/install.php

initial page was loaded fine. the error appeared after creating the DB tables (i know this because i checked the DB and the new tables were there)

I hope this helps.

I will also try velankar suggestions and see if it helps

I have had drupal 6 beta 4 installed with no issues.

When you say mod_rewrite and .htaccess directives I'm not sure where to look to find what options are set.

I have wordpress 2.31 and PHPWebGallery installed with no problems in separate directories.

***
.htaccess was created for my wordpress directory for successful installation. Do I need to do something similar for drupal 6 RC1 ?

Create a file called .htaccess within the root directory for your installation.
Place this line in that file:
SecFilterEngine Off
This will disable for that entire directory.

COBALT: so *now* you can install beta 4 without issues, but you cannot install RC1 *now* with the same procedure? It is important to check both at the same time, so hosting provider changes or whatever are not taken into account.

I installed drupal6 beta4 and the installation worked right away, (just now)

I remove all the files from mySQL manager and from the directory structure with "legacy file manager" (in cpanel)

I rebuild the mySQL files / user etc.
I create the directory /files

I begin to install drupal6 RC1 and I get the error. It seems like a rather bad error too. I can not attempt to recover the installation at any point. I need to uninstall / remove the files again to attempt a new installation with RC1

***
Installing Drupal6 RC1

The installation has encountered an error.
Please continue to the error page
An HTTP error 403 occurred. http://www.wxyz.com/drupal/install.php?locale=en&profile=default&id=1&op=do

"this is the error page"

Fatal error: Call to undefined function: _user_password_dynamic_validation() in /home/wxyz/public_html/drupal/install.php on line 710

Alright. Same host, two (shared) servers, two testbed sites.
This makes me want to stab myself in the eyes with a spork, slowly.

---------------------------------------
Site "H" - under this setup:
---------------------------------------
Apache version 1.3.37 (Unix)
PHP version 4.4.6
MySQL version 4.1.22-standard
Architecture x86_64
Operating system Linux
Kernel version 2.6.9-55.0.9.ELsmp

(5.x works fine, but) 6 rc1 throws these...

During install ths is the error page:
Fatal error: Call to undefined function: _user_password_dynamic_validation() in install.php on line 710

If I delete that line (I know how weak my test password is, thanks), then:

During install this happens again:
An HTTP error 406 occurred. http://example.com/install.php?locale=en&profile=default&id=1&op=do

The "error page" links to the next step in the install, but trying to save that results in:
Fatal error: Call to undefined function user_validate_name() in /home/sitename/public_html/install.php on line 1081

Attempting to access the site index after all this results in:
Fatal error: Call to undefined function user_access() in /home/sitename/public_html/includes/theme.inc on line 1637

---------------------------------------
Site "X" - under this setup:
---------------------------------------
Apache version 1.3.39 (Unix)
PHP version 5.2.5
MySQL version 5.0.45-community
Architecture x86_64
Operating system Linux
Kernel version 2.6.9-55.0.12.ELsmp

Works!

So...

Obviously, there may well be other server settings that are more relevant/responsible than any of that info, but there it is.

If anyone has suggestions on how to track down this problem, I'd like to help out.
I still think this is a problem with user.module getting loaded, since all the functions it just doesn't seem to recognize are in there, but hell if I know for sure.

Hm, that _user_password_dynamic_validation() call is in the configure form step (looking at the code and also from the comments above), so it happens after all modules should be setup, enabled and loaded (at the beginning of install_tasks()). After all modules are enabled, all modules will be loaded.

One thing I can think of here, is that drupal_bootstrap() is unable to load the modules because of some relative directory calculation issue on the file system.

1. Check whether module_load_all() is called at all (it should be called when the bootstrap process reaches the last phase with the install_tasks() call)
2. If it is called, check whether drupal_load() actually loads the modules.

If module_load() is not reached, we have a problem with the bootstrap process. If the modules are not loaded properly, we have some path problem properly (which would give some reasoning to the rewrite based tips above).

Try adding this line to .htaccess

I was having similar issues in 4.7x and 5.x with update.php

As far as I know, apache's mod_security is not necessary because drupal does its own filtering. mod_security will also mess with other user input and yield a blank white screen if certain settings are enabled.

I would suggest we add this to the options in .htaccess if there is no harm in doing so. Skulk confirms this line solves his issue.

Well, it should not hurt to run mod_security above Drupal, and we have some sites which do so without problems. While Drupal strives to be as secure as possible, it should never hurt to add another security layer on top, and we should not discourage it IMHO.

If this change fixes it then what about including it but commenting it out and including a link to a handbook page?

I'd wait to see if anyone else can actually confirm its effectiveness.

I installed drupal6 beta4 and the installation worked right away, (just now)

I remove all the files from mySQL manager and from the directory structure with "legacy file manager" (in cpanel)

I rebuild the mySQL files / user etc.
I create the directory /files

I begin to install drupal6 RC2 and I get the error. It seems like a rather bad error too. I can not attempt to recover the installation at any point. I need to uninstall / remove the files again to attempt a new installation with RC2

***
Installing Drupal6 RC2

The installation has encountered an error.
Please continue to the error page
An HTTP error 403 occurred. http://www.wxyz.com/drupal/install.php?locale=en&profile=default&id=1&op...

"this is the error page"

Fatal error: Call to undefined function: _user_password_dynamic_validation() in /home/wxyz/public_html/drupal/install.php on line 710

403 Errors in install/update operations are most likely mod_security acting up! Please try this to see if it's the case. http://drupal.org/node/203187#comment-677813

I had this same problem. (MySQL 4.1.4, PHP 4.4.2, Web server is Apache, Drupal is unable to determine the version or type, and just assumes Apache. I've sent my provider an email to ask what the version is).

For people stuck with this problem, the following worked for me: I uncommented the line in the .htacces file. (My site is at www.example.com/new, so I changed it to RewriteBase /new). Then I inserted the line "SecFilterEngine Off" at the top of the .htaccess file. Then I deleted everything on the webserver, re-uploaded everything, and dropped all the tables in the database (which the failed install did manage to create). Then the install worked.

For people troubleshooting this, it didn't work without all these steps. I did all this in the order I wrote it down, so it could be that dropping the tables was the key, and "SecFilter Off" wasn't necessary at all. I'll try some other combinations if anyone asks. I could also try it with PHP 5 and the same provider if necessary.

The Apache version is 1.3.34

Same worked for me (#27) : Apache/2.0.55 (Debian), PHP 5.1.6-1

Ok, I tried everything, dropped all tables, switched off mod-security2 (which has to be done in the global httpd-configuration by settin SecRuleEngine off), I downloaded drupal-6.0 as drupal-6.0-rc4 had failed. No success. I cannot install drupal on my debian etch system, apache2, php5. I am not installing in a subdirectory, the drupal directory is set as the virtual hosts's document root.

By the way, anyone of those not able to reproduce the error having their installations in virtual hosts? Is there any point where reverse address resolution may become a topic? For me, drupalsite.mydomain.whatever points to my IP address, my my IP address is reverse-lookuped as host.providersdomain.whatever... Just an idea.

CU Lars.

I had the same errors...

I tried "SecFilterEngine Off" in the .htaccess and it worked!

Thanks Fool2 for the suggestion!

So you were using an apache installation with modsecurity. With my installation it did not work. I have apache2 with modsecurity2, which I disabled. I wonder how much percentage of drupal installations runs on similar platforms (linux, apache2) and will break after an upgrade to 6. Maybe we should mark this bug as critical. I changed the version of this issue from 6.0-rc2 to 6.0, as it also appears in rc4 and the 6.0 release.

Could I ask that people also include their OS release for this problem? I suspect that it might be packaged rules (rather than package versions) triggering this bug in Drupal.

The system I am running on is Fedora 7, with httpd-2.2.6-1.fc7 (Apache), php-5.2.4-1.fc7 and the release tarball of Drupal 6.0. My testing showed the following negative results:
- While modsecurity2 did block a form upload, it was not blocking the include process
- Safe mode is not turned on
- include_path in PHP is not set
- There are no generic access controls blocking including of files on the site, or even from the modules/user dir
- The RewriteBase rules make no difference, whether in root dir or subdir
- SELinux, although being in Enforcing mode, is not blocking this. (Note that SELinux will probably block remote access to a MySQL database on another server, unless modified)
- Fedora Core 6 is not susceptible to the same bug
- This bug occurs in both virtual and "default" layouts
- There is *NO* block on including, I can even manually include the modules/user/user.module file with only the obvious errors due to the rest of Drupal being missing

It seems clear to me that this has to be a bug in Drupal, although most likely triggered by OS/distribution rules of some sort. Thanks to Gábor Hojtsy, I have a starting point in analysing the code to work out where the bug is occuring. Adding some simple (but ugly) echo's into includes/bootstrap.inc shows the following calls to drupal_load() (after confirming that module_load_all was being called):

drupal_load called on system
drupal_load called on filter
drupal_load called on system

Seems like a rather short list to me, with the obvious lack of the 'user' module. So, I made the same change on my Fedora Core 6 system that showed no problems:

drupal_load called on system
drupal_load called on filter
drupal_load called on block
drupal_load called on color
drupal_load called on comment
drupal_load called on dblog
drupal_load called on filter
drupal_load called on help
drupal_load called on menu
drupal_load called on node
drupal_load called on system
drupal_load called on taxonomy
drupal_load called on user

Somewhere along the line, Drupal is failing (not trying?) to load many required modules. I hope to work my way back up the chain to see where these modules are being selected, and try to determine why drupal_load() is being called on some of these modules in F7, and not others.

Edit: On the failing F7 system, the profile is set to 'default', but the various modules listed there are not being loaded. Although user isn't one of them, I'm going to start there anyway rather than wading through the various function calls to work out where else module selection is being done.

I have two servers running F7 displaying this behaviour, and one server running FC6 that does not. I'm fairly sure both F7's were fresh installs, not upgrades, so it shouldn't be hard to reproduce this bug by installing F7 and testing it (and disabling modsecurity2, which will break the install process before this bug occurs).

Regards,
Paul

Well, I tracked down where the problem is occurring...sort of...

module_load_all calls module_list, asking it to refresh the list of modules. As near as I can tell, on line 64 of module.inc, the module_list function makes a call to the system module asking for a list of installed/enabled modules, and this list appears to come back as 'system', nothing else. Since nothing else is listed as enabled, the load process never even looks at the other modules.

I'm not sure if I'm going to be able to get my head around how the system module works, in a reasonable amount of time. Hopefully this information will be useful to others in tracking down this bug. Maybe I can start at the beginning, and find where these modules should have been enabled and find out why...without working backwards through the entire system module first.

Well, just to totally confuse everyone (especially myself!), after enabling the modules that were already enabled on my FC6 system, like so:
UPDATE system SET status = 1 WHERE name = 'block' OR name = 'color' OR name = 'comment' OR name = 'dblog' OR name = 'filter' OR name = 'help' OR name = 'menu' OR name = 'node' OR name = 'system' OR name = 'taxonomy' OR name = 'user';

and then dropping and re-creating the database, and re-extracting the tarball, the whole install works just fine, up to an email error which is probably SELinux.

So...is it a race condition somewhere? I can't think of anything else off the top of my head...now I'm going to try the same MySQL manual update, followed by a drop and create, and an rm -rf and tar -xvf, on the server I was initially trying to install on. I'm not sure whether to cross my fingers or not...

OMG...it works. Deleting a directory tree and re-extracting the tarball, along with dropping and re-creating the database, should ENTIRELY remove all traces of a Drupal install on a system, right?!? How on earth can that combination of steps fix a problem like this, where modules are not being enabled in the system table?

I'll leave that to the real developers...but hopefully if there's anyone else who's been beating their head against a brick wall trying to get this sorted (after trying all the other suggestions here), they will now have some relief. Now, if only someone could reassure me of my sanity...

Environment:

I want to give some details of the environment of my failing installation:

Debian etch x86
Apache 2
PHP 5.2.0-8+etch10
Safe Mode On
Include Path .:/usr/share/php:/usr/share/pear

These should be more or less etch defaults.

The site is to be installed in a virtual host (/var/www/sitename) with a corresponding entry in /etc/apache2/sites_available/sitename.

CU Lars.

Hello

The fact that mod_security is involved means to me that this has to do with an HTTP request from the installation script. It could be blocking some AJAX or javascript calls that would set up the modules correctly.

I would do some http analysis to see exactly what's happening.

Immediately popping into my mind would be the passing of certain database arguments in a GET or POST variable-- which is at least part of what the secfilterengine filters.

If we could encode them somehow it might be better, but I am not even able to find the failpoint right now (I'm still developing on drupal5, at least until drupalcon)

I'm having the same problem on a fresh install of 6.0 on:

Apache version 1.3.37 (Unix)
PHP version 4.4.7
MySQL version 4.1.22-standard
Architecture x86_64
Operating system Linux

Fool2, you might like to have a closer look at my earlier messages.

Modsecurity blocks are clearly logged, and more than one person has disabled it without resolving this problem. I examined this issue in some detail, and I can categorically state there is *NO* access control preventing the module from loading (on my systems). Drupal is not trying to load the module, because it is listed in the database (system table) as disabled. I cannot suggest why, and that should perhaps be the focus of investigations.

I was able to work around this by manually turning on the user module, and several others in the system table (see previous post), drop the database, delete my drupal directory tree, and re-do the installation. Insane, but it worked...possibly some other combination would also, but once it worked, I could no longer test it.

Please note however - there are multiple reasons why a module may fail to load, including access controls, PHP settings, and this bug.

thank you "adencomp"

on install processing,
after insert database name and password, we meet the error message.
at this time system table is aleady created.
open the system database table and change 4 modules's status to "1"
(user, node, filter, block)

and click the error link again.

all works well!!!!!

ps:
if you change all modules that adencomp said, you will meet the no watchdoc table error.
enabling only 4 modules is enough^^

thank you "adencomp", thank you jei academy!

Adding SecFilterEngine Off worked for me too.

PHP Version 4.4.8
MySQL 4.1.14

I'm having the same probmlem with my shared hosting account at servage.net.

Including a SecFilterEngine Off in the .htaccess file doesn't work for me. I get a 503 Error after that.

I also had the same problem, the "Call to undefined function: _user_password_dynamic_validation()" during a fresh install on a brand new domain.

I was able to get around it by changing the module status for Block, Filter, Node, and User modules in the System table from 0 to 1, as suggested above (THANKS!).

PHP version 4.4.4
MySQL 5.0.45
Apache 1.3.39
OS: CentOS Linux

I had the same error on Drupal 6.1

PHP 5.2.4
Apache 2.2.0
MySQL 5.0.45

This is a standard Fedora 7 install.

Changing the above mentioned status records for the four modules worked. When the error occurred, I would get a blank page. No error page. From the CLI, I made the changes in the database, hit refresh on the browser, and the script was able to complete.

For me the SecFilterEngine Off change would yield a Server Error 500.

Sounds like the change necessary here is to modify the install script that populates the db entries for at least these four modules.

Thanks all for their due diligence and effort.

Regards,
Steve

Following the guidelines in #40 worked for me on shared hosting. Thanks for that.

Ver 6.2 Install when at database section gives error below. I have another site on same host with all the same using ver 5.7 without a problem.

Fatal error: Call to undefined function: _user_password_dynamic_validation() in /home/dollbill/public_html/install.php on line 710

MySQL 4.4.7

MySQL version 4.1.22-standard

Apache version 1.3.39 (Unix)

XP Pro
Firefox

Getting this error on a 7.x-dev installation. (2008 June 3 snapshot)

OS: Windows XP Professional with Service Pack 3
Website file system: FAT32
Web server: Apache/2.2.8 (Win32)
PHP: PHP Version 5.2.5
MySQL: 5.0.45

Put "SecFilterEngine Off" at the top of my .htaccess file.
Re do websites files.
Re-create database ("create database drupal;")
Browse to the site.
Now it works!

Note: If I run this using IIS as my Webserver than .htaccess is not an issue and the install works fine first time.

Changing the status for those 4 modules did the trick for me too.

Still anoying that the installer won't work on my shared host out of the box.

#40 helped

my environment:

Drupal 6.3
File system Writable (public download method)
MySQL database 5.0.51a
PHP 5.2.6
PHP memory limit 100M
PHP register globals Disabled

Just my luck to encounter another long-living-Drupal-bug :(

Neither #27 nor #40 worked:

PHP Version 4.3.9
Apache/2.2.0 (Redhat)
MySQL client version: 4.1.20

CORRECTION - #40 worked for me.

It is still not solved in 6.4, exactly the same error. I am going into mysql again to manually edit tables now.... :-(

EDIT:

to solve it:

log in to your database (I use mysql, so that is what I use here:)

mysql -u USER -p

in mysql (with USER being your mysql user name), enter:

UPDATE system SET status = 1 WHERE name = 'block' OR name = 'user' OR name = 'node' OR name = 'filter';

and exit the mysql CLI. Load the installer page that failed once again, you will get a notice to change the file permissions and can proceed with the set-up now. Good luck...

Same in 6.4 too

begin by a 403 error message, then Call to undefined _user_password_dynamic_validation()

The set status workaround works for me but same problem occurs with languages imports ( http://drupal.org/node/250305#comment-978532 )

Seem's to be linked with mod_security and mozilla / firefox ( http://drupal.org/node/255519#comment-978521 )

if that may help ...

open the system database table and change 4 modules's status to "1"
(user, node, filter, block)

#40 - WORKS FOR ME. Thanks

FYI, this is no longer happening in 6.3/4. I've installed a couple sites since then and they all worked fine out of the box.

If you have access to Apache's error.log, you may look there for a hint. An error triggered during the install process may be enough to break it. My install broke due to a silly php.ini setting.

Following the guidelines in #40 worked for me too. Thanks for that.

I followed guidelines in #40 too but it is not working.

I have php5 and trying to install drupal 6.8 on a new domain (clean fresh all new install).

Quite frustrating!

Edit : it worked using reply #52 command line

UPDATE system SET status = 1 WHERE name = 'block' OR name = 'user' OR name = 'node' OR name = 'filter';

Thanks

I just built my server from scratch. installed 2 sites without a problem.

Decided to get a little adventurous and installed mod_security and mod_evasive. Went to install my third site and I ran into this problem.

Going to add SecFilterEngine Off to the htaccess for now

Okay. For Drupal 7 HEAD, here's how I solved the problem.

First, I followed the instructions in #52. I was able to finish the install but I got "Class UpdateQuery not found". It wasn't just UpdateQuery that couldn't be found. It was basically all database-related classes. Then, I created a new file with the following content:

Server environment where the problem occurs:
Ubuntu Intrepid
Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4 with Suhosin-Patch
MySQL Server version: 5.0.67-0ubuntu6

I just tried a fresh install of 6.9 and received this error. I amnually enabled the user module using MySQL and then it worked.

Wow. this is a long living bug...

I've never had aproblem installing drupal 5/6 in various configuration. this is the first time i'm using some scripting to try and automate some stuff, and thous i meet this bug...

I'll try manually enabling/disabling do see if that works - but this really needs to be solved...

I saw that someone wrote about a connection to Firefox. (#53) I can confirm this. I had this problem trying to install Drupal 6.9. I had the call to undefined...-issue, but also the issue with languages (I was trying to install in Swedish). I tried the installation several times.

However, when I tried to make the same installation with Internet Explorer, there were no such problems. So that's a possible workaround for you.

Thanks kakor!

Weird problem...

Simply add this line of code after "<?php"

require_once './modules/user/user.module';

Good luck

This problem has been around since 2007, and nobody fixed it...

Anyway, I have mod_security installed, and then using firefox (ver.3), I had the same issue.
Using IE (ver.7), this problem did not occur.

It must have something to do with the way the form data is sent to the server.

#66 Confirm

IE7 WORK!
I think this problem occur by AJAX request in Firefox.

I had problems installing and updating modules with Drupal 6.9 on my Mac OS9 with Netscape 7. Everything worked well on my husband's Windows/IE.
I got a new Mac with OS 10.5, and Safari and Firefox both exhibited the same problems. So I tried a fresh install with Drupal 6.10, and got the "Fatal error: Call to undefined function: _user_password_dynamic_validation() ..." After trying the .htaccess fix, I got an internal server error. After changing the status of the four core modules in the database (#40), it worked.

Same issues here with a website provider in Germany running Debian. Nothing helped not even #40. Tried Opera, Firefox on Linux and Opera Firefox Sahara on Mac OS X. Installation worked with MS Explorer on Vistas. Thanks #66 for the hint.

... Matt

FWIW, I've performed a couple new installs since I posted here, and have not seen this problem again.

PHP Version: 5.2.5

Installed on root.
Same Error.
Installed on a subdirectory.
same error.
Followed #40
Error resolved!!!!

Thanks.

I can report the same issue as well, it does not matter though which browser I use....

patch submitted.

Also adds the include_once() line to install_configure_form, which was throwing errors about the missing USER_ constants.

Confirmed error in Firefox3, installing with Opera was no problem.

Error message:
Fatal error: Call to undefined function _user_password_dynamic_validation() in C:\wamp\www\genesis7_0\install.php on line 724

Oddly I do not consistently get the error, sometimes installs go fine with Firefox3, indeed I have installed D7 many times the past few weeks without issue.

Hi,
I have installed Drupal 5.x multiple times without errors, but the combination of security upgrades at my host site and drupal 6.13 has led to a raft of problems. This is really unfortunate b/c I want to use Drupal b/c of its ease of setup and configuration for someone who is not a PHP/MySQL master and now I am wondering if Drupal still fits these criteria.

Nonetheless, perhaps you can help by clarifying the fix for the above issue -- I have read through the whole discussion multiple times but before I act, I would like confirmation that I have read it correctly ...

Here's the deal --
Due to problems upgrading from 5.x to 6.x I had my host site wipe everything to start fresh.

Upon fresh install, when running install.php, I enter the database info I got the following error -- "An HTTP error 501 occurred". When clicking to see the error list, I get the white blank page.

My host turned on error reporting and I got this error -- PHP Fatal error: Call to undefined function user_access() in /www/virtualhosts/.../includes/theme.inc on line 1730.

Reading through various forums, someone suggested clearing browser cookies.

After doing this, I receive a new error -- "Call to undefined function _user_password_dynamic_validation()" -- which brought me to this page.

Here are the fixes that have been suggested on this page -- as far as I can tell:

1) various modifications to the .htaccess file

NOTE: I can't do this (and it seems there is debate over whether this is indeed the fix anyway) b/c my host does not allow uploading this file. So please do not suggest this.

2) UPDATE system SET status = 1 WHERE name = 'block' OR name = 'color' OR name = 'comment' OR name = 'dblog' OR name = 'filter' OR name = 'help' OR name = 'menu' OR name = 'node' OR name = 'system' OR name = 'taxonomy' OR name = 'user'

NOTE: I am not sure how to do this? I am most able to make changes via via a GUI interface - php myadmin/

3) open the system database table and change 4 modules' status to "1" (user, node, filter, block)

NOTE: is this the same as fix #2?

NOTE: I am not sure how to do this? I am accessing the database tables via a GUI interface - php myadmin. When I go to the database manager and click on the "system" table, the table has 10 rows:

* filename (no value under the "default" column header)
* name (no value under the "default" column header)
* type (no value under the "default" column header)
* owner (no value under the "default" column header)
* status (value = 0)
* throttle (value = 0)
* bootstrap (value = 0)
* schema_version (value = -1)
* weight (value = 0)
* info (value = null)

Am I not looking in the right place or is this table missing lots of rows?

4) log in to your database (this answer provided for people using mysql via command line)
mysql -u USER -p
in mysql (with USER being your mysql user name), enter:
UPDATE system SET status = 1 WHERE name = 'block' OR name = 'user' OR name = 'node' OR name = 'filter';
and exit the mysql

NOTE: Is this the same as above and how do I do this via a GUI interface - php myadmin? (running MySQL5)

5) do not use firefox for the install

NOTE: I am currently using firefox 3.0.11 on OS X 10.4.11 for the install. I have safari on my machine and can download opera if that is indeed the fix. Or try to find a Windows machine & internet explorer? Is firefox indeed the problem?

6) install.includeusermodule.patch .

NOTE: Thanks for the patch. I have no idea where to put this however? Please clarify for those of us just dropping into the drupal community ... is this already included in 6.13?

Thank you so much. I apologize for my level of ignorance here but your assistance will be very much appreciated.

@careernerd

You can't mark something as 'too be ported' until it has been committed to HEAD.

If #73 is against HEAD, let testbot fire it and see how it goes. Once approved, we can backport. Otherwise, if the patch is for 6.x, keep the issue at 6.x.

@brautigan9

This is not the appropriate venue for you laundry list of problems, sorry.

The last submitted patch failed testing.

Fix at #40 worked for me. Thanks!

Same error, checking my apache error log shows several of these:

[Mon Aug 24 14:35:16 2009] [error] [client 123.xxx.66.xxx] ModSecurity: Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [file "/etc/apache2/modsecurity_crs/modsecurity_crs_21_protocol_anomalies.conf"] [line "41"] [id "960015"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER"] [hostname "www.domain.com"] [uri "/"] [unique_id "erWaoc-ASakAAHMePKIAAAAN"]

As mentioned in other posts, running this bit of SQL on the DB and trying again allowed me to proceed.

UPDATE system SET status = 1 WHERE name = 'block' OR name = 'user' OR name = 'node' OR name = 'filter';

Disabling mod_security on the server fixes the Problem for all Browsers.

Maybe this also works? I haven't tried it:
http://www.convolutedtheory.com/tech/mod_security-and-drupal-62-issues/

Hi,
I found the solution of this problem. Problem is user module in not enabled.
at the time on installation database creation script is not working properly.

Thanks
Faaiq

What's causing the user module to not be enabled though?

Sorry, not reading all 80 comments, just received this same error when doing a multi-site install.

Fixed the error by setting the Base URL in the settings.php

Same error installing D6.14 for a person that was having trouble:
Thanks for this thread! Site installed followed #39 and #40

TODAY 11/17/09

If installing a fresh 6.14 with Firefox 3.5.5 it always reports this problem:

Install: Call to undefined _user_password_dynamic_validation()

If I install with IE 6 there is no problem at all.