'Notice: unserialize() [function.unserialize]: Error at Offset' when changing event dates

same error here at line 390 w/ drupal 5.10

I had the same problem . Check your drupal stauts report and check if the mbstring php module is installed on your server.
Hope this fix yours.

have this in Drupal 6 too. Did as described above (entered emailaddress) but that didn't fix the prob.

I found this error on different pages on my site. It comesh mostly at front page on my site, and when I refresh my page it automatically gone.
"Notice: unserialize(): Error at offset 80 of 1711 bytes in variable_initialize() (line 916 of /var/www/abc/includes/bootstrap.inc)"

The line which gives error in bootstrap.inc is
$variables = array_map('unserialize', db_query('SELECT name, value FROM {variable}')->fetchAllKeyed());
help me out

I had these 'strange' characters in my DB after migrating from one server to another and I was resolving it as Peter describes above. This will fix the problem but I will now describe how I stopped the problem occuring.

I found I had different DB and Table collations between my live and dev servers. Using PHPAdmin I simple changed the rogue collations (in my case I had some latin_swedish collations - I cannot explain why) so all the collations, for db and all tables, matched (in my case utf8_general_ci). I then re-exported and imported the db and problem solved!

Don't forget to back up your db before doing this!

Hope this helps, Phil

This happens when the data Drupal expects to unserialize doesn't match the data it does unserialize.

It's very unusual for this to happen in the normal course of events. It's much more likely to happen when you have migrated the database from one server to another, or backup-migrat'ed with a restore somewhere else, or mysqldumped and imported. In these cases it happens because the output format of the data from the original source doesn't match the input format.

If an export and import doesn't clear the problem, then the easiest solution for migration is to make sure that the process is UTF8-based from beginning to end, including the database connection. And be sure if you edit the export file before import that you either edit with a UTF8-based editor, or set the encoding to UTF8.

To do this you want the default character set on the server to be UTF8, and default collation to be utf8_general_ci. This is a setting in mysql.ini. Here's the nuclear option.

[mysqld]
default-character-set = utf8
character-set-server = utf8
collation-server = utf8_unicode_ci
init-connect = 'SET NAMES utf8'

[client]
default-character-set = utf8

[mysql]
default-character-set = utf8

[mysqldump]
default-character-set = utf8

You may consider removing the init-connect='SET NAMES utf8'. It automatically runs the SET NAMES to make the connection UTF8. But it's a little inconsistent. It doesn't run for users with SUPER privilege. Your root user is probably a SUPER. That's not your normal Drupal connection though. And if you use the database for more than Drupal, forcing the connection to UTF8 may be inappropriate.

Anyhow, for the purposes of pulling Drupal data in and out, you want any connection to be UTF8, so if write any custom PHP to manipulate the output you need to SET NAMES UTF8 COLLATION utf8_general_ci', either using the config file or by manually setting the data. If you are pulling data or pushing data using Drupal, the default connection for Drupal is to use UTF8, and the utf8 collation (if you haven't set another collation).

MySQL uses a hierarchy of encoding defaults - System > Database > Table > Column. Ideally you want to check all the way down for your database - that each table, and each column, is UTF8-based, but in practice it's unusual for Drupal data not to be. Pay special attention if you've manipulated tables by hand, or installed tables; if you didn't have the default set to UTF8 then you may have tables that are not UTF8. Older installations of MySQL and possibly Debian/Ubuntu may default to using latin1 and the latin1 swedish collation. If you find any non-UTF8 data, it's best to ALTER TABLE it. You can check the tables are UTF8 using 'SHOW TABLE STATUS' which lists all the tables, their encodings and collations.

Once you have the source data in UTF8, and the connection exporting the data in UTF8, you can export, using whatever method. For added pleasure, if you use mysqldump, you'll find some options to force UTF8 as default, though that should be set if you've altered your mysql config file and restarted mysql.

If exporting and importing in UTF8 still shows up a problem then you genuinely do have a serialization issue. You can fix them up by hand.

Include this code where you have the serialization error:

     $value = @unserialize($variable->value);
      if ($value === FALSE) {
        print 'unserialize : ' . $variable->name . '   |   ' ;        
      }
      else {
      
      $variables[$variable->name] = unserialize($variable->value); /* This line would be replaced by the normal line where the error is happening. */
      }

Don't use a call to the watchdog as suggested by an earlier comment because that may not yet be initialised, especially if your problem is in bootstrap. Use the print instead. This will list all the serialization problems. Remove this code after you've solved the problem.

Now, assuming there are only a few errors, you can fix them up by hand. Using mysql from the command line, check the value of a serialised value - e.g. if the problem is in the variables table
select * from variable where name="somestringvariable";
You'll see that you get output where the value is encoded as something like:
s:5:"hello"; which defines a string 'hello' having a length of 5. You get an serialization error when the string isn't the length expected. You would want to do something like selelect length(value) from variable where name="somestringvariable"; and then you'd do something like update variable set value=replace(value,"s:5923:","s:5881:") where name="somestringvariable"; In this example, 5923 is the length that the serialization thinks it has, and 5881 is the value you calculated by taking the actual length and subtracting 9 (i.e. the length of 's:5881:""').

Or maybe you see
b:0; which is a binary encoding for false. But unserialize seems not to reliably work on this for some versions of PHP. So you can update with i:0; which is an integer of 0, or false in PHP.

Similar tricks can be used for any other odd values - experiment by printing the serialized values of variables, to see what the encoding is.