Oops, deleted super user Drupal 6, what to do? maybe you emptied user table?

I left my thinking cap off and emptied the user table of a dev Drupal 6 site I was working on. If that happens to you, just access your database with phpMyAdmin or similar, and:

INSERT INTO users (uid, name, pass) VALUES ('1', 'yourname', md5('yourpassword'));

then edit the users table further to add your email address and set status = 1.

Drupal 6 Programmatically Create Users

How to programmatically create new users in Drupal 6:

'pass' => 'password', // note: do not md5 the password
'mail' => 'email address',
'status' => 1,
'init' => 'email address'
user_save(null, $newUser);

To update an existing user:

some_property = 'what_you_want_to_set_it_to';

// save existing user
user_save((object) array('uid' => $existingUser->uid), (array) $existingUser);

HerpCount.org – a new site for citizen science in Herpetology

Working with Phil Rosen, Kevin Bonine, Julia Fonseca, and Brian Powell, I have in my free time developed a cool site for citizen herpetologists. It enables citizen scientists to contribute observational data on herps of southern Arizona. In the next few months, we hope to add iPhone and Android applications to it, and to make many improvements to the site. We also want to expand its scope both geographically and taxonomically.

Check it out – HerpCount.org.

We have even gotten some press on it already, for example, here: article on HerpCount.

No one can log in to Drupal, several possibilities why

You have a Drupal site that is working fine, and then you discover it seems like all of a sudden, no one can login.

This happened to me, and it turned out to be connected to setting the cookie domain in the settings.php file. I set it at FCK Editor’s bequest. And then all heck broke loose, no one could log in. Commenting out the cookie domain line in the settings.php file solved the problem.

If you are moving between production and development versions of a site, then also check the cookie domain setting the sites/default/settings.php is correctly set for each installation.

Another time, it was connected to a cookie domain issue in which Drupal had upgraded how cookies were handled, and if the cookie domain line was set, users had to delete their old cookies in order to be able to log in. I think this happened around the updates somewhere between Drupal 6.16 to 6.20.

It looks in general like if you are experiencing this issue, no one can login, and it is not the cookie domain issue I had, then investigate as such:

i.e. other things to potentially try:

repair your database tables with phpMyAdmin or similar, in particular, the Sessions table. Empty your cache tables – this unlikely to be relevant, but heh I just like clearing them out, it makes me feel good, like everything feels neater and tidier that way 🙂 Delete the browser cookies associated with the site in question.

Most likely it is cookie related somehow.

Any one else have this problem, and it be a different fix? Please comment and let us know…

How To Move Your Drupal or WordPress Web Site to Amazon EC2 and Get Free Fast Hosting for a Year

Tired of slow shared hosting? Now you can move your Drupal or WordPress web site to Amazon’s EC2 cloud services, and you can even get free hosting for a year! That’s because Amazon has a deal going on to attract new users – they call it their free tier deal. Check it out, sign up.

Amazon’s EC2 service lets you create virtual servers of your own in their cloud. They have since added EBS (Elastic Block Store) and it is the addition of EBS that makes them very attractive for hosting your typical WordPress or Drupal web site, because it gives you persistent storage. The free deal is for running a single micro instance. A micro instance provides nominal computing power all of the time, with the ability to jump up to 2 EC2 Compute Units on demand, and 613 MB of memory. A normal small instance gives 1 EC2 Compute Unit all the time, along with 1.73 GB of memory. A small instance is not free, runs about $80 a month for most after it is all said and done. But the micro instance is great for most sites. I am running four low-traffic WordPress sites and 2 decent traffic Drupal sites on one micro instance, and I get fast page loads — I am very pleased. All told I only see about 1000 page views a day, but on shared hosting all I had was trouble and slow loading pages. And free for a year with low rates after that? Who can complain? Well, there is a downside. You have to configure and manage your server. It is not like with shared hosting where they have everything mostly set up for you.

But managing your own server is not that hard if you are interested in it at all. Setting up a mail server was the hardest part for me. And I detail all the steps below, for your reference, and as I future reference for myself. To save time, I refer you to other guides I used for parts of it.

So you signed up at http://aws.amazon.com/free/ – once you get your emails back from Amazon saying you are good to go, then it is time to log in to the AWS Management Console. Go here: http://aws.amazon.com/console/ and click on the button on the right side to sign in (choose the EC2 popdown next to the button).

First set up a security group. This is like a firewall setup. You’ll want to add SSH for port 20, for SSH access to the server. And you’ll want http access on port 80, and possible https access on port 443. Refer to the section “Setting up a security group” on this guide for more information.

Next, choose Key Pairs from the side bar menu and create a new key pair. This is used for authentication when SSH’ing into your server. More secure than password based authentication. For more info, see “Setting up your AWS account and tools” section in this guide. Save your key pem somewhere where you will not be likely to delete it on your computer.

Note, if setting up a micro instance, the guide I refer to above has information you should not follow about setting up persistent storage, because that article was written before EBS became available.

Now it is time to pick an AMI – Amazon Machine Image. This is like your virtual servers set up – what version or distribution of Linux you want to use, all ready to go. An Amazon Machine Image (AMI) is an encrypted machine image that contains all information necessary to boot instances of your operating system and software. For example, an AMI might contain all the software to act as a web server (e.g., Linux, Apache, and your web site). I went with Ubuntu Lucid LTS. Ubuntu is popular, well supported, and I like that they make long term support versions catering to web server use. From Amazon’s Help Guide:

To use Amazon EC2, you launch one or more instances of an AMI. An instance might be one web server within a web server cluster or one Hadoop node.

When launching AMIs, you can select an Amazon-provided AMI, a public AMI that another Amazon EC2 user provided, or an AMI that you create.

An Amazon EC2 instance can be launched from an AMI backed by either Amazon S3 or by Amazon EBS. Instances launched from AMIs backed by Amazon S3 use the local instance store as the root device (e.g., / or C:). An instance launched from an AMI backed by Amazon EBS uses an Amazon EBS volume as its root device.

I used ami-3e02f257. Make sure you pick an EBS (Elastic Block Store) version of an ami – micro instances require it.

More to come…

Put a project into git version control, with central svn style repository, + Drupal notes

Git is distributed and wonderful. Svn kinda sucks. But often you still want to sort of think of your git setup as having a one central bare repository, and git does that. Steps to set-up, for your reference and mine, follow:

Go to the base root directory of your project and type:

$ git init
$ git add .
$ git commit -m "initial commit"

now your project is under git’s purview.

$ git branch

and you see you have one branch named master that was auto-created by the git init and commit process above.

Now go to wherever you want the bare (central) repository to be.

$ mkdir my_repository.git
$ cd my_repository.git
$ git --bare init
Initialized empty Git repository in /home/git/my_repository.git
$ exit

your bare repository is set-up, simple as that, but now you need to push all the files into it:

First check and see if you have any remote repositories being tracked locally:

$ cd ~/Sites/myapp
$ git remote

None came up, good.

We already looked at local branches:

$ git branch
* master

Just one branch, the master branch that is auto-created by git when you did init/commit above.

Check .git/config:

$ cat .git/config
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

Now, push from your project to the bare repository:

First, let your local know about the remote (bare):

$ git remote add origin ssh://myserver.com/home/git/my_repository.git

Check your config file again ($ cat .git/config) and you will see new lines for the remote named origin.


$ git push origin master

All set. Now you can have others pull from the bare main repository, e.g.:

$ git clone ssh://username@myserver.com/home/git/my_repository.git


in Drupal, you probably do not want settings.php and .htaccess included in the repository. Depending, you might also want to include sites/default/files as an ignore directory. Really, should of done this much earlier, before we added files into git. also, note: To stop tracking a file that is currently tracked, use git rm --cached filepathname.

To ignore files, like svn propset ignore, go edit the exclude file to add in the file paths with wildcards that you wish git to ignore:

$ vim .git/info/exclude


-bash-3.2$ cat .git/info/exclude
# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~