Back to top

Very irritating Notice: unserialize() [function.unserialize]: after you setup an existing Drupal site

Recently, I started work on a site which was setup using tar ball & DB that was recived from another developer. As usual we put the site on one of our servers, only to realize that all the pages were displaying a humungous list of errors. Well technically they were PHP Notices but if you are purist like me, they are as anoying as errors or warnings.

All errors were of the same kind, here are some,

Notice: unserialize(): Error at offset 593 of 1753 bytes in EntityAPIController->load() (line 261 of /var/www/obfdrupal/sites/all/modules/entity/includes/

Notice: unserialize(): Error at offset 47 of 1207 bytes in DrupalDatabaseCache->prepareItem() (line 434 of /var/www/obfdrupal/includes/

As you can see, all were being caused due to a unserilze(). 

So as usual I started searching for a solution for the problem, to be accurate I searched for what causes such errors after drupal is migrated from one environment to another. The primary cuase of these errors is stale & ugly varibales in the DB. Among many new things in Drupal 7, one of them was how theme and module configurations are stored. Drupal 7 has a new and efficient way of loading module and theme settings from the database. The new loader requires all settings to be stored in the current (serialized) format. This is all great, except when few mdoules forget to clear their settings after uninstall, settings which are not stored in correct format, these left overs causes a tummy upset for Drupal and cause PHP notices on your site.

Solution to such issues,

I found many answers in Drupal's issue queue posted by develpors that had encountered this after a recent site update/upgrade or module update/upgrade. For some a simple cache clear worked (Lucky people :-/ ), for some they had to reomve the cache directory in the Drupal's files folder. But there was no silver bullet for the problem. You see, the solution largely depends on which settings are left in the DB causing the isuue or rather by which module. In some cases it is possible that the settings causing the problem are from a module that is already enabled, but a few required settings are missing, in other cases it is caused by a theme or module you tried some months back which forgot to clear its settings and is now coming back and haunt you. 

Here are some common solutions that should work for you, or atleast you should attempt before you procede to next step,

1. Clear cache from UI or drush, for many people this works.

2. If you get WSOD in step #1, procced to MySQL console and try to truncate everything that starts with cache_<some-name>. If you dont want to truncate everything (there is no risk here, cache tables will be filled with cache entries again), try clearing only the cache table that is causing you the problem ex: Views, Ctools, etc. Along with that cache table, also clear cache_bootstrap.

3. Check your status reports page to find if there are any environment issues, perhaps a PHP version issue with the new environment.

4. For errors coming from in views module, you can try to import export your custom views from a dev or staging enviroment.

5. Handy modules to check the varibales in your DB,

The fun part,

If all else fails, we need to go in and get our hands dirty. You will have to hunt for the ugly variables and squash them on by one. Here is how you start, for every error, we get the offset & the total length of the serialized string. We use the second byte of this error to scan the variables table for a variable which matches the legth of our serizlied string. 

SELECT name, LENGTH( value ) , value
FROM variable
WHERE LENGTH( value ) = "<byte size>"

This query will provide you with a result, listing the varibale name, its length and seriazled string. If its a varibale from an unused module, its safe to delete it,

DELETE FROM `variable` WHERE `name` = '<varibale_name>';

If its from a module that is enabled and needed on your site, procced to the module config page and enter the valid config value there and save the form. This should correctly insert the values again in the variable table.

And Huzzah !!



on 26 Feb 2014 by
Swarad Mokal
Solutions Architect, Sr. Drupal Developer, Team Lead

All men dream but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity; but the dreamers of the day are dangerous men, for they may act their dream with open eyes to make it possible.