Skip to main content

Drupal 7 notes: unserialize() and undefined index notices after importing users from a csv

Posted on: Tuesday, 24 May 2011 @ 10:31pm
Blatting about
More specifically

Long title is going to break my pretty layout.

So following on from the task of having to import a csv file of users into Drupal 6, I upgraded that install of Drupal 6 to 7, then exported the users, user roles and role tables into csv files for insertion into the database at work.  Of course I had to test it out on my local to make sure nothing was too broken.

Drupal 7 unserialize() and undefined index errors

Yeh right.

I discovered the source of the "Notice: Undefined index: 127 in user_admin_account() (line 212 of [...]/modules/user/" problem first, only because I noticed on the people listing that everybody's status was blank (it's supposed to say "active" or "blocked"). 

The database had decreed that everyone's status was 127, the source of that mysterious number.

Drupal 7 incorrect status in database

I can honestly say I have no freaking idea where the 127 came from.  It's a very simple fix of:

update `users` set `status`=1;

in the SQL tab of the offending table.

Drupal 7 sql command to fix the incorrect values in the status column

The "Notice: unserialize(): Error at offset 0 of 1 bytes in UserController->attachLoad() (line 288 of [...]/modules/user/user.module)" error was a bit trickier to track down.  After I failed at finding anyone else with my particular problem (everyone else's was related to I suddenly had the bright idea of doing the thing I should have done first and comparing the database I'd exported from to the one I was working with.

The "init" column of the one I'd upgraded was filled with Stuff:

Drupal 7 weird init column

In the one I'm working on, everything except the dummy email address I set up local devs with was set to 0.  They are in the csv file but they're not being imported.

The easiest thing I can think of to do would be to just dump the user table and import it into the one I'm working on, but that doesn't solve the import-from-csv problem and I think I will need to solve it that way as at work we've already gone through a lot of fun and games (not) failing at converting an existing MySQL database to PostgreSQL and opted to just do a fresh install on the PostgreSQL server.  Fortunately all I had to redo were the menus at that stage.

Until I find a better way, it looks like manual editing 89 records for me.  What fun.

Edit 25/05/11: I now suspect that the unserialize error is being caused by the fact that for some obscure reason, the picture column is in the wrong place.  In the database I dumped from, it's the last column.  In the database I imported into, it's the third last.  I have no idea why it did that as it's in the correct position in the cvs file.  Could be a fun one to solve so hoping it's a deceptively easy fix.

Also, I have no idea why I didn't notice it when I was comparing the databases before.

No comments yet

Bryan Casler Monday, 30 May 2011 @ 2:44am [Permalink]

Hi, I'm just wondering if you were able to figure this out. I just had someone do a D6->D7 migration for us and now this is popping all over. Like your update, I'm almost certain it's related to the user image.

bek Monday, 30 May 2011 @ 10:18am [Permalink]
Bryan Casler Tuesday, 31 May 2011 @ 5:40am [Permalink]

Thanks Bek, I'm still working on this issue. Appreciate the feedback.

Kasiretz Saturday, 10 November 2012 @ 3:29pm [Permalink]
I'd like to affirm hello to the forum - I justifiable ascribe to the corresponding in every respect forum so in another situation and things being what they are I'll appraise senseless to zip down something. Wonderful Regards

Add new comment

The content of this field is kept private and will not be shown publicly.