Attempts to update a D6.16 site to D7

Tagging for upgrade path.

Sorry! - stupid mistake. I didn't have PDO enabled in my PHP.ini.

Anyway, fixed that and on to the next error:

On visiting localhost\drupal\update.php, it now shows an orange box with:

Error

* Notice: date_default_timezone_set(): Timezone ID '3600' is invalid in drupal_session_initialize() (line 211 of C:\WebStuff\www\drupal\includes\session.inc).
* DatabaseSchemaObjectExistsException: Table date_formats already exists. in DatabaseSchema->createTable() (line 605 of C:\WebStuff\www\drupal\includes\database\schema.inc).

The website encountered an unexpected error. Please try again later.

During a normal installation there is a step that checks that the system meets Drupal's requirements. Should not this also be run at the start of the upgrade process to catch problems like PDO not being enabled?

Edit: I see that in Update.php

368 // Check the update requirements for Drupal.
369 update_check_requirements();

Looks as if this does such a check. Perhaps not early enough in the process?

Update.inc makes a load of changes to the D6 database. These include creating indexes, tables and fields:

327 db_add_index('system', 'system_list'
329 // Add the cache_path table.
335-7 db_add_field('url_alias', 'source' & 'alias'
339-50 db_add_field('menu_router', 'delivery_callback' 'context' 'tab_parent' 'theme_callback' & 'theme_arguments'
352 // Add the role_permission table.
376 db_add_index('semaphore', 'value'
462 db_create_table('date_format_type'
463 db_create_table('date_formats'
464 db_create_table('date_format_locale'

All of these are done without checking whether they already exist - and some of them do exist in my D6 database (e.g. tables date_format_type, date_formats and date_format_locale - presumably added by the Date module).

There is also the problem that, if a user has attempted to run update.php, gets some sort of problem reported, fixes the problem and then tries again, these changes may have been applied the first time round. They will then fail on the second attempt.

It therefore seems good practice to check whether tables exist and drop them (as is already done for example with the "queue" table in lines 511-13) and to drop fields or indexes before trying to create them.

Here is a patch which does that (this is a unified diff created by TortoiseMerge and converted from Windows CRLF format - not sure whether that is an acceptable format here).

With that patch applied, the update runs through.

The first screen (entitled "Drupal database update") (see screen_shot1) shows the orange timezone error message twice. Subsequent screens show it once. The final screen, shows a yellow message stating that the timezone has been updated to the default (see screen_shot2).

In the variables table in the Drupal 6 db "date_default_timezone" has the value "i:3600". In a fresh Drupal 7 install, this variable has the value "s:13:Europe/London" (which is the time zone I selected during the installation). Presumably the D6 timezone code is no longer understood by D7 - hence the error. But it seems to be fixed by the update - so, after the update, the value is "s:13:..." as above (which it presumably gets from my Locale since I wasn't prompted for it).

The issue is therefore, that this error message needs to be suppressed. I'm afraid I have no idea how to go about that!

Thanks for the hints. I have re-rolled the patch against HEAD and, hopefully, the format is correct this time.

I don't seem to be succeeding in producing a patch! Is there a Windows user out there with who can suggest what I am doing wrong.

I read the stuff from posts on Drupal.org found by searching for "Windows diff" or "Windows patch" and thought I was following the advice contained therein. The specific instructions in "Create patches on Windows" pointed at by scor use CVS.exe - which does not exist on my system (I am using TortoiseCVS).

So, what I have done:

- used either TortoiseMerge or WinMerge to compare the original update.inc and my modified version
- saved a patch with the type set to "unified" and the context to 3 (the options are 1, 3 or 5).
- put the resulting file through a text editor (EditPad Lite) to change line endings to Unix style LF only and the encoding to UTF8
- uploaded the resulting patch file - which, it seems, does not work in either case!

Try again!

OK, re-rolled it from root

Yes it was the right file, I just tried rolling it again with the same result.

To be clear:

1. In Windows Explorer, I navigate to my <doc root>/drupal7 directory - which is where index.php lives
2. I right click on the drupal7 directory and select CVS - Make patch ... from the context menu
3. This brings up a Tortoise CVS - Make Patch dialog which lists one file, update.inc with Status 'Modified'. I click [OK] and, it goes away and fetches the laest version of the file from the repository, generates the patch and I get a File save dialog to save a file called "drupal7.patch"
4. I save and open this file in EditPad Lite, re-save it with Unix style line endings and UTF8 encoding, rename it and attach it to my post on Drupal.org

So what am I doing wrong?

Apart from the patching problem, if I run the D6 -> D7 update on a patched copy of Drupal 7 Alpha 4 it works (or at least I get a site I can open successfully and view my data). If I run the same update on patched HEAD, when I attempt to open the resulting site I get:

Error

Error message
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'stuart_d6.drupal6_block_node_type' doesn't exist: SELECT module, delta, type FROM {block_node_type}; Array ( ) in node_block_list_alter() (line 2287 of C:\WebStuff\www\drupal7\modules\node\node.module).

The website encountered an unexpected error. Please try again later.

So I suspect that something committed to HEAD since Alpha 4 has broken this. I will attempt to find out where this happened and raise an issue there.

Maybe the problem is converting the patch file UTF8. Ones I have checked in other issues appear to be ANSI encoded. So lets try an ANSI version.

OK, so I have edited in the includes/ by hand - lets see if it likes that

Wow - it worked!

Thanks for your patience - and you are probably right about starting new issues. I think there are four seperate issues that have come up here:

• Attempting to run localhost/drupal/update.php without PDO enabled in PHP.INI caused WSOD. It looks as if the requirements check is too late too pick this up. The error occurs because including database.inc at the start of the file atempts to defines a class extending PDO. Raised in #793388: Attempting to update D6 -> D7 without PDO enabled causes WSOD.
• The attempts to create indexes, fields and tables that may already exist - i.e. what this patch fixes!. Raised i #799982: Updating D6 -> D7 fails if the D6 site has Date module applied
• The timezone variable causing an orange error report that is later fixed by the update process. This isn't fatal, but I think it would be better to suppress the error message.
• The problem with block_node_type in #18 that seems to have been introduced since Drupal 7 Alpha 4. Raised in #797668: Update fails on node_update_7006.

More appropriate title.