On a live server (problem never occured on development server) all events created using Events module have reset to 1 Jan 1970 and any attempt to change them fails and gives this error:

Notice: unserialize() [function.unserialize]: Error at offset 1016 of 1016 bytes in /home/fhlinux166/w/womeninjournalism.co.uk/user/htdocs/includes/bootstrap.inc on line 390

Having tried updating Events to dev version and then changing it back to same version on dev server, I am convinced this is a server / Drupal issue rather than the module itself.

Does anyone know what is causing this? Googling the problem gives a wide variety of reasons but nothing I can pinpoint. I'm not a PHP developer so this isn't really my strong point....




darumaki’s picture

I get the error and haven't found any posts about it

dharmanerd’s picture

same error here at line 390 w/ drupal 5.10

aangel’s picture


seems to have an solution, but haven't investigated yet

jc.vdb’s picture

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.

arnaudfischer’s picture

Just installed the Acquia stack and seeing the same message. Clearing the cache did not solve. The fix is in [Site Information] http://www.doitwithdrupal.com/2008/sessions/basecamp-built-drupal . I completed the info, ie Site Name and email address and the message seems to have gone away.

sunchaser’s picture

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

mahnster’s picture

I have this problem too. I am programming a module, made a menu option for admin/settings/my_email and calls the form creation function in my_email.admin.inc, and that looks fine, but when I enter the values I want to save, I get:

Notice: unserialize() [function.unserialize]: Error at offset 1480 of 2307 bytes in /var/www/vhosts/richmahn/subdomains/new/httpdocs/includes/bootstrap.inc on line 478

Notice: unserialize() [function.unserialize]: Error at offset 1677 of 2504 bytes in /var/www/vhosts/richmahn/subdomains/new/httpdocs/includes/bootstrap.inc on line 478

However, the fields in the form do save (i.e. can retrieve with variable_get()) Any thoughts?

dedybear’s picture

This error occurs when there is a character or characters within your array that you would like to serialize that will mess up the serialized string. The one that usually kills people is the ampersand. Here is a quick solution.

Add these functions:

function formatSerialize(&$strItem, $strKey)
    $strItem = str_replace('&', '[amp;]',$strItem);
function formatSerializeRev(&$strItem, $strKey)
    $strItem = str_replace('[amp;]', '&',$strItem);

Now that you have these in place, just before your serialize your array:
Run the following: (This is assuming your array variable name is $arrMenu)

$strSerialized = serialize($arrMenu);

once you have successfully unserialized your array, you can run the other:

$arrMenu = unserialize($strSerialized);

Good luck,


somesh50’s picture

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

bekie’s picture

Hi guys,

I had the same error on my site after migrating it to another server. (=> mysqldb : export - import)
after that i got this error, pinpointing this line (third one):

    $result = db_query('SELECT * FROM {variable}');
    while ($variable = db_fetch_object($result)) {
      $variables[$variable->name] = unserialize($variable->value);

via phpmyadmin i took a peek in the DB of my site in the variables table and one of the variables (footer variable) had some strange characters in it. After removal of these characters everything worked fine again. I guess somewhere along the export-import procedure the "é" character changed into two strange characters with which the unserialize function had serious problems ;)

i'm not saying that everybody's unserialize error can be solved by messing around in the variables table. You should start by looking into the bootstrap.inc file on the specified line to see what it is the unserialize function is trying to unserialize. Then you should try to find out where that data is coming from, and correct it.

Good luck everybody,

Peter Verbeek.

PhilDHD’s picture

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

federico’s picture

Thanks! I'm trying to do this but its very tedious using phpmyadmin (you have to go to each table, select every column...). For D6 there is the DB tuner module

Unfortunately I'm on D7, so i ran

a code to change all tables to utf8_general_ci

Now, every table is utf8_general_ci

Anyway, I'm still getting this error

Notice: unserialize() [function.unserialize]: Error at offset 256 of 337 bytes en UserController->attachLoad() (línea 288 de /var/www/modules/user/user.module).

Edit: I removed the code, because it brought other dangerous issues, I had to restore a backup

Anonymous’s picture

Notice: Undefined index: required in field_multiple_value_form() (line 207 of /Applications/MAMP/htdocs/sitename/modules/field/field.form.inc).

Listed as a php type by the Database logging module. Ran /update/php followed by initiating a cron run.

Looks like it worked. Can't get the notice reappear.

Tied up with other projects. Just got back to this and found it didn't work as first thought still have a problem. Now changed to:

Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of /Applications/MAMP/htdocs/sitename/modules/field/field.info.inc).

Problem cleared by clearing email as suggested by Arnaud Fischer's above post. Thanks Arnaud.

agungsuyono’s picture

In my case, I just re-export data from 'variable' table in the first site and then re-import again in the second site, and that's solved the problem.

Jeff Veit’s picture

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.

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

default-character-set = utf8

default-character-set = utf8

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.

adolf.mrls’s picture

i cant fix this :
a:68:{s:23:"skip_navigation_display";s:5:"focus";s:18:"breadcrumb_display";s:3:"yes";s:20:"breadcrumb_separator";s:8:"»";s:15:"breadcrumb_home";i:0;s:19:"breadcrumb_trailing";s:1:"0";s:16:"breadcrumb_title";s:1:"0";s:25:"display_search_form_label";i:1;s:14:"search_snippet";i:1;s:16:"search_info_type";i:1;s:16:"search_info_user";i:1;s:16:"search_info_date";i:1;s:19:"search_info_comment";i:1;s:18:"search_info_upload";i:1;s:21:"search_info_separator";s:3:" - ";s:18:"extra_page_classes";i:0;s:21:"extra_article_classes";i:0;s:21:"extra_comment_classes";i:0;s:19:"extra_block_classes";i:0;s:18:"extra_menu_classes";i:0;s:23:"extra_item_list_classes";i:0;s:18:"primary_links_tree";i:0;s:20:"secondary_links_tree";i:0;s:23:"links_add_span_elements";i:0;s:12:"at_user_menu";i:0;s:16:"block_edit_links";i:1;s:16:"rebuild_registry";i:0;s:13:"layout_method";s:1:"1";s:12:"layout_width";s:5:"960px";s:26:"layout_sidebar_first_width";s:3:"240";s:25:"layout_sidebar_last_width";s:3:"240";s:22:"layout_enable_settings";s:2:"on";s:19:"layout_enable_width";s:2:"on";s:22:"layout_enable_sidebars";s:2:"on";s:20:"layout_enable_method";s:2:"on";s:22:"equal_heights_sidebars";i:0;s:20:"equal_heights_blocks";s:1:"0";s:21:"equal_heights_gpanels";i:0;s:22:"horizontal_login_block";i:0;s:29:"horizontal_login_block_enable";s:2:"on";s:13:"style_schemes";s:17:"style-default.css";s:20:"style_enable_schemes";s:3:"off";s:7:"mission";s:0:"";s:12:"default_logo";i:0;s:9:"logo_path";s:30:"sites/sfnewtech/files/logo.png";s:15:"default_favicon";i:1;s:12:"favicon_path";s:0:"";s:13:"primary_links";i:1;s:15:"secondary_links";i:1;s:11:"toggle_logo";i:1;s:14:"toggle_favicon";i:1;s:11:"toggle_name";i:0;s:13:"toggle_search";i:1;s:13:"toggle_slogan";i:1;s:14:"toggle_mission";i:1;s:24:"toggle_node_user_picture";i:1;s:27:"toggle_comment_user_picture";i:1;s:20:"toggle_primary_links";i:1;s:22:"toggle_secondary_links";i:1;s:11:"logo_upload";s:0:"";s:14:"favicon_upload";s:0:"";s:20:"equalize_leaderboard";i:0;s:15:"equalize_header";i:0;s:26:"equalize_secondary-content";i:0;s:20:"equalize_content-top";i:0;s:23:"equalize_content-bottom";i:0;s:25:"equalize_tertiary-content";i:0;s:15:"equalize_footer";i:0;s:17:"exported_settings";s:1467:"settings[skip_navigation_display]="focus" settings[breadcrumb_display]="yes" settings[breadcrumb_separator]="»" settings[breadcrumb_home]="0" settings[display_search_form_label]="1" settings[search_snippet]="1" settings[search_info_type]="1" settings[search_info_user]="1" settings[search_info_date]="1" settings[search_info_comment]="1" settings[search_info_upload]="1" settings[search_info_separator]=" - " settings[extra_page_classes]="0" settings[extra_article_classes]="0" settings[extra_comment_classes]="0" settings[extra_block_classes]="0" settings[extra_menu_classes]="0" settings[extra_item_list_classes]="0" settings[primary_links_tree]="0" settings[secondary_links_tree]="0" settings[links_add_span_elements]="0" settings[at_user_menu]="0" settings[block_edit_links]="1" settings[rebuild_registry]="0" settings[layout_method]="0" settings[layout_width]="960px" settings[layout_sidebar_first_width]="240" settings[layout_sidebar_last_width]="240" settings[layout_enable_settings]="on" settings[layout_enable_width]="on" settings[layout_enable_sidebars]="on" settings[layout_enable_method]="on" settings[equal_heights_sidebars]="0" settings[equal_heights_blocks]="0" settings[equal_heights_gpanels]="0" settings[horizontal_login_block]="0" settings[horizontal_login_block_overlabel]="" settings[horizontal_login_block_enable]="on" settings[style_schemes]="style-default.css" settings[style_enable_schemes]="off" ";}

all s:n:"xxxx" have the appropriate size , but i don't know what happen ...
help pls...

markosaurus’s picture

Use this module;


You have a variable in your system table which should have been removed by an uninstalled module which didn't clean up after its self when it uninstalled. The variables are now meant to be serialized in the DB (stored as BLOB) but your rogue elements aren't.

Use this to check which ones are causing it and remove them, then let the module owners know so they can clean up better on uninstall :)

Miranda_NS’s picture

I occasionally get this error when moving sites between servers. In my case, it's caused by MySQL "thinking" the sql file I restore the database from is LATIN instead of UTF-8 encoded. I think this happens because I use different versions of MySQL on different servers.

This is easily fixed by opening the text file in a text editor and explicitly saving it with UTF-8 encoding (I use Sublime) before opening it in MySQL.