drupal 5.12 -> 6.8 and i lose administer by

By kvarnelis on 21 Dec 2008 at 00:26 UTC

Well, it looks like since Drupal 6 is finally (almost) ready for production sites, what with the release of views and an alpha of panels, so I thought I'd try out upgrading my site from 5.12->6.8.

I did the usual, e.g. turning off all non-essential modules before the upgrade, turning to Garland and starting up little by little.

I am able to run everything, clean urls, able to go to any admin task, post content, permissions seem fine, I've cleared the caches, etc. etc. Going to administer by module is fine, just administer by task is weird. I can see "user management" and the tasks under it, but that's all. Where are the other tasks? It's not the typical status update failure since that reports back fine, it's just that somehow the rest of the tasks are not appearing.

Comments

Run update.php again and

cog.rusty commented 21 December 2008 at 12:28

Run update.php again and make sure that it completes successfully and doesn't end up with a timeout or a blank page.

If it doesn't complete successfully, check http://drupal.org/requirements for Drupal 6, especially the increased requirements for php memory in case you need to do something on the server, and try running update.php again.

alas...

kvarnelis commented 21 December 2008 at 16:19

Thanks for responding! I know Drupal likes its memory so I upped it from 32M to 128M, but it didn't help. I ran update.php again and it went fine. Actually I haven't run into problems once with update.php. It says always it completed successfully. Since installation, I have installed views, cck and run update.php each time and it says it completed successfully as well. Another install I've brought over to 6 doesn't have this problem. I'm puzzled.

Have you checked whether

cog.rusty commented 21 December 2008 at 16:37

Have you checked whether your 128M setting is actually used or ignored, by checking how much php memory is reported in the admin/reports/status page?

Yes, all 128M are seen by

kvarnelis commented 21 December 2008 at 18:54

Yes, all 128M are seen by Drupal.

Are you using a custom theme

kjl commented 21 December 2008 at 16:42

What happens if you switch to a different theme?

As I mentioned above, I

kvarnelis commented 21 December 2008 at 18:55

As I mentioned above, I switched to Garland (for the record, I have also tried Pushbutton and Zen) before the update. No dice.

Also just went in and

kvarnelis commented 21 December 2008 at 19:08

Also just went in and replaced all of the modules with fresh code. Hit update.php again. No improvement. Everything else seems to work on the site, just the admin by task page doesn't build properly.

still debugging

kvarnelis commented 21 December 2008 at 22:27

For kicks I took another dump of my database (not the same dump, an earlier one) and plugged it into the Drupal 6 code. Interesting, this time when I first go to update.php, I get...

* user warning: Table 'v3.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('search404') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/v/includes/menu.inc on line 315.
* user warning: Table 'v3.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('search404') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/v/includes/menu.inc on line 315.
* user warning: Table 'v3.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('search404') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/v/includes/menu.inc on line 315.

This could be the problem? Maybe I missed that last time? Not sure what it does...
I did have search404 module installed, so it seems related.

Now mind you this is at the top of the update.php page, BEFORE I have run the update. After running the update, I get

user warning: Table 'actions_aid' already exists query: CREATE TABLE actions_aid ( `aid` INT unsigned NOT NULL auto_increment, PRIMARY KEY (aid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in /Applications/MAMP/htdocs/v/includes/database.inc on line 515.

No surprise as I had actions installed prior to the update.

Afterwards, Drupal threw a few errors as below until I selected a properly working theme.

* warning: array_map() [function.array-map]: Argument #2 should be an array in /Applications/MAMP/htdocs/v/modules/system/system.module on line 975.
* warning: array_keys() [function.array-keys]: The first argument should be an array in /Applications/MAMP/htdocs/v/includes/theme.inc on line 1760.
* warning: Invalid argument supplied for foreach() in /Applications/MAMP/htdocs/v/includes/theme.inc on line 1760.

With Garland selected, those go away.

All is well in this install too although again curiously the Administer-by-task menu is still incomplete, delivering exactly what it gave me earlier.

Also the menu.router table is definitely there now...

The menu router table was

kjl commented 22 December 2008 at 04:05

The menu router table was introduced in Drupal 6, so it's not significant that a d6 module was causing that error to appear when you reverted to a d5 db. The other errors regarding system and theme.inc also relate to a difference in the way regions in themes are registered, I think. So you'd expect to see those errors.

The only suggestion I can think of is that you upgrade from 5.12 to 6.0, and then 6.0 to 6.8. It's a total supposition, but maybe something is broken in the direct upgrade path from 5.12 to 6.8.

Just to clarify, although the links are missing, you can still access the various admin pages that should be linked from there, right? That would suggest the menu tables in the DB were successfully upgraded, and I would guess the problem is happening in the theme layer.

This problem is with the

Haggle commented 23 December 2008 at 08:33

This problem is with the latest patch and not with the 5-6 upgrade.

http://drupal.org/node/347296

The page you linked to

kvarnelis commented 23 December 2008 at 14:09

The page you linked to discusses the admin screen blank failure mode.

I don't get a blank screen, I get a fully rendered page with blocks, proper code that closes properly but only gives me the user configuration set of tasks. The administer-by-module page renders correctly, no problems whatsoever.

It's only the administer-by-task page that doesn't work.

Figuring that maybe even Garland is too much, I downgraded to Bluemarine and even there we have the same problem.

I will try this later, but

kvarnelis commented 23 December 2008 at 14:10

I will try this later, but yes, every page works, all the admin links work, and again, the admin-by-module page works. It's JUST admin-by-task that doesn't work. Only that one page. And even then, it partially works...

tried again

kvarnelis commented 28 December 2008 at 15:22

Ok, I tried again.

Same result.

I've disabled any blocks besides navigation, contributed themes, and modules. We're running on Garland and a default set here, folks.

I check to make sure everything is working in 5.12. Yes, it is.

I throw away the entire directory, install 6.0 (or 6.8).

I IMMEDIATELY call update.php

At the top of the page generated by update.php (that is, before I've RUN the updates), I get

* user warning: Table 'stinky.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('search404') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/stinky/includes/menu.inc on line 315.
* user warning: Table 'stinky.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('search404') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/stinky/includes/menu.inc on line 315.
* user warning: Table 'stinky.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('search404') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/stinky/includes/menu.inc on line 315.

Maybe I should try again with menu block off? It's curious that it's mentioning the search404 module which I had installed I've run out of ideas here. I don't know that much about Drupal's workings, but I have noted that the menu_router table contains information about the admin-by-task page.

I then run the updates. The only error it throws is

I shouldn't worry about that, right?

Then, whether I installed 6.0 and went up to 6.8 or just went to 6.8, regardless, I get a broken admin-by-task page that renders (not an out of memory error) but ONLY shows the User configuration settings. The footer is rendered so it's not breaking half way through.

Everything else works and this is a relatively big site. Now I could just chalk it up to Drupal-upgrade-weirdness and run with a broken admin-by-task page, but I'm concerned that in the future this will come back to bite me.

Is there some way to force a rebuild of the menus associated with that page?

http://www.varnelis.net

out of paranoia that it was

kvarnelis commented 28 December 2008 at 18:36

out of paranoia that it was search404 module doing this, i uninstalled it and, for good measure uninstalled actions module too to avoid any problems.

running update.php to 6 now resuls in
* user warning: Table 'last2008.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('favicon.ico') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/breaky/includes/menu.inc on line 315.
* user warning: Table 'last2008.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('favicon.ico') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/breaky/includes/menu.inc on line 315.
* user warning: Table 'last2008.menu_router' doesn't exist query: SELECT * FROM menu_router WHERE path IN ('favicon.ico') ORDER BY fit DESC LIMIT 0, 1 in /Applications/MAMP/htdocs/breaky/includes/menu.inc on line 315.

but problem is same as before. nothing better.

The table menu_router was

cog.rusty commented 28 December 2008 at 19:01

The table menu_router was introduced for the first time in Drupal 6 and didn't exist in Drupal 5. Normally, the D-6 update.php should just create that table, not complain about its absence.

You are saying that update.php itself produces the error messages? Or do they come after that? Update.php shouldn't expect to find the menu_router table in a D-5 database. So, either it thinks that it is already a D-6 database (because or wrong version numbers in the system table) and doesn't try at all, or it fails somehow and doesn't complete.

Is that a single-site installation, or some kind of multisite with prefixes and shared tables?

Exactly, update.php produces

kvarnelis commented 28 December 2008 at 21:00

Exactly, update.php produces the error messages.

The installation is from a multisite, but there are no shared tables, no prefixes.

It's just the code (all of it being 5) that is being shared.

Sorry if I wasn't complete

kvarnelis commented 28 December 2008 at 21:35

Sorry if I wasn't complete before... The initial load of update.php does NOT produce the error. It is only when I hit continue. Then we get the error at the top of the page that allows you to select the modules to update.

Another site that I loaded in from the same installation (e.g. different database, but same code) produced the menu router error in the same manner BUT that site seems to work fine with admin-by-task fully rendered.

Could someone comment on

kvarnelis commented 6 January 2009 at 16:52

Could someone comment on what generates the admin-by-task page and what generates the admin-by-module page? Is there perhaps a table I could repopulate with data from another install? A cache to flush, a table to empty?

I've looked around and can't seem to find anything that could be causing this.

http://www.varnelis.net

the page is generated

kjl commented 6 January 2009 at 21:55

the page is generated starting line 12 of system.admin.inc in the system module, where a function queries the menu_links and menu_router tables in the DB.

Simply visiting the menu admin page will flush the menu cache.

By the way, when you do the

kjl commented 6 January 2009 at 22:30

By the way, when you do the DB upgrade with update.php, if the entry in the system module dropdown selector is greater than "6000" that probably means cog.rusty is right and the wrong drupal version is stored in your original DB. you could try setting the system upgrade to 6000 or earlier.

AHA! I solved this thing.

kvarnelis commented 7 January 2009 at 20:29

AHA! I solved this thing. FINALLY.

Even after running the menu rebuild module, I had no success. Finally, I realized, my menus are an awful mess. I went in and deleted my primary links, also reset all of the menus and deleted any new ones that existed. That did the trick. Update worked without problems. Apparently the menu tables can become corrupted. Any thoughts about how to really bring them down to zero and rebuild?

I had more trouble until I

kvarnelis commented 8 January 2009 at 03:50

I had more trouble until I finally figured out that the problem is that Drupal 6 builds the admin-by-task *page* from the navigation *menu*. So if you have taken out the various tasks from the administer heading, it will say there are none available.

This was not, as far as I recall (I'm too lazy to start up Drupal 5 again) the case in Drupal 5 and I don't believe it is documented anywhere.

From an information architecture standpoint this is counterintuitive. I've opened up an issue about this, I'll file it there.

Another solution: update missing router_path

cquincy commented 26 December 2012 at 21:21

I have been struggling with the issue for a while, so I wanted to share my solution in case it helps someone else. I tried all the suggested solutions including clearing all the caches manually, deleting the Navigation menu and none of them worked for me. We have drupal 5 sites that were upgraded to drupal 6. After digging around in the source code and database I noticed that all the menu_links.router_path fields were null. Updating the router_path to the same value as the link_path did the trick and now the admin page is rendering again.

update menu_links 
set router_path = link_path where (router_path is null or router_path = '') 
and module = 'system' and menu_name = 'navigation';