Upgrading from D5 -> D6 url_alias field errors prevent upgrade, manual bootstrap necessary

Suffering the same problem.

4.7 -> drupal 6.
All optional modules disabled
Site off-line
pushbutton theme
Doesn't matter whether update_free_access is true or false.

Did you visit any other page before or after going to update.php?

If you don't run it then do something else, or do something else before you run it, then you'll get those errors because you're bootstrapping drupal before you've upgraded. This is normal, if not pretty.

I don't understand why this issue was renamed and re-prioritized. The issue with language fields in url_alias is still present. I documented this at http://drupal.org/node/347942#comment-1163535 . The url_alias field requires manual language field addition to even get to the upgrading, which will then harmlessly complain that the field already exists.

I did the upgrade process correctly, path was *disabled*.

I think the problem is that even when going straight to update.php on a fresh upgrade, path processing for the site's default frontpage occurs since $_GET['q'] is empty, which means that if you have a 'Default front page' set you will get the aforementioned warning and be unable to update without manually adding a db field as described by cha0s. One remedy would be to include in D5->D6 update instructions to empty the 'Default front page:' in Site Information and then set it back after running update.php.

Also...if

function drupal_init_path() {
  if (!empty($_GET['q'])) {
    $_GET['q'] = drupal_get_normal_path(trim($_GET['q'], '/'));
  }
  else {
    $_GET['q'] = drupal_get_normal_path(variable_get('site_frontpage', 'node'));
  }
}

instead looked like...

function drupal_init_path() {
  if (!empty($_GET['q'])) {
    $_GET['q'] = drupal_get_normal_path(trim($_GET['q'], '/'));
  }
  elseif (!strstr($_SERVER['SCRIPT_NAME'], 'update.php')) {
    $_GET['q'] = drupal_get_normal_path(variable_get('site_frontpage', 'node'));
  }
}

then it would prevent path processing of the front page whenever update.php is run. I don't know my way around path.inc, so I don't really know what problems a change like that could bring about but it worked for my test upgrade.

On a side note, you need E_ALL or E_USER_WARNING level error reporting and display_errors = stdout in order for this to prevent update.php from running successfully because of a warning like

Warning: Unknown column 'language' in 'where clause' query: SELECT src FROM url_alias WHERE dst = 'node' AND language IN('en', '') ORDER BY language DESC in C:\Inetpub\wwwroot\drupal6\includes\database.mysqli.inc on line 164

so that might explain why it is not a more common problem...but it is still a problem. I was able to replicate with a fresh 5.15 install unable to update to 6.9 because update.php would error out.

This is indeed a real bug. If there is a single entry in the url_alias table, Drupal will throw errors upon trying to upgrade to Drupal 6. cYu got it correct in #5 that this is caused by a call to drupal_get_normal_path(), which ultimately will try to lookup a URL in the url_alias table (but only if there are any records in it). Since the language column does not exist, it's going to throw a warning. Worse yet, since this error will break JSON calls, Batch API will break and updating to Drupal 6 is impossible.

This patch is a modified version of #5, where instead of checking for update.php, it checks for the MAINTENANCE_MODE constant. This does not apply to Drupal 7, since the url_alias table does not contain any schema changes between 6 and 7.

Here's the error function backtrace:

1	0.0046	{main}( )	../update.php:0
2	0.0093	drupal_bootstrap( )	../update.php:608
3	0.1632	_drupal_bootstrap( )	../bootstrap.inc:971
4	0.1775	drupal_init_path( )	../bootstrap.inc:1055
5	0.1776	drupal_get_normal_path( )	../path.inc:21
6	0.1776	drupal_lookup_path( )	../path.inc:131
7	0.1780	db_query( )	../path.inc:80
8	0.1782	_db_query( )	../database.mysql-common.inc:42
9	0.1788	trigger_error ( )	../database.mysql.inc:128

To reproduce:
1. Install Drupal 5
2. Enable path module.
3. Create a story node and give it a custom path.
4. Upgrade to Drupal 6.

You will receive a warning on update.php preventing you from updating.

Hmm, sorry I got a previous patch uploaded. This one has quotes around 'MAINTENANCE_MODE'.

That patch worked for me, and changing to check 'MAINTENANCE_MODE' is a good change. Only problem I see is that previously $_GET['q'] always left that function being set to something, so functions like batch_process() in form.inc could use it without checking if it was set. Now, though, places like that will throw a notice for undefined index. Setting $_GET['q'] = '' for maintenance mode pages fixes this for me.

Bump! I'm wondering if we need to provide some test for this, if so, could someone advise where to create it? Would that be in includes/tests ? It apears as of now that directory is empty... any pointers appreciated, thanks!

For those who just want to fix the problem and do the upgrade, running this SQL should get you past this error during the upgrade process
ALTER TABLE url_alias ADD `language` varchar(12) NOT NULL default ''

Otherwise, my vote for getting it fixed.

@Agileware: Thanks. That's exactly what I need to go fast through the update.

My vote also to solve this, as otherones may experiment this problem further.

This patch is a modified version of #5, where instead of checking for update.php, it checks for the MAINTENANCE_MODE constant. This does not apply to Drupal 7, since the url_alias table does not contain any schema changes between 6 and 7.

While this might not lead to any problems in 7, I'd still say it is a bug that drupal_get_normal_path(variable_get('site_frontpage', 'node')); gets called when at update.php, install.php, cron.php or any other scripts run out of the root, so the patch could apply to D7 as well.

Subscribing. Ran into this when trying to upgrade one of my sites from 5 -> 6. Manually applied the changes from cYu's patch in #9 and this fixed the issue for me.

Changed the priority to critical: not being able to upgrade a fairly standard D5 site to D6 seems critical to me.

can somebody plese fucking tell where to put this file, I mean i know where , but should i add it at the end or replace the existing text in path.inc

why nobody thinks abot newbies, it is like I dont fucking bother to explain, learn php

Umm...if you are planning on hacking core, then yes...please do learn PHP.

If during a 5 > 6 upgrade you are seeing this error, one way to get around it without changing code is to perform the step mentioned in a linked issue above just before running update.php,

QUIRK: add a language field to the url_alias table:
I don't know what's up with this, but I had to do this to make everything work. Using phpmyadmin (or similar), create a field 'language' (VARCHAR length 2) in the url_alias table. I have not filed a bug against this (or checked if it's already been reported), but it was necessary to upgrade for me. You'll get a (harmless) warning later about how it tried to create the field and it already existed, you can ignore that.

Another way would be to relax your error reporting settings, taking away E_USER_WARNING or have your error messages not print to screen.

And easy on the dirty pirate hooker language...

Did not do anything

I get these errors

* user warning: Table 'altermed_optimizacija.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('node') ORDER BY fit DESC LIMIT 0, 1 in /home3/altermed/public_html/optimizacija/includes/menu.inc on line 315.
* user warning: Table 'altermed_optimizacija.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('node') ORDER BY fit DESC LIMIT 0, 1 in /home3/altermed/public_html/optimizacija/includes/menu.inc on line 315.
* user warning: Table 'altermed_optimizacija.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('node') ORDER BY fit DESC LIMIT 0, 1 in /home3/altermed/public_html/optimizacija/includes/menu.inc on line 315.

That is an unrelated issue.

If you google your error message you will come across http://www.drupalace.com/blog/2009_02_02/checking_out_drupal_6_update_up... which suggests the error comes from:

Among the errors, it was clear that D6 was choking while updating certain modules, especially CCK, Views, Image, Nodereference, and Paging. My leaving these modules enabled may or may not have been a problem, but actually reading the update directions carefully reveals that upgrading D5 modules to the latest version is a key step in updating to D6.

sorry all my modules are upgradet, i used update module just for that purpose

and i disabled all custom modules that i uploaded myself, set the theme to bluemarine and put the site offline mode

i just cant do it

This is definitely a problem, however, the supplied patch does not work.

Update: I can verify that the line

ALTER TABLE url_alias ADD language varchar(12) NOT NULL default '';

worked.

Patch at #9 worked for me upgrading to Drupal 6.15. Isn't about time it got committed?

Has this been fixed in the latest D6?