Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Fatal error: Call to undefined function: _user_password_dynamic_validation() in install.php on line 710
This happens after installing a fresh copy of 6.0-rc1 after supplying the DB credentials.
Environment:
PHP 4.4.7
MySQL 4.1.22-standard
The URL with the error is: /install.php?profile=default&locale=en
Comment | File | Size | Author |
---|---|---|---|
#73 | install.includeusermodule.patch | 1.05 KB | Jon Pugh |
Comments
Comment #1
karenm CreditAttribution: karenm commentedalso 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.
Comment #2
karenm CreditAttribution: karenm commentedIf 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.
Comment #3
Gábor HojtsyWell, 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.
Comment #4
velankar CreditAttribution: velankar commentedI 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.
Comment #5
agentrickardRunning 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.
Comment #6
velankar CreditAttribution: velankar commentedI 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
Comment #7
ScoutBaker CreditAttribution: ScoutBaker commentedI 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.
Comment #8
gregglesI 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.
Comment #9
agentrickardFor 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.
Comment #10
velankar CreditAttribution: velankar commentedYour 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.
Comment #11
C0BALT CreditAttribution: C0BALT commentedduring 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 /
Comment #12
gregglesSo, the commonality seems to be 4.4.4.
@agentrickard - what is your php version? can you test with 4.4.4?
Comment #13
ScoutBaker CreditAttribution: ScoutBaker commented@greggles - the OP listed PHP 4.4.7 (which happens to be the version I also tested on).
Comment #14
agentrickard@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?
Comment #15
dgen CreditAttribution: dgen commentedHi,
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
Comment #16
C0BALT CreditAttribution: C0BALT commentedI 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.
Comment #17
Gábor HojtsyCOBALT: 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.
Comment #18
C0BALT CreditAttribution: C0BALT commentedI 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
Comment #19
karenm CreditAttribution: karenm commentedAlright. 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.
Comment #20
Gábor HojtsyHm, 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).
Comment #21
Fool2 CreditAttribution: Fool2 commentedTry 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.
Comment #22
Gábor HojtsyWell, 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.
Comment #23
gregglesIf this change fixes it then what about including it but commenting it out and including a link to a handbook page?
Comment #24
Fool2 CreditAttribution: Fool2 commentedI'd wait to see if anyone else can actually confirm its effectiveness.
Comment #25
C0BALT CreditAttribution: C0BALT commentedI 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
Comment #26
Fool2 CreditAttribution: Fool2 commented403 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
Comment #27
riskone CreditAttribution: riskone commentedI 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.
Comment #28
riskone CreditAttribution: riskone commentedThe Apache version is 1.3.34
Comment #29
Morn CreditAttribution: Morn commentedSame worked for me (#27) : Apache/2.0.55 (Debian), PHP 5.1.6-1
Comment #30
grobe CreditAttribution: grobe commentedOk, 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.
Comment #31
sgtaw CreditAttribution: sgtaw commentedI had the same errors...
I tried "SecFilterEngine Off" in the .htaccess and it worked!
Thanks Fool2 for the suggestion!
Comment #32
grobe CreditAttribution: grobe commentedSo 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.
Comment #33
adencomp CreditAttribution: adencomp commentedCould 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
Comment #34
adencomp CreditAttribution: adencomp commentedWell, 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.
Comment #35
adencomp CreditAttribution: adencomp commentedWell, 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...
Comment #36
grobe CreditAttribution: grobe commentedEnvironment:
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.
Comment #37
Fool2 CreditAttribution: Fool2 commentedHello
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)
Comment #38
jdp CreditAttribution: jdp commentedI'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
Comment #39
adencomp CreditAttribution: adencomp commentedFool2, 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.
Comment #40
canyonhp CreditAttribution: canyonhp commentedthank 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!
Comment #41
keith.smith CreditAttribution: keith.smith commentedComment #42
sillhuwet CreditAttribution: sillhuwet commentedAdding SecFilterEngine Off worked for me too.
PHP Version 4.4.8
MySQL 4.1.14
Comment #43
Krummrey CreditAttribution: Krummrey commentedI'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.Comment #44
Steel Rat CreditAttribution: Steel Rat commentedI 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
Comment #45
Frameshift CreditAttribution: Frameshift commentedI 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
Comment #46
tobbe_s CreditAttribution: tobbe_s commentedFollowing the guidelines in #40 worked for me on shared hosting. Thanks for that.
Comment #47
DoctorMike CreditAttribution: DoctorMike commentedVer 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
Comment #48
craigcarboni CreditAttribution: craigcarboni commentedGetting 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.
Comment #49
Krummrey CreditAttribution: Krummrey commentedChanging 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.
Comment #50
yngens CreditAttribution: yngens commented#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
Comment #51
kulfi CreditAttribution: kulfi commentedJust 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.
Comment #52
grobe CreditAttribution: grobe commentedIt 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...
Comment #53
alm06130 CreditAttribution: alm06130 commentedSame 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 ...
Comment #54
commerce CreditAttribution: commerce commentedopen the system database table and change 4 modules's status to "1"
(user, node, filter, block)
#40 - WORKS FOR ME. Thanks
Comment #55
Steel Rat CreditAttribution: Steel Rat commentedFYI, 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.
Comment #56
c960657 CreditAttribution: c960657 commentedIf 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.
Comment #57
Saulo CreditAttribution: Saulo commentedFollowing the guidelines in #40 worked for me too. Thanks for that.
Comment #58
patataur CreditAttribution: patataur commentedI 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
Comment #59
davidburnsI 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
Comment #60
axyjo CreditAttribution: axyjo commentedOkay. 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:
I ran that file using a web browser. After it finished executing, Drupal started working again. I'm not sure of the equivalent for Drupal 6.
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
Comment #61
bbeyer CreditAttribution: bbeyer commentedI just tried a fresh install of 6.9 and received this error. I amnually enabled the user module using MySQL and then it worked.
Comment #62
asak CreditAttribution: asak commentedWow. 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...
Comment #63
kakor CreditAttribution: kakor commentedI 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.
Comment #64
asak CreditAttribution: asak commentedThanks kakor!
Weird problem...
Comment #65
oradoe CreditAttribution: oradoe commentedSimply add this line of code after "<?php"
require_once './modules/user/user.module';
Good luck
Comment #66
DrupalDope CreditAttribution: DrupalDope commentedThis 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.
Comment #67
magicbank CreditAttribution: magicbank commented#66 Confirm
IE7 WORK!
I think this problem occur by AJAX request in Firefox.
Comment #68
MoonchildCH CreditAttribution: MoonchildCH commentedI 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.
Comment #69
langelino CreditAttribution: langelino commentedSame 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
Comment #70
Steel Rat CreditAttribution: Steel Rat commentedFWIW, I've performed a couple new installs since I posted here, and have not seen this problem again.
Comment #71
meetsang CreditAttribution: meetsang commentedPHP Version: 5.2.5
Installed on root.
Same Error.
Installed on a subdirectory.
same error.
Followed #40
Error resolved!!!!
Thanks.
Comment #72
Zarevac CreditAttribution: Zarevac commentedI can report the same issue as well, it does not matter though which browser I use....
Comment #73
Jon Pughpatch submitted.
Also adds the include_once() line to install_configure_form, which was throwing errors about the missing USER_ constants.
Comment #74
Jeff Burnz CreditAttribution: Jeff Burnz commentedConfirmed 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.
Comment #75
brautigan9 CreditAttribution: brautigan9 commentedHi,
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.
Comment #76
agentrickard@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.
Comment #78
leingang CreditAttribution: leingang commentedFix at #40 worked for me. Thanks!
Comment #79
flickerfly CreditAttribution: flickerfly commentedSame 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';
Comment #80
derjochenmeyer CreditAttribution: derjochenmeyer commentedDisabling 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/
Comment #81
faaiqsj CreditAttribution: faaiqsj commentedHi,
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
Comment #82
axyjo CreditAttribution: axyjo commentedWhat's causing the user module to not be enabled though?
Comment #83
coderintherye CreditAttribution: coderintherye commentedSorry, 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
Comment #84
dbeall CreditAttribution: dbeall commentedSame error installing D6.14 for a person that was having trouble:
Thanks for this thread! Site installed followed #39 and #40
Comment #85
freddym CreditAttribution: freddym commentedTODAY 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.
Comment #86
benjaminsalka CreditAttribution: benjaminsalka commentedI have also gone through every post on this page and haven't nipped it in the bud yet.
Changing the status on the modules in the systems folder seems to be working for most people, but the status on all mine are fine, so I can't figure out where the error is coming from.
Comment #87
flickerfly CreditAttribution: flickerfly commented@freddym To the best of my understanding, it is the generally accepted procedure of Drupal to mark the version of the highest affected version.
@faaiqsj You didn't resolved the problem, nor provide information that wasn't provided above. Since you haven't provided a patch to resolve the isssue for several months, I'm pulling assignment so others don't think they shouldn't take a look at it.
Comment #88
jpoesen CreditAttribution: jpoesen commentedThis is just too weird.
Tried:
- installing D6.16 with drush 6.x-3.x-rc3
- installing D6.16 manually (old skool wget-style)
- installing Managing News beta 8
Got hit by this bug on Chrome (build 5.0.342.9) on OS X (10.5.8), but *not* on Firefox 3.6.3.
--> see comment #85 where this occurs on Firefox but not on IE...
Here be much weirdness.
Comment #89
zenlan CreditAttribution: zenlan commentedDownloaded: http://ftp.drupal.org/files/projects/drupal-6.16.tar.gz
...
Installing on Server: Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i mod_autoindex_color PHP/5.2.8
Chrome: 4.1.249.1064 (45376): After set up database -> Fatal error: Call to undefined function _user_password_dynamic_validation() in
install.php on line 733
Firefox 3.6.3: No problems, good install.
After installing via Firefox I am able to log in via Chrome and all seems well. So far.
...
Installing on Server: Apache/2.2.14 (FreeBSD) mod_ssl/2.2.14 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.12
Chrome: 4.1.249.1064 (45376): No problems, good install.
Firefox 3.6.3: Didn't try
Comment #90
madth3 CreditAttribution: madth3 commentedJust adding my case since the error was the same and I solved it with the comment 83
Drupal 6.17
Apache 2.2, Mysql 5.1 and PHP 5.2 although I don't believe those were relevant.
No mod_security installed
OpenSuSE 11.
My condensed experience:
(each try started from zero, files from tar.gz and clean database)
In my case, I believe the problem was being caused because the target machine is behind a proxy and the URLs generated by the installation script were wrong. So maybe the root cause is not the same as previous cases but the effect was the same: some calls not being done or executed properly during installation and leaving the database in an inconsistent state.
Comment #91
CasaDelGato CreditAttribution: CasaDelGato commentedI just ran into this problem as well while setting up a new subdomain on a multi-site install.
My base_url was already set.
I did the changes from comment 40, and then the install completed normally.
Comment #92
lasr CreditAttribution: lasr commentedIncredible! in IE7 works ... hahaha
Big Bill!
Comment #93
zainykhas CreditAttribution: zainykhas commentedHi,
I am trying to install Drupal 6.19 on a shared domain www.example.com/abc where "/abc", "/efg", and "/wxy" each refer to different websites. This is what I believe the above comments refer to as shared domains.
Now, I have modified the settings.php and htdocs as advised in the comments above but I still get the same error of
Fatal error: Call to undefined function _user_password_dynamic_validation() in /home/www/htdocs/guilds/eesoc/install.php on line 733
Can anyone advise me what else do I need to modify apart from the settings.php and htdocs. I have even changed three browsers (Chrome, Firefox, and IE)
Thanks
Comment #94
David_Rothstein CreditAttribution: David_Rothstein commentedThis issue apparently exists in Drupal 7, and there's a patch in #73.
Trying to give it a more comprehensive title, also. If you look through the forums and lots of closed/unreproducible issues in the queue, it seems these kinds of errors are happening in a variety of situations. We need to get to the bottom of why the user module isn't loaded sometimes.
Comment #95
David_Rothstein CreditAttribution: David_Rothstein commentedFrom looking at the patch I can tell it won't apply anymore (would need a reroll).
It also would be nice to figure out the root cause; explicitly loading those files in those places really seems like it shouldn't be necessary.
Comment #96
leilyrken CreditAttribution: leilyrken commentedProblem met with 6.19, fixed by setting the base_url and restarting the installation (after a drop/create of the db)
Comment #97
Anonymous (not verified) CreditAttribution: Anonymous commentedMuchas Gracias!
Con esto resolví el problema.
Thank you "adencomp" and "canyonhp".
All Works Well!
Comment #98
agentrickardThe fact that hacking settings.php after creation "fixes" the issue does not mean the problem has been solved.
Please do not adjust the version. This needs fixing in D7.
Comment #99
teknikqasubscribing
Comment #100
The New B CreditAttribution: The New B commentedI'm afraid I got stuck with the same problem using the Web scripts installer (similar to Installatron) on a shared host (Linux, MySQL 5, PHP 5). I can't tell what version of Drupal it's offering, but it's likely to be a recent one.
Fatal error: Call to undefined function _user_password_dynamic_validation() in /var/www/[....]/install.php on line 733
The possible solutions which have been offered thus far include:
1. In .htaccess, add "SecFilterEngine Off"
2. In .htaccess, modify RewriteBase /[...] if the database is installed in a subdirectory, and remove #
3. trying a browser other than Mozilla Firefox, preferably Internet Explorer
4. Solution #40: changing the module status for Block, Filter, Node, and User modules in the System database table from 0 to 1.
However:
1. produces a server error; I also tried wrapping Ifmodule tags around it, but this has no effect.
2. nothing.
3. nothing
4. Where exactly are we supposed to find the "system database table"? My hosting provider has given me PHPmyadmin. Would that do or would I need to have direct access to a MySQL client (which I don't)?
Regards
Comment #101
The New B CreditAttribution: The New B commentedOh well, using another (presumably more advanced) web script installer seems to have solved the problem for me.
Comment #102
David_Rothstein CreditAttribution: David_Rothstein commentedComment #103
Eduardo Romero CreditAttribution: Eduardo Romero commentedI just experienced this error on a 6.20 (and 6.19 install). It worked once i set $base_url in sites/default/settings.php, cleared the database tables and run the install again.
Comment #104
ramiroque CreditAttribution: ramiroque commentedhad the same problem.... I was using Google Chrome and it didn't work.
Worked when I used Internet Explorer .... (IE is good for something after all)
Comment #105
lucyconnuk CreditAttribution: lucyconnuk commentedHad same problem with fresh install of 6.22. I was using Firefox
Dropped all my database tables and tried again using IE - this time no problems.