Thread

base64 decoded, that string is s👎”“;

So an empty serialized string. Somewhere the site preferences are getting wiped out.

This appears to be happening after the first large block of converting DB to UTF8.

After I started the upgrade, I just spammed the refresh button on the exp_sites table through my mysql client. Initially I see the serialized data get converted to larger base64 decoded strings, and then just after the first set of converting to UTF8, all the fields are reset to the above empty base64 encoded string. The “ud_next_step” value in the config.php file *I think* says database cleanup, but this happens very quickly to tell exactly.

The issue is occuring somewhere in ud_200.php, specifically this loop:

foreach($query->result_array() as $row)
        {
            foreach($row as $name => $data)
            {
                if (substr($name, -12) == '_preferences')
                {
                    // base64 encode the serialized arrays
                    $data = strip_slashes(unserialize($data));
                    
                    // one quick path adjustment if they were using the old default location for template files
                    if (isset($data['tmpl_file_basepath']) && trim($data['tmpl_file_basepath'], '/') == BASEPATH.'templates')
                    {
                        $data['tmpl_file_basepath'] = EE_APPPATH.'/templates/';
                    }
                    // also, make sure they start with the default cp theme
                    elseif (isset($data['cp_theme']) && $data['cp_theme'] != 'default')
                    {
                        $data['cp_theme'] = 'default';
                    }
                    // new name for a debugging preference
                    elseif (isset($data['show_queries']))
                    {
                        $data['show_profiler'] = $data['show_queries'];
                        unset($data['show_queries']);
                    }
                    // docs location
                    elseif (isset($data['doc_url']))
                    {
                        $data['doc_url'] = 'http://ellislab.com/expressionengine/user-guide/';
                    }
                    $data = base64_encode(serialize($data));
                    $row[$name] = $data;
                }
            }

... to make matters worse, after many many testing attempts where I would reset both the database and system files back to pre-upgrade backups, it randomly worked. Nothing changed, nothing was done differently. It just decided to work.

I have seen a number of attempts where it would randomly fail, usually complaining that a certain database field could not be found.

The usual outcome would be that it says it completes, but with the wiped out preferences. This one last time it just worked.

I’m really confused and really frustrated by this experience.

Thanks for the update, Ian. I’ve sent you a PM.

Was there a resolution to this issue? I’m having the exact same problem.

Last I’ve heard is that it’s potentially an out of memory situation that casuses the 2.0 upgrade to run in a loop. On my next upgrade try I’m going to experiment with upping the max memory value for the script before doing the upgrade. If you get a chance to try that, please post back here if it works or not.

Hi Sean,

Along with upping your memory your server’s PHP max_execution_time may also be set too low, forcing the upgrade script to end prematurely. Check with your host about increasing this value from the typical default of 30 seconds.

Let us know how you get on

I’ve come back to testing the 1.6.6 to 2.1.3 upgrade process, but unfortunately the problem remains even after upping the max memory and max execution.

Here’s how I set these values:

created /system/.htaccess:
==

php_value memory_limit '512M'
php_value max_execution_time 512

==

I also added these two lines to the top of /system/installer/updates/ud_200.php:
==

ini_set('memory_limit','512M');
set_time_limit(512);

==

I’m thinking that should be quite large and long enough…. Unfortunately the upgrade process still fails in the same way, by looping through (at least) the do_update method twice.

This is especially noticeable, because on the second loop through I get the ‘you must place all your template files in the templates/XXX/ directory’ warning. This does not occur the first time around, because the files are located there. During the first loop, they get moved as expected. And then of course on the second loop, they are missing. After ‘ignoring’ this warning, that’s when the preferences get wiped out as the script continues to the next section of script ~line 93.

I have a 17.7 MB exp_channel_data table, so if there’s a memory issue, this is what the root of it would be. But why did setting the memory limit to a very high value not fix it?

Definitely interested in any feedback / insight you all may have…

Ian,

Can you move that htaccess from system/ into your root please and remove the single apostrophes. 128M should be enough

php_value memory_limit 128M
php_value max_execution_time 512

Then to confirm this has taken login to your control panel open up PHP Info

Control Panel Location:  Admin > Utilities > PHP Info

look for memory_limit and confirm this is at 128M

That did seem to solve the issue.

Interestingly, the 2.2.0 updater updates from 1.6.6 to 2.2.0 (almost) flawlessly, and does not seem to be affected by this issue. (It does have a different unrelated issue, but that is not blocking me from performing the upgrade when I need to.)

So, it looks like this problem is resolved in 2.2.0, or by upping memory_limit. Thanks all.

Hi, Ian -

Glad to hear this is finally working for you!  If anything else comes up, please do let us know.

Sean - I’m going to close this off as it has gotten a bit long, but if you are still running into this, please start a new thread and we’ll be happy to assist.

Thank you!