Can't Create First Account

Hey there, Don't feel like a tool :)

I'm not really sure why that's happening for you... Usually when you create the first account, it goes directly to a password change screen, thus bypassing the email registration.

One thing you can do, is if you have phpMyAdmin installed, you can log in and reset the admin user's password like this:

UPDATE `users` SET pass = MD5('password') WHERE uid=1;

Replace password with the password you want.

(Thanks to: drupal.org/node/113179)

BTW: Is drupal.org really really slow for anyone else this evening?

Just want to double check that you are following the link in the text that says "make first account" when you are doing this. (I don't have it in front of me, so I'm trying to do this from memory.) But read that text carefully. You should click on the link in the text rather than try to create a new account like any other new user would. That ought to work for you. You don't need email set up for that.

Steve
--
http://etmeli.us/ - photos, commentary, occasional sarcasm

My 5.1 installation was working fine for a while, then suddenly stopped letting me in -- I couldn't even create new user accounts when I set the first line of user_access() to return TRUE.

Completely clean 5.1 installs don't work either, now. Could it be a cookie issue? My first attempts to clear them selectively hasn't worked, but I'll give it another shot.

I had the exact same problem, and I was able to fix it by doing the following:

In the settings.php file for the site (sites/default/settings.php for most), near the bottom, there is an ini_set('session.cookie_domain') call, surrounded by some fancy parsing of $_SERVER['HTTP_HOST'] ...

if (isset($_SERVER['HTTP_HOST'])) {
  $domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']);
  // Per RFC 2109, cookie domains must contain at least one dot other than the
  // first. For hosts such as 'localhost', we don't set a cookie domain.
  if (count(explode('.', $domain)) > 2) {
    ini_set('session.cookie_domain', $domain);
  }
}

I commented out this entire block (use /* to start comment and */ to end it), and just manually set session.cookie_domain to my domain name (WITHOUT port #):

ini_set('session.cookie_domain', 'example.zapto.org'); // no http://, no :port#

Once you do this, I would recommend closing your browser if it is already open, just to make sure a new session is established next time you visit your site.

I have seen a bunch of threads about this problem, and the consensus always seems to be that it is a problem with cookies or sessions, but I have never seen anyone mention this setting. While other solutions work for some people, the problem seems to still be unsolved for many, and I hope this will help those folks like it helped me. I think the main issue is that the $_SERVER['HTTP_HOST'] variable contains the port number when it is non-standard (not port 80, like example.zapto.org:8000 or my.drupal.site:8080) and browsers don't like that in the domain attribute of the cookie that is sent to them. At least Firefox did not seem to be registering these cookies at all when PHP's session.cookie_domain attribute contained the port number. Changing it to include only the host name seems to do the trick.

If this doesn't work for you, I would at least recommend checking out your cookies (in Firefox, Tools...Options...Privacy...Show Cookies) and verifying that there is a cookie (for me, named "PHPSESSID") coming from the domain your Drupal site is on. That way, you can likely narrow it down to a cookies problem (or not).

-John

I had the exact same problem. Restarted a couple of times.

Last solution: I changed the function user_password(...) in /modules/user/user.module to return a constant value like this (end of function):

  //return $pass;
  return 'pw';

After that, dropping the database, recreating it with install.php, it worked - the function determines a password for a new user, which is now always 'pw'. Of course you have to reverse this change, otherwise all users will get the password 'pw'!

Funny enough, the behaviour of "create first user" changed as well - I think that should not be the case...

- Martin